[REBOL] Re: RFC: rebol-framework / list-view
From: petr:krenzelok:trz:cz at: 13-Nov-2002 0:12
Robert M. Muench wrote:
>Hi, I'm interested in your opinion how the following challange can be
>solved:
>
>- A user can do a fulltext-search through all records.
>- As a result a list of all matching records are returned.
>- The list can include several kind of record-types
> (address, project, note).
>
Ah :-) Robert, if you wrote this mail because of my msgs at IOS
Messenger, well ... it was just an idea ... but I have already stop here
and explain:
My objection was as follows:
Building database (relational) stuff for quite some time, working
closely with end users, I observed one strange phenomenon. Ppl tend to
look for visual data representation. I will take our real-life
confirmation order example. What does SAP offers by default e.g. is
pretty stupid and it leads to pretty bad customs. In SAP, all you have
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
report to see list of contracts for company X. So SAP invented so called
Help Search
(translated from Czech lang term). It is multi tab dialog
box with various fields, one of them being Contract number .... so you
can type something like "123*", but it does not solve the situation
quickly. The proof of wrong aproach is tens of ppl each using various
paper-notebooks to keep track of various stuff themselves, on the paper ...
In our old system, what we offered was maybe more primitive, but it imo
follows user's thinking patterns in more close way. Simply said - show
list-view (grid) with usefull info, allow to switch index, let ppl
visually select - they know how to use mouser wheel, arrows, enter,
insert, delete and escape keys - clean, simple, fast. We also offered
our users various tree-views, but they were not so popolar as grid based
ones.
And now - don't ask me why - ask users :-) Of course, it is our
environment, so everyone of us could have different experience here ....
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 -
and here comes navigation - company ---> offer | order | invoice ...
etc. But once I get into context of company/invoices - I see just
invoices. So, I am not sure it is usefull to perform full-text search
and offer mixed list-view with different kind of info .... not for db
app .... maybe for some kind of knowledge base - yes ...
I hope others will comment too ... I am not the only developer coming
from XBase area here surely ;-)
>- Records have a different number of fields.
>- Records of the same type can have different number of fields.
>
tree-view or grid - I think we will not invent something revolutionary
here. Powerfull grid systems allow users to choose which table columns
they want to see etc.
>I now want to show a list to the user where he can pick a record. The
>selected record is than displayed.
>
>So what I want is a multi-record-type-list-view :-))
>
>The questions/ideas I have are:
>1. Foreach record-type get a list that defines the order of data-fields
> for the row.
>2. Find the highest number of data-fields from the records in the result
> set(that's already working).
>3. Somehow do a list layout and size the columns to fit the maximum data
> length.
>
>Any other ideas? Robert
>
not sure .... good points surely ... I will have to think about visual
data representation, but from what I know, I don't know if there is any
better way of how to visualise data to users, than what is typically
available in other environments ....
-pekr-
