71

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?

Devin
  • 37,944
  • 15
  • 79
  • 140
Manfred Moser
  • 1,329
  • 1
  • 12
  • 15
  • 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 Jul 09 '15 at 04:03
  • @LindseyD .. same here. – Manfred Moser Jul 09 '15 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 Jul 10 '15 at 13:23
  • Which modal? ;) – Abektes Jul 11 '15 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 Aug 08 '15 at 23:52

8 Answers8

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.

JDB
  • 863
  • 1
  • 5
  • 10
  • 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 Jul 07 '15 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 Jul 07 '15 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 Jul 07 '15 at 21:30
  • 1
    In my opinion, the modal should have all the necessary information that is required to make the decision. "Are you sure you want to delete the song [name] by [artist]?" – harsimranb Jul 08 '15 at 19:08
  • 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 Jul 08 '15 at 19:17
  • 1
    @tohster I notice you studiously avoid the point unlike, for example, harsimranb who at least made a sensible suggestion, although I still agree with JDB. The great motto of Xerox's original system (that your heroes at Apple copied) was "Don't mode me in". That's as true today as it ever. You do need modals sometimes, but don't compound it by stealing the user's context too. And "what UX have you designed...?" is inane kneejerk criticism of what is a user viewpoint. I don't CARE how many UXes anyone designed if they get the one I'm using wrong. – Nagora Jul 08 '15 at 20:36
  • @Nagora, "stealing the user's context" is the wrong way to think about this. The modal dialog is a context. That is why modern use of modals frequently adds scrims or masks to deliberately fade out the background: when the modal is correctly designed it should provide appropriate context. Your view of this being "wrong" is supported by neither empirical facts or a properly reasoned set of tradeoffs: it's exactly the kind of dogmatic logic that leads to poor UX design. BTW I met 11 members of the original Xerox team at an event here in April and they had good things to say about Apple UX. – tohster Jul 08 '15 at 20:51
  • 1
    @tohster I imagine they would. Anyway, the point is that the model box becomes - forces itself to become - the user's context while often requiring the user to refer to the context that s/he actually is interested in. That's not a difficult thing to understand, is it? – Nagora Jul 08 '15 at 20:56
  • @Nagora, there are certainly legitimate reasons to use movable modals. For example, in real-time interfaces it may be unavoidable if the underlying data (e.g. a radar map) is changing in a way that cannot be provided inside the modal. But these cases are exceptions. Overwhelmingly, the root cause of why users want to move modals in apps is the designer's failure to design the workflow reasonably. Remember that moving a modal is a lot of cognitive load too: good design should, and almost always can, avoid taxing the user this way. – tohster Jul 08 '15 at 21:04
  • 1
    I've cleaned up these comments as it was turning into more of a discussion. Please move over to [CHAT] if you wish to continue. Keep comments directly related to the answer, requesting clarification or making suggestions. – JonW Jul 09 '15 at 12:28
  • 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 Aug 08 '15 at 23:50
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.

Community
  • 1
