Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: RFC: rebol-framework / list-view

From: brett:codeconscious at: 13-Nov-2002 11:07

> in your menu (tree) is - edit Contract, new Contract. Well, so you want > to edit last contract from company X - how are you supposed to do that? > You intuitively go and select Edit Contrac item - the only field which > waits for you on the screen is - Contract number. As I said - it is > stupid, dumb, screwed. SAP offers reports - but noone will run XY sec
:^)) Yes, I've worked on similar systems. Such things belong in history. A colleague and I had the opportunity to create a data-centric interface with a particular system. We opted to let users navigate the data visually (of course there were some advanced filtering tools). From a list of records - double click the desired one - and they you have the details of the information in its original input layout (though with uneditable fields grayed). The list was not simply a navigation tool only, it was a useful tool in its own right because it contained totals. So by using a filter - people could do ad-hoc online enquiries - drilling down for the information. I'm sure lots of developers have seen and programmed such systems today. The users learnt this way of dealing with their data in a single 30 minute training session, in fact they were telling us how it would be used after about 15 minutes. Quite a constrast to what I heard before. Another data-centric system I built for property managers also had similar results - people understood intuitively how to operate it - which cut my training requirements :^)
> I am not sure it is usefull to have list of different BOs mixed? If I > know I am looking for a Company, I will select company, and then get > list-view related to company information ... now what domain specific > info related to company can I be interested in? - Offer, Confirmation of > Order, Order, Invoicing, etc. - but only at ONE of them at the time -
In the system I referred to above, we had a list (grid) of mixed transactions. When viewed all together and ordered in date order they provided a comprehensive transaction history. They could be filtered on type or by party/entity. So some columns were available across all transaction types, some were not. Where a transaction had no information in a particular column - it was left blank. I think people do this sort of thing naturally on paper. You can imagine that this was supported by some sophisticated programming - and it was. I user might imagine they were dealing with a single part of the system - under the hood there were all sorts of supporting components.
> >Any other ideas? Robert
You could specify a list of fields that must be shown [name addresss contact-person fax ...]. This list could also specify the order you want them presented in. You could allow this list to be selected from a union of the available fields across your records - like we did in the system I described above - and in this case to leave blank those cells that are not applicable to the record. Alternatively you could mandate that this list is to be selected from the intersection of the available fields across your records, making your display code somewhat easier perhaps. Our system was far less dynamic than the one you are working on so the number of possibilities we had to deal with was finite :^) A second block could specify your column widths - no more ideas on that from me though :^) Regards, Brett.