HIGまとめ ー App Architecture ー

ローディング（Loading）

コンテンツの読み込み中に空白または静的な画面が表示されると、アプリがフリーズしているように見え、混乱とフラストレーションが生じ、ユーザーがアプリを離れる可能性があります。

ローディングが発生しているときは明確にしてください
少なくとも、何かが起こっていることを伝えるアクティビティスピナーを表示します。さらに良いのは、はっきりと進捗状況を表示して、ユーザーが待機時間を測定できるようにすることです。

できるだけ早くコンテンツを表示します
期待する画面が表示される前に、コンテンツの読み込みで人々を待たせないでください。すぐに画面を表示し、コンテンツがまだ利用できない場所を見分けるためにプレースホルダーテキスト、グラフィック、アニメーションを使用します。コンテンツが読み込まれたら、これらのプレースホルダー要素を置き換えます。可能な限り、アニメーションの再生中やユーザーがレベルやメニューを操作しているときなど、その後のコンテンツをバックグラウンドで前処理します。

読み込み時間を隠すために人々に訓練させたり、楽しませます
ゲームプレイ、面白いビデオシーケンス、興味深いプレースホルダーグラフィックスについてのヒントを示すことを検討してください。

ロード画面をカスタマイズします
標準のプログレスインジケーターは通常は問題ありませんが、ときどき文脈から外れていると感じる場合があります。アプリやゲームのスタイルに合ったカスタムアニメーションや要素を使用して、より没入感のある体験を設計することを検討してください。

追加のガイダンスについては、プログレスインジケーターを参照してください。

モダリティ（Modality）

モダリティは、ユーザーの前の文脈から離れた一時的なモードでコンテンツを提示するデザイン手法であり、終了するには明示的なアクションが必要です。コンテンツをモーダルで提示すると、次のことができます。

・自己完結型のタスク、または密接に関連する一連のオプションに人々が集中できるようにします
・人々が重要な情報を受け取り、必要に応じて行動するようにします

iOSは、アプリ内で特定の状況で使用するアラート、アクティビティビュー（またはシェアシート）、およびアクションシートを提供します。アプリでカスタムモーダルコンテンツを表示するために、iOS 13以降では次の表示スタイルがサポートされています。

シート（Sheet）

シートプレゼンテーションスタイルは、基礎となるコンテンツを部分的に覆うカードとして表示され、カバーされていないすべての領域を暗くして、それらとの対話を防ぎます。親ビューまたは前のカードの上端は現在のカードの後ろに表示され、カードを開いたときに中断したタスクを思い出せるようにします。人々は次の方法でカードを却下します。

・画面の上部から下にスワイプする
・カードのコンテンツが上にスクロールされたとき、画面上のどこからでも下にスワイプする
・カード内のボタンをタップする

複雑なタスクができない非没入型のモーダルコンテンツにはシートを使用します

フルスクリーン（Fullscreen）

フルスクリーンスタイルは、画面全体をカバーします。前のカード画面は完全にカバーされているため、視覚的な混乱が最小限に抑えられます。ユーザーはボタンをタップすることでフルスクリーンのモーダルビューを閉じます。

フルスクリーンモーダルビューを使用して、ビデオ、写真、カメラビューなどの没入型コンテンツや、ドキュメントのマークアップや写真の編集など、フルスクリーンプレゼンテーションの恩恵を受ける複雑なタスクを実行します。

※注
もし現在のコンテキストモーダルビュースタイルを使用してスプリットビュー、ポップオーバー、またはフルスクリーンではない他のビュー内にモーダルコンテンツを表示する場合、小さい環境でモーダルコンテンツを表示するときシートの使用を切り替える必要があります。

筋が通っているときにモダリティを使用します
モーダルエクスペリエンスを作成するのは、現在のタスクとは異なるタスクを選択したり実行したりすることに人々の注意を集中させることが重要な場合のみです。モーダルエクスペリエンスは現在の状況から人々を引き離し、却下するためのアクションを必要とするため、明確なメリットが得られる場合にのみ使用することが不可欠です。

重要な情報（理想をいうと提訴の理由になりうるもの）を提供するためのアラートを準備します
通常は、何かが間違っているためにアラートが表示されます。アラートは体験を中断し却下するにはタップが必要になるため、侵入が正当化されることを人々が感じることは重要です。ガイダンスについてはアラートを参照してください。

