通知中心系統
目的
通知中心系統為應用程式內的通知中心、動態消息或收件匣提供了一個結構化、可重複使用的設計框架。在現代 Web 應用程式中，特別是 SaaS 工作區、社群入口網站、協作編輯器和電子商務帳戶中，通知讓使用者了解非同步事件的動態（例如：提及、評論、系統警報、工作流程狀態更新、任務完成）。
如果沒有專門的通知中心，應用程式將被迫依賴侵入性的覆蓋層（Modal）或短暫、容易被忽略的通知（Toast/Banner）。此系統集中管理這些更新，控制它們的視覺層級、互動狀態（已讀與未讀）、上下文分組和響應式適應，同時確保完整的鍵盤和螢幕閱讀器無障礙性（WCAG AA）。
使用案例
- 協作工作區： 彙總文件評論、共享資料夾、任務指派和提及（例如 Slack、Notion、Figma）。
- 非同步工作流程： 追蹤長時間運行的操作，例如資料匯出、背景報表、建置部署或批次處理。
- 交易更新： 追蹤電子商務送貨進度、訂閱續約提醒或付款確認。
- 社交與社群動態： 管理按讚、回覆、追蹤、群組邀請和活動更新。
- 帳戶安全與健康狀態： 通知使用者新的登入位置、密碼變更或儲存空間配額警告。
何時不應使用
- 關鍵性阻斷： 如果某事件必須阻止使用者完成當前任務（例如：付款失敗、會話過期、提交無效資料），請使用
overlay-and-dialog-system（Modal/Alertdialog）。 - 短暫、單一任務的回饋： 對於立即確認直接操作（例如：「連結已複製」、「設定已儲存」），請使用 Toast（參見
toast-and-snackbar-system）。 - 全域停機公告： 對於全站、高優先級的系統警報（例如：「30 分鐘後進行排程維護」），請使用全域橫幅（參見
banner-and-alert-system）。 - 獨立的轉換登陸頁面： 獨立登陸頁面應最小化外部連結和干擾。全域通知圖標會適得其反。
輸入
- 資訊架構（通知結構）：
- 元資料： 作者頭像/縮寫、事件來源、動作類型。
- 內容： 標題（發生什麼事）、內文（其他詳細資訊/上下文）、時間戳記。
- 狀態： 已讀與未讀、高/中/低優先級、已封存。
- 動作： 主要目標連結、內聯快速操作（例如：「核准」、「標記為已讀」、「靜音討論串」）。
- 顯示上下文與密度： 介面是高度密集的 SaaS 儀表板（需要節省空間的彈出式列表項目），還是寬敞的平台（可以利用側邊抽屜或頁面）？
- 觸發圖示： 視覺錨點（通常是鈴鐺圖示）和通知徽章設計（數字計數與簡單的點狀指示器）。
- 互動操作佈局： 可用的批次操作（例如：「全部標記為已讀」、「全部清除」、「通知設定」）。
輸出
- 觸發徽章結構： 標題圖示、數字徽章計數和靜默指示器點的具體設計標準。
- 容器佈局規範： 大小、邊界、定位和容器行為（下拉式選單、側邊抽屜或專用頁面）。
- 通知卡片結構： 明確的內部佈局（頭像、主體、時間戳記、未讀指示器點、快速操作觸發器）。
- 狀態轉換矩陣： 未讀與已讀狀態、懸停狀態、啟用狀態、焦點環和載入骨架的獨特樣式。
- 鍵盤與螢幕閱讀器規範： 焦點陷阱參數、輪流 tabindex 結構、live-region 公告定義和自訂 aria 描述。
工作流程
1. 設計頁首觸發器與徽章指示器
通知中心的進入點幾乎普遍位於全域實用程式頁首（右側）。
- 鈴鐺圖示： 選擇一個簡潔的鈴鐺圖示。
- 未讀計數徽章：
- 將圓形徽章放置在鈴鐺圖示的右上象限。
- 將徽章計數限制為
99+（或在極其緊湊的佈局中為9+），以防止容器溢出。 - 如果計數為 0，則必須從 DOM 中移除徽章或使用
display: none隱藏它（切勿在紅色氣泡中顯示0）。 - 包含一個
aria-label或隱藏的螢幕閱讀器文字，明確說明未讀通知的數量（例如：<span class="sr-only">，4 則未讀通知</span>）。
2. 選擇容器佈局模式
根據密度、目標裝置和所需的互動量來選擇佈局：
- 模式 A：下拉式彈出視窗（桌面預設，用於中等內容密度）
- 相對於觸發器進行定位。
- 建議尺寸：最小寬度
320px，最大寬度420px。高度限制為500px，並帶有可滾動容器（overflow-y: auto）。 - 使用標準彈出視窗機制（或原生 Popover API）來錨定彈出視窗，以確保它出現在頂層堆疊上下文中。
- 模式 B：側邊抽屜（最適合高內容密度或複雜操作流程）
- 從螢幕右邊緣滑入，佔據整個視口高度。
- 建議寬度：
360px到480px。 - 使用微妙的背景疊加層（遮罩）使頁面背景變暗。
- 模式 C：專用通知頁面（行動視口或複雜收件匣管理的備用方案）
- 一個全螢幕檢視，適用於排序、搜尋、篩選和大量管理深層通知封存。
3. 建立內部卡片層級與結構
每個單獨的通知都是一張卡片（<ol> 或 <ul> 內的一個列表項 <li>）。它必須遵循嚴格的垂直和水平網格層級：
+-------------------------------------------------------------+
| (•) [頭像] **小明** 在 _專案 X_ 中提到了您 (x) |
| "請審查修改後的 UI 草稿。" |
| [ 3 小時前 ] [ 核准 ] [ 拒絕 ] |
+-------------------------------------------------------------+
- 未讀指示器點（水平錨點）： 在極左側放置一個小而高對比度、主要顏色的點（例如藍色或紫色）。這是未讀項目的最快掃描錨點。
- 頭像/圖示區域： 在指示器旁邊放置一個圓形頭像（用於使用者產生的事件）或一個帶有彩色背景的分類實用圖示（用於系統事件）。
- 文字區塊（垂直流程）：
- 標題/頁首： 粗體文字，突出顯示執行者和動作。
- 摘錄： 較小、顏色較淡的文字，顯示次要內容（例如：評論文字、錯誤描述）。使用 CSS line-clamp 將文字限制在最多 2 行。
- 時間戳記： 顏色較淡的小文字（例如
12px），顯示相對時間（例如：「5 分鐘前」、「昨天」）。
- 快速操作（上下文觸發器）：
- 將快速操作按鈕對齊放置在文字摘錄下方（例如：「接受邀請」、「檢視評論」）。
- 在懸停/聚焦時，在右側角落提供一個微妙的次要觸發器（例如：溢出選單按鈕或直接的「標記為已讀」勾選按鈕）。
- 關閉/消除圖示（X）應位於右上角，尺寸至少為
24x24px以利觸控互動。
4. 建立清晰的狀態轉換
提供不同的狀態以反映使用者互動：
- 未讀狀態： 淺色背景、粗體文字、可見的藍色指示器點。
- 已讀狀態： 淡化未讀背景，將文字粗細改為常規，隱藏指示器點。
- 懸停/焦點狀態： 稍微改變背景顏色（例如：從白色變為柔和的灰白色），並顯示次要內聯觸發器（例如：「封存」、「標記為已讀」）。
- 聚焦狀態： 當透過鍵盤導航時，在單個項目周圍顯示高對比度的焦點環。保持焦點可見且清晰（最小 2px 輪廓並帶有偏移）。
- 停用狀態： 如果某個操作卡片正在處理中（例如：點擊「核准」），則套用內聯載入旋轉器，將不透明度降低至
0.5，並將按鈕屬性設定為disabled以防止雙擊。
5. 定義批次操作和空狀態
- 頁尾導航： 始終提供一個「檢視所有通知」（連結到專用頁面）或「全部標記為已讀」的頁尾連結。
- 空狀態： 當沒有通知或所有通知都已清除時，顯示一個包含鼓勵性視覺元素（例如：勾選標記或鈴鐺）、中性標題（「全部搞定！」）和指向「通知設定」的次要描述性連結的空狀態（參見
empty-state-system）。
6. 實作鍵盤焦點和螢幕閱讀器管理
- 觸發開關： 在鈴鐺圖示上按
Enter或Space可切換彈出視窗。套用aria-expanded="true/false"和aria-controls="notification-panel-id"。 - 焦點陷阱（用於抽屜和彈出視窗）： 開啟時，鍵盤焦點必須立即移動到面板內的第一個可操作元素（通常是「全部標記為已讀」按鈕或第一個通知項目）。當面板可見時，焦點必須被限制在面板內。按下
Escape必須關閉面板並將焦點直接返回到鈴鐺圖示。 - 輪流 Tabindex / 列表導航： 如果有數十個通知項目，允許鍵盤使用者使用
ArrowUp和ArrowDown鍵在卡片之間導航，只保留一個定位點（tabindex="0"用於活動項目，tabindex="-1"用於其他項目）。這避免了強迫鍵盤使用者跳過 50 個連結才能到達頁面底部。 - 螢幕閱讀器公告： 使用隱藏的
aria-live="polite"區域，在動態發生時公告未讀計數的更新（例如：「來自莎拉的新通知」）。
決策規則
規則 1：下拉式選單 vs. 側邊抽屜 vs. 頁面
使用此佈局網格選擇容器結構：
- 選擇下拉式彈出視窗如果： 應用程式平均有少於 10-15 個通知，主要包含簡短更新，且操作很簡單（例如：直接連結或快速關閉）。
- 選擇側邊抽屜如果： 通知面板包含互動式索引標籤（例如：「全部」、「提及」、「封存」），需要豐富的多行卡片摘要，或需要複雜的表單欄位（例如：直接在通知內輸入文字回覆）。
- 選擇專用頁面如果： 使用者正在管理通知密集型工作負載（例如：GitHub PR 審查收件匣、Zendesk 支援工單、Shopify 商店警報），這些工作負載需要強大的搜尋篩選器、勾選多重選擇和大規模的封存工作流程。
規則 2：頭像與圖示指示器
- 如果通知是由特定人員觸發的社交或直接協作事件（例如：「莎拉分享了一個檔案」），則使用使用者頭像（圖片或縮寫）。
- 如果事件是系統產生的（例如：「資料庫備份完成」），則使用系統圖示（帶有特定狀態顏色：紅色用於警報，黃色用於警告，藍色用於資訊）。
規則 3：標記為已讀操作行為
- 點擊通知卡片應同時將使用者重新導向到深度連結目標並將項目標記為已讀。
- 在卡片上提供一個專用、可見的「標記為已讀」勾選圖示，使使用者能夠在不導航離開面板的情況下將項目標記為已讀。
限制條件
1. 對比度與尺寸 (WCAG AA)
- 文字對比度： 確保所有通知副本滿足
4.5:1的對比度。時間戳記和淡化摘錄的對比度不得低於4.5:1（或大型文字的3:1）。 - 觸控目標： 單個按鈕（關閉圖示、接受/拒絕連結、標記為已讀勾選）的觸控目標必須滿足 WCAG 2.2 SC 2.5.8 的最小目標尺寸
24x24px。 - 鍵盤對比度： 焦點環與卡片背景的對比度至少為
3:1。
2. 響應式設計
- 桌面： 浮動面板必須智能定位。如果觸發器靠近螢幕右邊緣，則彈出視窗必須與其右側對齊以防止裁切。
- 行動視口 (
< 768px)： 將桌面下拉式彈出視窗轉換為全螢幕面板或底部對齊的上滑式表單，以確保拇指可及性並防止小的、不可滾動的彈出視窗容器。
3. 動態堆疊
- 確保彈出視窗或抽屜的 z-index 配置高於標準佈局元素，但低於模態觸發器（例如：
--z-index-popover: 1000，--z-index-modal: 2000）。
常見失敗模式
- 「無法逃脫的收件匣」： 在桌面上開啟下拉通知彈出視窗，但未能提供
Escape鍵關閉監聽器。使用者被迫尋找並點擊一個微小的「X」或點擊外部來關閉。 - 「徽章卡住」循環： 通知徽章顯示
3個未讀項目，但開啟面板並未在視覺上突出顯示哪些卡片是未讀的，也未提供清除方式將它們標記為已讀。徽章保持卡住，導致使用者疲勞並最終導致橫幅盲視。 - 「大雜燴」動態消息： 將完整的電子郵件段落、原始資料庫日誌和市場行銷推廣內容塞入一個小型下拉面板中，導致版面溢出並破壞視覺層級。
- 滾動時版面偏移： 使用靜態像素座標樣式的彈出視窗，在滾動時未能保持與頁首鈴鐺圖示的連接，隨機漂浮在內容上方。
- 雙重焦點輪廓： 雙層焦點樣式，其中外部容器卡片和內部深度連結按鈕同時捕獲焦點，要求鍵盤使用者每個通知跳轉兩次。
驗證標準
- 徽章計數行為： 如果未讀計數為
0，則紅點或數字指示器完全從視圖中隱藏。 - 狀態對比： 未讀卡片在視覺上與已讀卡片明顯區分（使用背景、文字粗細和指示器點）。
- 目標尺寸： 卡片內部的每個可點擊按鈕/連結都滿足 WCAG 2.2 的 24x24px 觸控目標最小值。
- 響應式轉換： 在行動視口上，通知面板會轉換為全螢幕或底部對齊的佈局。
- 鍵盤導航：
Escape關閉面板並返回焦點。ArrowUp/ArrowDown可以在項目之間移動。焦點被限制在面板內。 - 螢幕閱讀器：
aria-live區域在收到新通知時進行廣播。 - 載入狀態： 載入骨架在獲取通知時清晰可見。
- 錯誤狀態： 如果通知擷取失敗，則提供重試選項。
- 邊界情況： 當徽章計數超過
99+（或9+）時，徽章會正確截斷。 - 無障礙名稱： 鈴鐺圖示具有
aria-label，指示“通知”和未讀計數。 - 批次操作： 「全部標記為已讀」出現在面板頂部或底部。
- 空狀態： 當沒有通知時，會顯示鼓勵性狀態訊息以及指向通知設定的連結。