UI構造標準

UI構造標準 は何をしますか？

インターフェースが使いにくくなるのは、規模ではなく構造が原因です。300の設定を持つアプリが簡単に操作できる一方で、30の設定を持つアプリが迷路のようになることがあります。その原因は常に同じいくつかの要因に集約されます。同じコントロールが複数の場所に存在する、メニューがコードやチーム構造を反映している、アクションと設定が混在している、ラベルのないアイコン、スコープが不明瞭、そして何も削除されないことです。

解決策は、主要なプラットフォームが既に採用している方法を、すべてのアプリで同じように実践することです。そうすることで、ユーザーは既に知っている知識を活用できます。

• 1つの統一されたレイアウト。 左側に検索可能なカテゴリ一覧、右側に開いているページ、各行は左側にラベル、右側にコントロールを配置します。
• 1セットのカテゴリ名。 アカウント、通知、プライバシーとセキュリティ、アクセシビリティ、外観、言語と地域、データとストレージ、そして製品固有の項目。7つの質問で、あらゆる設定を正確に1つのカテゴリに分類できます。
• コントロールを減らす。 最善の設定は、より良いデフォルト値によって不要になり、決してリリースされない設定です。
• 残った各コントロールに1つのホーム。 すべての設定、遷移先、コマンドはレジストリ内のレコードであり、各レコードには正確に1つのホームがあり、インターフェースはそのレコードから描画されます。誰も手動でコントロールを配置しない場合、構造がずれることはありません。

ジョブを選択

以下の表からリクエストを見つけ、そのセクションと、指定されたファイルのみを読んでください。

リクエスト	セクション	併せて読むファイル
「設定/メニュー項目/ボタンを追加する」	1つのコントロールを追加する	通常はこれのみ
「このUIは乱雑だ」「これをレビューして」「ユーザーがものを見つけられない」	既存のインターフェースを監査する	references/audit.md, references/rules.md
「設定画面、サイドバー、ツールバーを構築/設計/再設計する」、または機能のリストを1つにまとめる	新しいサーフェスを構築する	references/categories.md, references/visual-design.md, references/record-schema.md
「設定を整理する」「どのようなカテゴリを持つべきか」	標準カテゴリ	references/categories.md
「これをプロジェクトに設定する」	レジストリを採用する	references/record-schema.md

どんなジョブであっても、作業中のプロジェクトを尊重してください。コードベースに既に設定レジストリ、コンポーネントライブラリ、またはマークアップに関する独自のルールがある場合は、それらを拡張してください。並行するシステムを導入しないでください。この標準は構造を記述するものであり、テクノロジーを指定するものではありません。

evals/フォルダには、このスキルのテストケースが含まれています。これは参考資料ではありません。タスク中に読まないでください。

1つのコントロールを追加する

以下の5つの質問を順に尋ね、最初に「はい」となった時点で停止します。その判断と理由をユーザーに伝えてください。もはや該当しない質問についてユーザーを誘導しないでください。

1. より良いデフォルト値によって不要にならないか？ デフォルト値を変更したり、状況を検出したり、単にユーザーが嫌がる動作（誰も必要としない確認、自動保存されるものに対するプロンプト）を削除することで、すべてのユーザーのニーズを満たせる場合は、そうしてください。設定は不要です。
2. システムまたは管理者が既に決定しているか？ テーマ、テキストサイズ、通知の許可などは、下位のレイヤーに属します。それに従ってください。製品に独自の選択肢を提供する正当な理由がある場合、その選択肢には「システム設定を使用する」が含まれ、それがデフォルトです。単なるオン/オフスイッチであってはなりません。
3. 一度実行するだけで、継続的な選択ではないか？ その場合はアクションです。ボタンとして、トグルの外側で、コンテキスト内、またはページの下部にあるラベル付きグループに配置します。
4. 週に1回以上変更されるか？ その場合、コントロールはコンテキスト内、つまり変更する機能の隣に、そのホームページへのリンクとともに配置します。ホームページには引き続きリストされます。
5. 約20人に1人未満しか変更しないか？ その場合、ティアは高度です。3つ以上の高度な項目があるページでは、それらを「高度な設定」フォールドに表示します。それより少ない場合は、最後に配置された通常の行です。

それ以外の場合は、該当する主題ページの標準的な行です。

質問1または2への回答が「はい」だった場合は、その旨を明確に述べ、設定の代わりにその変更を提案してください。すべての設定には、テスト、サポート、そして他のユーザーがものを見つける能力にコストがかかるため、ユーザーはまずより安価なオプションを聞くべきです。それでも設定を希望するかもしれません。それはユーザーの判断です。数行でフォールバックとして提供してください。

ホームの選択. 標準カテゴリの7つの質問を使用し、存在するページにマッピングします。コントロールがどれにも当てはまらない場合、それは欠落した主題の証拠です。その旨を述べ、1つ提案してください。「一般」「その他」「詳細設定」という名前のページを作成しないでください。既存のインターフェースにそのようなページが既にある場合は、代わりに最も適切な名前の特定のページに新しいコントロールを配置し、キャッチオールについては後で修正する価値があるものとして1行で言及してください。1つのコントロールを追加するリクエストは、監査のリクエストではありません。

