Should Dialogs be avoided in modern applications?

Question

I have used a few dialogs on the last system I designed. The application was a business application with many database tables and I used many datagrids to show data. It was common that I placed a button below the datagrid with the text Create new item or Create new group or whatever was listed in the grid. In other words the button was used to create a new row in the table.

When the user clicked the button a new (modal) dialog was created with the textfields and at the bottom a submit-button. But is this really the recommended way to do it? or how should I design the application without modal dialogs?

If this had been a web-application, I had probably sent the user to a new web page containing the form, but that sounds similar to a modal dialog for me.

Should Dialogs be avoided in modern applications? and what are the alternatives?

Answer 1

As general rule, you should use dialog boxes only when you have to. It’s preferred that you use direct manipulation or input or edit-in-place, where the user works directly on the data objects represented in a primary window. In the case of creating objects, the edit-in-place approach has either:

• An Insert button that creates the object and adds a blank row to the datagrid for input of the field values,

• A permanent blank row at the bottom of the datagrid (or elsewhere) –if the user types values into it, then the app creates a new object.

I compare these two approaches on SO in answering the question “What’s best when inserting into a table view, an add button or a blank line?”

Compared to either edit-in-place approaches, dialog boxes have following disadvantages:

• Additional learning. It adds a window to the app, with its title bar and buttons (e.g., OK and Cancel) and fields –fields that are often already exist on the parent datagrid, but arranged differently. This incrementally adds to what users have to learn.

• Attention shifting. Popping up a dialog requires that the user shift attention to something new, which has a certain re-orientation cost, and makes the user feel less in control of the data.

• Additional clicks. Dialog boxes need to be executed and dismissed. This takes at least one extra button click. In contrast, with edit-in-place the user can create multiple objects before saving (if saving isn’t automatic).

• Modality. If you have to have a modal dialog box, then you’re removing user flexibility, forcing users to either complete the creation or abandon it. If they need additional info from elsewhere in the app to complete the creation, they are forced to discard whatever work they’ve done.

• Risk of loss work. One accidental click of the Cancel button reverts any input the user made and dismisses the dialog, forcing the user the start over. One-click loss of multiple inputs is not characteristic of properly designed primary windows, plus primary windows typically support Undo.

Dialogs should be used for atomic actions that require parameters; that is, situations where the app must have certain input from the user in order to technically or logically complete the action. For example, if creating an object requires field values that cannot be defaulted, then it’s probably good to use a dialog.

Such a Create dialog probably should have only the required fields, not any optional ones. Let the user complete any optional fields back on the datagrid. Because of modality and risk of loss work, dialogs should be as simple as possible. As a rough rule of thumb, the user should be able to complete input in about 20 to 30 seconds –that’s a tolerable amount of work to have to re-do.

You are correct that in web apps, a separate input page is pretty much equivalent to a modal dialog box, where the user is forced to either complete or cancel a transaction before doing anything else. This is what gives many web apps a clunky “indirect” feel compared to the fluid feel of a direct manipulation desktop equivalent.

Answer 2

In Mac OS X there is Spaces which is virtual desktops (and also in dual screen setups). Multi window apps doesn't work well with Spaces, modal dialogs still have a tendency to pop up on the wrong desktops!

Instead if you use sheets that are mounted to the parent window, then it will not bother users in the same way.

Answer 3

Sometimes it will work and sometimes not, but with the example you've suggested, it 'seems' that an ajax update could place the new row into the table. You indicated that you used a dialogue box with the new data row/grid and then a submit button. What's not clear is whether this is a confirm dialogue with editable content or whether it's just a yes/no thing. What's also not clear is what the user is editing/adding content-wise to then add the new row to the data grid.

Seems to me you could allow the new row to be created/edited by the user within the page and then update it, all without dialogue boxes. If you have to open a new panel for some reason, generally a nicely styled modal is preferential to a dialogue box now because you don't actually open a new browser instance, take the user away from the page they're on or remove control from them. Most UX research tends to show that the 'back' button is still the only fully understand browser control mechanism. Popups and even tabbed UIs are hit and miss depending on the user.

Answer 4

I think the disadvantages are mentioned. I do not think however that you can or should dismiss dialogues at all.

Inline editing / creation (as one would in Excel) is useful for typing in lots of records fast, or editing very specific values.

But it might not be the best when you need to save a more detailed record than is shown in your table listing. Say, it displays a person's name, addres, date of birth. When entering a new record however, you may wish to also include social security, place of birth, relationships to parents, judicial status or a whole range of other options.

Dialogues can also help with easier ui, providing dropdownboxes for linked information, providing feedback, putting in datepickers or other ui elements. Most of those can't be put in inline editing without crowding the UI severely.

Separating the action of saving the information from data entry is not just a burden, it can also be helpful to provide a structured moment of review: did I fill out everything, is it ok now? I very much like that option when ordering something online for example, you can gather and fill out the information step by step, and then there is a clear moment of decision before it is actually completed.

So I do think it depends on the context: the number of fields, the type of information provided, the structure in which information is gathered. I would not advise to avoid dialogues in general: just think of where they are suited and where they aren't.

As for modal or not, non-modal can make it confusing (because the dialogue can hide behind others and gets lost or forgotten), modal can make it irritating (because you can't do anything besides what you are doing.) Usually, modal dialogues aren't the best way to go, but once again, use them where fitted rather than blindly avoiding them.

With screens getting larger, it might be an option to place the dialogue (or detailed view) alongside the table overview. Then again, with the increase of smartphones also lots of screens get smaller, and there dialogues are even more important because editing a table when you only see a few cells at the time just doesn't work very well.