72

We use modal dialogs in a web application for actions that require the users to take an action, like log in or configure something before being able to proceed.

We fixed a few layout issues and now have them automatically centered and sized. They can no longer be moved by the user as part of the interaction.

I have mixed feeling about this:

  • on the one hand it is nice to be able to move them out of the way

  • but on the other hand, the whole point of the dialog is to command attention and moving it out of the way seems to indicate a wrong use case

so..

Should modal dialogs be movable by the user?

Improve this question
5
  • 10
    I'm surprised by the amount of support for movable modals. A modal is supposed to feel like an interruption, with only the ability to move forward or cancel. Anything beyond that is probably a bad use-case for a modal.
    – Lindsey D
    Commented Jul 9, 2015 at 4:03
  • @LindseyD .. same here.
    – Manfred Moser
    Commented Jul 9, 2015 at 17:58
  • 11
    Stack Exchange's flag dialog seems like a pretty good example of a modal that is usefully movable; it lets me see the post I'm flagging, so that I can refresh my memory about details or quote snippets as I'm writing a message to the mods. What would the anti-movable-modal crowd suggest SE should do instead? Make the modal unmovable? That would hurt my use case and serve no purpose. Display the entire dialog inline somewhere? That would blur the line between the dialog and the rest of the page. The anti-movable answers here are big on generalities but so far all devoid of concrete examples.
    – Mark Amery
    Commented Jul 10, 2015 at 13:23
  • Which modal? ;)
    – Abektes
    Commented Jul 11, 2015 at 15:30
  • @LindseyD What can you clarify what the alternative nice looking design is. Take a look at Facebook "create an event" dialog for the example that made me come back and complain here. You're on your events page, and you go to create an event. Hang on a minute, what did I put in the description of that last event? Oh crap .. modal. This is a regular frustration. What should that form have taken? (Note that to solve my problem, I not only need to be able to move the dialog, I need to be able to click through a link on the window that initiated it!)
    – GreenAsJade
    Commented Aug 8, 2015 at 23:52

8 Answers 8

Reset to default
64

Usually the downsides outweigh the upsides

i.e. usually the answer is "no"

Here are some of the typical considerations with movable modal dialogs. Note that some of these verge on implementation issues, but I've included them anyway because they all have usability impact:

  • Moving the modal requires a lot of cognitive load. The user has to find the handle, re-orient visual depth to the underlying layer, locate the information and then the modal drag handles, then move it (see KLM-GOMS analysis for example).

  • If users are needing to move modals, this is usually the result of poor design. Modals are blocking interfaces and are intended to be used that way. If a users are needing to move modals to see underlying content, you are imposing a big cognitive tax on users. Typically, this happens because of bad UX workflow/IA design, for example:

    • Underlying app is not designed to provide correct visual flow leading up to the modal trigger/popup, so users don't have the right information when the modal appears.
    • Trigger interaction (e.g. button) to open the dialog isn't properly conveyed or labeled so the user is surprised or unprepared when the dialog opens and asks her for something.
    • Dialog doesn't provide enough reasonable information for the user to complete the modal workflow task.
    • Dialog is designed into the wrong stage or sequence in the workflow.
    • Dialog is not the correct interface element for the workflow (e.g. the task is not blocking, or should not be undertaken outside of the underlying form/window context).

  • User moves dialog partly/mostly offscreen. While it sounds good to give more freedom, the result here is that the dialog content is now hidden, which presents potential usability issues (e.g. what happens when one button is offscreen and the user forgets its there?). There is a usability tradeoff here to resolve.

  • User moves the dialog, and then resizes the browser window. The dialog may now be offscreen, so this case needs to be worked out.

  • Scrolling ambiguity with responsive layouts. Sometimes dialogs overflow a screen because of content considerations (e.g. Material Design provides for this). When the dialog is fixed the scrolling interaction is clear. If the dialog is partly offscreen, the scroll interaction can get very awkward. Additionally you have to figure out whether to scroll the background layer itself.

All of these considerations are solvable through combination of design and implementation. But in practice, they are enough to convince the most sites that it's not worth making dialogs movable, which is why they usually aren't.

