Human Interface Guidelinesの学びとデデザイン例をまとめてみた Vol.5 【/controls編】

ゆん

2021年10月20日 11:46

HIGレポートの第5弾となる今回は、Human Interface Guidelinesの/controls編をまとめました。

Buttons

要約・学び）
ボタンは何か固有のアクションを開始できるもの。背景色・テキスト・アイコンなどカスタマイズが可能。

システムボタンはナビゲーションバーやツールバーに表示されることが多いもので、どこでも使用可能。

ボタンのテキストは基本動詞にすること（個人的に重要と認識）。またボタンはボタンをタップすると何が起こるかを示し、インタラクティブ性？を持つこと。他にもテキストは冠詞、接続詞の調整、4文字以下の前置詞を除くすべての単語を大文字にすること。

またテキストのコピーを作る際にはテキストを短く意識すること。長いと小さい画面では切り捨てられる可能性がある。

デフォルトでは、システムボタンには境界線や背景はなしで、必要な場合にのみ、境界線または背景を追加することを検討する。

※背景色なしの動詞で大文字の例、これがデフォルト

Detail Disclosure Buttons
[詳細開示]ボタンは、追加的な情報をモーダルビューで表示する。

Info Buttons
[情報]ボタンは、アプリの構成の詳細を表示するもの。アプリのデザインと調和させることを意識する。

Add Contact Buttons
ユーザーは、[連絡先の追加]ボタンをタップすると、連絡先のリストを参照し、加えてキーボード入力を許可し、連絡先を記入することができる。

上記画像はすべて原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/buttons/

参考デザイン）

カレンダーデモ

※背景色なしの動詞?の例

Color Wells

要約・学び）
カラーウェルは、タップするとカラーピッカーが表示される。カラーピッカーを使用することで、一貫したユーザーエクスペリエンスを提供するのに役立つ。

上記画像はすべて原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/color-wells/

Context Menus

要約・学び）
コンテキストメニューを使用することで追加機能？別アクションができる。またコンテキストメニューによってインターフェイスの乱雑を防ぐ。

上記画像は原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/context-menus/

コンテキストメニューはPeeka and Pop??に似ているが、大きな違いがある。

- コンテキストメニューは、iOS13以降を実行しているすべてのデバイスで使用できます。Peek and Popは、3DTouchをサポートするデバイスでのみ使用できます。
- コンテキストメニューには、コンテキストに関連するコマンドがすぐに表示されます。ピークアンドポップでは、コマンドを表示するために上にスワイプする必要があります。

↑原文まま）

一貫してコンテキストメニューを採用すること。一部の場所でアイテムのコンテキストメニューを提供し、他の場所では提供しない場合、ユーザーはその機能をどこで使用できるかわからなくなる。

またよく頻繁するアイテムはメニュー内の上部に設置すること（思考：上から読むからなのか？あまり上部すぎるとタップしづらくなると思ったが、コンテキストメニュー内の量がそこまで多くなるとは考えられないので問題なし）。

背景としては上部に配置すると、ユーザーは探しているアイテムを見つけるのに役立つから。またメニュー内は各項目をグループ化すること。視覚的なグループを作成すると、見つけやすくなる。

他にも、コンテキストメニューと編集メニューを同じにしないこと。同じアイテムに対して両方の機能が有効になっている場合、ユーザーは混乱するため。

Edit Menus

要約・学び）
テキストフィールド、テキストビュー、Webビュー、画像ビューの要素を長押しまたはダブルタップすると、コンテンツを選択し、コピーや貼り付けなどの編集オプションを表示すること。

編集オプションはデフォルトで、オプションには[切り取り]、[コピー]、[貼り付け]、[選択]、[すべて選択]、および[削除]コマンドが含まれる。

編集オプションを実装する上で、3つ意識する。
・編集メニューと同じ機能を持つ他のコントロールを実装しないこと。ユーザーエクスペリエンスに一貫性がなく混乱を招く。
・カスタムコマンドの数を最小限に抑えること。選択肢が多すぎると圧倒される。
・カスタムコマンド名は短くすること。動詞または短い動詞句にし、大文字を使用します。※冠詞、接続詞の調整、4文字以下の前置詞を除くすべての単語を大文字に適用する

参考デザイン）

Labels

要約・学び）
ラベルは、短いメッセージにすること。画面上のインターフェイス要素を説明するに関しては不明。

背景としては？ラベルを読みやすくすること。ラベルのスタイルを調整したり、カスタムフォントを使用したりする場合は、読みやすさを犠牲にしないこと。

ユーザーがデバイスのテキストサイズを変更してもラベルの見栄えが良くなるように、動的に対応するようにすること。

Page Controls

要約・学び）
ページコントロールは、フラットな画面数を示す。ページコントロールは目的のページを見つけるのに役立つ。

