Day 13｜手機版不是把 Sidebar 縮小：Header、Navbar、Sidebar 與 Bottom Navigation 怎麼分工

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天把邀請成員和建立活動的輸入流程接起來後，我順手把瀏覽器縮到 360px。桌面那條 Sidebar 依然很有自己的想法，硬是占著半張畫面。

內容區已經快被擠成收據了，它還站得筆直。

問題來自一開始的需求：

做一個 SaaS 後台的側邊選單和手機版選單。

原始實驗在 2026 年 7 月 24 日使用 Codex Desktop 完成，當時沒有保存第一張畫面。為了保留可檢查的基準，我在 7 月 27 日用當日 GPT-5 系列模型重跑同一句 Prompt，沒有補目的地頻率、手機優先順序與焦點規則。

圖 1：第一版桌面很像管理後台，手機也真的「有選單」。問題是每個目的地都被當成一樣重要。

有一說一，單看桌面版，它大概有七八十分：品牌、側欄和目前頁的底色都在，看起來也頗像一套正經 SaaS 後台。

切到手機後就不是這回事了：

• 完整 Sidebar 直接縮進左側，正文只剩一小條。
• 概覽、專案、活動紀錄與設定一起搶空間。
• 目前頁只靠底色表達，顏色不明顯就很難辨認。
• 畫面提供了「手機選單」，卻沒有替手機使用者決定什麼最值得留下。

AI 第一版不是少做一個元件，而是少做一層判斷：同一批目的地到了不同裝置，應該怎麼重新分工？

我把這個問題整理在 桌面與手機導覽架構比較頁 ：

圖 2：畫面上的元件都能帶人前往別處，但它們負責的層級、頻率和裝置完全不同。

先算目的地出場幾次，不要先列一張元件購物清單

我先把 LumenDesk 的使用情境攤開：概覽、成員與專案會頻繁切換；設定和活動紀錄必須找得到，但不值得長住手機底部；搜尋、帳號與通知則是跨頁都可能使用的工具。

這張表才是真正需要交給 AI 的資訊架構。只寫「要有 Header、Sidebar 和手機選單」，講的是零件；補上頻率、層級與裝置，才是在交代零件怎麼一起工作。

六個常見名稱也不在同一層競爭。它們各自接住不同問題：

這張角色表不是要 AI 把六種元件全部裝上去。剛好相反，它的用途是排除不需要的候選：同一批主要目的地通常只需要一套主導覽，其他元件負責補上跨頁工具、手機入口與目前位置。

Header 與 Navbar：一個管跨頁工具，一個只適合少量平行目的地

Header 元件頁 裡放的是品牌、目前工作區、帳號，以及手機版的主選單入口。這些內容有一個共通點：使用者走到哪一頁，都可能需要它們。

圖 3：Header 承接跨頁共用內容；搜尋條件、儲存與匯出等頁面操作，仍留在各自內容區。

Header 很容易變成 UI 雜物抽屜。搜尋、篩選、儲存、匯出、通知、語言和深色模式全部排成一列，每個功能都在，真正要用時卻像在工具箱底部撈螺絲。

判斷方式很直接：只屬於目前頁面的操作，就留在頁面裡；跨頁共用的入口，才值得進 Header。手機版的 Header 還要提供完整導覽入口，但不用把整份網站地圖直接攤在頂部。

Navbar 元件頁 則適合少量、同層級而且常往返的目的地，例如概覽、成員、專案。

圖 4：Navbar 適合少量平行頁面；項目開始折行或需要分組時，就代表它已經扛不住。

Navbar 的空間不是吃到飽。當目的地長到八九個、名稱開始折行，或需要分成「工作區」與「管理」兩組時，應改由 Sidebar Navigation 承接結構，低頻項目再退到完整選單。

LumenDesk 沒有同時採用 Navbar 與 Sidebar，因為它們會重複呈現同一批主要目的地。這不是「多一條路總比較方便」：兩套主導覽若名稱、順序或目前頁狀態不同步，使用者反而得先判斷哪一套才算數。

因此我的選擇是：

• 只有 2～4 個平行頁面時，使用 Navbar，拿掉 Sidebar。
• 目的地較多、需要分組或層級時，使用 Sidebar，拿掉重複的 Navbar。
• Header 保留跨頁工具，不拿來補成第三套主導覽。

桌面 Sidebar 不只是一條灰色區域，而是資訊架構

