令人沮喪的設計模式：大型下拉懸停菜單

複雜的網站通常依賴於復雜的導航。 當一個網站包含數千個頁面時，通常結合微型網站和數百個子部分，最終導航將變得更深入和廣泛。 而如此復雜的多級導航，顯示選項的廣度需要相當多的空間。 想想大型電子商務零售商和大型企業網站，它們迎合了許多受眾並擁有大量切入點。

難怪處理這種複雜性的常用方法是讓客戶快速接觸大量導航。 這正是大型下拉菜單在某種程度上成為網絡機構的原因——儘管主要用於復雜和大型項目。 大型下拉菜單本質上是出現在用戶操作上的大型疊加層。 通常它包括混合的鏈接、按鈕、縮略圖，有時還包括嵌套的下拉菜單和疊加層。

幾十年來，這種導航的常見行為是在鼠標懸停時打開菜單。 幾十年來，一個普通用戶對這種模式的抱怨是絕對缺乏對子導航如何以及何時打開和關閉的確定性和控制。

有時子菜單會意外出現，有時會突然消失，有時會在屏幕上停留一段時間，儘管鼠標指針已經在頁面的另一個非常不同的部分，或者完全在另一個頁面上。

為什麼巨型下拉懸停菜單令人沮喪？

大型下拉菜單使用起來很麻煩的主要原因是意圖和期望不匹配。 使用懸停菜單，我們嘗試通過跟踪鼠標行為來推斷特定意圖並採取行動，但我們的客戶在訪問頁面時可能有非常不同的目標和非常不同的限制。

客戶的行為通常是不可預測的，儘管我們的分析可能會講述一個稍微不同的故事，數據點在較長時間內收集並標準化。 我們很少能準確地預測行為。

我們通常探索的常見場景有：

1. 客戶瞄準類別鏈接並直接前往該類別以探索該類別中的子導航項。
2. 客戶將鼠標移向屏幕上的目標，但鼠標必須移動的軌跡覆蓋了一個導航鏈接，該鏈接會打開一個大型下拉菜單。

但是，還有很多其他情況需要考慮。 僅舉幾個：

1. 客戶希望在輸入搜索自動完成時查找大型下拉選項。 為此，他們必須不斷重新打開大型下拉菜單，或使用並排放置的單獨瀏覽選項卡。
2. 客戶可能會使用觸控板（或鼠標）來操作大型輔助顯示器，因此指針移動會更慢、突然且不准確。 這將導致每次用戶在前往頁面頂部的 CTA 或購物車時暫停時，大型下拉菜單會不由自主地打開。
3. 客戶想要打開類別頁面，因此他們前往類別鏈接，單擊它，但由於大型下拉菜單出現延遲而出現閃爍。
4. 使用大型下拉菜單中的嵌套子菜單，客戶希望在他們當前所在的類別中探索類似的項目，但由於嵌套，他們必須一遍又一遍地重新打開大型下拉菜單，並在同樣的懸停隧道一遍又一遍。
5. 想像一下，當您想要調整窗口大小時，就在您將要捕捉到窗口的右邊緣時，一個懸停菜單不斷出現——只是因為您將鼠標光標移動得太近了。
6. 用戶開始慢慢向下滾動以評估頁面上的內容，但菜單不斷彈出。 並且每次用戶移動光標來閱讀大型下拉菜單的內容時，菜單都會意外消失。

問題是我們需要支持所有這些意圖和所有這些事故，但同時我們需要確保我們不會為任何這些情況創造令人討厭和令人沮喪的體驗。 當然，作為設計師和開發人員，我們已經發明了許多技術來解決這個問題。

懸停進入/退出延遲

第一個解決方案，也是最常見的解決方案之一，是引入懸停進入/退出延遲。 我們需要確保菜單不會打開，也不會過早關閉。 為此，我們引入了延遲，通常為 0.5 秒左右。 這意味著我們為客戶提供大約 0.5 秒的緩衝時間：

