安安～我是ChiYu～
昨天，我把林子安的詳細資料放進 Drawer，總算不用每看一位成員，就把整張清單蓋起來一次。
清單脈絡保住了，Drawer 裡卻又冒出三個需求：
最初的 Prompt 把它們揉成一句：
在問號圖示上滑過去，顯示詳細說明和操作。
昨天結尾就停在下面這張圖。這是我依照第一版需求，在網站上重建的錯誤現場；它不含真實帳號與個人資料：
圖 1：和昨天結尾是同一張畫面。一個問號同時負責說明、角色設定與主管預覽，滑鼠移開後全部一起消失。
照這句話做下去，很容易得到一個什麼都能裝的 Tooltip。先放說明，再塞按鈕，最後連主管資料也一起住進去。外觀看起來整齊，元件的工作內容已經亂到需要重新面試。
我先不急著替三個需求各配一個新元件，而是把滑鼠移開，問了一個比較掃興、但很好用的問題：
如果浮層完全沒有出現，使用者還能完成工作嗎？
答案會把 Tooltip、Popover 與 Hover Card 分開，也會直接淘汰一些根本不該躲進浮層的資訊。
Vibe Coding 時，要求 AI 做出 hover 動畫很簡單；真正需要寫進 Prompt 的，是資訊缺席後會不會害人做錯、鍵盤能不能開，以及手機上要怎麼找到同一份內容。
這篇沿用 LumenDesk 的虛構工作區；人名、通知與專案都只是示範資料。三種元件的操作版本已放在網站：
先看這三種浮層的責任分界：
圖 2：先判斷資訊是不是完成任務所必需，再看浮層裡有沒有操作，以及內容是否在預覽一個既有對象。
這張圖把外觀放到很後面才談。卡片是黑色、白色，陰影濃一點或淡一點，都不會改變它的責任；資訊的重要性與可不可以操作，才會。
我先把 Drawer 裡的三個需求重新分工。
角色權限規則會影響管理員的選擇，藏在問號裡風險太高，所以直接寫在角色設定旁。即使完全沒碰問號，使用者也要看得到限制。
變更角色本來就是 Drawer 裡的主要工作，保留清楚的欄位與儲存按鈕就好。沒必要為了湊一個 Popover，再把操作藏進第二層浮窗。
主管姓名的快速預覽倒是適合 Hover Card。原本的姓名仍可前往正式資料頁，浮層只負責讓管理員先瞄一眼部門、角色與近期專案。
結果三個需求拆完，只留下一個浮層。這很正常。認識元件不是為了每種都用一次；知道什麼時候不要用，通常更省事。
接下來我另外用「同步排程」測 Tooltip，用「通知摘要」測 Popover。這兩個情境比較能看出各自的工作邊界。
我先開啟網站的 Tooltip Demo，然後故意不靠 hover。
問號按鈕有「同步排程說明」這個可辨識名稱，旁邊直接顯示：
我用鍵盤把焦點移到問號，Tooltip 顯示「每 15 分鐘執行一次」；按 Escape 後提示收合，焦點仍留在問號按鈕。觸控裝置也可以點選問號暫時開啟。
實際畫面如下：
圖 3：同步狀態與時間直接留在卡片上，Tooltip 只補充「每 15 分鐘執行一次」。
這次測試通過。即使 Tooltip 完全沒出現，使用者仍知道同步是否正常，也看得到下一次執行時間。問號只是補充，不負責藏住救命資訊。
W3C 的 Tooltip Pattern 將 Tooltip 定位為 hover 或 focus 時出現的描述；焦點仍留在觸發元素，並且應能以 Escape 收合。Tooltip 裡不該再放需要 Tab 進去操作的連結、按鈕或輸入欄位。不過 APG 目前仍把這份 Tooltip Pattern 列為 Work in Progress，因此我不會只靠它驗收；還會用 WCAG 對可關閉、可滑入與保持顯示的要求補上檢查。W3C WAI-ARIA APG：Tooltip Pattern、W3C WCAG 2.2：Content on Hover or Focus
交給 AI 時，我會把原頁資訊和 Tooltip 補充內容分開寫：
在 LumenDesk 的資料同步卡片中，於「同步排程」旁加入問號 Tooltip。
同步是否正常、上次完成時間與下一次同步時間必須直接顯示在卡片上。Tooltip 只顯示一句補充：「同步會在每 15 分鐘執行一次」。使用者以滑鼠 hover 或鍵盤 Tab 聚焦問號時顯示；按 Escape 收合；Tooltip 內不可放連結、按鈕或任何需要操作的內容。觸控裝置可點選問號暫時開啟。
這段 Prompt 沒有只寫「滑過去顯示說明」。它把哪一段必須常駐、哪一段可以晚點出現交代清楚，AI 就不會順手把 09:45 和 10:00 也收進泡泡裡。
接著換通知摘要。
這次的浮層裡有三則待處理通知，還有一顆「前往通知設定」按鈕。使用者不只閱讀，還要在裡面做下一步，所以 Tooltip 已經不適任，該交給 Popover。
我從「查看通知摘要」開啟網站 Demo。這個情境裡的 Popover 含有操作，所以我刻意讓焦點進入第一個按鈕；按 Escape 或點面板外部時收合，焦點再回到原本入口。
圖 4：Popover 內有三則通知和「前往通知設定」，因此需要完整的進入、操作與離開路徑。
這張畫面最重要的不是多了一個按鈕，而是使用者真的走得進去，也走得回來。若 Popover 看得見，鍵盤焦點卻仍卡在外面，它只完成了視覺上的開啟。
HTML 的 popover 屬性提供 Top Layer、顯示狀態與 Light Dismiss 等原生行為，其中 auto 類型可以在點到面板外部時收合。但它不會替內容自動選好語意，也不代表每個 Popover 開啟後都該把焦點移進去。這次因為通知摘要裡有操作，才選擇把焦點移到第一個按鈕；若只是沒有控制項的短補充，焦點策略會不同。WHATWG HTML：Popover
在 LumenDesk 的通知中心加入「查看通知摘要」按鈕。點選後開啟一個 Popover，顯示三則待處理通知與「前往通知設定」按鈕。
Popover 開啟後，鍵盤焦點移到面板裡的第一個操作按鈕；按 Escape 或點面板外部時關閉，並讓焦點回到「查看通知摘要」。這是局部摘要，不要遮住整個頁面，也不要把它做成需要多步填寫的 Dialog。
如果內容一路加成長表單、開始處理高風險確認，或必須阻止背景操作，Popover 就該下班了。後面的工作應交給 Dialog 或完整頁面，不需要硬把通知小卡養成迷你設定中心。
最後回到主管姓名。
Hover Card 適合預覽一個已經存在的對象，例如成員、專案或檔案。使用者還留在目前清單，就能先看到部門、角色與近期專案，再決定要不要進正式頁面。
它和 Tooltip 的差別不只是卡片比較大。Tooltip 補充一句描述；Hover Card 提供某個對象的背景資料。卡片消失後，原頁仍要保留姓名、職稱或其他完成判斷所需的資訊。
網站的 Hover Card Demo 以「林子安」為入口。桌面版可以滑過名稱或用 Tab 聚焦來打開快速預覽，游標也能從姓名移進卡片，不會剛跨過縫隙就被關門。
圖 5：Hover Card 預覽林子安的部門、角色與近期專案；原列表仍保留職稱與角色。
這裡也驗出目前 Demo 還沒過關的地方：「林子安」外觀看起來是連結，點擊卻被攔下來改成開啟預覽。桌面滑鼠與鍵盤的預覽路徑成立，觸控版卻把「前往正式頁面」和「打開預覽」塞在同一次點擊裡，兩個工作開始搶方向盤。
我最後會保留姓名連結的正常導覽，再於旁邊提供一顆看得見、名稱清楚的「預覽林子安」按鈕。觸控使用者按預覽，想看完整資料就按姓名；不必猜第一次點擊是在預覽，還是在前往。Hover Card 只加快預覽，不搶走正式入口，否則這份資料就像只對滑鼠使用者營業。
WCAG 對 hover 或 focus 才出現的額外內容提出三個實際檢查方向：內容能否關閉、游標能否移到內容上，以及內容會不會在使用者還需要時立刻消失。這些要求不是 Hover Card 的專屬規格，但拿來驗收很合適。W3C WCAG 2.2：Content on Hover or Focus
這次改寫後的 Prompt，會把桌面與觸控入口分開：
在 LumenDesk 的專案負責人欄位保留「林子安」姓名連結，點擊後正常前往完整成員頁。旁邊另放一顆可見的「預覽林子安」按鈕，供觸控與鍵盤使用者開啟 Hover Card。
桌面滑鼠 hover 姓名、鍵盤 focus 預覽按鈕，或點選預覽按鈕時，顯示部門、角色與近期專案。游標從觸發元素移入卡片時不得立即關閉；按 Escape、焦點離開整組元件，或使用者明確收合後才關閉。Hover Card 不放唯一操作，也不能攔截姓名連結的正常導覽。
只在桌面把游標滑過去，三種元件都可能看起來沒問題。我會再用鍵盤、觸控和「完全不開浮層」各走一次：
| 測試方式 | Tooltip | Popover | Hover Card |
|---|---|---|---|
| 完全不開浮層 | 主要任務仍能完成 | 入口要說清楚裡面有操作 | 原頁仍能前往正式資料 |
| 鍵盤操作 | focus 顯示，Escape 收合 | Enter／Space 開啟，內容可依序聚焦 | focus 也能看預覽，不能只支援 hover |
| 觸控操作 | 關鍵資訊不能依賴它 | 點選開啟，外部點擊或返回可關閉 | 姓名負責前往，獨立預覽按鈕負責開卡；不要讓一次點擊猜兩件事 |
| 浮層內容 | 一兩句，不放控制項 | 可以有按鈕或連結 | 預覽既有對象的摘要 |
這張表比「請做出漂亮的 hover 效果」有用很多。AI 很會補淡入、位移和陰影，卻不一定會主動替沒有滑鼠的人留一條路。
有些資訊根本不能參加今天的元件選秀。
「同步失敗」、「目前沒有權限」或「刪除後會影響哪些資料」，只要沒看見就可能讓工作做錯。這類資訊應直接出現在原頁，或提供非常清楚、可操作的入口，不能只在游標剛好停對地方時才現身。
其餘內容可以沿著這張選擇圖往下走：
圖 6：必要資訊直接顯示；短補充用 Tooltip；需要操作時用 Popover；預覽既有對象時再考慮 Hover Card。
我的順序會是：先判斷資訊缺席會不會害使用者做錯，再看內容裡有沒有操作，最後確認它是不是某個對象的預覽。走完這三步，元件通常已經選得差不多，不用再靠卡片尺寸猜名字。
把畫面交給 AI 後，我會逐項確認：
這份驗收不要求 AI 使用哪一套框架。只要最後的互動必須靠滑鼠「剛好滑到」，我就不會把它判定為完成。
最後，我把同步頻率留給 Tooltip、通知操作放進 Popover、主管摘要交給 Hover Card。角色權限限制直接顯示在設定旁，沒有為了湊元件又藏回問號裡。
拿掉滑鼠後，我用鍵盤與點選重走一次。Tooltip 與 Popover 的主要路徑成立，Hover Card 的桌面 hover、focus 與移入卡片也能運作；但觸控入口仍要拆成「姓名導覽」和「預覽按鈕」才算通過。即使完全不打開浮層，也不會漏掉完成任務需要的規則。開頭那句「滑過去顯示詳細說明和操作」，現在已經拆成資訊必要性、操作方式和對象預覽三種責任。
接著，管理員準備儲存成員角色。畫面同時出現三則訊息：通知管道尚未選擇、系統今晚維護，以及「先從最小權限開始」的建議。
原始需求只寫：
「系統有錯誤或提醒時，顯示一個通知。」
下面這張圖，是我依照第一版需求在網站上重建的錯誤現場，不含真實帳號與個人資料：
圖 7：三則訊息用了同一種顏色與位置。通知管道錯誤正在擋住儲存，真正要修正的欄位卻留在下方設定卡。
黃色不是問題，Banner 也沒有做壞。真正麻煩的是操作錯誤、全站公告與決策建議被排成同一層，使用者得自己判斷哪一句正在擋住工作，再往下找對應欄位。
明天就來處理 Alert、Banner 與 Callout，看看這三句話各自該站在哪裡。
iThome鐵人賽
看影片追技術