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?

5 Answers 5


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.

  • 1
    I have questions about your last two bullet points: How is inline editing going to help you with the issue of Modality? You have to leave the page you are on to go look at that additional info elsewhere in the app as well. As for Risk of lost work, how do you not have that with inline editing as well? There are always actions on the screen you are viewing that take you somewhere else just as easily. In fact, a dialog helps in that regard because it limits the paths available to leave your editing without saving. Commented Mar 30, 2011 at 12:59
  • @Charles With a modal dialog, you can't interact with the main window until the dialog is dismissed. Making the dialog modeless would be an improvement, but the dialog still obscures the content and controls on the window behind it, so it would have to be either moved out of the way, minimized, or dismissed. The user is likely to dismiss the dialog with the cancel button, destroying his work, just so he can get more information and restart that same work. The other advantage of inline editing you might have overlooked is that it supports undo. (Closing a dialog isn't typically undo-able.) Commented Mar 30, 2011 at 13:40
  • @Patrick - that is only an advantage of inline editing if you implement it. And you can implement undo in any form, even with closing a dialog if you want to. Don't see any advantage there. Also, undo doesn't work any better with inline editing if you click on a link/button/whatever that takes you somewhere else, which is exactly the same as clicking close on a dialog. Commented Mar 30, 2011 at 13:56
  • @Patrick - Also, how is not being able to interact with the main window any different with inline editing? You can't go somewhere else in the main window, because you would lose your changes just as much as if you closed the dialog. If you can't go somewhere else to "look at other data in the application", what value is there in "interacting" with the main window? Commented Mar 30, 2011 at 13:57
  • @Charles That makes sense if we're talking about a web page. I understood the question to be about GUIs, not web apps. ("If this had been a web-application...") Commented Mar 30, 2011 at 15:14

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.

  • Sheets in Mac OS are the exact same thing as dialogs in Windows. They sit on top of the main app and you can't get back to the main app without closing them. This isn't talking about multi-window apps, it's talking about dialogs. Commented Mar 30, 2011 at 12:56

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.


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.


This is just from my own inexperience in the UX design. I'm loving UX design, but modals as you have said, could be a little cumbersome if you end up showing one after another and another.

I ended up using two different patterns for modals.

One, I use it for example, when making a dangerous action, like deleting a record permanently, in a single row of a table. The delete action automatically unzips into two smaller buttons with the mark and cancel icons. This "unzipping of buttons pattern", can only be used in confirmations, when space is needed, and no description needs to be shown

The other pattern in case I needed to put some description, is showing directly below the record or form, a new form, that appears only when clicking the delete button, or whatever triggers it, kinda like an accordion.

Usually this last pattern, I like to use it as a sub-form of some sort and keep the description or question short.

So now, each time I'd like to show a modal for confirmation, I like to show it directly below the main actions of the form in question, it makes very clear to the user directly, they need to confirm their actions. Maybe this confirmation dropdown pattern could be replicated in more scenarios.

And I'm guessing it could be screen-read easily, since the new form would appear next to the clicked buttons, directly below in the html or whatever client-side marking language is used.

  • can you add a mockup of your solution for easy visualization?
    – Devin
    Commented Aug 7, 2023 at 20:33

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.