• 如果需要，穿過軌跡到達遠程目標，或
• 表明他們打算通過留在大型下拉類別鏈接上來探索導航，或者
• 如果他們不小心離開了大型下拉菜單的邊界，請糾正錯誤。

換句話說，只要客戶停留在大型下拉覆蓋範圍內，我們就會繼續顯示它。 一旦客戶將鼠標光標移出子導航覆蓋層至少 0.5 秒，我們就會隱藏覆蓋層。

雖然它解決了頁面意外閃爍的問題，但它會在用戶離開超級下拉菜單超過 0.5 秒的情況下引入延遲。 結果，它減慢了與整個站點上的大型下拉列表的每次交互。 不幸的是，它很快就會變得非常引人注目，尤其是在導航使用很多的情況下。

一些實現添加了淡入/淡出過渡以使巨型下拉菜單的出現不那麼突然，但實際上它導致進入/退出延遲增加到 0.8-0.9 秒，這也引入了更明顯的落後。 ADAC.de 就是一個例子，它具有 100 毫秒的淡入延遲和 300 毫秒的淡出過渡。 （不過，在大型下拉菜單的不同類別之間切換時，這種轉換並不適用。）

顯然，覆蓋層保持可見的時間越長，我們對有意逃離覆蓋層的人的懲罰就越嚴厲。 實際上，這會成為一個問題，因為我們在用戶操作和 UI 響應之間引入了一個表面上的超時。

寬容的鼠標移動路徑：軌跡三角形

與其引入延遲，我們可以嘗試對客戶將要走的路徑更加慷慨。 由於鼠標移動本質上是不准確的，為了最大程度地減少挫敗感，我們可以避免狹窄的懸停隧道並擴大旅行走廊。

例如，我們可以使用亞馬遜的三角形技術，其中我們構建了一個軌跡三角形，將鼠標指針的當前位置與超大下拉區域的邊緣連接起來。 如果該區域應該出現在右側的類別旁邊（如下圖所示），我們將鼠標指針連接到列出類別的容器的右上邊緣和右下邊緣。

只要用戶停留在三角形內或整個大型下拉區域內，疊加層仍會顯示。 如果用戶選擇在三角形之外旅行，超級下拉覆蓋的內容將相應改變。 當然，一旦用戶完全移出類別列表，它就會立即完全消失。

Chris Coyier 在他關於具有更寬泛的鼠標移動路徑的下拉菜單的帖子中強調了這種技術的一些技術複雜性，以及 Alexander Popov 在“Aim-Aware Menus”上的香草 JavaScript 演示。

使用這種技術，我們可以最大限度地減少子導航突然消失和重新出現的摩擦。 但是如果類別鏈接位置太近，或者我們通過將鼠標懸停在更大的按鈕上來顯示懸停菜單，它可能會變得無效。 我們可以對 SVG 路徑出口區域做得更好。

SVG 路徑出口區域

在使用之前的技術計算軌跡三角形時，有時我們不僅會跟踪鼠標指針的確切位置，還會隨著指針的每次移動重新計算三角形——一直如此。 我們可以通過一次計算整個SVG 覆蓋區域並跟踪鼠標指針是否在其中來改進策略，而無需一直重新計算三角形。 一個很好的例子是 Hakim el Hattab 的實現，它根據導航項在屏幕上的位置使用 SVG 動態繪製區域。

Hakim 的解決方案實際上是響應式的，所以如果子導航不適合屏幕，它會浮動在主導航項旁邊，以全寬或全高顯示。 SVG 路徑區域將相應地重新計算，但前提是用戶垂直或水平滾動。 您可以在 Hakim 的菜單模式調試視圖模式中看到該技術的工作演示。

雖然這個選項是精確的，並且完全消除了我們看到的懸停延遲的滯後，但當客戶不小心穿過一個大型類別列表時，它會導致閃爍，這會提示在每個導航項上打開大型下拉列表。

同樣，問題的根源在於客戶無法控制大型下拉菜單何時打開和關閉，他們也無法了解這些菜單何時出現或消失。 這種缺乏可預測性通常會導致錯誤和挫敗感。 但有時大型下拉菜單有更深層次的、隱藏的可訪問性問題。