モーダルタスクをシンプルで短くし、焦点を絞ってください
アプリ内でアプリを作成しないでください。モーダルタスクが複雑すぎると、モーダルコンテキストに入ったときに中断したタスクを見失う可能性があります。画面の階層を含むモーダルタスクの作成には特に注意してください。人々は道に迷い、手順をたどる方法を忘れる可能性があるためです。モーダルタスクにサブビューを含める必要がある場合は、階層を通る単一の道と完了までの明確な道を指定します。タスクを完了する以外の目的で「完了」ボタンを使用しないでください。

常にモーダルビューを閉じるボタンを含めます
たとえば「完了」または「キャンセル」を使用できます。ボタンを含めることでモーダルビューがアシスティブ・テクノロジー（障害を持つ人の日常生活のサポートのための技術）にアクセスしやすくなり、拒否ジェスチャーの代替手段が提供されます。

必要に応じて、モーダルビューを閉じる前に確認を得ることで、データの損失を回避できるようにします
ビューを閉じるためにユーザーが拒否ジェスチャーまたはボタンを使用するかどうかに関係なく、アクションによってユーザーが作成したコンテンツが失われる可能性がある場合は、状況を説明し人々に解決方法を提供するアクションシートを提示します。

ポップオーバーの上にカードを表示しないでください
ポップオーバー内にカードを表示できますが、ポップオーバーの上に何も表示してはいけません（アラートの場合を除く）。まれに、ポップオーバーでアクションを起こした後にカードを提示する必要がある場合は、カードを表示する前にポップオーバーを閉じてください。

一般的に、モーダルタスクを見分けるタイトルを表示します
人々がモーダルタスクに入ると以前のコンテキストから切り替わるので、新しいコンテキストを明確にすることをお勧めします。また、タスクをより十分に説明するか、ガイダンスを提供する画面の他の部分で、テキストを提供することもできます。

モーダルビューの見た目をアプリと同じにします
たとえばモーダルビューにナビゲーションバーが含まれる場合、アプリのナビゲーションバーと同じ見た目を使用する必要があります。

アプリで意味のあるモーダルトランジションスタイル（画面遷移のスタイル）を選択します
アプリと同じにし、一時的なコンテキストシフトの気付きを高めるトランジションスタイルを使用します。デフォルトのトランジションでは、モーダルビューが画面の下から上に垂直にスライドし、閉じられたときに元に戻ります。アプリ全体で一貫したモーダルトランジションスタイルを使用します。

ナビゲーション（Navigation）

人々は予測しない限り、アプリのナビゲーションに気付かない傾向があります。あなたの仕事はアプリに注意を向けることなく、アプリの構造と目的をサポートする方法でナビゲーションを実装することです。ナビゲーションは自然で馴染みのあるものである必要があり、インターフェイスを支配したり、コンテンツから焦点を奪ったりするべきではありません。iOSには3つの主なナビゲーションスタイルがあります。

階層ナビゲーション

目的地に到達するまで、画面ごとに1つの選択を行います。別の目的地に行くにはステップをたどるか、最初からやり直して別の選択を行う必要があります。設定とメールはこのナビゲーションスタイルを使用します。

フラットナビゲーション

複数のコンテンツカテゴリを切り替えます。音楽とApp Storeはこのナビゲーションスタイルを使用します。

コンテンツ駆動型またはエクスペリエンス駆動型のナビゲーション

コンテンツ内を自由に移動するか、コンテンツ自体がナビゲーションを定義します。ゲーム、書籍、その他の没入型アプリは通常、このナビゲーションスタイルを使用します。

常に明確な道筋を提供します
アプリのどこにいるのか、そして次の目的地に行く方法を常に知っておく必要があります。ナビゲーションのスタイルに関係なく、コンテンツの道筋は論理的で予測可能で、追跡しやすいことが不可欠です。一般的に各画面ごとに1つの道筋を人々に与えます。複数のコンテキストで画面を表示する必要がある場合は、アクションシート、アラート、ポップオーバー、またはモーダルビューの使用を検討してください。

コンテンツにすばやく簡単にアクセスできるような情報構造を設計します
最小限のタップ、スワイプ、および画面を必要とする方法で情報構造を整理します。

タッチジェスチャーを使用して、流動性を作ります
最小限の摩擦でインターフェイスを簡単に移動できるようにします。たとえば、画面の横からスワイプして前の画面に戻ることができます。

