UI 結構標準 是做什麼的？
介面會因為結構問題而難以使用，而不是因為數量。一個擁有 300 項設定的應用程式可以很容易導航，而一個只有 30 項設定的應用程式卻可能像個迷宮。原因總是那幾個：同一個控制項出現在多個地方、選單反映了程式碼或團隊的組織方式、動作與偏好設定混雜在一起、未標籤的圖示、不可見的範圍，以及從未移除過期的東西。
解決方案是採用主要平台已經在使用的方式，並且在每個應用程式中都以相同的方式執行，這樣使用者就可以運用他們已經知道的知識：
- 一個熟悉的佈局。 左側是一個可搜尋的分類清單，右側是開啟的頁面，行中標籤在左側，控制項在右側。
- 一套分類名稱。 帳戶、通知、隱私與安全性、協助工具、外觀、語言與地區、資料與儲存，然後是產品自己的主題。透過七個問題，任何設定都可以被歸類到恰好一個分類中。
- 更少的控制項。 最好的設定是那個根本不需要發布的設定，因為一個更好的預設值讓它變得多餘。
- 每個保留下來的控制項只有一個家。 每個設定、目的地和指令都是一個登錄中的記錄，每個記錄都只有一個家，而介面是從這些記錄繪製出來的。當沒有人手動放置控制項時，結構就不會偏移。
選擇任務
在這個表格中找到你的請求，然後只閱讀該章節及其提到的檔案。
| 請求 | 章節 | 也請閱讀 |
|---|---|---|
| "新增一個設定 / 選單項目 / 按鈕" | 新增一個控制項 | 通常不需要閱讀更多 |
| "這個 UI 亂糟糟的", "審查這個", "使用者找不到東西" | 審查現有介面 | references/audit.md, references/rules.md |
| "建立 / 設計 / 重新設計一個設定畫面、側邊欄或工具列"，或一個要轉換成設定畫面的功能列表 | 建立新的表面 | references/categories.md, references/visual-design.md, references/record-schema.md |
| "組織我們的設定", "我們應該有哪些分類" | 標準分類 | references/categories.md |
| "為我們的專案設定這個" | 採用登錄系統 | references/record-schema.md |
無論任務是什麼，都要尊重你所在的專案。如果程式碼庫已經有設定登錄系統、元件庫或自己的標記規則，請擴充它們；不要引入一個並行的系統。這個標準描述的是結構，而不是技術。
evals/ 資料夾包含此技能的測試案例。它不是參考資料；在執行任務時不要閱讀它。
新增一個控制項
依序詢問這五個問題，並在第一個"是"時停下來。告訴使用者這個決定和原因；不要引導他們通過不再適用的問題。
- 更好的預設值是否能讓它變得多餘？ 如果可以透過改變預設值、自動偵測情況，或直接移除人們不喜歡的行為（例如一個沒必要的確認對話框、一個自動儲存的提示）來滿足所有人的需求，那麼就這樣做。不需要設定。
- 系統或管理員是否已經決定了它？ 主題、文字大小、通知權限等屬於底層。遵循它。如果產品有充分的理由提供自己的選擇，那麼這個選項必須包含"使用系統設定"作為預設值；它永遠不能只是一個簡單的開啟/關閉開關。
- 它是只執行一次，而不是持續的選擇嗎？ 那麼它是一個動作：一個按鈕，與切換開關分開放置，在上下文中，或在其頁面底部的一個有標籤的群組中。
- 它是否每週或更頻繁地更改？ 那麼控制項應放在上下文中，與它所更改的功能旁邊，並附帶一個指向其主頁面的連結。主頁面仍然會列出它。
- 是否少於大約 1/20 的人會更改它？ 那麼它的階層是進階。一個頁面上如果有三個或更多進階項目，則將它們顯示在一個"進階"折疊區塊中；如果少於三個，則將它們放在最後，作為普通行。
否則，它就是其主題頁面上的一行標準控制項。
如果問題 1 或 2 的答案是肯定的，請直接說出來，並提議用那個變更來取代新增設定。每個設定都有測試、支援以及影響其他人尋找東西的能力的成本，所以使用者應該先聽到更便宜的選項。他們可能仍然想要這個設定；這由他們決定。用幾行文字提供它作為備用方案。
選擇主頁面。 使用標準分類下的七個問題，對應到現有的頁面。如果控制項不適合任何一個，這表示缺少一個主題：請說明並提議一個。不要建立名為「一般」、「其他」、「雜項」或「進階」的頁面。當現有介面已經有這樣的頁面時，將新控制項放在命名最好的特定頁面上，並用一行提到這個雜項頁面，表示值得以後修復。要求新增一個控制項不是要求進行審查。
會問問題的控制項。 一個帶有「不再詢問」的確認對話框是一個上下文中的設定控制項（問題 4）：勾選框和設定行是同一筆記錄，因此可以稍後找到並撤銷該選擇。絕不要提供「不再詢問」而沒有一個地方可以撤銷它。
要向使用者展示多少資訊。 如果專案有一個登錄系統，請撰寫完整的記錄（欄位如下），並檢查它所在的頁面是否仍在限制範圍內。如果沒有，或者使用者只要求建議，請用簡單的文字回答：要新增什麼、放在哪裡、叫什麼、預設值是什麼以及為什麼，以及它適用於此裝置還是整個帳戶。像 id、tier、owner 和 reviewed 這樣的欄位是後勤記錄；在對話式的答案中省略它們。當你不知道記錄需要的某些資訊時（例如設定是否在裝置之間同步、有哪些頁面存在），請在一個子句中說明你的假設，然後繼續。
審查現有介面
目標是一份具體的、可修復的發現列表，每個發現都與規則編號相關聯，以及一個提議的結構。首先閱讀 references/rules.md，以便發現可以引用規則，並使用 references/audit.md 中的報告範本。
審查可能涵蓋設定、導航、工具列，或全部三者。審查使用者要求的部分以及你能看到的內容。如果畫面沒有任何設定，請跳過範本中關於設定的部分；不要為了符合範本而硬塞內容。
- 庫存盤點。 列出人們可以更改或觸發某些事情的所有地方：設定畫面、帳戶選單、上下文選單、每個項目的對話框、導航列表、工具列、圖示列、命令列標誌、設定檔。在大型程式碼庫中，委派搜尋或搜尋模式（標籤、切換開關、選單建構器）；不要完整閱讀大型檔案。對於每個控制項，記錄其顯示的標籤、類型、所在位置以及如何到達。當控制項完全沒有標籤時，請說明，用位置來描述它，並將任何關於其功能的猜測標記為猜測。
- 測量。 計算規則限制的數量：更改事物的位置、頂層導航入口、每頁設定數量、深度、每個工具列的按鈕數量、僅圖示的控制項、沒有可訪問名稱的控制項、搜尋框數量，以及相同類型的物件顯示了多少不同的指令集。
- 找出症狀。
- 同一個設定或指令可以在多個地方存取，或者兩個控制項互相疊加或衝突
- 一個主題分散在好幾個頁面
- 同一件事有多個名稱；連結的標籤與其目標的標題不同；相近的兩個重複名稱並列
- 命名為「一般」、「其他」、「雜項」、「進階」的頁面
- 動作（匯出、刪除、登出）與偏好設定或目的地混在一起
- 範圍只在提示文字中說明，或完全沒有說明
- 標籤中使用開發者的術語
- 只有一個項目的群組，以及超過其限制長度的列表
- 沒有可見文字的圖示；一個圖示用於兩種含義
- 工具列超過五個按鈕；指令集在不同類型的物件之間有所不同
- 沒有當前位置的標記
- 一個畫面上有多個搜尋框
- 將「顯示」、「隱藏」或「重新排序」控制項作為解決雜亂的解決方案
- 提出建議。 對於設定：適用的標準分類加上最多兩個產品主題，總共最多九個，每個控制項都恰好映射到一個。對於導航：最多九個頂層入口，其餘放在有標籤的群組下。對於工具列：每種物件類型一個指令集，工具列上放五個，其餘放在「更多」下。列出哪些內容會離開表面以及它們去哪裡。說明這些分組只是提案，需要透過卡片分類法和樹狀測試（五個人就能發現主要問題；目標是 80% 的任務成功率）來確認，因為分組必須符合使用者的思考方式，而這無法從程式碼中讀出。
- 排序變更，使那些不需要任何人重新學習的變更優先：圖示上的文字和當前位置標記，然後是合併重複項和統一命名，然後是統一的工具列，最後是重新分組。移動東西排在後面，因為它會讓現有使用者付出代價。如果需要採用登錄系統，它應該放在最後，並且是提議而不是強推；使用者只問了要在畫面上更改什麼。
根據對新使用者的困擾程度對發現進行排序。肯定已經有效的東西：現有的登錄系統、搜尋、重置或定位機制是修復的基礎，這樣說可以防止不必要的重寫。
建立新的表面
- 首先對每個項目執行五個問題。 產品願望清單中總是包含一些應該是更好的預設值、屬於系統、或者是動作而非偏好設定的東西。從登錄系統中移除這些項目，並在你的摘要中列出它們及其原因，以便使用者可以否決你。
- 在撰寫任何標記之前，先撰寫記錄，遵循
references/record-schema.md。如果存在登錄系統，請添加到其中。 - 使用七個問題對每個記錄進行歸檔（下一節）。省略那些會為空的類別。當人們會按名稱尋找它時，一個只有一兩個設定的類別是可以的（例如通知）；否則將其折疊到相鄰的類別中。關於某個主題的狀態應留在該主題的頁面上；只有應用程式範圍的資訊才放在「關於」下。
- 檢查限制條件（如下），手動或使用檢查器。
- 從記錄中繪製標準佈局，遵循
references/visual-design.md以了解排列、大小、控制項和狀態，以及references/patterns.md以了解行為。簡而言之：在寬螢幕上，分類列表在頁面旁邊，在窄螢幕上則在頁面之前；一個欄位寬度接近 1,100 px；標籤在左，控制項或當前值在右；相關行放在包含群組中；開關用於開和關，單選按鈕用於兩到五個選項，沒有「儲存」按鈕；目標至少 24 px，觸控目標則為 44 到 48 px；文字對比度 4.5:1；不要只靠顏色顯示資訊。每行顯示其範圍，當它與預設值不同時，則顯示一個已更改的標記和「重置」按鈕。搜尋框位於頂部。每個記錄都有一個穩定的地址。動作應與偏好設定分開，破壞性的動作則應更分開。 - 說出你假設的內容：預設值、範圍和擁有者是你必須猜測的，需要由使用者確認。對未知的擁有者使用
unassigned；不要發明團隊名稱。
標準分類
依序詢問這些問題，並在第一個"是"時停下來。順序是打破平局的關鍵。
| # | 問題 | 分類 |
|---|---|---|
| 1 | 它是關於你是誰、你如何登入、或你支付了什麼嗎？ | 帳戶 |
| 2 | 它是否決定產品何時或如何打擾你？ | 通知 |
| 3 | 它是否控制其他人、其他應用程式或服務可以看到、保留或做些什麼？ | 隱私與安全性 |
| 4 | 它的存在是為了讓有特定需求的人能夠看到、聽到或操作產品嗎？ | 協助工具 |
| 5 | 它是否只改變外觀？ | 外觀 |
| 6 | 它是關於語言、時間或格式嗎？ | 語言與地區 |
| 7 | 它是關於資料存放位置、數量或透過哪個網路嗎？ | 資料與儲存 |
| 否則：它更改了哪個功能？ | 最多兩個產品主題之一（例如訊息、編輯器、播放） |
「關於」（版本、說明、法律資訊）是頁腳的一個連結，不計入分類。由管理員為所有人做的設定是一個單獨的表面。一個設定少於約 15 個的小型應用程式可以使用一個頁面，並將這些名稱作為組標題。
因此，來電鈴聲屬於「通知」，而不是「通話」；「減少動態效果」屬於「協助工具」，而不是「外觀」。當一個設定可能同時屬於兩個分類時，根據第一個「是」的答案歸檔，並將另一個分類的名詞放在其搜尋詞中。references/categories.md 涵蓋了大型產品、套件、命名和推理。
這些名稱是作業系統已經在使用的名稱。從它們開始，只有在產品自己的使用者透過卡片分類法將事物分組不同時，才更改它們。
記錄
| 欄位 | 它所回答的問題 | 允許的值 |
|---|---|---|
id | 它的永久名稱是什麼？ | 一個點分隔的路徑，例如 chat.notifications.sound。永遠不會重複使用或重新命名。 |
kind | 它是哪一類東西？ | preference, action, status, list, destination, command |
subject | 它是關於哪一個名詞？ | 恰好一個主題。這是它的家。 |
scope | 它改變了誰或什麼？ | item, device, account, organization |
tier | 需要它的人有多少？ | everyday, standard, advanced |
label, summary | 它叫什麼，它的作用是什麼？ | 一個簡單的標籤；一句話描述結果 |
search | 一個人會輸入什麼來找到它？ | 同義詞、舊名稱、術語 |
value | 它持有什麼類型的值？ | 一個類型，帶有選項或範圍 |
default, default_reason | 如果沒人動它會發生什麼？ | 大多數人會選擇的值，以及原因 |
risk | 如果更改它會破壞什麼？ | safe, care（可回復）, destructive（永久遺失） |
owner, reviewed | 誰決定它何時消失？ | 一個擁有者和它最後一次被證明為合理的日期 |
目的地和指令使用較少的欄位。完整結構在 references/record-schema.md 中，assets/registry.example.json 是一個可用的範例。
限制條件
| 限制 | 值 | 來源 |
…
（原文已截斷）