懸停時打開的巨型下拉菜單的陷阱

如上所述，上面列出的所有技術都有相同的目標。 他們試圖預測用戶打開和關閉導航菜單的意圖，依賴於對鼠標移動速度、停留在單個區域的持續時間或屏幕上的確切位置的一些觀察。 對於某些客戶來說，這些預測有時會失敗，而且對此也無能為力。

懸停時打開的大型下拉菜單有很多可訪問性問題。 顯然，我們需要支持僅使用鍵盤的用戶在超級下拉菜單中的導航，並且我們需要確保項目也能正確地向屏幕閱讀器宣布。 但在總體佈局方面，我們需要謹慎放置mega-dropdown的位置。

搜索被大型下拉菜單中斷

如果任何重要的功能顯示在離大型下拉導航足夠近的地方，這通常會引起大量的麻煩和投訴。 例如，如果在大型下拉區域上方顯示搜索欄，這最終會導致令人難以置信的摩擦和挫敗感。

除非使用了足夠長的懸停進入/退出延遲，否則巨型下拉式覆蓋將始終阻礙搜索和搜索結果之間，就像下面的 Thesauraus.com 上的情況一樣。 每次用戶從搜索欄移向結果（並返回）時，大型下拉菜單都會阻礙。

多個子導航出現延遲

當在懸停延遲時打開多個子導航時，體驗會很麻煩，一個接一個。 下面的沃達丰網站就是一個不幸的例子。 如果在這種情況下，每個導航項也充當到該類別的獨立鏈接（除了打開一個大型下拉菜單），我們應該期待整個網站上大量的憤怒點擊。

在上面的示例中，有 4 級導航顯示在彼此下方，其中 2 級在懸停時打開，過渡時間為 300 毫秒。 同時，由於每個分類標題也是分類頁面的鏈接，用戶也可以直接跳轉到分類頁面。 但是一旦他們點擊了——在他們等待新頁面出現的時候——懸停菜單將短暫地呈現半損壞的外觀——通常沒有足夠的時間轉換到正確的視圖以供客戶註冊。

再加上用戶稍舊的設備上的任何內存或處理問題、幾個繁重的瀏覽器擴展以及在後台運行的防病毒檢查，整體體驗將很快變得難以忍受。

此外，由於第 4 級導航只有在第 3 級導航已經打開時才會在懸停時出現，而第 3 級導航只有在第 2 級導航已經打開時才會在懸停時出現，所以在第 4 級導航的頁面之間移動級別，用戶必須一遍又一遍地重新打開導航並記住他們之前單擊的位置以將隧道懸停到第 4 級別。

我們基本上將我們之前談到的延遲和懸停隧道問題加倍，總是讓用戶等待導航出現，並在導航出現後要求他們在懸停走廊內非常精確。 這就是沮喪的來源。

如果您確實必須處理這種複雜的導航，那麼當只使用一個（而不是兩個）懸停菜單時問題是否消失可能值得測試。 該菜單會稍大一些，並將所有選項都包含在列中。 或者，如果可能，對於每個類別，考慮將該類別中的所有導航選項顯示為永久導航欄（側邊欄或粘性頂部欄）——通常它應該完全消除所有這些問題。

類別標題做了太多事情

正如我們之前看到的，有時類別標題有兩種不同的功能。 一方面，每個類別標題都可以鏈接到該類別的頁面，因此客戶可以單擊它們直接進入該頁面。 另一方面，他們也可以打開一個大型下拉覆蓋。 因此，如果用戶將鼠標懸停在標題上足夠長的時間，大型下拉菜單將打開，但用戶可能已經點擊了鏈接，這將導致閃爍。 對於客戶來說，當界面沒有真正提供任何提示時，很難有正確的期望。

有幾個選項可以解決此問題：

