User:Luxspes/UI Design: Edit then List vs List then Edit

= Introduction = An UI that will be used to manipulate data can be built following several guidelines, this article firs explains the different ways the UIs are built, and then explains the way the elected pattern affects the persistence mechanism

List then Edit Pattern
In this "pattern" for UI structure, after the user selects an option in the menu he sees a window that allows searching with some controls (generally in the top of the window),and with some control in the bottom that represents the search results, then the user selects one of the search results (an object, or row if you prefer) and he proceeds to work (edit, modify) it, for that he opens a new window "the editor" (perhaps by doubleclicking the selected object, perhaps by clicking an "edit" button in the list window) in the editor he may modify the object being edited as much as he likes, and then click "save" if he wants to commit his changes or "cancel" if he wants to rollback them. If the user wants to create a new object, the list has a "new" button that also calls the "editor" so that the user can set the initial values for the fields before the object is commited to the database for the first time

Edit then List Pattern
In this other "pattern" for UI structure after we select an option in the menu we are right there in the editor, but all the controls that could allow us to modify the current object (or row) are disabled, because we haven't searched for any (or created a new one) from here the user can choose to create a new object that action has the effect of enabling all the control in the editor, or search for an alredy persisted object (or row) by clicking the "search button", that shows the search "list" window, in the top of that window there are controls to configure the search criteria, and in the top a control to represent the search results, from here the user can choose one of the search results (an object or row), and click on the "accept" button, which takes him back to the editor that now is displaying the previously selected object, here the use may choose to make some changes and click "save", or just cancel click "cancel" but actions have the efect of disabling the controls in the editor UI until the buttons "search" or "new" are used again.

Edit in List Pattern
When an application generaly follows List the Edit, sometimes, if the info in the selected object is very simple, the user may modify it right there, but for for objects with medium to complex (several fields, to one or to many relations with other objects) calling a window to modifiy the object is more comfortable for the user

Search in Editor Pattern
Some times, the developer likes to use the same UI to Edit and to Search, this works like some kind of "query by example", that is when user enters the editor, instead of being disabled an waiting for a click on the "new" or "search" button, the controls are enabled, and if the user writes some data in to them and clicks "search" the already persisted object (or row) that is more similar to the partial information already written in the editor is loaded. Sometimes there are many objects that match the query by example, here is when a navigator control can be a nice thing to have.

Master List, Detail Editor Pattern
This is also a very common configuration, both the list and the editor are in the same window, the list generaly in the top, and the editor in the bottom.

Persistence
Okey, until now I have exposed what I think are the some of the common "patterns" used to create UIs that manipulate data, now... what I find more interesting about this is the the way this "patterns" affect the way the data is stored or retrieved from persistence:


 * If we use Edit then List:
 * The Edit is displayed on the screen
 * The user clicks "search" and the search List window appears
 * The user configures the search criteria in the List window
 * The objects (or row) matching the criteria are shown in the List window
 * The user selects one of the matching objects and click in the "accept button" in the List window
 * We return to the Edit window, that now is displaying the selected object.
 * We can make changes to the current object by clicking "save" or click "cancel" to dismiss the changes, if we do either action the Edit controls are disabled and we again have to click "search" or "new" to work with an object
 * The problem here, is that the user might want to see the same search results he used the last time, but each time we call the search List window, we are creating a new object, and all of the configuration from the last time we called it is alredy lost (this disvantange has a "nice side", because we dont have to worry about showing "stale data" to our user)
 * Another disavantage is that maybe not all the controls we use to manipulate the data in the edit windows are "databindable" so we have to manually reset the state of the Edit window, and if we dont do it correctly we could have bugs that "transfer" information between edits. (First I edit John and set his age to 24, the I edit mary, and her age is also shown as 24, but her age is 56, and we had no intention of changing it)
 * If we use List and then Edit:
 * The list is diplayed on the screen
 * The user configures the search criteria in the List window
 * The objects (or row) matching the criteria are shown in the List window
 * The user selects one of the matching objects and click in the "edit button" in the List window.
 * The "Edit" window appears on top fo the List window, and is displaying the selected object.
 * We can make changes to the current object by clicking "save" or click "cancel" to dismiss the changes, if we do either action the Edit window is closed and we return to the List window
 * One of the advantages of this approach is that we don't have to worry about the "tranfer between edits" bug, because each time we call the Edit window, it is a new window, without any data ready to configure itself to match the data contained in the object we are going to edit.
 * Then problem of keeping the search results to reuse them is also automatically solved, because the search List window was never closed, it was there all time, behind the edit window.
 * The problem now is that some of data shown there may not be updated, or perhaps, it has data that has never been on the database, and that we do not want on the database, how can that be? well, we edited the object in the edit window, and the databinding ensured that the changes were written to the object before we clicked "save" or "cancel", if in the Edit window we clicked "save" then we don't have a problem but if we clicked cancel, now we need to rollback in memory changes and some of this changes could have modified relationships with other objects, or properties of the other objects, we could have created, deleted or updated a complex graph of objects "only in memory" and now, we need to rollback all this changes, if we are using an Object Relational Mapper (ORM) that supports this (like Apple's Enterprise Objects Framework) or a relational cache that allows for in memory transactions (like the .NET DataSet) we can solve this problem easily, but if we are using an ORM like NHibernate that AFAIK does not rollback in memory changes then you have a problem, you have to refetch the information from the database.

This seems like a big ommision from the NHibernate guys... but it isn't exactly so, everything I have exposed here, has been on the assumption that we are working in a "SmartClient" that holds local information, and Hibernate was born in "the web world" in the web, you "need" to refecth the information on each request and you dont really pass the object you are going to edit from the list to the edit, it easier, and more efficient to just pass the primary key, of course the problem there is that you can only do that with objects previously persisted in the database, if you object is new... well you don't actually store the information directly in your object, you store the information in the webcontrols, or in the querystring, and only, when you finally want to save, you extract the information from the webcontrols and write it in to your object (at least that was the way I did it in the Java world) the problem is that with the new JSF, or with the new databiding facilities of ASP.NET 2.0, you can actually bind you controls directly with you datasources... and then how will we rollback the in memory changes? should we build a framework on top of NHibernate, a kind of "in memory object context" that handles the commits and rollbacks in memory? and what about a list with an edit that has list that has an edit (complex nested interfaces) should the object relational mapper facilitate the building of this kind of UIs? or should a new framework deal with the problem of communicating the persistent objects with the UI? is using DTOs really the solution? if NHibernate can almost transparently persist objects to the UI, shouldtnt this other framework do the same to transparently present the object in to the UI without having to manualy create objects to do this job?

Other User Interface Patterns
Designing Interfaces