[REBOL] Re: RFC: rebol-framework / list-view
From: petr:krenzelok:trz:cz at: 13-Nov-2002 7:03
Brett Handley wrote:
>>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
>
we allowed to press enter to edit the record, insert to insert new one,
delete to delete it, and escape to close the window - ultra fast ...
forget your mouse ;-)
> - 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.
>
a good ones! Powerfull grid system. Grid system we used was pretty
advanced too. You could specify headers, but also footers, multiline
rows, various designs, coloring for certain values. Users could
add/remeove columns, specify collumn order, width, etc ... and save
their set-up ....
Ppl have yet to learn, how ineffective is tree-view in that regard. The
whole Windows Explorer crap - how can anyone use it for navigation? It
is good for selecting path/context, but not as a data viewer ...
>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 :^)
>
of course :-)
>>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.
>
I think that it can be easily done for the same record structures. But I
had something slightly different in mind. Look at following screenshots:
http://www.robertmuench.de/rebol-framework-howto.html
Now as you can see, rotary button shows contact/company. But you can
enter whatever you want in the text field, so I tried "MikroTOP", name
of 'project item in RFM system. Now ask yourself - is that the case in
real-life, where you have your data organised? If you already know
MikroTOP name, you surely know what it relates to - it is a project. So
it was me who suggested Robert the ability to select "context" by rotary
button, and use it already as a filter - simply once I select "project",
all projects available should be listed. If there are other BO
structures related to the project, it should be somehow displayed. So if
I translate it into graph structure - I wanted following enhancement at
least:
- selecting particular context on the left (master) side, would alredy
provide grid/list of relevant items. Clicking upon one of them
would/could do something on the right (detail) side, e.g. bring "project
name" box in the middle of the pane, and then graph of relations would
be displayed. So if there is e.g. relation from company --> employee,
pressing employee box would bring it into the centre once again, and
left (master) side would list employees for certain = selected company
... The question is, if visual graph is any better than generating
buttons for above menthioned relations ("employee") Now:
1) it came to my mind just now drinking morning coffee, so don't count
on that :-)
2) I have no experience with graph structure, petri nets and the like ...
3) my POV can be affected by my experience in XBase/relational field,
and non-experience in distributed database systems, so I have yet to
see, what area is RFM better in, than traditional relational model,
expcept the fact, that your per-record-fields can vary ...
Anyway ... as for future IOS, I want to see repository based system,
roles, rules, workflow mechanisms and better scalability in low-lovel
(RMP protocol). It is not call to RT, just a hint of what will come
anyway, being done by RT, or user-base. I would welcome more ppl
participating on the idea of RFM, distributed databases, etc.
The first thing I want to understand is - why relational model is being
regarded as outdated by some of developers. I looked at Senteces
associative data model, it shows some promise, but I yet have to
understand, what is RFM better in than relational model ...
>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.
>
it could be done probably by inspecting repository of BOs and also
probably part of grid-system itself by default ...
-pekr-