標準のナビゲーションコンポーネントを使用します
可能な限り、ページコントロール、タブバー、セグメンテッドコントロール、テーブルビュー、コレクションビュー、スプリットビューなどの標準ナビゲーションコントロールを使用します。ユーザーはすでにこれらのコントロールに精通しており、アプリを回避する方法を直感的に知っています。

ナビゲーションバーを使用して、データの階層を移動します
ナビゲーションバーのタイトルには、階層内の現在の位置を表示できます。戻るボタンを使用すると、前の場所に簡単に戻ることができます。

タブバーを使用して、コンテンツまたは機能の同カテゴリを提示しますを使用して、コンテンツまたは機能の同カテゴリを提示します
タブバーを使用すると、現在の場所に関係なく、すばやく簡単にカテゴリを切り替えることができます。

同じ種類のコンテンツのページが複数ある場合は、ページコントロールを使用します
ページコントロールは、使用可能なページ数と現在アクティブなページを明確に伝えます。天気アプリはページコントロールを使用して、場所固有の天気ページを表示します。

TIP
セグメンテッドコントロールとツールバーはナビゲーションを有効にしません。セグメンテッドコントロールを使用して、情報をさまざまなカテゴリに整理します。ツールバーを使用して、現在のコンテキストと対話するためのコントロールを提供します。

オンボーディング（Onboarding）

起動時間は新しいユーザーをオンボードし、リピーターと再接続する最初の機会です。高速で楽しく、教育的な起動体験を設計します。

起動画面を提供します
アプリの起動時に起動画面が表示され、アプリが高速で応答性が高いという印象を与えながら、初期コンテンツを読み込むことができます。この画面はアプリの最初の画面にすぐに置き換えられるため、制限可能なテキストとインタラクティブな要素を除いてよく似ているはずです。

適切な向きで起動します
アプリが縦向きと横向きの両方をサポートしている場合、デバイスの現在の向きを使用して起動する必要があります。アプリが1つの方向でのみ実行される場合、常にその方向で起動し、必要に応じてユーザーがデバイスを回転できるようにする必要があります。説得力のある理由がない限り、横向きモードのアプリはデバイスが左に回転したか右に回転したかに関係なく、正しい方向を向く必要があります。追加のガイダンスについては、適応性とレイアウトを参照してください。

即座に行動に移ります
コンテンツに辿りついてアプリの使用を開始するのに時間がかかるスプラッシュ画面、メニュー、指示を表示しないでください。代わりに、人々がすぐに飛び込めるようにします。アプリにチュートリアルやイントロシーケンスが必要な場合はスキップする方法を提供し、リピーターに表示しないようにします。

ヘルプが必要な場合を予想します
人々が立ち往生している可能性がある時間を積極的に探します。たとえば、ゲームは一時停止したときやキャラクターが前進していないときに気軽に役立つヒントを表示できます。初めて何かを見逃した場合に備えて、ユーザーがチュートリアルを再生できるようにします。

チュートリアルの基本事項を順守してください
初心者にガイダンスを提供することは問題ありませんが、教育は優れたアプリ設計の代わりではありません。何よりもまずアプリを直感的にします。あまりにも多くのガイダンスが必要な場合はアプリの設計を再検討してください。

学習を楽しく発見可能にします
実行して学ぶことは、指示リストを読むことよりもはるかに楽しく効果的です。アニメーションとインタラクティビティを使用して、徐々にコンテキストに沿って教えます。インタラクティブに見えるスクリーンショットを表示しないでください。

前もって設定情報を尋ねることは避けてください
アプリは正常に機能することを期待しています。大多数のためにアプリケーションを設計し、異なる構成を必要とする少数のユーザーがニーズに合わせて設定を調整できるようにします。可能な限り、デバイスの設定とデフォルトから、またはiCloudなどの同期サービスを介して設定情報を取得します。設定情報を要求する必要がある場合はアプリ内で最初に要求し、ユーザーがアプリの設定で後で変更できるようにします。

アプリ内ライセンス契約および免責事項を表示しないでください
アプリをダウンロードする前に、App Storeに同意書と免責事項を表示してください。もしアプリに含める必要がある場合は、ユーザー体験を妨げないバランスの取れた方法で同意書と免責事項をまとめます。

