Why you should stop using dialogs12
I posted a tweet viagraday about why I think you should not use dialogs, and it seems people are still pretty skeptical, so I felt the urge to elaborate a bit.
So why do I dislike dialogs that much? After all, I have written countless JavaScript implementations of dialogs and overlays in the past, and we have one in jQuery UI for quite some time now (and while I’m starting with my rant, keep in mind this is purely my personal opinion, not the one of the jQuery UI team). Diving into the browser and social game world, it slowly became crystal clear to me what the issue really is about.
Dialogs invite you to be lazy.
Solving the issue of navigation and interaction within your information architecture of your website or game is a very hard challenge. “Uh, if I just had a good place to put that invitation feature somewhere in my UI..”. If you are a web designer or developer, chances are you shared a similar frustration before. But wait! Thankfully, there’s an easy way out. Just take the feature and pack it in a dialog! That way, we don’t have to clutter our UI and can hide certain features, bring them up when needed. …right ?
Let’s turn it the other way around to see what’s going on here. By using a dialog, lightbox or overlay, you are effectively cheating. The content in your dialog will not fit into your centralized user experience, and remains disconnected. Your users have a harder time to relate to features in lightboxes. Even worse, modal dialogs often break one of the most important rules of great user experience: Never block the interaction of your users an your product.
Dialogs are the new popups. So the next time you are setting up a dialog, take a break and think about a better integration.
12 Comments
gercheq on October 13th, 2010
I totally disagree. Lightbox implementations help you to simplify your design and hide secondary actions (usually behind a button or a link).
ie. It doesn’t really make sense to have a contact form or feedback form sitting always in the page.
Paul on October 13th, 2010
@Andrew sorry for not being clearer about my point. I think there’s a definite use case for hiding actions. I just don’t think that dialogs are the right way to implement it. I do like dropdowns, slide-ins etc. They are usually connected to your page, and don’t feel so disconnected in the overall experience.
Paul on October 13th, 2010
@gercheq see my answer for Andrew. My point is not that it’s bad to hide features.
Bruno Garcia on October 13th, 2010
Totally agree, especially for games. Having a game that relies on dialogs is a tell tale sign of feature creep, where new features were wedged in with dialogs rather than being intuitively integrated into the game. This is common with social games for no good reason.
Mike McNally on October 13th, 2010
I’ve experienced explicit user feedback from usability testing expressing great delight at the fact that our application drives most user actions through dialogs. (I admit to finding that somewhat surprising, but it’s happened several times.) It’s totally dependent on the character of the application, of course, but my real-world experience is that forms left dangling amidst navigation tools are an invitation for disaster when 2/3 of your users forget to click “Save” or “Go” 2/3 of the time. The flip side of that, an “auto-save” or “everything’s persistent” setup, works great for apps with “document-like” interaction, but it’s really creepy for apps with different character.
For apps that involve managing structured data and modelling already-familiar real-world activities – like, for example, any variation on the “home banking” theme – a modal scheme of “I want to do something / I’m telling you the details / OK Go” seems to be readily understandable by ordinary people. The dialog becomes the important flow, because for that user they’ve explicitly initiated a process that they understand. That the rest of the application is unavailable is actually a feature, because the procedure is (presumably) important and the application does a disservice to the user by *not* hiding distractions.
As a very experienced computer user and software developer, the constraints of modal dialogs irritate me, but I don’t count.
(Also, after reading through this, I don’t mean to imply that you don’t have “real-world” experience of course.)
Paul on October 13th, 2010
@Mike this is fairly interesting, thanks for sharing your insights! I agree there are situations where you would like to control the user interaction flow, but I wonder if that can’t be solved by hiding other features or moving to an entirely different page, rather than through opening model dialogs… but I digress, I agree it’s not entirely black and white. Your bank example could have been solved fairly well with a step-by-step procedure I think, next/prev buttons at both sides and then allowing the user to progress through pagination. No real need to popup another modal.
Anway, thanks again for the good example!
Mike McNally on October 13th, 2010
Hey @Paul – you’re right, there are other ways of doing things – but really, is launching from some context into a separate step-by-step sequence really “morally” distinct from a (also step-by-step, at least action-confirm/summary) dialog? In both cases, the surrounding context – navigation, status or tabular history view, page tools – are hidden or obscured or absent.
It’s weird for me to be posing arguments in favor of dialogs, because in a lot of ways I don’t like them very much. I’m not much of a designer and absolutely no kind of design innovator, so I’m kind-of stuck with this mechanism (and equivalents) for now. I will eagerly embrace anything better yet equally “coddling” towards my non-sophisticated users as soon as it comes along!
Jonathan on October 13th, 2010
Dialogs are over-used. Definitely.
But the idea that we should never use them is hooey. Think interactive UX design for a moment. There is a reason modal dialogs exist. It is because a user has entered a pipeline and it is appropriate to guide them to resolution. If they choose to back out it Should be an active choice.
Web modal dialogs serve one useful function: guiding the user through a brief activity that is highly related to the page content but should not be considered a passive, consumptive activity. It reinforces the decision making process without moving you out of the informational context that incited that action.
Sorry for the brevity, posting from a phone.
A'braham Barakhyahu on October 13th, 2010
Dialogs should be used sparingly, and they are not. Having a dropdown, slide in, etc are more modern approachrs that should be used more and are not.
Glad i saw this article. A slide down would be a better solution to a ui item i was talking to a coworker about than a modal dialog.
Janko on October 13th, 2010
Interesting points Paul. I’d say that dialogs should really be user sparingly. I’ve shared my thoughts on this one a few months ago: http://www.jankoatwarpspeed.com/post/2010/06/17/modal-overlays.aspx
abhidilliwal on October 19th, 2010
I agree with u they are the new pop-ups we shud avoid them as far as possible
Andrew Dupont on October 13th, 2010
“Let’s turn it the other way around to see what’s going on here. By using a dialog, lightbox or overlay, you are effectively cheating. The content in your dialog will not fit into your centralized user experience, and remains disconnected. Your users have a harder time to relate to features in lightboxes.”
I’m really trying to understand where you’re coming from here, but I don’t agree with a single thing in this paragraph. I think you’re saying that content in a dialog should instead reside somewhere on the page that’s always visible, but I’m not sure I agree that that’s a goal worth striving for.
“Even worse, modal dialogs often break one of the most important rules of great user experience: Never block the interaction of your users an your product.”
What if you actually have modal interactions, though, where a user must make a decision before proceeding? What would you do instead?