Improve this answer
20
  • Currently they are movable and we had objections from users when locking them down. Seems like this points to a wider usability problem. Would you agree? Can you elaborate on reasons to take the movability away? You already mentioned a few problems with them being movable. Ohers?
    – Manfred Moser
    Commented Jul 7, 2015 at 21:16
  • 6
    @ManfredMoser I'd have to understand what your users are saying. Typically some fraction of users will complain with most UX changes, even for the better. That doesn't mean the decision is a bad one (e.g. lots of users hated the move from command line email to graphical email), but I'd need to understand more. Try to figure out why exactly users are moving the dialogs...and whether there is an underlying UX reason you need to fix first. If your users are vocal then they won't mind having you observe how they use the movable dialogs.
    – tohster
    Commented Jul 7, 2015 at 21:34
  • You are assuming that the modal dialog is part of a browser window, whichnis itself a full separate program. You talk about browser, site, etc. In this case, the dialog is embedded inside another window and that causes complications. And also in that case, the user can use apps other than the browser (or tab therein) to do something before adressing the dialog. I read the question as partaining to desktop windows, which clearly has different considerations.
    – JDługosz
    Commented Jul 8, 2015 at 5:39
  • P.s. I see he did specify he was asking about a web page. I mean to point out only that a "fixed" inside another movable/sizable window is a distinct concept. We have system-modal and application-modal, and this is a further specialization of application. I think there must be a name for that.
    – JDługosz
    Commented Jul 8, 2015 at 5:48
  • 2
    @JDB I agree. While UX design should ideally be independent of implementation, the reality is that implementation constraints frequently dictate UX choices, and modals are an example of this happening even with world class companies (Google has 7000+ engineers!). As you suggest, modal dialogs are often the result of bad upstream information/workflow design: that upstream design is actually the first place to look when confronted with this decision. BTW i enjoyed reading your answer too (+1)
    – tohster
    Commented Jul 8, 2015 at 17:09
71

I hate it when a modal dialog appears asking me to confirm an action and the only way I can confirm that, yes, this is the record I want to delete, is to view the information underneath the immovable dialog.

I usually have to cancel, double check, then click again.

Or, consider this scenario:

Hey Mr. Team Leader, there's this case I'm working on and I'm not sure what to do about it because of XYZ.
whaa-whaa-whaa
The case number? I'm not sure... it's covered by an immovable modal dialog.
whaa-whaa-whaa-whaaaaa
I can't close it. I'm seven steps in and it's not offering me the option to cancel.

It's one thing to command attention (even lock down the page underneath). It's another thing to obscure the page that you are being asked about. If your dialog has nothing to do with the data displayed on the page (e.g. a session timeout warning) then it's acceptable, otherwise let your user move the dialog.

Improve this answer
11
  • 5
    The problem with unexpected visual changes on the screen—which could be a dialog box popping up—is that it triggers a looming-stimulus response. This is involuntary, causes the subject to flush short-term memory, release some adrenaline, and re-scan the environment. The flushing of short-term memory is a problem. Depending on the context, making the dialog box movable, or replicate key information IN the dialog box—but without making it seem like a cluttered, burdensome read. (Yes, all design choices are about resolving the tension between conflicting design objectives, aren't they?)
    – JeromeR
    Commented Jul 7, 2015 at 20:40
  • 13
    This seems like a wider issue and wrong usage of a modal dialog. Doesnt really justify making it movable imho, but rather a need to change the content of the dialog or even use a different pattern.
    – Manfred Moser
    Commented Jul 7, 2015 at 21:17
  • 10
    @ManfredMoser - No matter what the modal may contain, it will certainly obscure the information underneath which, more often than not, represents the user's current context. You may not always be able to predict what information the user will need when. Personally, I avoid modals as much as possible, but if you are going to show one, allow the user to at least move it. (Preventing the modal from being hidden is a trivial programming task.)
    – JDB
    Commented Jul 7, 2015 at 21:30
  • 6
    @harsimranb - This goes back to my assertion that you'll probably never know exactly what the user will need, and there may be too much information to repeat in the modal. For example, what if the song name and artist name are the same, and I'm trying to delete the song from the XYZ album rather than the ABC album? Or what if I have two copies of the same album and I'm trying to delete the copy recorded at 256Kbps?
    – JDB
    Commented Jul 8, 2015 at 19:17
  • 2
    THIS. It happens ALL THE TIME. Take a look at Facebook "create an event" dialog for the example that made me come back and complain here. You're on your events page, and you go to create an event. Hang on a minute, what did I put in the description of that last event? Oh crap .. modal. This is a regular frustration. Don't make forms modal.
    – GreenAsJade
    Commented Aug 8, 2015 at 23:50
7

A lot of argument for making modal dialogs non-moveable centres around the fact that the need to move them stems from poor design.

This is persuasive.

So - if you are a perfect designer, than you can lock them in place with confidence.

For the rest of designers out there, are you willing to be the one frustrating your user through some oversight of design on your part? If not, then make them moveable(*).

(*): At least where this is a fairly clean thing to do. A case like in a responsive design it can easily bring worse problems, but in a straightforward desktop setting there's not a lot to lose.

Improve this answer
6

Modal dialogs should be movable unless you have a good reason for them to be fixed in place. Few users will ever actually move modal dialogs, so the chance of hitting any of the "dangers" mentioned are incredibly slim. But those users who do move dialogs do it for a reason, and that is usually because the dialog obscures some information they want to see before proceeding. If you choose to fix your dialogs in place, make sure you aren't hiding anything.

Improve this answer
3

FIXED DIALOG

Use for mandatory actions as it emphasizes the necessity to take that action. But, it should not hide necessary information

MOVABLE DIALOG

You can use movable dialog boxes unless they don't hide the information. Most websites don't use movable dialog boxes these days, as it just hinders the flow and visibility

But these are just guidelines

Pinterest displays a fixed login dialog box if you are a new user. Unless you sign in/sign up, you can't go in. It stands there like a bouncer outside a club (No password? You ain't goin' nowhere inside pal!)

But, if you observe, the background is blurred and keeps scrolling, giving the users a sneak peek of what they can expect from Pinterest. This increases curiosity. This is an awesome UX. The dialog is fixed but it still gives you a hint of information.

Pinterest login

You can imagine a more engaging movable dialog box for the same scenario.

Example: Pinterest can have the same login as a movable dialog, with another box on its right. This box de-blurs and reveals the background, wherever the login dialog is moved. This can end up being an awesome micro interaction. A rough concept image attached.

Pinterest login redesigned

In the end, it's about how you are using these elements, both effectively and creatively, to engage the users.

Improve this answer
4
  • 4
    I would argue that nothing about a modal dialog that blocks access to the content you want to see unless you complete a registration form is anything remotely resembling an "awesome UX."
    – Zach Lipton
    Commented Jul 9, 2015 at 7:03
  • Depends on the context. Earlier you can't see any content before signing in. Now, a sneak peek helps you understand what to expect before you sign in. Solves both business and user objectives.
    – Gautham Raja
    Commented Jul 9, 2015 at 7:31
  • 2
    It's not intuitive, though. Since Pinterest is the only website to use this, I would expect that there is some way to close the login box and, when I encountered this the first time, I wasted quite a bit of time figuring out why can't I access the content.
    – Petr Hudeček
    Commented Jul 10, 2015 at 5:56
  • 1
    @GauthamRaja Respectfully, no it doesn't.
    – Craig Tullis
    Commented Jul 12, 2015 at 5:26
1

I find it frustrating when a modal box is unmoveable, as many times the response depends on what is behind the box. E.g. if an application displays a modal "Close without saving?" box, I want to be able to move the box out of the way to look at the document behind and see if there is anything that I want to save. It's bad enough that I can't bring the document to the front and read it in a "read-only" mode while the box is open.

EDIT: For situations involving login or configuration, it is less likely that the user will want to view the window behind. Just bear it in mind though, if say they've forgotten what they're logging in to or what they're configuring. There's no harm done in making your modal box moveable - if you're concerned about the user not realising that it's modal, you could still dim the background window but make the box moveable over the dimmed background.

Improve this answer
0

I don't really understand why the "answer" is no. The whole reason dialogs exist (whether modal or not) is to provide non-blocking alternatives to two problem-area controls:

  1. javascript alert(): because of blocking and not being flexible with styles
  2. popup windows: separate thread, blocked by popup blockers, etc.

I vote very heavily yes, dialogs should always be draggable even if it makes it more complex, although I do understand why someone would not because of how hard it is to program for all the different possibilities. I just wish the creators of the html5.1 felt the same way.

Improve this answer
-1

By the way you phrased the question, it seems like these actions are pretty critical to the application running smoothly.

...that command the users to take an action like log in or configure something before being able to proceed.

If that's the case, then you shouldn't allow them to be moved. What's to stop the user from moving it out of the way and (potentially) breaking your application by not completing a critical step? Since (I'm assuming) it is a temporary window, that won't be the worst to have that stationary.