ページコントロールの外観・デザインに関して。現在開いているページのインジケーターを強調的に表示する。おそらく白の濃さを他より濃くするがスタンダードな気がする。これによってユーザーはリスト内のページを他と比較でき、相対的な位置を推定できるようになる。またリストが多いときは収縮する。またリストが多い場合は、ページコントロールに加えてリストビューを提供することを検討すること。リストが長いと、スワイプジェスチャが疲れる可能性がある。

またページコントロールは画面下部かつ中央に配置する。ページコントロールの場所を常に知っているようにする、つまりスタンダードなところに位置させる。

Customizing Indicator Images
カスタムインジケーターの場合は、最大2種類で、リストに特別な意味を持つ1つのページを見つけやすくする。

上記画像はすべて原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/page-controls/

Pickers

要約・学び）
ピッカーは、1つ以上の値でスクロールしてリストを表示する。例えば日付ピッカーで、日付や時刻を選択できる。値を選択することで、情報を簡単に入力できるようになる。

ピッカーの使いどころとしては、選択肢が多い時（中程度から~多）、一方で選択肢が短いときはプルダウンメニューを採用する。※でもこれってwebの話でネイティブだと選択肢が短い性別の選択でもピッカーが多い気がする

ピッカーだと視覚的重みがあり、操作性が限定されると書いている。たしかにピッカーはアラート的な感じでポップオーバーの形式で表示されるため、その考えは受け入れられる。ゆえにユーザーからすると負担を強いられそう。選択肢が少ない場合はユーザーがわざわざ負担のかかる、制限される手段を取らなくてもいいと思う。

選択肢の数によって決定するUIに関して他にも存在し、選択肢がかなり多い場合、リストかテーブルを採用するのが推奨とのこと。背景としてはリストとテーブルは高さを調整でき、テーブルにはインデックスを含めることができるため、リストのセクションをターゲットにするのがはるかに高速になるため。

またこれは重要な原則で、ピッカーの順番は、予測可能で論理的な順番にすること。たとえば国だとアルファベット順にしたり、他にもよくあるものだと都道府県を北からに整列するなど。

背景としては、順番が分かるとユーザーは自分の選びたい項目にすばやく移動できる。逆を言えば順番がわからないとユーザーは一個一個読んで選択肢を探さなければならないため、選択に時間がかかる。

Date Pickers
（あまり見たことがないが）日付ピッカーはテーブルなどグループ化されたピッカー。

- インライン—リストやテーブルの行などの小さなスペースに収まり、展開して編集ビューを表示する編集可能なフィールド
- コンパクト—モーダルコンテキストで編集ビューを表示するために展開するラベル
- ホイール—従来のスクロールホイールのセット

上記画像は原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/pickers/

日付ピッカーには4つのモードがある。

- 日にち。月、日、年を表示します。
- 時間。時間、分、および（オプションで）AM / PM指定を表示します。
- 日時。日付、時間、分、および（オプションで）AM / PM指定を表示します。
- カウントダウンタイマー。最大23時間59分までの時間と分を表示します。このモードはコンパクトスタイルでは使用できません。

参考デザイン）

Progress Indicators

要約・学び）
Progress Indicatorsはアプリがコンテンツを読み込んだり、長時間のデータ処理操作を実行したりなとローディング中に表示するもの。アクティビティインジケーターやプログレスバーで、アプリが停止していないことをユーザーに知らせ、待機時間を知らせる。

これを使う背景としては、静的な画面を見つめてステイさせないようにするため。

Activity Indicators
アクティビティインジケーターは、定量化できないタスクが実行されている間に回転して表示されるもの。

逆に定量化できている場合はプログレスバーを使い、できるだけ定量化されているプログレスバーを優先すること。

背景としては、ユーザーが何が起こっているのか、どのくらいの時間がかかるのかを把握できるようにするため。個人的な見解としては、どれだけ待たされるかわからない場合の方がユーザーはフラストレーションが溜まることから、できるだけ可視化して、不満を作らないようにさせる。

またアクティビティインジケーターは、タスクの完了を待っている間に、役立つ情報とセットで利用すること。通常のインジケーターだけでは何の価値ももたらさないため。

Progress Bars
プログレスバーには、タスクの進行状況を示すために左から右に塗りつぶされていくインジケーター。

プログレスバーは前述の通り、明確に定義された期間のタスクに用いる。進捗状況を正確に共有すること。不正確な進行状況情報を表示しないこと。またアプリに合わせて（例えば色や画像など）プログレスバーの外観をカスタマイズ可能。

Network Activity Indicators
ネットワークアクティビティインジケータは、ネットワークが発生すると、ネットワークアクティビティインジケーターが回転し、ネットワーク（接続？）が完了すると消える。

