モダンiOSナビゲーションパターン 日本語訳
Modern iOS Navigation Patterns (Japanese Text Ver.)
この資料は、Frank Rausch 氏による Modern iOS Navigation Patterns の、日本語訳版です。オリジナル版 “2023-03-07” を基にし、CC BY-NC-SA 4.0 ライセンスによって公開しています。
オリジナルを日本語に訳すにあたり、なるべく元の表現を尊重するように心がけていますが、一部の表現については、訳者による解釈の補足や文言調整を加えています。
目次
はじめに
この資料では、iOS appのためのよく知られたナビゲーションパターンをすべて掲載しています。ドリルダウンやモーダル、ピラミッド、シーケンスなどの代表的なパターンを含みます。Apple Human Interface Guidelinesの非公式な追加の章とでも思って読んでくだされば幸いです。
1. 構造的なナビゲーション
典型的なiOS appには決まった構造があります。多くの場合、それは複数レベルのツリー構造になっています。この構造によって経路の選択を予測しやすくなっています。構造的なナビゲーションパターンは、ユーザーがどこからやって来たのか、いまどこにいるのか、そしてどこに戻ればよいのかを明示し、信頼感を与えます。
ドリルダウン (Drill-Down)
ドリルダウンナビゲーションは、情報のツリー構造をカスケーディングリストとして構成し、レベル単位やスクリーン単位で横断できるようにします。
ここでの遷移は、列（リスト）間の水平移動を意味します。右へ移動するとツリーの階層（レベル）が深くなり、逆に左へ移動すると階層（レベル）が浅くなります。 遷移の表現にはアニメーションが適用されます。
ドリルダウンナビゲーションはステートレスです。常に階層移動が可能であり、状態を保存するかどうか等の問いかけによって移動が中断されることはありません。
訳者注釈： ユーザーの意思による階層移動が何かによって止めらないことを意味します。例えば、バックボタンを押した際にアラートダイアログを割り込ませて戻る動作を一時停止させるといったことは、基本的にはできないようになっています。もしもそのようなインタラクションを組み込みたいのならば、後述するモーダルビュー関連のパターンを検討してください。
ナビゲーションバーには、現在の階層に関するタイトルを表示します。
リスト各行のディスクロージャ・インジケータ（＞）は、階層を深く掘り下げることが可能であることを示します。
バックボタン（＜）は、階層を戻るための経路をわかりやすく提示します。表示範囲が許するならば、ボタン名は「戻る」の表記ではなく、親階層（レベル）のタイトルをそのまま表示する必要があります。
スクリーンの左端から右方向にスワイプすると、バックボタンを押した結果と同じになります。
右から左へ表記する言語（Right-to-Left, RTLレイアウト）の場合、ドリルダウンの方向とコントロールのレイアウトは、読む方向に合わせて鏡像にします。（レイアウトやアイコンの左右が反転します）
データベースを絞り込んだりするために、ツリー構造を動的に構築することができます。 例えば音楽プレーヤーでは、ある同じアルバムを探すために、“アーティスト”、“アルバム”、“ジャンル”といった異なる階層の出発点からドリルダウンを行うことができます。
iOSのドリルダウンナビゲーションは、macOSのFinderが採用する “Miller Columns” パターンにおける1列部分に相当するもので、その亜種と言えます。
訳者注釈：
ここで言う音楽プレーヤーの例は、iTunes / Music.appのカラムブラウザを指していると思われます。ジャンル、アーティスト、アルバムの3列表示によって目的の楽曲を絞り込めるUIでは、選択した項目によって、情報が絞り込まれた形で下層のリストが動的に再構築されます。例えばジャンルに「J-Pop」を選択すると、J-Popに紐づけられたアーティストのみのリストとアルバムのリストが再構築されます。
“Miller Columns” とはカスケーディングリストパターンの別名です。macOSのFinderにおける「カラム表示」や、iTunes / Music.appにおけるカラムブラウザ、iOSのUINavigationControllerは典型的なMiller Columnsです。
関連資料：
Who invented Miller columns? [closed]
フラット (Flat)
フラットナビゲーションパターンは、ルートレベルで階層を並列に区分し、大抵はタブバーの形で表します。iPadOSではタブバーの代わりにサイドバーを用いることがあります。
タブ項目はそのappの主要な特性を中心に構成します。これにより、ユーザーの期待やそのappで何ができるかに関するメンタルモデルが形成されるようになります。1
常にいずれかのタブ項目が選択状態になっていると、メインコンテンツ領域に現在何が表示されるのかがわかりやすくなります。（そのように設計すべきです）
現在選択されているタブ項目をシステム側から勝手に変更してはいけません。（タブの自動切り替えの禁止） 例えば、ユーザーとの対話なしにプログラム的にタブを切り替えたり、他のUI要素の操作によって副次的にタブが切り替わったりすることは避ける必要があります。
訳者注釈： タブの自動切り替え（タブジャンプ）を避けることの原則は基本的に守るべきでしょう。このことはWWDC22 10001 - Explore navigation design for iOSでも解説されています。
タブバーは、モーダルシート（後述のオーバーレイ）によって一時的に覆われる場合を除き、appの前面に表示され続けます。
タブは、音楽、ビデオ、写真などのライブラリのように、同一コンテンツの大きなコレクションに対するフィルタとして使用するか、あるいは異なるエントリポイントとして使用することができます。
各セクションはナビゲーション状態を保持します。
訳者注釈： タブの切り替えによって、前に表示していたタブ内のナビゲーション階層の位置がリセットされたりしません。例えば、検索タブである程度ドリルダウンした状態からホームタブに切り替えたとしても、再び検索タブに戻ってきた際に、以前の表示階層が適切に復元されます。Webブラウザなどの一般的な「タブ」の挙動をイメージしてみてください。
タブバーは予測可能な方法で動作する必要があります。タブを押したらタブ切り替えするのではなく何かのシートを表示したり、アクションボタンとして振る舞ったりするべきではありません。
悪名高いハンバーガーメニューは、タブバーにとっての悪い兄弟分です。ナビゲーションUI全体が小さな3本線のアイコンに隠されていると、それらの要素を見つけにくくなってしまいます。ハンバーガーメニューは2015年頃から数年くらいの間iOSのデザインでも流行していましたが、タブバーの方がより発見可能性が高く使いやすいという調査結果が明らかになったため、app開発者たちは次第にハンバーガーメニューを廃止しました。
- Nielsen Normal Groupによる見解: Hamburger Menus and Hidden Navigation Hurt UX Metrics
- ハンバーガーメニューを廃止したSpotifyの例
ピラミッド (Pyramid)
ピラミッドパターンでは、同じ階層にある兄弟ビュー間を移動する際に、わざわざ親スクリーン（レベル）に戻ることなくその場で素早く移動することができます。
一般的なメディア系のappは、水平方向のスワイプジェスチャによって兄弟ビュー間を移動できるようにしていることがあります。また、iOSの “Mail” appの「次のメッセージ」「前のメッセージ」ボタンのように、スワイプジェスチャではなくボタンによって兄弟間移動の手段を提供する方法もあります。
iOSの “写真” appはピラミッドパターンを採用しています。いずれかの写真をタップしてフルスクリーンで開いたあと、左右にスワイプすることで隣接する写真に移動できます。
量の少ないコレクションにはページコントロールを使用し、項目の総数や現在位置が視覚的にわかりやすくなるようにしましょう。
ハブ・アンド・スポーク (Hub-and-Spoke)2
ハブ・アンド・スポークパターンは、互いに関連性の低い項目群で構成される大きなコレクションを階層化させたい場合に最適です。子ビューはフルスクリーンで展開されますが、それらを切り替えるためには最初のハブに戻る動きをします。
訳者注釈： ハブ・アンド・スポークとは、中心拠点とそこから放射状に伸びる各子拠点の形状を指すネットワークです。中心と子の間の繋がりは強いが、子同士の繋がりは弱い場合に、この構造が使われることがあります。
iOSのホーム画面は、インストールされているすべてのアプリケーションの集合体です。これは一種のハブとして、また、システム全体としてそれが「信頼できる中立的な状態」としてうまく機能します。
iPhoneの画面下部にあるホームインジケータ（横長の棒のこと）は、ユーザーが操作方法を学習しやすく、常に利用可能な「非常口（エスケープ・ハッチ）2」として機能します。これを使えば慣れ親しんだホーム画面にいつでも戻ることができます。 すなわち、iPhoneでは基本的にどの状態にいてもホーム画面（ハブ）に退避できる手立てが用意されているということです。
ちなみに、このパターンはappレベルではほとんど使われません。システムレベルで起こるapp間遷移のような「強力な分離」が必要になる場面では用いられますが、そのようなことはappレベルのデザインではほとんどないでしょう。
2. オーバーレイ型ナビゲーション
オーバーレイパターンは、ユーザーに何かを注目させるための表現です。基本的にはappがどのような状況にあってもオーバーレイを表示できます。モーダル方式のオーバーレイは、それが消える前に何かしらのユーザー操作が必要です。この種のものは、appを別のモードに切り替えて、その背後にあるインターフェイスを遮断（操作できなく）します。一方、非モーダル＝モードレス方式のオーバーレイは、一時的な通知のような表現に用いられ、appの操作を遮るものではありません。
強いモーダル (High-Friction Modal)
訳者注釈： “High-Friction”を「（干渉の度合いが）強い」と訳しています。
複数のアクションを持つシートやアラートダイアログなど、干渉が強いモーダルオーバーレイは、ユーザーがいずれかの決定を下すまでその背後にあるものを遮断します（操作できなくします）。
モーダルオーバーレイを解除するには、ユーザーによる決断と操作が必要です。状態を保存するかどうか、フォームに入力したデータを確定するか（「完了」を押す）、破棄するか（「キャンセル」を押す）、といった行動を指します。
モーダル表現は、電子メールの作成やカレンダーイベントの追加など、特定の自己完結型タスクを完了させることに向いています。1
複数のアクションを持つステートフルなシートやアラートダイアログは、典型的な「強いモーダル」です。
弱いモーダル (Low-Friction Modal)
訳者注釈： “Low-Friction”を「（干渉の度合いが）弱い」と訳しています。
シート、メニュー、ポップオーバーなどの干渉の度合いが弱いモーダル表現は、appの他のインターフェイス部分を一時的に遮りますが、「強いモーダル」に比べ、何かしらのユーザーの判断を必要とはしません。
すなわち、簡単に破棄できるということです。「弱い干渉」とは、そのモードから逃れる方法を深く考える必要がないことを意味します。閉じるボタンを押すか、シートを下にスワイプするか、コンテクストメニューやポップオーバーの外側をタップしたりすれば、この種のモーダルビューはすぐに消えてしまいます。
OKボタンが一つしかないアラートダイアログは比較的簡単に排除することができますが、それが弱いモーダルと分類されたとしても、非モーダルになるわけではありません。シングルアクションのアラートは可能な限り避けましょう。
シングルアクションアラートは、ユーザーの思考や操作をいちいち中断させます。この種の表現は、インラインテキスト表示や非モーダルな通知でも代替することができます。
（可能な限りシングルアクションアラートを避け、そういった表現を採用しましょう）
非モーダル＝モードレス (Non-Modal = Modeless)
訳者注釈： 訳者の方で「モードレス（Modeless）」の言葉を強調しています。
非モーダルのオーバーレイは、スクリーンの一部を覆い隠しますが、その背後にあるインターフェイスを遮断する（操作できなくする）ことはありません。すなわちモードレスなので、インターフェイスへの干渉はほとんど生じません。
OSからの通知など、app外のトリガーに反応して表示されることもあります。
自動的に消えるのであれば、最小限の注目で、かつ一目でわかる情報を提供する必要があります。
一時的な非モーダルオーバーレイには、追加でインタラクティブ性を持たせることができます。通知バナーのタップ操作や、音量インジケータのスワイプ操作などが挙げられます。
オーバーレイが他の部分を遮らず、かつオーバーレイが自動的に表示／非表示にならない場合、90年代のUIのベテランたちはそれをパレットと呼びます。
訳者注釈： Photoshopなどに見られるパレット系のUIを指しているのだと思いますが、それをわざわざ指摘する理由をよく読み解けませんでした。
3. 埋め込み型ナビゲーション
埋め込み型ナビゲーションでは、iOSの厳格なUI構造と空間モデルに適合させることが求められ、特段の注意が必要です。これらのパターンは、appの構造内で明確に定義された場所か、モーダルオーバーレイのいずれかの方法により、別のビューに格納または埋め込む形が最善です。
状態変化 (State Change)
ビューは複数の状態を持つことができます。例えば、ビューの読み込み中にプログレスインジケータを表示し、読み込み完了後にそれをコンテンツに置き換えても、階層自体の位置変化は起こりません。（単一のビューが状態変化したと見做せます。）
状態変化が階層的でもモーダルでもないことに注意しましょう。
その場限りで起こるような小さな状態変化では、全画面遷移を避けましょう。
その他の例：
リストの編集状態、WebブラウザのUI、マップの移動操作、ズーム可能なイメージの操作。
同じスクリーン上にある同じデータの表示方法を変えることも、ユーザーの階層的な位置を変えずに画面の内容を変える状態変化と言えます。 （例えば、あるコレクションのリスト表示とグリッド表示を切り替える、など）
ステップ・バイ・ステップ (Step-by-Step)
ステップ・バイ・ステップパターンは、ガイドツアー、セットアップのフロー、オンボーディング／チュートリアル、オンラインストアの情報入力のような場面で、一連の流れを直線的に繋ぐものです。
一連の流れの中でステップを前後に移動しても、その階層レベルは変わりません。これは、前述のドリルダウンのパターンとは異なる構造です。
ステップ・バイ・ステップの流れの中では、ステップを戻すためのバックボタンを階層型ドリルダウンパターンにおける階層の移動とは異なる目的を持つことを強調する必要があります。
訳者注釈：
「階層」と「ステップ」の言葉を区別してください。ここでいう「階層レベル」とは、ビューとしての階層を示すもので、ウィザードなどのステップのことは指していないことに注意しましょう。
iOSではステップ・バイ・ステップのウィザードUIにもドリルダウンと同じUIを使用することがほとんどです。しかしUIの性質としては両者異なるため、デザインではそのことを念頭に、誤った表現をしないよう心がける必要があります。例えば、バックボタンはビュー階層を遡るのではなく前のステップに戻ることを意味します。
ステップ・バイ・ステップのプロセスは、通常、「完了」または「閉じる」ボタンで終了できます。これらのボタンは、それを含むモーダルビューも一緒に閉じてしまいます。
ユーザーが選択したオプションによって、その後のステップ数や経路を分岐させることができます。
「ウィザード」と「アシスタント」は、このパターンの代替名です。
ユーザーはステップ・バイ・ステップのプロセスを退屈に感じることがあります。ユーザーが頻繁にそれを実行することが予想される場合、例えばステップを1つのビューにまとめることなどを検討し、コンテクストの切り替えを減らしつつ、情報の解像度を上げるよう工夫しましょう。
コンテンツ主体 (Content-Driven)
コンテンツ主体のナビゲーション3（非線形ナビゲーション、体験主体型のナビゲーション）とは、ハイパーリンクやボタンによって、他のページやビューに移動できるパターンです。Webブラウザのナビゲーションはこの方式です。
iOS appでは、ハイパーテキストや没入型ゲーム、または同様の非線形コンテンツを表示する種のappを除き、このパターンの採用を避けてください。
Appでハイパーテキストコンテンツを表示する必要がある場合は、戻る・進むコントロールを持つブラウザインターフェイスで表現することを検討してください。自己完結型のブラウザインターフェイスにすることでappの（ネイティブ）UIからそれを切り出し、状態変化を理解しやすくします。
訳者注釈：
例えばWebコンテンツの遷移をドリルダウンナビゲーション（UINavigationController）の仕組みに入れてしまうと、UI全体の状態変化がわかりづらくなってしまうからそれを避けること、自己完結型のビュー（WebView）に収めておく方が都合が良いことを言っているのだと理解しました。
SFSafariViewControllerのように、強いモーダルビューによってWebViewを括ってしまい、ネイティブUIの階層からそれを分離させることも検討できるでしょう。
アプリケーション間の移動にはリンクを使用することができます。ディープリンク2はいずれかのappまたはWebサイトから別のappの階層奥深くにユーザーを直接誘導させる際に使用します。
（URLスキームまたはドメインに関連付けられたユニバーサルリンク (Domain-bound Universal Links) と言います。）
参考文献
- Apple WWDC 2022: Explore navigation design for iOS
- Tidwell, Jenifer (2020). Designing Interfaces (Third edition). O’Reilly.
- Apple Human Interface Guidelines / Navigation(Archive.org, 2022-01-19)