[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.