アプリの再起動時に以前の状態を復元します
アプリ内の以前の場所に到達するために、人々にステップを巻きもどさせないでください。アプリの状態を保持および復元して、中断したところから続行できるようにします。

人々に早い段階で、頻繁にアプリの評価を尋ねないでください
あまりにもすぐに、または頻繁に評価を求めることは面倒で、受け取る有益なフィードバックの量が減ります。よく考えられたフィードバックを促すには、評価を求める前にアプリについて意見を述べる時間を人々に与えます。常に迅速に評価することから逃れる方法を提供し、ユーザーにアプリの評価を強制してはいけません。

再起動を奨励しないでください
再起動には時間がかかり、アプリの信頼性が低く、使いにくいように見えます。システムに起動したばかりでないと実行できないメモリやその他の問題がアプリにある場合は、それらの問題に対処する必要があります。

許可のリクエスト（Requesting Permission）

ユーザーは、アプリが現在の場所、カレンダー、連絡先情報、リマインダー、写真などの個人情報にアクセスする許可を与える必要があります。この情報にアクセスできるアプリを使用することの利便性は高く評価されていますが、個人データを管理することも期待しています。たとえば、人々は写真に物理的な位置を自動的にタグ付けしたり、近くの友人を見つけたりするのが好きですが、そのような機能を無効にするオプションも必要です。

アプリで明らかに必要な場合にのみ、個人データを要求します
個人情報の要求を疑うのは自然なことです。特に必要がない場合は当然です。個人データが明らかに必要な機能を使用している場合にのみ許可要求が発生するようにしてください。たとえば位置追跡機能を有効にした場合、アプリは現在の場所へのアクセスのみを要求します。

アプリが情報を必要とする理由を説明してください
システムの許可要求アラートに表示するカスタムテキスト（目的文字列または使用方法の説明文字列）を提供し、例を含めます。テキストを短く具体的にし、大文字と小文字を使い、人々がプレッシャーを感じないように礼儀正しくしてください。アプリ名を含める必要はありません。システムは既にアプリを識別しています。

〇　「 アプリはいびき音を検出するために、夜中にあなたを記録します。」
✖　「より良い体験のためにマイクへのアクセスが必要です。」
✖　「マイクアクセスをオンにします。」

アプリが機能するために必要な場合にのみ、起動時に許可をリクエストします
アプリが動作するのに個人情報次第になっていることが明らかな場合、ユーザーはこのリクエストに悩まされません。

不必要に位置情報を要求しないでください
位置情報にアクセスする前に、システムをチェックして位置情報サービスが有効になっているかどうかを確認してください。この知識があれば、機能が本当に位置情報を必要とするまでアラートを遅らせるか、アラートを完全に回避することができます。

システム提供のアラートを使用します
標準のアクセス許可アラートのテキストをカスタマイズできますが、標準のアラートの動作または外観を複製するカスタムプロンプトを追加しないでください。

設定（Settings）

一部のアプリでは装備または配置を選択する方法を提供する必要がありますが、ほとんどのアプリはそうすることを回避または遅らせることができます。成功したアプリはほとんどの人にとってすぐに上手く機能しますが、体験を整える便利な方法も提供します。ほとんどの人が期待するように機能するようにアプリを設計すると、設定の必要性が減ります。

システムから何ができるかを推測します
ユーザー、デバイス、または環境に関する情報が必要な場合は、ユーザーに尋ねるのではなく、可能な限りシステムに問い合わせてください。たとえば、誰かに郵便番号の入力を求めてローカルオプションを提示する代わりに、現在の位置情報を使用する許可を求めます。ユーザーが情報へのアクセスを拒否した場合は、潔く手動入力に切り替わります。

アプリ内の設定オプションに慎重に優先順位を付けます
アプリのメイン画面は重要なオプションや頻繁に変更されるオプションに適しています。セカンダリ画面は、たまにしか変更されないオプションに適しています。

変更された設定オプションをまれに公開します
設定アプリはシステム全体で構成を変更するための中心的な場所ですが、そこに到達するにはユーザーがアプリを離れる必要があります。アプリ内で直接設定を調整する方がはるかに便利です。必要に応じて設定へのショートカットを提供します。

必要に応じて、設定へのショートカットを提供します
「設定>プライバシー>位置情報サービス」など、ユーザーを設定に導くテキストがアプリに含まれている場合、その場所を自動的に開くボタンを提供します。