views:

114

answers:

5

I always have trouble designing the user interface when it come to manage a list of object.

For example, I need to manage a list of employees. At my work, we always switched between two method of managing the employees:

  1. Use a single split screen with the left part being the list of employee, and the right part being the place where you edit the employee. There is usually a toolbar (or ribbon bar) at the top to allow Add/Modify/Remove.
  2. Use a two windows approach: the first one is a full size list with the same toolbar at the top. When someone press a button (or double click an employee), it open a dialog that let you add or modify that employee.

While I prefer the 2nd approach, I don't have any UI expert reference to back my choice or to dismiss it.

Does anybody have any suggestion or references that would help me design a good UI for mananing a list of object?

+1  A: 

Dialogs are modal, and user-experience specialists generally frown on that. A split screen allows not only editing, but also very natural "perusal with all details" of one given employee [or other kind of object] (there may be more info about each than the bare list can usefully show); a button to "make this detailed-info editable" seems a very smooth, natural and seamless approach, without the unpleasantnesses connected with dialogs, popups, "tooltips" appearing on hover, and the like.

For a reference summary of UX criticism of modal operation, you might start at wikipedia and follow their links.

Alex Martelli
My opinion about the split screen is that it make it hard to know when an object is saved, since there is usually no save or no cancel button.
Pierre-Alain Vigeant
@Pierre - There are multiple ways to deal with this: 1. Show a modified indicator on the item; 2. have an Apply button; 3. implicitly save on navigating to a different item. (Or any combination of these)
Franci Penov
I would definitely recommend some visible indication of "object was modified" -- e.g. a different background, or something more obtrusive yet -- AND apply and cancel buttons. I'm more hesitant on auto-apply (on human-factors grounds).
Alex Martelli
A: 

I've used the "email client" layout with some success. The left hand side of the screen contains navigation elements (analogous to folders in an email client); the right hand side is divided into top and bottom in a split window, with the top containing a list (e.g. of employees - analogous to a list of emails) and the bottom containing a form (consisting of tabbed pages) to edit selected items in the list (analogous to a single email which you are composing or viewing). The email client layout has the major benefit of familiarity - almost everyone uses email! And the major email clients all follow the same layout, reinforcing the familiarity benefit.

Vinay Sajip
+2  A: 
Alex Papadimoulis
Glad to get a comment from someone like you M. Papadimoulis. In some way, the "dialog" that pop don't actualy need to be a dialog. It can be another window. But that could result in many employee window open.
Pierre-Alain Vigeant
This is very nice, and reminds me of "Natural Language Output" from Alan Cooper's UI book _About_Face_.
Michael Petrotta
This model is good if the primary objective is viewing the list. If the primary objective is editing the list items, this model doesn't work very well.
Franci Penov
@Franci, for my example if I understand your comment, if there is a high rotation of employee and it need to be edited a lot, I should look toward an editable grid for the most basic employee fields, and maybe use a dialog only for the less used fields.
Pierre-Alain Vigeant
Since it's an internal app, you might be interested to know you have a typo: "any one" should be "anyone".
Joel Coehoorn
Also, the first blurred word is still readable as "Advertisers".
Joel Coehoorn
@Pierre - yes, you got the idea.
Franci Penov
@Joel: Or *maybe* that's part of the obfuscation. Hmmmm....
Alex Papadimoulis
@Pierre: It's all about the end users. When I've used web apps where I *couldn't* have multiple Employee Windows open, I find it frustrating. OTOH, I've supported apps where multiple windows created lots of problems. Middle ground I've found: name the windows like, "_employee88472", "_employee827123" or whatever their ID is, so you can only have one window per emp open. Or something.
Alex Papadimoulis
A: 

The right answer depends on whether your list primary objective revolves around editing objects or viewing the list.

If editing is infrequent operation, you can settle for it being in a separate window and use the screen space on the main view to show as much details as needed.

However, if editing is going to be a frequent operation, you want it in place with the list, as opening a new window creates too much of a friction.

Franci Penov
+1  A: 

Option 1 allows the user to see more list items at a time, so it is preferred when the user is likely to need to jump around a lot in the list (e.g., to find the next record to edit). More items means less scrolling, among other things.

Option 2 can usually get the user to editing the field faster, since there is no waiting for a new browser window to open and no cognitive re-orientation needed by the user, so it is better for heavy data entry (e.g., making a change to every record, one after another).

Both options are substantially inferior to edit-in-place in the table by using an editable grid or replacing your table with an array of appropriate controls (text boxes, combo boxes, checkboxes, etc.) that are populated with the field values for the appropriate set of records. Users change fields directly in the table and select a Save button or menu item to update all changed records at once. Or you can save automatically whenever a field loses focus, if your bandwidth can handle it.

Compared to Options 1 and 2, edit-in-place has the following advantages:

  • No need to click an Edit button to change a record, an additional navigation step that takes time and learning (e.g., the user has to learn the “edit” icon).

  • No need to visually re-acquire the fields in another location in order to edit them, making editing faster and easier.

  • No second window or form layout to learn and understand, and to consume screen real estate that the user may want to use for something else.

  • No modes –the users can fluidly switch between editing and viewing, and save whenever its convenient.

If you have too many fields for the Employees to show in the table even with horizontal scrolling, then you need to choose between (1) having a split-screen master-detail layout in a single window, and (2) having two windows and allowing drill-down. However, optimizing the display of “extra” fields is a separate issue from how to edit records. The general rule for usability is that if a field can be edited by the user, always make it editable for the user wherever that field appears, whether it be in a table, a detail overflow area of the screen, or a separate drill-down detail window.

Michael Zuschlag