#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.

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.

#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:

• 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.

• User moves the dialog in order to see content underneath. This may sound like a good thing for UX, but it is more often a result of poor dialog design. The whole point of a modal interaction is that it is meant to be self-contained and blocking. So allowing users to deliberately or habitually circumvent the modality (even to get information underneath) is often an excuse for bad modal/workflow design to begin with...for correct modal design, the relevant information should be contained inside the dialog so that the user can perform her task without needing to look for information elsewhere.

  • If folks are interested in more details here, leave a comment and I'll expand since modal design and IA is pretty well studied.

• 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.

#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.