質問をするコントロール. 「次回から表示しない」を伴う確認は、設定のためのコンテキスト内コントロールです（質問4）。チェックボックスと設定行は同じレコードであるため、選択内容を後で見つけて元に戻すことができます。「次回から表示しない」を、それを元に戻す行がどこにもない状態で提供しないでください。

ユーザーにどれだけ表示するか. プロジェクトにレジストリがある場合は、完全なレコード（以下のフィールド）を書き、そのページが制限内にあることを確認してください。ない場合、またはユーザーが単にアドバイスを求めた場合は、平易な言葉で答えてください。何を追加するか、どこに、何という名前か、デフォルト値は何か、その理由、そしてそれがこのデバイスに適用されるかアカウント全体に適用されるか。id、tier、owner、reviewedなどのフィールドは簿記用です。会話の回答には含めないでください。レコードに必要な情報がわからない場合（設定がデバイス間で同期されるかどうか、どのページが存在するかなど）、その前提を節で述べて続行してください。

既存のインターフェースを監査する

目標は、ルール番号に関連付けられた、具体的で修正可能な所見のリストと、提案された構造です。まず references/rules.md を読んで、所見がルールを引用できるようにし、references/audit.md のレポートテンプレートを使用してください。

監査は、設定、ナビゲーション、ツールバー、またはこれらのすべてをカバーする場合があります。ユーザーが尋ねた内容と、あなたが見ることができるものを監査してください。画面に設定がない場合は、テンプレートの設定部分をスキップしてください。無理に当てはめようとしないでください。

1. 棚卸し. ユーザーが何かを変更またはトリガーできるすべての場所をリストします。設定画面、アカウントメニュー、コンテキストメニュー、アイテムごとのダイアログ、ナビゲーションリスト、ツールバー、アイコンストリップ、コマンドラインフラグ、設定ファイル。大規模なコードベースでは、スイープを委任するか、パターン（ラベル、トグル、メニュービルダー）を検索し、巨大なファイル全体を読まないでください。各コントロールについて、表示されているラベル、種類、場所、および到達方法を記録します。コントロールにラベルがまったくない場合は、その旨を述べ、位置で説明し、その機能に関する推測は推測としてマークします。
2. 測定. ルールが制限するものをカウントします。変更可能な場所の数、トップレベルのナビゲーションエントリ数、ページあたりの設定数、深さ、ツールバーあたりのボタン数、アイコンのみのコントロール数、アクセス可能な名前のないコントロール数、検索ボックス数、および同じタイプのオブジェクトが表示する個別のコマンドセット数。
3. 症状を見つける.
   • 同じ設定またはコマンドが複数の場所からアクセス可能、または2つのコントロールがスタックまたは競合している
   • 1つの主題が複数のページに散在している
   • 1つのものに複数の名前がある。ラベルがターゲットのタイトルと異なるリンク、似たような名前が隣り合っている
   • 「一般」「その他」「詳細設定」という名前のページ
   • アクション（エクスポート、削除、サインアウト）が設定や遷移先の間に置かれている
   • スコープがヒントテキストでのみ説明されている、またはまったく説明されていない
   • ラベルにビルダーの語彙が使われている
   • 1つのアイテムのみのグループと、制限を超えた長さのリスト
   • 可視の単語がないアイコン。1つのアイコンが2つの意味に使われている
   • 5つを超えるボタンを持つツールバー。同じタイプのオブジェクト間で異なるコマンドセット
   • 現在位置を示すマーカーがない
   • 画面に複数の検索ボックスがある
   • コントロールの表示、非表示、並べ替えが乱雑さの解決策として提供されている
4. 提案する. 設定の場合：標準カテゴリに加えて最大2つの製品主題、合計で最大9つまで、すべてのコントロールが正確に1つにマッピングされます。ナビゲーションの場合：最大9つのトップレベルエントリ、残りはラベル付きグループの下に。ツールバーの場合：オブジェクトタイプごとに1つのコマンドセット、バーに5つ、残りは「その他」の下に。サーフェスから完全に削除されるものと、その移動先をリストします。グループ化は、カードソートとツリーテストで確認するための提案であると述べてください（5人で大きな問題を見つけ、80%のタスク成功率を目指します）。グループ化はユーザーの考え方と一致する必要があり、それはコードから読み取ることはできません。
5. 変更を順序付ける 誰も再学習する必要がない変更を最初にします。アイコンへの単語の追加と現在位置マーカー、次に重複の統合と名前の統一、次に一貫したツールバー、最後に再グループ化です。移動は既存ユーザーにコストがかかるため、後回しにします。レジストリの採用が適切な場合は、最後に行われ、提案として提供され、強制されません。ユーザーは画面上で何を変更するかを尋ねました。

新しいユーザーにとってどれだけ害になるかによって所見を順序付けます。既に機能しているものを評価します。既存のレジストリ、検索、リセット、またはアドレスメカニズムは、修正の基礎となるものであり、それを述べることで誰も必要としない書き換えを防ぎます。