1. 為了表明該類別的標題是一個鏈接，加下劃線可能會有所幫助，
2. 為了使類別標題和下拉列表之間的區別更加明顯，添加一個垂直分隔符（例如垂直線）和一個圖標（V 形），
3. 讓類別的標題只打開超大下拉菜單，並在超大下拉菜單中添加指向類別“主頁”部分的鏈接。 它也可以是一個突出的“查看所有選項”按鈕（參見上面的《衛報》示例）。

如上所述，有時您會看到一個額外的圖標用於指示菜單打開了一個覆蓋，而類別的標題是一個鏈接。 在我們的可用性測試中，我們注意到無論何時出現圖標（無論是哪個圖標），用戶通常都會在心理上區分單擊圖標將提示的操作和提示的操作通過單擊類別標題。

在前一種情況下，他們通常希望打開一個下拉菜單，在後一種情況下，會出現類別頁面。 更重要的是，他們似乎希望菜單在點擊/單擊時打開，而不是懸停。

Mailchimp 是一個很好的大型下拉列表示例，它避免了上述大多數問題，類別的標題僅用於打開一個大型下拉列表。 具有:focus樣式的鍵盤用戶可以訪問下拉列表。 選擇後，每個類別都會突出顯示為下劃線，這可能會導致某些人認為標題已變成鏈接，尤其是因為下劃線與導航頂部的“定價”鏈接完全相同。 也許用背景顏色突出它會更防彈。 懸停菜單的一個很好的參考示例。

一般來說，避免使用多個功能重載類別標題似乎是一個好主意。 這不僅適用於大型下拉菜單，而且幾乎適用於所有菜單，包括手風琴或工具提示：整個區域應作為擴展，在點擊或單擊時顯示導航選項。 在大多數情況下，這種方式更簡單，更不令人沮喪。

設計更好的大型下拉菜單：點擊/單擊菜單

大型下拉菜單經常在懸停時打開的常見原因之一是因為許多大公司希望讓他們的客戶快速了解網站上可用的廣泛選項。 隨著懸停時導航選項的變化，我們可以更快地顯示更多選項，客戶也可以更快地探索更多選項。 這就是為什麼很難想像沒有大型導航覆蓋的大型電子商務零售商，例如。

但是，如果將懸停導航替換為點擊/點擊導航，則最好測試參與時間和點擊率是否保持不變（或增加）。 事實上，上面列出的大多數問題都可以通過這樣做輕鬆解決：只有當用戶明確提示此特定操作時，大型下拉覆蓋才會打開和關閉。 因此，無需跟踪鼠標指針，或微調懸停進入/退出延遲。 另外，由於無論如何都沒有懸停在移動設備上，我們需要提供一個選項，以便在點擊/單擊時以一種或另一種方式打開移動設備菜單，因此我們也可以將其保持這種方式用於更大的屏幕。

柏林猶太博物館網站就是一個很好的例子。 頂部導航欄不僅可以通過點擊打開大型下拉菜單，而且基於圖標的側邊欄導航也是如此。 此外，由於用戶必須主動打開/關閉覆蓋，我們可以使用:focus / :active樣式突出顯示所選類別。

該網站不使用任何圖標來指示菜單可以打開或關閉，並且菜單選項不是驅動到單獨頁面的鏈接。 這使得整體體驗非常平靜和可預測，儘管與懸停菜單相比，顯示導航選項的速度可能較慢。

但是，由於該網站沒有很多導航選項可供顯示，這似乎運作良好。 這是一個很好的參考示例，在處理通過點擊/單擊打開的可訪問大型下拉菜單時要牢記。

如果你有更多的導航，一個稍微高級一點的例子是 Allianz.de。 子導航不是使用一個大型的大型下拉菜單覆蓋，而是分組為較小的下拉菜單。 但是，菜單並不總是顯示每個類別的所有選項。 相反，它突出顯示了最重要的選項，並在底部提供了查看所有選項的鏈接。 唯一可能缺少的細節是一個 V 形，表示單擊時會出現一個下拉菜單。

