U.C13 匯入錯誤卡片出現「重新載入擴充功能」— 錯誤行動與層級不對位
錯誤 UI 提供的行動,解決問題的層級要等於錯誤發生的層級 — 資料層的錯誤配上執行環境層的行動(重載擴充功能),既不解決問題、又放大破壞半徑。這張卡記錄這條對位原則被通用錯誤容器打破、由使用者回饋抓回來的過程。
觀察
電子書庫總覽 Chrome 擴充功能(book_overview_v1)的匯入功能出錯時(檔案格式錯誤、內容不合法),錯誤顯示複用了 popup 的通用 errorContainer — 這個容器是為擴充功能執行層錯誤設計的,帶「重新載入擴充功能」按鈕。使用者回饋指出:Chrome Web Store 上架版對「匯入錯誤」不該出現 reload extension 按鈕(commit 72cd5f370)。
修復:建匯入專屬的 importErrorContainer,只有「關閉」按鈕(沒有 retry / reload)— 匯入錯誤的正確下一步是換一個檔案再試,不是重載執行環境;同時把文案集中到 IMPORT_MESSAGES 常數、移除對通用錯誤處理器的依賴。
判讀
錯誤有層級、行動也有層級。檔案格式錯誤是資料層、訊息通道斷線是通訊層、service worker 崩潰是執行環境層。行動同樣分層:換檔案重試(資料層)、重新連線(通訊層)、重載擴充功能(執行環境層)。對位原則:行動解決的層級 = 錯誤發生的層級。層級過重的行動不解決問題(重載擴充功能不會讓壞檔案變好)、還附帶代價(狀態遺失、流程中斷)。
通用錯誤容器是不對位的結構性來源。為最嚴重錯誤設計的容器(帶最重的行動)被所有錯誤複用時,輕錯誤自動繼承重行動。錯誤 UI 的複用要以「行動相容」為邊界、不是以「都是錯誤」為邊界。
使用者會照著按鈕走。錯誤畫面上的按鈕是系統給的行動建議,使用者傾向直接採納 — 不對位的按鈕等於系統主動引導使用者做無效且有代價的操作。
策略
對每個錯誤 UI 的行動清單問一句:這個行動解決的層級,等於這個錯誤發生的層級嗎?過重(重載 / 重啟 / 重裝出現在資料層錯誤)與過輕(執行環境崩潰只給「關閉」)都是缺口。
錯誤容器按行動分組:行動集合不同的錯誤用不同容器 / 元件,避免複用時行動一起被繼承。
文案與行動集中管理:錯誤訊息散在 HTML 各處時,行動不對位很難被掃描發現;集中成常數表後「哪類錯誤配哪些行動」一眼可查。
下一步路由
- 錯誤訊息的診斷與行動職責 → 錯誤訊息撰寫原則
- 重試行動的設計 → Retry 機制 UX
- 對照案例(行動缺失 — 只有重試沒有退路)→ U.C1 五個狀態零個退出路徑
#ux-design #case-study #error-recovery #chrome-extension #web #error-action