However, if you do want them to be movable, consider adding in some sort of fallback that tells the user they need to complete "Critical Step A" before moving on, otherwise it could be bad news for your users.

Improve this answer
6
  • 3
    In application critical scenarios you could potentially overlay a lightbox type panel betweeb the modal and body so that you could still freely move and view under the modal without being able to click or input anything.
    – DasBeasto
    Commented Jul 7, 2015 at 19:50
  • 6
    If it's truly a modal dialog, then the user won't be able to interact with the parent page until the modal is closed. Moving it won't have any effect. If it's not a modal, then the position won't matter that much as the user can easily access the parent page use keyboard shortcuts, etc.
    – JDB
    Commented Jul 7, 2015 at 19:53
  • 1
    One thing you can do to cue users that the dialog box cannot be moved is to lightbox the background. Lightboxing means adding a partially transparent layer over everything behind the active dialog box, to make the background darker. Lightboxing doesn't test will users who face accessibility barriers. For example, screen readers may still read objects in the background that are supposed to be inactive. so please make sure you handle that, for the sake of your Blind users.
    – JeromeR
    Commented Jul 7, 2015 at 20:45
  • 1
    @JDB I deleted my previous comment. I'm so dead-set against immovable modals that I misinterpreted what you were saying. You're saying that modal, even if movable, still prevents the user from interacting with the underlying layer, so the user must deal with the modal (or dismiss it) before they're able to do anything else. So making the modal movable does NOT by definition enable interaction with the underlying page. And it shouldn't. The modal SHOULD prevent interaction with the underlying page. But in my opinion it should still be movable. Separate although related issues...
    – Craig Tullis
    Commented Jul 12, 2015 at 6:06
  • 1
    @JDB If it's truly a modal dialog, then the user won't be able to interact with the parent page until the modal is closed. This is not true; reading the page is one undeniable interaction that the user might want to have before closing the dialog.
    – hlovdal
    Commented Jan 19, 2016 at 23:49

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.