ただし、iOS13およびエッジツーエッジディスプレイを備えたデバイスでは非推奨です。 iOS 12以前、および端から端まで表示されていないデバイスでは使用。

上記画像は原文を参照）
https://developer.apple.com/design/human-interface-guidelines/ios/controls/progress-indicators/

iOS 14以降では、ボタンでプルダウンメニューを表示して、ユーザーが選択できるアイテムやアクションを一覧表示できます。プルダウンメニュー（または単にメニュー）を使用して、ボタンのアクションに直接関連するアイテムを提供したり、現在のコンテキストで役立つアクションのリストを提供したりできます。

メニューには、アクションシート、コンテキストメニュー、ポップオーバーに比べていくつかの利点があります。

例えば：
- メニューは、それを表示するボタンのすぐ近くで開くので、人々はメニューの項目と実行しているアクションとの関係を即座に理解できます。
- メニューには、アクションの一覧表示に加えて、主要なアクションに影響を与えるために使用できる選択肢を提供できます。
- メニューはすばやくアニメーション表示され、表示時に画面が暗くなることはないため、トランジションと全体的なエクスペリエンスの両方に軽量感があります。

Pull-Down Menus

要約・学び）
iOS 14以降では、ボタンでプルダウンメニューを表示して、ユーザーが選択できるアイテムやアクションを一覧表示できます。

メニューには、アクションシート、コンテキストメニュー、ポップオーバーに比べていくつかの利点があります。

- メニューは、それを表示するボタンのすぐ近くで開くので、人々はメニューの項目と実行しているアクションとの関係を即座に理解できます。（現在のアクションから近いので、文脈をすぐに理解し、すぐにアクションしてもらえる？）
- メニューには、アクションの一覧表示に加えて、主要なアクションに影響を与えるために使用できる選択肢を提供できます。
- メニューはすばやくアニメーション表示され、表示時に画面が暗くなることはないため（ポップオーバーのように）、トランジションと全体的なエクスペリエンスの両方に軽量感があります。

メニューにすべてのアクションを入れないこと。たしかにメニューに含めると、インターフェイスを乱雑にすることなくデザインできつつも、メニューに含めてしまうと、階層が一段階深くなり、ユーザーは何かを行うために少なくとも2回タップする必要がある。

メニューのUIはセパレータ・グループ化を使用することで、ユーザーは関連するメニュー項目を視覚的にすばやく理解できる。ただし、メニューで3つ以上のグループを使用すると、解析が困難になる可能性がある。

メニュー項目が破壊的である場合、メニューは赤いテキストを使用してユーザーに知らせる。プラス、アクションを選択すると、ポップオーバーで表示すること。

参考デザイン）

Refresh Content Controls

要約・学び）
ユーザーが手動でコンテンツの更新を実行するもの。例えばメールアプリでは、受信トレイメッセージのリストを下にドラッグして更新し、新しいメッセージを確認できる。

ただし、定期的に自動更新して、データを最新の状態に保つようにすること。ユーザーはコンテンツの即時更新をトリガーできることを嬉しく思うけれど、更新させないこと。すべての更新を開始する責任をユーザーに負わせてはいけない。つまりユーザーは自分でコントロールできることにプラスの感情があるが、そもそも本質としてユーザーの負担を増やさないようにシステム側で常に自動更新する必要あり。

またアニメーションがあるため、基本的には？テキストは不要です。その代わりに？更新されるコンテンツに関する価値のある情報を伝えると良い。たとえば、ポッドキャストの更新コントロールは、タイトルを使用して、ポッドキャストの最後の更新がいつ行われたかをユーザーに通知するといったようなもの。

参考デザイン）

Segmented Controls

要約・学び）
セグメントコントロールは、2つ以上から構成され、各セグメントは相互に排他的なボタンとして機能する。

UIとしては、すべてのセグメントが同じ幅で、ボタンと同様に、セグメントにはテキストまたは画像を含めることができる。

取り扱いの注意事項
- セグメントの数を制限すること。背景としてはセグメントが広いほどタップしやすくなり、広く保つためには数を制限すること。iPhoneでは5つ以下を推奨。
- セグメント内のサイズの一貫性を保つこと。すべてのセグメントの幅が等しいため、コンテンツが一部のセグメントを埋めて他のセグメントを埋めない場合は見栄えがよくない。
- セグメント内ではコントロールでテキストと画像を混在させないこと。個々のセグメントにテキストまたは画像を含めることができるが、2つを1つのコントロールに混在させると、インターフェイスが切断されて混乱する可能性がある。
- セグメント内にコンテンツを適切に配置すること。セグメント化されたコントロールの背景の外観を変更する場合は、コンテンツの見栄えが良く、位置がずれていないことを確認すること。