tohster
  • 41,070
  • 14
  • 107
  • 139
  • 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 Jul 07 '15 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 Jul 07 '15 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 Jul 08 '15 at 05: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 Jul 08 '15 at 05:48
  • @JDługosz I'd probably go with "page modal." Though I guess "tab modal" might work--assuming the web app doesn't have tabs of its own. I thought of keeping the preexisting "document modal," but that is supposed to include any window working on a document. Plus, the web app may have a further document inside of it. – trlkly Jul 08 '15 at 05:55
  • I like page modal because it's a layout of a page contained in a larger presentation element, and its common use in web pages. – JDługosz Jul 08 '15 at 06:45
  • The first two and fourth reasons you've provided have more to do with implementation errors than with the UX of a movable dialog. Those scenarios should never happen, but I've seen them happen even with immovable modals. The third and fourth points are good encouragements to stop and ask whether a modal is actually the correct solution (it often is not). Modals are overused and oft abused shortcuts to cram as much functionality onto a single screen as possible. I've seen modals launching modals launching modals (3 deep!). – JDB Jul 08 '15 at 15:50
  • 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 Jul 08 '15 at 17:09
  • Nah, complete horse-hooey. I can't count the number of times I've been presented with a modal dialog, then needed information that was obscured by the dialog in order to deal with the dialog, but couldn't move the dialog to see what was underneath, forcing me to close the dialog to reference the necessary information. If you're going to put a window on a screen, let me move the bleeping thing if I want to. It's my choice, not yours. Respectfully. – Craig Tullis Jul 12 '15 at 03:21
  • @Craig respectfully, it's the designer's choice and not yours, although you can certainly blame the designer :-) Choices around what to show and not to show are made with every single window, form, panel, widget, and label in a user interface. That choice is no different for a modal. Failure to show the right information in a modal is no different from failure to show that right information in any other window (e.g. causing you to hit a back button). The constraint is just perceived more offensively in a modal because the info is in the background, but the design choice is the same. – tohster Jul 12 '15 at 04:33
  • @tohster Respectfully, the designer deciding how I can and cannot use the machine is borderline obnoxious, sort of like all the "pixel perfect" web designs that predominated for a decade or so were mired in old print publication notions and were obnoxious. I guess what I mean is, it's my machine, my choice. If the UX is obnoxious enough, I'll choose a different product. By "I," of course I mean any user of the software. In the case of the immovable modal dialog, the failure of the designer to include necessary information would have been mitigated by simply allowing me to move the dialog. – Craig Tullis Jul 12 '15 at 05:22
  • I actually detest UX's that force somebody else's aesthetics as an additional layer on top of the operating system's basic UX for the very reason that such constraints often end up suffering from the designer's or another involved party's lack of foresight, ending up crippling the user experience instead of enhancing it. The OS designers have spent far more time studying usage patterns and catering to usability. If your design makes me frustrated, I will find alternatives, and recommend to others that they avoid your product. So ultimately, it is indeed my choice. – Craig Tullis Jul 12 '15 at 05:24
  • "re-orient visual depth to the underlying layer" seems like a red herring. There's only one focal length on a computer monitor, no need to re-focus. If the window is resized, just have a little JavaScript automatically reposition the dialog so it is still on-screen (not so hard). If the user wants to move the dialog mostly off-screen, let 'em. It's their computer. And I 100% AGREE that in very many cases, a modal dialog is probably a symptom of an underlying design deficiency. – Craig Tullis Jul 12 '15 at 05:46
  • @Craig browser modals and browser apps are cross-platform and need not comply with the way your OS works. A draggable modal in windows may not make sense in on a tablet or on a smartphone for a responsive site. You can (and should!) abandon any software whose usage you detest, but the facts work massively and overwhelmingly against your point of view here, because the vast majority of the most popular sites on the web do not offer draggable modals and users have not abandoned them. – tohster Jul 12 '15 at 05:47
  • @Craig actually it's well documented through cognitive focus and inattentional blindness studies that the area of visual focus is very small...often less than about 2 arc degrees in many situations. Also, users do in fact perceive different layers on a screen: that is also well documented for both windowed operating systems and also for browser CSS layers (watch the Google videos on Material Design for example). That's why modern modals are designed with deliberate depth (box shadows) and background masks, to amplify the existing perceptual behavior. – tohster Jul 12 '15 at 05:52
  • @tohster and yet I see plenty of griping here about sucky non-movable modal dialogs, which tells me that part of the reason people aren't abandoning sites is just lack of alternatives. It's a little like presidential elections in Russia. Vote for anybody you want to, just as long as it's the party leader. Which does not mean the party leader is a great person or even particularly good at the job. Most OS's have similar underpinnings. Mobile touch OS's tend to have more lightboxy, modal popups, but the context is very carefully constrained--not true with far too many websites. – Craig Tullis Jul 12 '15 at 05:53
  • @tohster Interesting, then, how modern Flat Design has been taking the world by storm (no "deliberate" depth or shadows, deliberate removal of 3D effects, etc.). All that stuff is so yesterday... ;-) – Craig Tullis Jul 12 '15 at 05:55
  • @tohster I would echo and agree with a sentiment expressed elsewhere here, that in far too many cases a modal dialog ends up being used where it really isn't the right solution. In other words, it might be the wrong design choice in the first place, and making it immovable exacerbates the problem. On the other hand, something like a logon dialog is its own context and is perfectly appropriate as an immovable modal dialog. I'm just saying that just because the designer has a hammer, it doesn't make everything a nail, and rigid thought even with respect to something like this is no virtue. – Craig Tullis Jul 12 '15 at 06:14
  • @Craig I agree with that last point...also your question around flat design is a good one though probably out of scope here so maybe we should take this up in chat. – tohster Jul 12 '15 at 06:19
  • @tohster Agreed, except I'm going to bed. ;-) Note that I didn't say I necessarily like flat design, by the way. – Craig Tullis Jul 12 '15 at 06:23
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.

GreenAsJade
  • 167
  • 6
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.

Mohair
  • 1,439
  • 2
  • 8
  • 5
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.

Gautham Raja
  • 868
  • 4
  • 11
  • 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 Jul 09 '15 at 07: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 Jul 09 '15 at 07: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 Jul 10 '15 at 05:56
  • 1
    @GauthamRaja Respectfully, no it doesn't. – Craig Tullis Jul 12 '15 at 05: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.

micheal65536
  • 286
  • 1
  • 7
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.

Alan
  • 3,848
  • 1
  • 14
  • 32
Jake Pogorelec
  • 11
  • 1
-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.

BDD
  • 3,052
  • 4
  • 23
  • 39
  • 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 Jul 07 '15 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 Jul 07 '15 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 Jul 07 '15 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 Jul 12 '15 at 06: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 Jan 19 '16 at 23:49
  • @hlovdal - I don't think "reading" would be included in the standard definition of "interact", which usually implies having some sort of effect on the thing you're interacting with. Modal dialogs prevent clicks, button presses, taps, etc, on the underlying form... that's what makes them "modal" rather than "modeless". – JDB Jul 19 '17 at 14:06