在移動設備上，mega-dropdown 是一組手風琴，可以很好地選擇顏色對比和縮進來指示導航的層次結構。 每個手風琴一次不會顯示超過 4 個導航項。 一個很好的複雜的大型下拉導航的參考示例，效果很好。

如果您正在尋找技術實現，您可以查看 In Praise of the Unambiguous Click Menu，其中 Mark Root-Wiley 展示瞭如何構建可訪問的點擊菜單。 想法是開始將菜單構建為純 CSS 懸停菜單，使用li:hover > ul和li:focus-within > ul來顯示子菜單。

然後，我們使用 JavaScript 創建<button>元素，設置aria屬性，並添加事件處理程序。 最終結果可作為 CodePen 上的代碼示例和 GitHub 存儲庫獲得。 這也應該是您菜單的一個很好的起點。

手風琴與覆蓋與移動上的拆分菜單

不用說，並不是每個點擊/點擊的大型下拉菜單都表現良好。 Target.com 是另一個有趣的示例，可訪問的大型導航避免了多列佈局，並且在時間上只顯示一個導航級別——所有導航都在點擊/點擊時打開。

下拉菜單一次僅在一列中顯示選項，因此當您在類別中移動時，您始終保持專注於屏幕上的同一疊加層。 每個選定的部分都會佔據整個列。 體驗是可預測的和平靜的，但客戶可能再次看到較少的導航。

來自丹麥的公共交通服務網站 Dinoffentligetransport.dk 使用了多個欄目，頂部的導航與 V 形圖標相輔相成，並且也可以通過點擊/點擊打開。

在一些其他實施方式中，可以看到多個重疊出現在彼此之上。 事實上，聯合利華就是這種情況（下例）。 大型下拉菜單在點擊/單擊時打開，同時顯示多個 V 形。 每個人字形代表什麼？ 客戶點擊它們時應該期待什麼？

“我們的品牌”指向一個單獨的頁面，而它下面的每個標籤都會在大型下拉列表的頂部打開一個新的導航覆蓋。 您是否注意到“所有品牌”帶有下劃線，而導航選項的其餘部分沒有？ 可以看出設計師創建菜單的意圖。 事實上， “所有品牌”是一個鏈接，而其他標籤則打開一個疊加層：

有了所有這些選項，我們將如何在移動設備上顯示大型下拉導航？ 事實證明，在移動設備上對此類大型下拉疊加進行分組是很困難的：通常沒有足夠的空間或視覺輔助來以不同的方式突出顯示不同的級別並使其易於區分。 在上面的示例中，可能需要一段時間才能確定我們實際到達了哪個頁面。

正如我們在 Dinoffentligetransport.dk 上看到的那樣，使用手風琴方法可以更容易地理解我們目前處於哪個級別以及我們有哪些選擇。 但是，最好在每個小節中為鏈接添加下劃線，因為它們會將客戶引導至該類別的頁面。 此外，整個類別欄應該可以點擊並展開手風琴。

在上面的示例中，大多數時候我們可能一次只能顯示有限數量的導航部分。 但是如果每個部分的標題都比較短，我們可以將屏幕水平分割，同時顯示多個級別。 LCFC.com 就是這種模式的一個很好的例子。

哪個選項效果最好？

以我個人的經驗，當我們比較移動設備上的巨型下拉菜單的實現時，垂直手風琴似乎比疊加（無論是單列還是多層）更快且更可預測。 拆分菜單似乎比手風琴更快，更可預測。

手風琴和拆分菜單都有一些優點：

• 無需顯示“返回”按鈕即可返回父頁面。
• 每次跳轉時，眼睛都不必在導航菜單的頂部和部分的子導航之間跳轉。
• 客戶可以更快地在多個級別之間導航：他們可以跳到他們覺得有趣的手風琴，而不是多次點擊“返回”。
• 客戶可以同時探索多個部分（除非實現會在打開另一個手風琴時自動關閉一個手風琴）。 覆蓋是不可能的。

