UI Design: Edit then List vs List then Edit

Today I was thinking about the way I build UIs (List the Edit) and the way most people I know build UIs (Edit then List) and the relation that the way you build you UI has with the way you store the data you manipulate in you UI.
So I wrote an article about that in my blog: http://luxspes.blogspot.com/2006/04/ui-design-edit-then-list-vs-list-then.html
And would like to hear opinions about it... and perhaps get ideas to build some kind of framework on top of NHibernate that make it easier to manipulate persistent objects

I "created new UI pattern names" to describe the different way a datamanipulating UI is tipically created... because I could't find an "official" name for this two ways of building UIs, I would love to hear of any book that deals with this topics and that gives this "patterns" an official name... of course, it is also possible that this shouldnt be considered patterns... in that case I would love to hear recomendations on how to call them.

I am also thinking about writing an small article about this in the Wikipedia, but for that I need sources to backup my article, and util now, i have not been able to find any... so I would appreciate any help on that...

Answer this question

UI Design: Edit then List vs List then Edit

Srini111
http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnwui/html/iuiguidelines.asp sure sounds similar ...

Also you will find many business apps for the list then edit methodology as it often makes more sense and its a bit easier to do in a generic sense.

also

and perhaps get ideas to build some kind of framework on top of NHibernate that make it easier to manipulate persistent objects

see castle project .. They have already done activerecord on top of nhibernate and can dynamically generate list/edit screens for the activerecord classes.

Cheers,

Greg
MVP-C#
Michael Legner
Here is a little summary of the article:

When you build a "data oriented" aplication (your typical mostly CRUD application) the workflow goes more or less like this:

List then Edit
-You see a list of objects (for example the catalog of products in amazon)
-You select an object and a windows to modify appears in front of you (you Edit it, to modify it propertys, for example when you select a Contact to change its address in Outlook)

or perhaps the UI follows Edit then List:
-You see an empty and disabled window that could be used to edit an objects, the only buttons that work are "new" and "search"
-If you click "search" you are presented with a window to search (the List) after finding the record you want to work with, you click "accept" in the List window
-You return to the Editor window that now is enabled and allows you to edit the selected record.

Sometimes, both views (the List and the Editor) are visible at the same time like in the Two-Panel Selector pattern (there is a link in the article in my blog)

After describing this two "patterns" the article focuses on how the way we chose to organize data oriented UIs affects the services our persistency mechanisms need to provide....

Do you think I should add screenshots to make things more clear ...
(I dont know if there is much common ground on this subject)
ffattizzi
I think it dpends on how much experience the developer has in the field where his application will be deployed. Take for instance a warehouse where employees (pickers and packers) who need to keep the flow going, the "List then Edit" will be much more acceptable in such enviornment.
Don Lafontaine
So... no answers
bsierad
Hi!
Excelent example... and... would you say that most of the applications that you have built have been of this type Did you give this names (List the Edit) to this kind UI before reading this posts if not then what name did you give to this "pattern"
UI Design: Edit then List vs List then Edit

Answer this question