模態彈框是否應該可以拖動？

01-23

模態對話框/彈框（Modal Dialogue Box）是什麼？

模態對話框強制要求用戶回應，否則用戶不能再繼續進行操作，直到與該對話框完成交互。

什麼時候會有拖動模態彈框的需求？

由於模態彈框出現後，就無法操作彈框以外的區域，因此拖動彈框的需求只會是：

在與彈框交互的同時，需要拖動彈框查看底部被遮擋的界面內容。

因此，我的理解是：

A. 如果沒有以上需求，則不需考慮拖動

讓用戶專心於彈框中的任務，此時最好能將此對話框設計成看起來就不可拖動。如：

B. 如果有以上需求，則必須讓彈框可拖動

由於用戶有需求，所以會很自然地嘗試去拖動，此時設計只需要給予適當的隱喻（頂部有 titlebar，滑鼠移到頂部游標變化等），即可達到目的。

有趣的是，Apple 在 OS X Human Interface Guidelines: Dialogs 一章中講到系統級對話框，其中的模態對話框 Document modal 和 App modal，剛好對應了「不可拖動」和「可拖動」兩種情形：

另外，由於彈框的打擾性很強，在實際做設計時，最好先想清楚：是否只能用彈框的形式？然後再考慮：設計什麼樣的彈框能更好地滿足這個設計目的？需要考慮的因素包括彈框樣式、底部是否有遮罩、能否被拖動、彈框大小，彈框位置等等。

—

附：問題背景和自我推翻

這個問題提出的背景是我們一坨人的一次午飯討論，大家各有各的看法，但總體基本傾向於「模態彈框應該可以拖動」，持該觀點的人包括我，當時我所深信不疑的幾個理由包括：

因為彈框浮動在下方的內容之上，看起來應該是可以拖拽移動的。
用戶受系統級窗口的交互習慣影響，認為有頂欄的就可以被拖動，因此看到有頂欄的模態對話框，會有類比心態。
拖動雖然沒什麼用處，加上後覺得不能拖的不會去拖，沒有什麼損失；但那些覺得可以拖的人，拖動了，就會很爽。

然而過後頭腦冷靜下來想一想，發現這些理由並不可靠。理由 1 和 2 均是建立在「一個有頂欄、浮起的、看起來可以拖動的模態彈框」的形式之上的推斷。反過來想，如果一個彈框被設計成另一種看起來就不可拖拽的形式，是不是用戶就應該認為它不可拖拽了呢？即形式決定了預期。對於理由 3，用戶為什麼會需要一個沒什麼用處的功能？（在設計了符合預期的樣式下）依然認為這個對話框可以拖動的人，如果發現拖動不了，會產生很嚴重的後果嗎？還是只是少數幾個人心理上接受不了的問題？

推翻後回到問題原點，寫了這篇回答，歡迎繼續探討~

在程序運行的過程中，如果出現了模態對話框 / 彈框，那麼將無法對主窗口進行交互，直到模態對話框退出才可以操作。

我認為模態彈框是否拖動需要看具體使用場景來進行定義。然後根據需求場景，在設計上需要明確區分可拖動和不可拖動的彈框樣式，合理的視覺樣式以便讓用戶在對彈框進行交互時有個心理預期。

主窗口和模態彈框有直接或間接的上下文聯繫，即可拖動。

所謂上下文聯繫，即主窗口內容與模態彈框內容有關聯或相呼應的。比如知乎寫作模式中的「插入圖片」模態彈框（如下圖），用戶在調起「插入圖片」彈框時，如果需要對文字內容進行回顧的需求，那麼會下意識地拖動彈窗對文字內容進行回顧，再選擇相應的圖片進行插入操作，因此有上下文聯繫的彈窗應該是可以拖動的。

而彈窗的視覺樣式設計必需得讓用戶感知到可以拖動。

「插入圖片」模態彈框 — 知乎寫作模式

主窗口和模態彈框沒有上下文聯繫，則不需要拖動。

比如 Design+Code 中的 Buy the book 和 YuTube Gaming 中的 Switch accounts 彈窗，與主窗口內容是沒有關聯的，拖動該彈窗的需求幾乎沒有，這時更應該讓用戶專註彈窗內容本身，因此沒有上下文聯繫的彈窗是可以不需要拖動的。

而彈窗的視覺樣式必需設計成不會讓用戶感知到可以拖動。

Design+Code 和 YuTube Gaming 模態彈框

那麼問題來了，如果全部模態彈窗都可以拖動，也沒問題吧？

我認為具體問題還是具體分析，比如：