桌面主要導覽交給 Sidebar Navigation 。LumenDesk 把概覽、成員、專案放進「工作區」，活動紀錄與設定放進「管理」。

圖 5：桌面 Sidebar 將工作區與管理項目分組，也提供收合與目前頁標示。

Sidebar 能同時呈現較多目的地、群組與層級，也可以收合，替內容區讓出空間。但收合不是把導覽名稱一起刪掉。使用者必須能再把它展開，只剩圖示時也要知道每個入口通往哪裡。

第一輪收合很順，連結名稱卻一起蒸發

2026 年 7 月 24 日，我按下「收合側邊導覽」。側欄成功縮成圖示列，正文仍顯示目前在「成員」，展開按鈕也留在原位。只看截圖，很容易讓它過關。

接著檢查瀏覽器可存取結構，才發現部分導覽入口只剩沒有名稱的 Link。

視覺使用者也許還能猜圖示，鍵盤與螢幕閱讀器使用者卻失去了「概覽、成員、專案」這些目的地名稱。原本只要求 Tooltip 不夠，我把條件改成：收合後，每個 Link 在可存取結構中仍保留原本名稱。

同一頁若有不只一組 <nav>，還要提供可區分的名稱，例如「主要導覽」與「側邊導覽」。不然輔助科技一路讀下去，只會遇到好幾個都叫 navigation 的區域。 W3C WAI：Landmark Regions

AI 做出收合動畫，只能算完成一半。連結名稱留得住、收合按鈕能說明目前狀態，這個 Sidebar 才真的完成收合。

手機 Bottom Navigation：目的地與「更多」操作不能混成一類

手機空間少，不適合把完整 Sidebar 原封不動搬過去。LumenDesk 將「概覽、成員、專案」三個高頻目的地留在 Bottom Navigation ，設定與活動紀錄則由 Header 的完整導覽進入。

圖 6：Demo 底部有三個目的地與一個「更多」開關；正式規格會把完整選單統一交給 Header。

網站 Demo 保留一個「更多」開關，正好暴露出命名問題：前三個項目會前往頁面，第四個只是打開完整選單。它們雖然排在同一列，並不是四個同等重要的目的地。

正式規格因此只讓三個高頻目的地住在底部。「設定、活動紀錄」沒有消失，只是退到第二層。Android 的 Navigation Bar 指南也將這類元件用在精簡視窗中的三到五個重要目的地。 Android Developers：Navigation bar

Bottom Navigation 一旦塞到六個、八個入口，標籤與點擊範圍都會開始縮水；若又混入「建立」「搜尋」「更多」等命令，使用者在按下前還得猜這次會切頁，還是會打開另一層介面。固定在底部不代表責任相同。

完整導覽用 Navigation Menu／Drawer，但別誤套命令 Menu

低頻目的地仍然需要找得到，只是不必一直占著底部。LumenDesk 由 Header 的「開啟主選單」按鈕展開完整導覽，內容包含活動紀錄與設定。

圖 7：Navigation Menu 暫時收納低頻連結；除了打開，也必須交代展開狀態、關閉方式與焦點返回。

如果內容只是一般頁面連結，用 Disclosure Navigation 或 Drawer 裡的連結清單就夠了。不要因為名稱裡有 Menu，就硬套桌面軟體命令選單的 menu／menuitem 模型；那會多出方向鍵、焦點管理與角色規則，而且不符合一般網站導覽的連結預期。

手機 Drawer 除了打得開，還要能用 Escape 關閉，點選目的地後也應收合；關閉時，焦點回到原本的開啟按鈕。使用鍵盤的人才不會在選單消失後，連自己站在哪裡也一起弄丟。 W3C WAI：Disclosure Navigation

這裡的重點不是名稱一定叫 Navigation Menu 或 Drawer，而是它裝的是導覽連結，不是「刪除、重新命名、匯出」這類命令。命令選單會留到後面的文章再處理，今天不要先把兩種互動模型攪在一起。

不同導覽不能各說各話：目前頁要同步

使用者切到「成員」時，Sidebar、手機底部導覽、完整選單與頁面標題都要說同一件事。這就是 Current Page Indicator 的責任。

圖 8：多組導覽指向同一個目前頁，可見樣式與 aria-current="page" 也要同步。

目前位置不能只靠一點不太明顯的底色。文字、圖示、背景或外框可以一起提供差異；程式結構則用 aria-current="page" 交代目前頁。 W3C WAI：ARIA26

