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. Table with tabs for editing specific rows

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. Editing a row

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?

  • Screenshots would definitely help, as it sounds like a rather complex system. You can upload them somewhere (e.g. dropbox) and then simply add a link. It's also a little unclear why in option 1 you'll need all 6 lists to open at the same time - can't they just open in place (e.g. a dropdown menu)?
    – Dan Barak
    Commented Jul 18, 2012 at 20:21
  • Now able to add screenshots. Hopefully this provides more context to why dropdowns aren't appropriate (the user is selecting multiple items from very large lists.)
    – Elizabeth
    Commented Jul 18, 2012 at 21:01
  • Have you considered a simple drill-down? User clicks on a row to edit, system refreshes the page and displays Edit layout. This avoids all sorts of flow issues.
    – Jung Lee
    Commented Jul 19, 2012 at 4:31
  • A drill down is similar to the third option, with a page refresh instead of animation. My main concerns with this is what does the navigation look like when in this edit state? Are they on the same page as when they were on the summary table? And how do they get back to the table - do I need “Save and go back to table” and “Don’t Save and go back to table” buttons?
    – Elizabeth
    Commented Jul 20, 2012 at 19:09

3 Answers 3


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.