There seems to be an increasing use of modal dialog boxes on the web, but when should you use them? Why would you choose to use them instead of inline controls or another page, and when should you completely avoid them?
7 Answers
I use a combination of inline editing, soft modals, full modals and floating windows.
- Inline editing. If possible, always try to use this. It requires the least amount of context switching. It's quick.
- Soft modals. Example: Windows Start Menus. They are rich controls and can have forms, but they spawn off a single menu and can be dismissed by clicking anywhere. These are good to use from menus.
- Full Modals. These mask the entire screen and allow ONLY interaction with the modal. I use these when I want to focus the user on one task and not continue without filling in the form.
- Floating Windows. These are good for status messages. They float on the UI but can be moved around and minimized. Use these for things that need to persist as you travel around the application.
I hope this is helpful.
-
1Good, and informative response. I would just like to clarify that points 2 and 4 are not actually modals. Modal dialogs force the users to interact with it before they can return to the parent application. Further reading: en.wikipedia.org/wiki/Modal_window– RichCommented Feb 2, 2013 at 2:02
-
1Yes true, but I wanted to cover different ways the use case gets solved. Commented Feb 6, 2013 at 19:09
The most general rules I could think of would be:
Modal dialogs can make sense when they help you keeping the flow (i.e. you don't have to leave the page you're on).
Don't use modal dialogs for things that should be linkable or searchable (as the URL doesn't change, it can't be linked externally and that includes search engines).
Edit: Also take a look at facebook, with a few exceptions I think they handle it pretty well.
I have found that modals are best to use when you are trying to isolate an action by the user. By using a modal you capture the focus of the user and this allows you to remove secondary distractions, such as navigation, utility links, images or other components that could distract from what you want the user to see or experience.
As far as when NOT to use a modal you will just have to use your best judgment on that one. I don't think you can apply strict rules to something like that.
My rule of thumb would be to use a modal window when there is a dead end for the functionality. For instance, when you update profile information, set up an account etc.
-
1Your examples are specific things that I would NEVER put into a modal dialog. Updating data should never be put into something like that because there is no good way to show confirmation unless you then show a second modal dialog.– Charles BoyungCommented Dec 20, 2009 at 17:56
-
1@Charles: That's simply not true. There are a few good ways to show a confirmation. For example one would be to show it on top of the page (like gmail does when sending or deleting a mail). A other option would be to update the modal dialog itself to show the confirmation.– PhilCommented Dec 20, 2009 at 19:59
-
@Phil - do you actually think people see confirmations when you put them in those locations? I'm sorry, but no, they do not.– Charles BoyungCommented Mar 3, 2010 at 6:33
-
1I agree with Charles - the confirmation message can be prominently displayed in either the original page or the lightbox (before the action is performed). If the message is missed it's because that's not been designed properly.– tomCommented Apr 27, 2010 at 8:16
-
@charles - do you think people actually need to see the confirmations for things which they can safely assume have happened? By the way, there are other ways too, such as change-spotlight and self-healing-transition.– EricsCommented Oct 27, 2011 at 22:35
Some people distinguish between dialog boxes and alert boxes (an alert box typically has only one or two buttons and no other inputs, whereas a dialog has input fields of some sort). And there is a school of thought that says you should never use modal alert boxes (See "Should alert boxes be avoided at any cost?".)
Putting a form into a modal dialog can be more responsive than putting it into a separate page, since the dialog box code can be contained entirely within the previous page -- no network traffic. However I have seen many users who are confused by modal dialogs. You'll want to test with end users. Of course. :)
Modal dialogs should only be used when the user is required to make a choice or needs to know something specific before continuing. Warnings about how something that they are choosing to do can potentially cause problems (like deleting something permanently) and things like that.
Logging in to access a secured section of the site (or to post a comment on a page) is also okay, as long as you do it correctly.
-
I think there are many more usages for modal dialogs. It really depends on the website. For example I wireframed a messaging platform and used plenty of modal dialogs because like this you never have to leave the important content and it can't be linked or searched anyway because it's all behind a login.– PhilCommented Dec 20, 2009 at 20:06
I posted this on another question, but I'll include it here as well:
I'm working on an implementation of a webpage that needs to feel like a flexible web app. There are multiple forms that the user can fill out.
For my purposes and users, here some assumptions (agreed on by stakeholders & SMEs, but may be overturned in user testing):
- Users coming to this web app know what they want to do. They are coming to complete a specific task known in advance. That is the purpose of this page. Users don't come here to look around.
- Because they know what they're doing, they know the required information to fill out the necessary forms.
I've been suggesting the use of lightboxed forms. I'm normally be against using modal windows, but I'm am also VERY opposed to just sending the user to new pages every time they attempt a simple update or add. And I don't think that accordions are the correct solution here (though they might be an alternative option).
In our context, the lightbox forms are only displayed upon user request. They allow quick, easy escape/closing. They focus the user on the action they just requested so there is no surprise at the change on the page. The users are not removed them from the page/app they are working in.
One of the forms is has three (3), discreet steps. So we are using a wizard in the lightbox with progress tracking. This has actually been a significant challenge point with a single person in our group, who (rightly so) is adamantly opposed to multi-panel modals. Usually I agreed in whole.
In this case, a wizard is an accepted pattern for this type of interaction. The users know what they are trying to do and the steps necessary to do it. The lightbox focuses the user on their requested action without leaving the overview page (which gives information on selections and previous action inputs), but allows for quick closing.
While I agree that modals/overlays/lightboxes/etc should be used sparingly, they are not evil or poor UX by nature. User requested versions for a focused task are a valid use case and in many situation may be superior than alternatives when implemented carefully.