What is the best model for editing and viewing data that is summarized in a table?

Question

I am designing a web application that has several tables displaying many rows of user entered objects. My users are fairly technically savvy. I’d like to bring the user to a place where they can view more detail and edit the data for a specific row.

I’ve considered the following options:

1. Opening a modal dialog: With so much data to edit, editing within a model dialog feels very cramped. Also, because the user is doing a lot of ‘picking’ from other lists (like selecting users from an active directory), I either need to display separate lists (up to 6) in the dialog for the user to choose items from, or, spawn additional modal dialogs (!).
2. Opening a tab: When the user edits a row, a new tab would be created. This gives a bit more space and doesn’t have the multiple dialog box problem, but because of the nature of tabs, the user can ‘leave’ the tab, without making a decision to save or cancel. Also, we then are using tabs inconsistently – to display an overview table, and details of specific rows. (This is similar to Yahoo Mail).
3. ‘Sliding’ in the view/edit panel, to replace the table: (similar to going into folders in github) This solves the problems of the above two options, but it is not a common interaction. It also isn’t clear to me how the user gets back to the table (“Save and go back to table” and “Don’t Save and go back to table” buttons are a little wordy.)

An example of the table, using option 2 for editing.

An example of what the edit might look like. I imagine clicking on the edit button would open up a dialog with a dual list (similar to this: Best way to select a subset of items in a long list). Having many dual lists on one page would be quite crowded.

Are any of these a clear choice for usability? Are there other options to consider? Is there a standard or examples where one of these options works well?

Answer 1

It appears to me you have already answered your own question (3 being the answer).

In cases where the editor is an evolved one (which is clearly your case), an assumption can be made that the users will spend some time on it. Given such scenario, one can argue that a maximised space is well justified and would be well beneficial for the user.

Another reason to choose such an implementation is that it is very standard with iPads (or iPhones), making your application more 'iPad' friendly (although I'm not sure this is anywhere in your agenda).

Accordingly, the corresponding interaction with iPads simply gives a top toolbar with two buttons - 'save' and 'cancel'; given your users are fairly technical, no further captions should be needed (and if I'm honest, the iPad proves that even non-technical users understand what these buttons do).

Dialog are somewhat a thing of the past when it comes to web application and mobile applications. We still use them for alerts, and basic user input (such as password entering). Reason being is that with desktop application users are accustomed to the concept of multiple windows (and a dialog is another window). Another reason is that the system preferences on a mac can simply not take over your whole screen, so it must display a window. But the preferences on Google's Chrome, or on Gmail will occupy maximum size - both web applications and mobile apps largely work on the concept of one screen to serve it all, thus a pop-up dialog is not very common.

Another thing to consider with dialogs is that they can be synchronous or asynchronous - the former could be an issue with some systems.

The usage of tabs is generally useful when the assumption is that the user would like to toggle between the various tabs (like browsing a help directory), or when the tab action will close the tab (such as 'send email'). It is not advised if all you are trying to achieve is the user editing a record, where the user must either save or cancel. An open tab in your system would mean 'transaction incomplete', is it your intention to allow users to incomplete the editing of a record yet having an access to the editing of another?

Option 3 provide an elegant solution to your problem, as the user is forced to explicitly complete the 'edit transaction' (same as with dialogs).

There are alternative strategies - like hooking on blur events (user leaves the editor portion) or automatic saving (where there's no undo - all changes are immediately saved). The latter is gaining popularity (more user friendly), but is only appropriate in specific case, which I don't believe your system involve.

Answer 2

The problem you are trying to solve, if I understand it correctly is "find and edit". So the first thing that comes to mind is whether your search can support advanced filters that can help users create custom table subsets?

Beware of bulk operations. Technically savvy users will need powerful, automated ways of operating on large number of rows.

Do you have a fixed list of all the user tasks for this table? I suggest that'd be a great starting point.

Next, figure out the common or universal actions. These go to the top or left "control" or "actions" menu.

Now, what you'll be left with are item specific actions. Depending on the nature of those, you choose between option 1 of 3.

Answer 3

Is there a chance that your users might want to compare details of 2 different rows? i.e. see the full details side by side? If so, the modal or "sliding" options won't cut it...

You might also consider opening the data "in-place" (similar to an accordion control).
This would mean that all rows below the selected one are pushed down and you see all the extra info between them and the selected row.
By allowing the user to open a few rows, they might also be able to run the comparison I've mentioned above (assuming it's a valid use case of your system of course).

My last point would be that you should also allow the user to edit directly from the original table/grid. i.e. pressing the "100 users" cell, would be as if they've already opened the detailed view and pressed the appropriate "edit" button.