一般來說，手風琴和拆分菜單似乎是更好的選擇。 但是當有很多導航時，它們似乎不能很好地工作。 每當每個類別有超過6-7 個項目時，最好在另一個手風琴（或單獨的頁面上）的 6-7 個項目下方添加一個“瀏覽全部”按鈕，或者使用覆蓋。

因此，根據導航的數量，我們可以從 split-menus 開始，然後如果它不可行，則轉到手風琴，如果導航仍然變得複雜，最終將手風琴變成覆蓋。

當最終可能不需要大型下拉菜單時

我們已經在上一篇文章中引用了 Gov.uk 團隊的工作，但他們的見解在大型下拉菜單中也很有價值。 對於大型、多層次的導航，團隊決定採用表單專家 Caroline Jarrett 的每頁一件事原則的發現。 根據 Caroline 的說法，“從設計師的角度來看，自然會'一起'的問題 [...] 不需要在同一頁面上為用戶工作”。 Caroline 主要將其應用於 Web 表單的設計，但我們也可以將其應用於導航的上下文中。

因此，這個想法是完全避免複雜的大型下拉菜單，並為客戶提供一種清晰、結構化的方式來瀏覽網站的溝渠，從一個頁面到另一個頁面。 就 Gov.uk 而言，它似乎是通過一個經過深思熟慮的信息架構和指南來實現的，引導訪問者通過可預測的步驟實現目標。

Kanton Zurich 使用相同的模式。 所有選項都以結構化方式顯示，而不是多層下拉導航，主要主題在頂部顯示為“熱門主題”，每個部分內的導航顯示為頂部的粘性導航欄。

另一種方法是使用“我想要”導航模式。 除了傳統的導航，我們還可以提供一個“導航下拉菜單”，讓客戶可以構建他們選擇的導航查詢，並直接被引導到他們正在尋找的頁面。 基本上，它是一系列下拉菜單，出現在另一個下拉菜單下，讓用戶選擇他們打算在網站上執行或查找的內容。

有一段時間，Commonbond 上使用了該模式（參見上面的視頻），Corkchamber.ie 上也使用了它。 一種有趣但非常規的方式來提供對深層導航的訪問，而無需使用大型下拉菜單。

大型下拉導航設計清單

每次我們提起關於大型下拉菜單的對話時，每個人似乎都在幾個小組中安頓下來：一些同事喜歡懸停，另一些喜歡點擊和點擊，一些喜歡兩者兼而有之，而另一些則不介意，只要有既是一個類別鏈接，也是一個打開菜單的圖標。

不可能說一種方法總是比其他方法更好，但在技術實現和用戶體驗方面，點擊/點擊打開菜單通常會減少麻煩和挫敗感，同時允許簡單的實現，從而導致在可預見和平靜的航行中。 在移動到懸停菜單之前，我們可以嘗試先保持點擊/點擊行為，衡量參與度，然後研究是否需要懸停。

和往常一樣，在設計和構建大型下拉菜單時，請牢記以下一些一般事項：

• 避免將重要的、經常使用的項目靠近大型下拉導航（例如搜索欄、CTA、購物車圖標）（如果懸停），
• 避免在巨型下拉菜單中出現多個子導航並延遲出現（如果懸停），
• 避免使用多種功能重載類別標題。
• 在類別標題下劃線以將它們標識為指向類別頁面的鏈接（當然，如果它們鏈接到類別頁面）。
• 如果可以，請在每個子類別中添加“主頁”鏈接或“瀏覽全部”按鈕，而不是直接鏈接類別。
• 避免水平覆蓋並考慮用垂直手風琴和拆分菜單替換它們，
• 添加一個圖標以指示類別標題在點擊時觸發大型下拉菜單（例如 V 形），並始終使其足夠大以方便點擊（例如 50×50 像素），
• 當大型下拉菜單出現/消失（最多 300 毫秒）時，避免長時間的淡入/淡出過渡，
• 考慮測試結構化指南或導航查詢（“我想要”導航模式），而不是或附加到大型下拉列表。
• 如果可能，請避免使用大型下拉懸停菜單。