新しいサーフェスを構築する

1. 最初にすべての項目に5つの質問を実行します。 製品のウィッシュリストには、より良いデフォルト値、システムに属するもの、または設定ではなくアクションであるべきものが常に含まれています。カットした項目はレジストリから除外し、理由を添えてサマリーにリストし、ユーザーがあなたの判断を覆せるようにします。
2. マークアップの前にレコードを書き、references/record-schema.md に従います。レジストリが存在する場合は、それに追加します。
3. 7つの質問（次のセクション）ですべてのレコードを分類します。 空になるカテゴリは除外します。1つまたは2つの設定があるカテゴリは、ユーザーが名前で探す場合（通知）は問題ありません。それ以外の場合は、隣のカテゴリに統合します。主題に関するステータスはその主題のページに残します。アプリ全体の情報のみを「バージョン情報」の下に配置します。
4. 制限（以下）を確認します。 手動またはチェッカーツールを使用して。
5. レコードから標準レイアウトを描画し、references/visual-design.md（配置、サイズ、コントロール、状態）、references/patterns.md（動作）に従います。簡単に言うと、ワイド画面ではカテゴリリストをページの横に、狭い画面では前に配置します。1列で幅は約1100pxまで。ラベルは左、コントロールまたは現在値は右。関連する行はグループ化。オン/オフにはスイッチ、2〜5つのオプションにはラジオボタン、保存ボタンはなし。ターゲットは少なくとも24px、タッチの場合は44〜48px。テキストのコントラストは4.5:1。色だけで情報を表示しない。各行はスコープを表示し、デフォルトと異なる場合は、変更マーカーとリセットボタンを表示します。検索は上部に配置します。すべてのレコードには安定したアドレスがあります。アクションは設定から分離し、破壊的なアクションはさらに分離します。
6. あなたが仮定したことを述べてください。 あなたが推測しなければならなかったデフォルト、スコープ、およびオーナーは、ユーザーが確認する必要があります。不明なオーナーには unassigned を使用し、チーム名を発明しないでください。

標準カテゴリ

順に質問し、最初に「はい」となった時点で停止します。この順序がタイブレーカーです。

#	質問	カテゴリ
1	あなたが誰か、どのようにログインするか、何を支払うかについてですか？	アカウント
2	製品がいつ、どのようにあなたに割り込むかを決定しますか？	通知
3	他の人、他のアプリ、またはサービスが見たり、保持したり、実行したりできることを制御しますか？	プライバシーとセキュリティ
4	特定のニーズを持つ人が製品を見たり、聞いたり、操作したりできるようにするために存在しますか？	アクセシビリティ
5	見た目だけを変更しますか？	外観
6	言語、時刻、または形式についてですか？	言語と地域
7	データがどこに、どれだけ、どのネットワークを介して保存されるかについてですか？	データとストレージ
	それ以外の場合：どの機能を変更しますか？	最大2つの製品主題のうちの1つ（メッセージ、エディタ、再生）

バージョン情報（バージョン、ヘルプ、法的情報）はフッターのリンクであり、カウントされません。管理者が全員に対して行う設定は、別のサーフェスです。約15未満の設定を持つ小さなアプリは、これらの名前をグループ見出しとして1ページを使用します。

したがって、通話の着信音は「通話」ではなく「通知」です。「モーションを減らす」は「外観」ではなく「アクセシビリティ」です。設定が2つに該当する可能性がある場合は、最初の「はい」で分類し、もう一方のカテゴリの単語を検索ワードに追加します。references/categories.md は、大規模製品、スイート、命名、および推論をカバーしています。

これらの名前は、オペレーティングシステムが既に使用しているものです。これらを出発点とし、製品のユーザーがカードソートで異なるグループ化をした場合にのみ変更します。

レコード

フィールド	それが答える質問	許容値
id	その永続的な名前は何ですか？	chat.notifications.sound などのドット区切りパス。再利用または名前変更不可。
kind	それはどのような種類のものですか？	preference, action, status, list, destination, command
subject	それはどの1つの名詞についてですか？	正確に1つの主題。これがそのホームです。
scope	誰または何を変更しますか？	item, device, account, organization
tier	何人の人がそれを必要としますか？	everyday, standard, advanced
label, summary	それは何と呼ばれ、何をしますか？	プレーンなラベル。結果についての1文。
search	人はそれを検索するために何を入力しますか？	同義語、古い名前、専門用語。
value	それはどのような種類の値を保持しますか？	オプションまたは範囲を持つ型。
default, default_reason	誰も触れなければどうなりますか？	ほとんどの人が選ぶ値とその理由。
risk	変更すると何が壊れますか？	safe, care（回復可能）、destructive（永久に失われる）
owner, reviewed	それが削除されるタイミングを誰が決定しますか？	オーナーと、最後に正当化された日付。

遷移先とコマンドは、より短いフィールドセットを使用します。完全なスキーマは references/record-schema.md にあり、assets/registry.example.json は動作例です。

制限

| 制限 | 値 | 由来 |

…

[翻訳のため省略]