在「移動端」上，即使模態彈框與主界面有上下文聯繫，無論 App 或者 Web 中相應的模態彈框都不應該拖動。畢竟移動端的屏幕與操作自由度都較小，拖動窗口就顯得有點牽強，相比下則更需要用戶對當前展現的內容保持專註，所以用戶潛意識有對彈窗進行拖動的想法就極其之小，拖動的意義已經不大。
在「桌面操作系統」上，屏幕區域比較大，而應用程序的交互自由度比較高，所以大部分模態彈窗是可以進行拖動是沒有問題的。
在「桌面 Web 」上，各家網站的模態彈窗能拖與不能拖的規則都不太一樣，我個人更希望是如上表達的觀點。

以上觀點只是我個人對模態對話框 / 彈框（Modal Dialogue Box）的理解，所以不是絕對答案

個人認為模態彈框是應該在任何情況下都能拖動的。

首先，需要看到底部內容的彈框是一定要能夠拖動的，而不需要看到底部內容的彈框可以分為兩種，第一種是需要佔用大面積的彈框，比如 Twitter 的私信和 Medium 的關注人列表：

這種彈框佔據了整個頁面的面積，但這種情況更應該做成一個單獨的頁面，Twitter 和 Medium 的設計都有些問題：

比如 Twitter 的私信入口是頂部標籤的位置，點擊以後卻出現了一個彈框；而 Medium 關注人列表由於全屏幕都是彈框，關注人數目很多，導致右側的滑動條變成了兩個挨在一起：

這種情況下，頁面內容所需要的面積很大，而且不是需要用戶首先完成的操作，所以這種情況根本就不應該使用彈框。如果是需要用戶首先完成的操作同時又要佔用很大的面積，可以在一個單獨的頁面里再進行引導。

另外一種情況是彈框所需要的面積很小，通常是提示用戶確認是否刪除某個東西或者取消某個操作，或者容納一兩個輸入框這類的彈框。這種彈框的確可以做成看起來完全不能拖動的形式，比如 Windows 的彈框:

或者 OSX 在單個文檔窗口的這種彈框：

這種彈框的做法概括起來都是讓彈框的四邊中的一部分和窗口連接起來，使得彈框本身和窗口看起來是一個整體，所以不會讓人產生能夠拖動的感覺。但這種彈框並不能解決所有問題，比如 Windows 的彈框看起來兩邊的空間非常的空，而 OSX 的這種彈框在 Web 端多半是不適用的。

除此之外的做法，比如 Airbnb 這種：

個人認為這種將頂欄、漸變、陰影都去掉的彈框依然會讓人產生能夠拖動的感覺，因為無論如何這種彈框看起來都是將一個卡片疊加在原本的窗口上，所以只要是這樣的情況就會讓人產生能夠拖動的預期，如果有這種預期，就應該把它做成能夠拖動的彈框。另外，個人認為將模態彈框做成可拖動的並不會分散注意力，因為模態彈框本身就是禁止了彈框外的所有操作的，在彈框上多一個或者少一個能夠拖動的功能對用戶注意力的影響應該是不大的。

可以不能拖動，只要你確定用戶一定能完成操作。

見過太多 ** 網頁沒處理極端解析度，把模態對話框塞到用戶戳不到的地方去的情況了。（我就是喜歡用手機訪問你打我呀）

視場景而定。PC上應用程序級別的模態對話框大多數是可以拖動的。系統級模態對話框兩者都有，比如Windows登錄界面（全屏彈窗）不可拖動，UAC對話框則可以拖動。

有一個不成文的慣例：有標題欄的彈窗一般都是可以拖動的，沒有標題欄的彈窗則不可拖動。但在網頁上又不一樣了 - 目前的網頁上，常見元素一般都是不可拖動的，當然要是做成可拖動且沒有bug的話，體驗會更好。

分情景，當用戶需要看到被遮擋的內容時可以拖動常見於PC—web，但是這僅僅處於一種模態窗口不太緊急時的情況，但是這種情況個人認為是一個糟糕的設計，因為窗口的內容完全可以融入到頁面的UI當中，如果是緊急情況或者需要馬上處理這樣的情況用戶的注意力應該在窗口上所以拖動就毫無意義，在c/s（客戶端應用）中彈框是可以移動的因為彈框常常不存在模態形式，並且需要配合桌面工具一起操作，這是可以的。

另外就是我們最熟悉的移動設備，由於屏幕太小的原因它大多數不支持拖動，移動設備一定要做到引人注意才行所以必要時才會彈窗，彈窗是優先順序最高的，不要試圖移動它。

為什麼要拖動彈窗？難道用戶不是儘快地想彈窗消失嗎？看到彈窗我就焦慮了，你還讓我去拖動它...

能拖動的應該是窗口，是可以和當前操作並行的，彈窗是當前操作的一個狀態，以便用戶能繼續下一步操作，不應該能拖動。

彈框不動的話，背景為什麼不黑屏，這樣不是更專註於任務么？模態窗口也是要聯繫上下文內容的，移動是一定要有的。另外個人覺得工具是不要限制人挪來挪去點點戳戳的本能。