担当サービスのcomponentがちょっと辛くなってきたので、世間的に有名なデザインガイドラインを参考にしまくろうと読んだのでメモ。

2016/7/21時点のMaterial Design - Dialogを訳読します。かなり意訳含む。
当方英語はたぶん中学生レベルなので、間違っていたり、こういう意味じゃないこれ？とかあればご指摘いただけますと助かります(´･ω･`)

ねらい：

モデルケースの理解
デザインガイドラインに必要な構成要素の確認
Material Designへの理解を深める
英文読解の速度向上

やらないこと:

完全な日本語訳: 意味がわかればok。言い回しガンガン変えてます

注意

わからなかった箇所は ? つけてます。
NOTE: 斜体 は自分のメモ書きのための超意訳。間違ってるかも。

なぜDialogかというと、うちのDialogが結構やばいから。
あとシステマチックなUIの割に、解釈がサービスによってかなりまちまちだから。

ダイアログ

ダイアログはユーザに特定のtaskを知らせる。重要な情報やユーザの意思決定、複数のtaskを含んでいてもよい。

ダイアログはtextとUI controlを含みます。却下されるか、必要な行動がなされるまで、それにfocusさせ続けます。ユーザの操作などを中断させるものなので、控えめに使うべきです。

ダイアログのタイプ:

アラート: 状況を伝えたり、承認を求めるためにユーザの操作を中断させるもの
シンプルダイアログ: リスト項目の詳細や行動を提供する
シンプルメニュー: リスト項目のオプションを表示する
認証ダイアログ: ユーザに明確な選択を承認することを求める

ふるまい

ダイアログは他の要素や、画面上の何かに覆い隠されることはありません。
ダイアログは却下されるか、必要な行動がなされるまで、常にfocusし続けます。

全画面ダイアログ(mobileのみ)

全画面ダイアログは、保存前に一連のタスクをまとめて行うために(?)、複雑なタスクや入力方式エディタ(IME)に最適です。

Behavior ... ふるまい
Alerts ... アラートについて
Simple menus ... シンプルメニューについて
Simple dialogs ... シンプルダイアログについて
Confirmation dialogs ... 認証ダイアログについて
Full-screen dialogs ... 全画面ダイアログについて
Specs ... 詳細な仕様

1. ふるまい

1-1. Beyond standard dialogs: ダイアログを使うべきでない場合?

ダイアログはモーダルウィンドウのサブタイプであり、ここでの包括的な例としては、標準的なマテリアルシステムのダイアログのためのものです?。（他のモーダルウィンドウの構造は、ここで覆われていない?。なぜなら、それらは購入フローのためのブランドボタンや、非標準的なUIフォーム要素、独自のレイアウトのような、とても多くのバリエーションを持つからだ。）

NOTE: 標準的なダイアログに収まらないような、多くのバリエーションを持つ場合はダイアログを使うべきでない？

1-2. 中断を減らすこと

ユーザの行動を中断するものなので、ダイアログの多用は控えること。ダイアログは突然現れ、ユーザに現在のtaskを中断させ、ダイアログの内容に集中させます。全ての選択や設定、あるいは詳細な承認をさせるべきではありません。そういった場合は、ダイアログの代わりに、現在のコンテキストを維持するメニューや、インラインの拡張を用いるべきです。

NOTE: ユーザの意図しない妨害物なので、無闇に使うべきではない。全てをダイアログ上でさせるのではなく、メインコンテンツに配置するなどの代替手段を講じるべき。

1-3. ダイアログを目立たせる

ダイアログは、他の要素や画面上の何かで遮られてはいけない。ダイアログは却下されるか、設定を選択するなどの必要な行動がなされるまで、常にfocusし続けます。

ダイアログが避けるべきこと:

ダイアログ上で別のダイアログを開くこと
スクロールさせるコンテンツを含めること

1-4. 全画面ダイアログの例外

アプリケーションのZ軸方向の認識や視覚的なノイズを著しく増やすことなく、それらのデザインが素材の付加的なレイヤーをもつために、全画面ダイアログは、pickerのような付加的なダイアログを開くかもしれない。

NOTE: 理解できる範囲の階層かつ視覚的に煩わしくなければ、全画面ダイアログ上でpickerのような付加的なダイアログを開くことは許容する。

1-5. スクロールさせるコンテンツの例外

着信音リストのような、いくつかのダイアログコンテンツはスクロールを要する。

スクロール可能なオプションのリストのために、ダイアログは上部にタイトルを固定する。アイテムのリスト上の位置によらず、タイトルが見える状態でアイテムを選択できるようにすること。
さもなければ、タイトルはコンテンツ上からスクロールアウトします。Actionは常にコンテンツのスクロール時に所定の位置に残ります。

ダイアログは、ダイアログを呼び出す親要素からは分離されたものであり、親要素自体をスクロールすることはありません。

NOTE: リストなどのデータ表示ならスクロールできてもよい？。その場合は何のリストかわかるようにタイトルを固定しておくこと。

1-6. 付加的な要素の表示

ダイアログ上の付加的なコンテンツを開示するために、コンテンツ領域にインライン拡張します?。もしくは、たくさんのコンテンツに最適な代替componentを使うことを検討してください。

1-7. ダイアログの拒否

ダイアログは、ダイアログ外をタッチ/クリックする、あるいは、Androidのバックボタンを使うことで拒否できます。あるいは、ユーザーにはっきりとどれか１つのアクションを選ばせるために、ダイアログの挙動は無視されることもあります?。

2. アラート

アラートは、承認を求めたり、ユーザの置かれた状況を伝えるために、ユーザの操作を中断させるものです。

2-1. Snackbarとの違い

Snackbarは、confirmや下書きの破棄などのような操作の後の付加的な情報を表示します。ユーザに、たった今行った操作の取り消しを可能にします。

2-2. タイトルバーのないアラート

多くの場合、アラートにはタイトルは必要ありません。
アラートは、文章かどちらか一方を選択させる (?):

質問を尋ねる（例：「この会話を削除しますか？」）
アクションボタンに関連した意見を作る

Do: "Discard draft? - CANCEL, DISCARD"
肯定的なアクションテキスト"Discard"は、決定の結果をはっきりと示している。

Don't: "Discard draft? - NO, YES"
否定的なアクションテキスト"No"は、質問に回答はするが、その後何が起きるかを示していない。より良いアクションの組み合わせは、明確に"Cancel"と"Delete"とすることだ。

2-3. タイトルバーのあるアラート

タイトルバー付きのアラートを使うのは、connectivityを失なう恐れのあるような、ハイリスクな状況のみです。タイトルとボタンテキスト単独で、ユーザーが選択を理解出来るようにすべきです。

もしタイトルが必要なら：

「USBストレージを消しますか？」のような、明確な質問やコンテンツ領域の説明つきのステートメントを使う
「警告！」や「本当にいいですか？」のような、謝罪や曖昧なもの、質問文を避ける

Do: このダイアログは明確な質問を投げかけている。actionの影響を簡潔に詳細を説明し、明確なactionを提供している。

Don't: このダイアログはあいまいな質問を投げかけており、影響の範囲がはっきりしない。

NOTE: アラートはほとんどの場合タイトル無しで成り立つ。重大な警告であればタイトルがあってもよいが、その場合も、タイトルやアクションボタンのみで状況を把握できるよう、明確な質問や説明・選択肢を用意すること。

3. シンプルメニュー

mobile, tabletのみ

シンプルメニューはリスト項目のオプションを表示します。そして、ただちに選択肢から選ばせます。詳細はComponents > Menus > Simple Menusを見てください。

相違点： シンプルダイアログはリスト項目や関連するアクションののための詳細なオプションを表示します。シンプルダイアログはシンプルメニューと同じようにコンテンツを表示できます。
しかしながら、シンプルメニューの方がユーザの現在のコンテキストをより妨害しないため、シンプルメニューの方が好ましいです。

4. シンプルダイアログ

シンプルダイアログは付加的な詳細やリスト項目についてのアクションを提供します。たとえば、シンプルダイアログはアバターやアイコン、明確なサブテキスト、あるいは直行するアクション（アカウント追加のような）を示すことができる。

タッチした時の挙動:

ただちにオプションを選択することで、オプションとメニューを閉じる
ダイアログ外をタッチしたり、backボタンを押すことで、アクションをキャンセルし、ダイアログを閉じる

4-1. 中断を減らすこと

シンプルダイアログは、シンプルメニューよりユーザの操作を遮るものなので、控えめに使われるべきです。

4-2. 明確なキャンセルボタンは置かない

シンプルダイアログは、承認やキャンセルのような明確な操作のボタンを持ちません。

Don't: このシンプルダイアログは明確な「Cancel」ボタンを持っている

4-3. 詳細

行の高さはシンプルダイアログ毎に異なる
シンプルダイアログは画面上の垂直/水平方向に中央に表示される
スクリーンの端からダイアログまでの距離は、少なくとも左右40dp、上下24dpは空けること
ダイアログのコンテンツはダイアログの端から24dp空けること

4-4. Avoid text wrapping:

シンプルメニュー上のテキストが別の行を包括するなら、代わりにシンプルダイアログを使います??。

Do: このシンプルダイアログは行の高さが異なる

5. 認証ダイアログ

認証ダイアログは、ユーザに、選択肢が実行される前に、明確に確認を求めます。たとえば、ユーザは複数の着信音を聞くことができますが、最終決定をするのは「OK」をタッチする時だけです。

認証ダイアログで「Cancel」をタッチするか、backボタンを押すと、actionをキャンセルし、変更を破棄してダイアログを閉じます。

例: 次の認証ダイアログでの着信音の選択は、「OK」をユーザが押すまで設定されません。control付きの認証ダイアログの例はテキストの左側に位置します。

NOTE: アラートとの違いは、confirmのコンテンツ領域での選択の有無？

5-1. １つの値の認証とすること

認証ダイアログは、date pickerのよいな、リスト以外のレイアウトに使用できますが、シンプルな値を明確にすることに集中します?。(日付は選択するが、時刻と曜日は選択しない)

例: 日付の選択はユーザが日付をタッチし、「OK」ボタンを押すことでsetされます。
例: ユーザは手で時計を動かし「OK」をタッチすることで、時刻を選択します。

5-2. キャンセルボタンと承認ボタン

認証ダイアログは、明確な承認ボタンと明確なキャンセルボタンの両方を提供します。キャンセルボタンかbackボタンをタッチするか、離れることで、変更を破棄します。

5-3. ダイアログがダイアログを開くことを避ける

奥行きの把握や視覚的複雑さが増すため、認証ダイアログは付加的なシンプルダイアログやシンプルメニューを開くことを避けるべきです。もし複雑なtaskが必要とされるなら、代わりに全画面ダイアログを用いることを検討してください。

Do: 明確な確認とキャンセルボタンを提供している
Don't: １つしかないダイアログボタンは、システムのbackアクションの影響を曖昧にします。backでキャンセルするのか、それとも確定するのでしょうか？

6. 全画面ダイアログ

Mobileのみ: スペースが限られているので、全画面ダイアログは、より大きな画面の端末で使われるダイアログよりも、モバイル端末に適しているかもしれません。

6-1. 使い方

全画面ダイアログは、実行するか破棄する前に、一連のtaskをまとめます（例：カレンダーの予定の作成）。「Save」がタッチされるまで、何の選択も保存されません。「X」をタッチすると、すべての変更を破棄しダイアログを抜けます。

全画面ダイアログは複雑なレイアウトや、山積みになったマテリアルのシートの見た目を最小限にし、一時的にアプリケーションの理解度を高い基準値にリセットすることを可能にします?。複雑な操作の１つとして、シンプルメニューやシンプルダイアログを開くことを許容します。

全画面ダイアログは、これらの基準に合うタスクの中身のために用いられます。

ダイアログは、たとえばkeyboardのような入力方式エディタ（IME）を必要とするcomponents（pickerやform要素など）を含みます
リアルタイムで保存されないとき
アプリケーションに下書きする容量？がないとき
バッチ処理やキューの実行がそれらに先立って変更するとき?

例: 全画面ダイアログは、日付の選択に使われるシンプルダイアログをサポートします。
例: date pickerは全画面ダイアログから開かれます。

6-2. Actions

承認/拒否ボタンは画面上部の全画面ダイアログ上に配置する

6-3. 承認

承認アクションには、説明的な動詞（例：保存する、送る、シェアする、更新する、作成する）を用い、画面の右上に配置する。承認actionに、「完了」「ok」「閉じる」などの曖昧なラベルは用いません。

承認アクションは、ダイアログ上のすべての必須項目を埋めるまで、非活性にしておきます。

6-4. 破棄

画面左上の×ボタン、バックボタン共に、破棄アクションは全画面ダイアログを閉じ、変更を破棄します。

何の変更もない場合、ダイアログは閉じ、破棄確認は必要ない。
もしユーザが変更を加えていた場合、破棄アクションの承認を促す。

Don't: 承認アクションに「閉じる」のような曖昧な表現を用いている
Do: 何か変更を加えている場合に、破棄アクションの承認をユーザに促している。

6-5. ナビゲーション

全画面ダイアログの中で用いられる「×」は、常に保存されている状態を示す「↑」とは違うものです。たとえば、設定で用いられる↑は、明確な承認やキャンセルアクションなしに、すべての変更がただちに実行されることを示します。

例：設定画面上の「↑」は、どの変更も選択に応じてただちに保存されることを示す。
例：設定画面上の「×」をタッチすると、すべての変更を破棄します。変更は保存をタッチしないと保存されません。

NOTE: 「←」ボタンが左上にある時は、変更が即座に保存されるもの。（The up arrow（↑）じゃなくて「←」な気がする・・・）

6-6. タイトル

全画面ダイアログのタイトルは、Dynamic Typeを使いません。

タイトルは簡潔であるべきです。タイトルはもし必要なら二行になってもよく、それでもはみ出る場合は省略されるべきです。

もし全画面ダイアログが可変長のタイトルや想定以上に長いタイトル（たとえば、他言語にすることで長くなってしまう単語など）を使う場合、タイトルテキストを、App barの代わりにダイアログのコンテンツ領域に配置します。

Don't: App barに可変長のタイトルを用いることは避ける。
Do: 長いタイトルは全画面ダイアログのコンテンツ領域に配置している。

7. Spec: 仕様

ダイアログはコンテンツ、アクション、オプショナルのタイトルを持ちます。

7-1. タイトル（option）

タイトルは選択がもたらす形式を簡潔に説明します。タイトルは常に全体が表示され、必要な時にのみ使われるべきです。たとえば、タイトルは、ダイアログのタスクのどれが関係していて、決定がどのような影響を与えるかを明確にします。

7-2. コンテンツ

ダイアログの内容は、一般的に、テキストやUI操作の要素から成り立ちます。アイテムの削除や設定項目の選択を承認するなどの特定のタスクに集中させることができます。

7-3. アクション

ダイアログは集中をもたらし、通常肯定的/否定的なアクションセットに限られます。

肯定的なアクション: 右側に配置し、プロセスを続行します。肯定的なアクションは「Delete」「Remove」などのような破壊的なものです。
否定的なアクション: 肯定的なアクションの左側に配置し、元の画面に戻るか、プロセスの途中に戻ります。
肯定的/否定的なアクションのラベル: 「キャンセル/OK」や特定の能動詞や決定の結果を表す動詞句にします。

Don't: 否定的なアクションが肯定的なアクションの左側にある

ダイアログは、ダイアログのタイトルとコンテンツに直接関連する、明確な選択を持ちます。

Don't: ユーザーに多義的であいまいな選択を与えない。この例では、明確なアクションが提示されていないので、「キャンセル」は、タイトルに関連した意味を持たない。

7-4. 承認アクション

継続を求めるダイアログが必要な状況では、アラートでは、アクションを１つにすべきです。このタイプのアラートは破壊的なので多用しないようにしましょう。view content内に拡張するような、ユーザに情報を伝える別の手段を検討しましょう。

7-5. アクションの数

ダイアログは２つより多くのアクションを持つべきではありません。「Learn more」のような３つめのアクションは、ダイアログから離脱し、タスクが未完了になる可能性があります。

ヘルプページへの誘導に「Learn more」というアクションを使うことを避けましょう。代わりに、ダイアログ上にインラインで書くべきです。もしより広範囲な情報が必要なら、ダイアログに入る前に提供しましょう。

Don't: 「Learn more」アクションはダイアログを離脱し、はっきりしないstateのままにしてしまいます。

NOTE: ヘルプへの誘導はコンテンツに含める。ユーザが混乱し離脱されかねないので、３つめの選択肢は避ける。

7−6. 色

ダイアログのアクションは通常システムカラーを用います。しかしプロダクトのカラーパレットを反映します。ダイアログの内容とダイアログのアクションを区別するために、カラーパレットのアクセントカラーのようなcontrasting colorを使いましょう。

7-7. 大文字のない言語?

中国語や日本語、韓国語のような、大文字のない言語では、本文と区別するために、一定の配置やスペース、色は重要です。

たとえ肯定的なアクションが非活性であっても、一定の配置のアクションやテキスト色は本文とアクションを区別するのに役立ちます。

肯定的なアクションは何かを選択するまで非活性にします。否定的なアクションは非活性にすることはありません。

7-8. コンテンツガイドライン

コンテンツ領域の余白: 24dp
タイトルと本文の間の余白: 20dp
ボタン周りの余白: 8dp
ボタンの高さ: 36dp
アクション領域の高さ: 52dp
ダイアログの標高?: 24dp

コンテンツ領域では、アクションと区別するために、下部に24dp空けます。

7-9. ボタンの幅と余白

ボタンの高さ: 36dp
ボタンの最小幅: 64dp
ボタンの内側の余白: 8dp
ボタンとボタンの間隔: 8dp
ボタンの高さ: 36dp
ボタンエリアの高さ: 52dp
左のボタンの余白: 24dp （超意訳）左側のボタンには最低でも24dp空ける必要がある?
右のボタンの余白: 8dp
ボタン間の余白: 8dp

スクロールするダイアログでは、コンテンツ領域とアクションの間に境界線を引きます。

7-10. 隣り合わせのボタン

ボタンを並べるときは、「OK」「キャンセル」ボタンのように、通常それぞれのラベルがボタンの最大幅を超えないようにする。

ダイアログ上のボタンの最大幅を求めるには:
ダイアログのボタンの最大幅 = (ダイアログの幅 - 8dp - 8dp - 8dp)/2

7-11. ボタンの最大幅を超える場合： stacked buttonを使う

最大幅を超えるラベルのボタンのとき、テキストに配慮してボタンを縦に積みます（stacked buttonsを使う）。肯定的なアクションは否定的アクションの上に積みます。

タップできるボタンの高さ: 48dp
テキストとタップ領域の間隔: 24dp
タップ領域とダイアログの下部の余白: 8dp
ボタンテキストの右端とダイアログの端の余白: 16dp

7-12. シンプルダイアログのkeyline

左端と右端の縦方向のkeylineは24dpにします(?)。アイコンやアバターがあるときは、コンテンツは左端から80dp空けます。

7-13. 全画面ダイアログのタイトル

全画面ダイアログのタイトルは必要であれば２行になっても構いませんが、それ以上は省略すべきです。タイトルは簡潔にすべきですが、他言語対応で単語が長くなるような場合には、タイトルをwrapする必要があるかもしれません。

１行のテキストの場合のapp barの高さ: 56dp
２行のときのapp barの高さ: 80dp
タイトルテキストのkeyline: 72dp
タイトルテキスト: 20sp
タイトルテキストの上下の余白: 20dp
否定的アクションの左端の余白: 16dp
肯定的アクションのテキスト: 14sp
肯定的アクションの左右の余白: 16dp

まとめ

Alertって選択できないもので、Confirmは与えられた２択から選択するようなものだと思っていました(´･ω･`)
ダイアログonダイアログは避けるべきだと思っていましたが、全画面ダイアログ上でならOKとか、線引きが重要そうです。

デザインガイドラインに必要そうなもの

Material DesignとSemantic UIのGlossaryを参考に…

項目	説明
概要	Componentが何のためのものなのか、何を表すものなのか、機能効果とデメリットについて
Type	alertやconfirmなど、別タイプが存在する場合組み合わせ不可
Variation	サイズ、色違いのパターン組み合わせok
Usage	使い方類似するComponent, Typeとの違いの説明。使う/使うべきでないケースと例外 OK,NGパターンの例示
Behavior	Componentの挙動（タップ時やkey操作時など、Componentとして意図する挙動を全て）
State	loading,errorなどのステート
Contents Spec	Componentの構成要素について、オプションか必須か
Design Spec	余白や文字サイズ、レアケースでの表示の変更の詳細要素の配置の意図

Material DesignのDialogを訳読してみる