一套導覽若回答不了「我在哪裡」，使用者即使找得到入口，也容易懷疑剛才到底有沒有切換成功。多套導覽並存時，還要共用同一份目前路由狀態，不能 Sidebar 指著成員，手機底部卻還亮著概覽。

改寫 Prompt：不是多加選單，而是把跨裝置責任寫完整

為 LumenDesk 團隊工作區建立一套響應式全站導覽。先依目的地頻率與層級分工，不要把桌面 Sidebar 直接縮到手機上。

桌面版：
- Header 左側放品牌 LumenDesk，右側放帳號入口與跨頁工具；目前頁面的搜尋、篩選、儲存與匯出留在內容區。
- Sidebar Navigation 作為唯一主要導覽：概覽、成員、專案分為「工作區」；活動紀錄、設定分為「管理」。提供收合按鈕，收合後仍可用同一按鈕展開。
- 不要再用 Navbar 重複顯示同一批目的地。若產品只有 2 到 4 個同層級目的地，可改用 Navbar，並移除 Sidebar。

手機版：
- Header 保留品牌、帳號與「開啟主選單」按鈕。
- 點擊後以 Drawer 顯示完整導覽連結；Escape、點擊關閉或選取目的地後可收合，關閉後焦點回到開啟按鈕。
- Bottom Navigation 只固定顯示概覽、成員、專案。設定與活動紀錄留在 Drawer，不要再放一個假裝是目的地的「更多」。
- Drawer 裡是一般頁面連結，不要套用桌面命令 Menu 的 menu／menuitem 角色。

狀態與驗收：
- 每一組導覽都以文字與可見樣式標示目前頁，並在目前連結加上 aria-current="page"。
- 不同導覽區域使用有名稱的 nav，例如「主要導覽」與「側邊導覽」。
- Sidebar 收合後只隱藏可見文字，不得移除連結的可存取名稱。
- 360px 下，Sidebar 不與正文並排，整頁不得水平溢出。
- 不使用只有顏色才看得懂的目前頁狀態。

這版沒有規定 Sidebar 要幾個像素，也沒有要求更多動畫。真正改變結果的，是每個入口在桌面和手機上的工作，以及關閉、收合與切頁後怎麼驗收。

第二版先救回手機，再補上收合名稱

重新分工後，桌面 Sidebar 可以收合，手機也不再把完整側欄和正文並排；360px 下沒有整頁水平溢出。

圖 9：手機把完整清單交給 Header 的 Drawer，高頻目的地則留在底部。

第一輪複測仍有一項沒過：部分收合後的圖示連結失去名稱。補上「只隱藏可見文字，不得移除可存取名稱」後，我在 2026 年 7 月 27 日重新檢查，概覽、成員、專案、活動紀錄與設定五個 Link 都保留完整名稱；展開／收合按鈕的名稱也會跟著狀態切換。

目前仍未驗證的是正式螢幕閱讀器實聽與 200% 縮放。DOM 有 aria-label，不能直接替這兩項蓋章；同樣地，已修正並複測的入口名稱，也不該繼續寫成目前失敗。

交付前，我至少會重跑三個動作：

1. 收合 Sidebar，再把它展開，確認每個入口名稱仍在。
2. 切到「設定」，確認不同導覽與頁面標題同步指出設定。
3. 縮到 360px，開啟 Drawer 後按 Escape，確認焦點回到觸發按鈕。

這三步能走完，才算從「有做手機版」往「手機上真的能用」前進。

導覽把我送到頁面，頁面裡又冒出五種「進度」

現在 Header 管共用入口，桌面由 Sidebar 攤開完整資訊架構；產品若只有少量平行頁面，才改由 Navbar 接手。手機底部只留高頻目的地，完整清單則從 Header 開啟。不同導覽也不再各自亮著不同頁面。

我終於順利進入「帳號申請」，結果頁面一打開，又同時看到系統位置、申請步驟、資料分頁、文件完成比例，全都長得有點像「你現在到哪裡」。

圖 10：五個問題各問各的，AI 卻很公平地全部回答 50%。

明天要拆的不是進度條配色，而是 Breadcrumb、Pagination、Stepper、Progress Indicator 與頁內導覽各自在回答哪一種「到哪裡」。

延伸閱讀

• W3C WAI：Landmark Regions
• W3C WAI：Navigation Landmark Example
• W3C WAI：Disclosure Navigation
• W3C WAI：ARIA26 - Using aria-current to indicate the current item
• Android Developers：Navigation bar

資料查閱：2026-08-07。