Should modal dialogs be movable?

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?

Answer

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.