3.04. ユーザインタフェース設計
この章では、Android における UI の設計について解説します。
参考：Application Structure
参考：Navigation with Back and Up | Android Developers
参考：Action Bar | Android Developers
参考：Navigation Drawer | Android Developers
参考：Multi-pane Layouts | Android Developers
参考：Swipe Views | Android Developers
参考：Selection | Android Developers
参考：Confirming & Acknowledging
参考：Notifications | Android Developers
参考：Metrics and Grids | Android Developers
参考：Iconography | Android Developers
- [ActionBar とナビゲーション](#ActionBar とナビゲーション)
- [TopLevel Views](#TopLevel Views)
- [Category Views](#Category Views)
- [Detail/Edit Views](#Detail/Edit Views)
- [Navigation with Back and Up](#Navigation with Back and Up)
- ActionBar
- マルチペインレイアウト
- [Contextual ActionBar](#Contextual ActionBar)
動画：Structure in Android App Design
一貫したナビゲーションと、期待通りの振る舞いは、良い UX の基本です。
Android では、これらを実現するためのナビゲーションコンポーネントとして、ActionBar を始めとする様々なコンポーネントを用意しています。
また、各々のアプリの構成は、そのコンテンツと利用の仕方に大きく依存した構造となります。
一方、一般的には、アプリの構成は、トップレベルのビューと、詳細を見たり編集をしたりするビューに分けられます。アプリが大きく複雑になると、両者をつなぎこむカテゴリのビューが使われます。
アプリの構造とナビゲーションを考える上で、そのアプリのユースケースを考えることは非常に重要な行為です。
アプリで一体どんなことをするのか、という事をユースケース図を用いて図示して、ナビゲーションを考えていきます。
- Top Level Views
- トップレベルのビューは、多くの場合、異なる種類のコンテンツを表示する。同じデータを異なる見せ方で表示する場合もあれば、根本的に異なる機能のファセットをトップレベルビューにまとめることもある。
- Category Views
- カテゴリビューでは、より深い階層へ入り、詳細を見たり、編集をしたりするための入り口を提供する。
- Detail/Edit Views
- このビューでは、ユーザがデータを編集したり、見たり、作成したりするためのインタフェースを提供する。
ユーザが最初に目にする画面です。 アプリを使用して、ユーザが最もやりたいと思うことをこのトップレベルビューで実現するのが良いでしょう。
ほとんどのアプリでは、コンテンツの表示のためにトップレベルビューを使用します。ナビゲーションだけのビューではなく、コンテンツを主体にしたビューを作ると良いでしょう。
ナビゲーションのために、すべての画面において、ActionBar を表示すべきです。
ActionBar で一貫したナビゲーションを提供し、重要なアクションをすぐに実行できるようにしておきましょう。
- ActionBar を用いて、アプリのアイコンと名前を表示する
- トップレベルビューが複数のビューを持つ場合、それらのビューに対する制御が出来るアクションを、ActionBar に含めておく
- アプリの中でコンテンツを作ることが出来る場合、コンテンツの作成ビューへのアクセスをトップレベルビューから出来るようにする
- コンテンツが検索可能な場合、検索アクションを ActionBar に置いて、ナビゲーションの階層構造を横断することができるようにする
トップレベルビューに様々な異なるコンテンツを表示する場合、下記のようなコンポーネントを用いて、それぞれのコンテンツへとスイッチできるようにします。
トップレベルビューに、並列でコンテンツを表示する場合に使います。
通常、並列に並ぶコンテンツが 3 つまでの場合に用いられます。
これ以上コンテンツが有る場合は、Fixed Tabs は不向きです。
タブは常に表示されているので、いつでもタブをクリックして切り替えることができます。
タブのクリック以外にも、横スワイプでのタブ切り替えもサポートしておくと良いでしょう。
この場合、ViewPager を用いて、ViewPager の現在位置と Fixed Tabs の選択を同期する必要があります。
ユーザが、並列に並んだコンテンツを頻繁に切り替える場合に、Fixed Tabs が最も適しています。
Fixed Tabs と同じように、トップレベルビューの切り替えのための、ドロップダウンリストです。
Fixed Tabs の場合、Fixed Tabs 専用の領域を必要とするため、縦方向に広く場所を確保したい場合に不向きです。
その代わりに、Spinner を用いることで、より広く縦方向の場所を確保することができます。
同じデータセットに対して、複数の異なったビューに切り替える目的で Spinner を用いることが最適です。
画面左側に隠れているメニューの表示で、ActionBar のアプリのアイコンをタップすることで表示できるものです。
トップレベルビューの上の一部に覆いかぶさる形で表示されるため、非常に多くの項目を入れることができます。
トップレベルビュー以外にも、この Navigation Drawers を適用することができます。
複雑な構造を持つアプリによく用いられ、特に、トップレベルビューとして扱うものがたくさんある場合や、直接下位のビューへ素早く遷移させたい場合などに最適です。
トップレベルビューのナビゲーション (Fixed Tabs、Spinner、Navigation Drawers) は、複数組み合わせてはいけません。
カテゴリビューを間に挟む事によって、多種多様な詳細ビューへのナビゲーションを実現します。
カテゴリごとにタブを用意する方法です。
カテゴリが、よく知らたものであれば、スクロール可能なタブを用いることができます。
スクロール可能なタブは、すべてのタブが画面上に表示されるわけではなく、常に現在位置とその両隣が表示されます。
これにより、多くのタブを実現できますが、あまりに多すぎると逆効果です。5〜7 個以上のタブは推奨されません。
各々のカテゴリが、あまり関連性がなく並列に並ぶ場合は、Fixed Tabs が最適です。
ListView や GridView で表示される各項目に対してのアクションを、ドロップダウンメニューなどでショートカット的に実行できるようにするものです。
これによって、階層構造を辿って詳細ビューへナビゲートすることなく、直接アクションを実行できるようになります。
詳細ビューにおいて実行可能なアクションは、カテゴリビュー上で、複数項目に対して同じアクションを実行できるようにしておくと良いでしょう。
たとえば、詳細ビューでデータの削除が出来るのであれば、カテゴリビュー上で、複数のデータに対して削除が実行できるようにする、ということです。
詳細ビューでは、アプリで取扱うデータへのアクセスと、アクションの窓口を提供します。
詳細ビューで、データに対して行うアクションに沿って（ユースケースに沿って）レイアウトを構築します。
ゲームやメディア・コンテンツのようなものだけが、フルスクリーン表示をするわけではありません。
コンテンツを共有したり、コメントをつけたり、検索したりするものであっても、フルスクリーンの体験が活かせます。
ユーザがしばらくの間 ActionBar に触れないでいると、自動でフェードアウトして、フルスクリーン表示に切り替えることができます。
これを Lights-out モードと呼びます。
ユーザはいつでも、画面をタップすることで、Lights-out モードを解除することができます。
複数ある項目を順番に見せるような場合には、複数の詳細ビュー同士を連携してナビゲートする仕組みを導入します。
スワイプビューの他、サムネイル一覧もこのナビゲーションに最適です。
Android には、2 種類のナビゲーションがあります。
1 つは、2.x のころからの、バックボタンによる"戻る"ナビゲーション。もう 1 つは、Honeycomb から登場した、ActionBar による"階層を戻る"ナビゲーションです。
Up は、ActionBar による階層を戻るナビゲーションです。
先ほどの構造の図で言うところの、詳細ビューからカテゴリビューへ戻ったり、カテゴリビューからトップレベルビューへ戻ったりするナビゲーションのことを指します。
よって、トップレベルビューでは、Up によるナビゲーションはありません。
一方、Back は、戻るボタンによる画面を戻るナビゲーションです。
こちらは、アプリの構造ではなく、ユーザが直近でとった行動の履歴を後戻りする意味を持ったナビゲーションとなります。
両者はよく似ており、同じように振る舞うことも頻繁に起こります。
しかし、Up はアプリの構造に着目しているため、アプリに閉じたナビゲーションとなる一方で、Back はユーザの行動に着目しているため、アプリをまたいだナビゲーションとなります。
このため、アプリのトップレベルビューで Back をすると、ホーム画面に戻ったり、他のアプリに戻ったりするようになります。
各画面は、アプリの構造とは異なるエントリポイントからアクセスされることを念頭においてください。
アプリの構造と異なるルートで呼び出された場合、Up ナビゲーションは、Back ナビゲーションと同じように振る舞うことが理想的です。
また、画面内での各種ビュー要素の切り替えは、ナビゲーションに影響を与えないようにします。
つまり、画面内のあるビューが切り替わったからと言って、Back ナビゲーションと Up ナビゲーションの役割が変わってはならない、ということです。
言い換えると、ビューの切り替えによって、アプリの構造における画面の立ち位置が変わることはない、と言うことです。
ビューの切り替えには、タブ切り替えやスワイプビューでの切り替え、Spinner による切り替え、一覧表示のフィルタリング、ソートなどが含まれます。
コンテンツの一覧表示を行うアプリの場合、そのリストから項目を選択して、詳細ビューを表示する、という構造が考えられます。
Gmail アプリのように、詳細ビューにおいても、左右のスワイプで一覧項目の詳細を切り替えるナビゲーションも有用ですが、この場合においても、Back と Up のナビゲーションの役割に変化はありません。
ただし、一覧表示から選択される、各々の詳細ビューが、強く関連し合わない場合には、Back と Up の役割は変化します。
例えば、一覧からある項目の詳細ビューへと遷移し、そこから更に別の項目の詳細ビューへと画面を切り替えた場合、Back はその遷移の履歴を戻るのに対し、Up はアプリの構造を戻るため、どの詳細ビューからでも必ず一覧表示へと戻ります。
また、カテゴリビューが存在するようなアプリにおいて、あるカテゴリの詳細ビューから、別のカテゴリの詳細ビューへと遷移した場合、Up ナビゲーションは、それぞれの詳細ビューが属するカテゴリのカテゴリビューへと戻るようにします。
アップウィジェットや通知を用いることで、ホーム画面からアプリ内の画面へ直接ナビゲートすることができます。
これにより、ユーザはアプリの構造を 1 つずつ辿ることなく、直に目的の画面へとたどり着くことができます。
このような場合に、Up ナビゲーションは、カテゴリビューなどの、直接ナビゲートされる画面へのナビゲーションの役割を持っている画面へ戻るようにします。そうでなければ、アプリのホーム画面へと戻るようにします。
一方、Back ナビゲーションは、より明確に、画面遷移の履歴を辿れるようにしておくべきです。
つまり、直接遷移する画面の間にある、アプリの構造上の画面を、Back によって戻ることが出来るようにしておくようにする、ということです。
もし、アプリが通知を出すときに、複数のイベントを同時に通知する必要がある場合、通知を 1 つにまとめて、通知をタップした際には、その通知に含まれる複数のイベントの要約を表示する画面へと遷移させることで、ユーザにどのイベントを掘り下げて見たいかを選択させる手法があります。
この方法を、Indirect Notification と呼んでいます。
通常の通知と異なり、Indirect Notification では、通知をタップした画面と遷移先の間には、いかなる画面遷移の履歴も積み上げることはありません。つまり、遷移先での Back ナビゲーションでは、通知をタップした画面へと戻るようにします。
Indirect Notification の要約を表示する画面から、さらにユーザがアプリの中へ遷移した場合は、これまでどおりの Back ナビゲーションと Up ナビゲーションを行います。
通知には、通知ドロワーに表示する以外に、ポップアップで表示する通知も存在します。
注意するべき点として、このようなポップアップの通知は、ユーザがどのような操作をしているかにかかわらず、強制的に画面にポップアップを表示するため、 ** すぐにユーザからのレスポンスを得なければならない場合で、ユーザの操作を遮るほどに重要な通知である場合 ** に使うべきです。
このポップアップの通知におけるナビゲーションは、Indirect Notification のナビゲーションとよく似ています。
ポップアップ表示における Back ナビゲーションでは、ポップアップが閉じられるべきです。
一方、ポップアップから対象のアプリに遷移した場合は、そのアプリの中での通常のナビゲーションを実行します。
Android プラットフォームの強みの 1 つに、アプリ間連携の仕組みが挙げられます。
とても簡単に、別のアプリを起動してナビゲートすることができます。
Android において、Activity は、ある 1 つの画面を構成し、ユーザの様々なアクションを受け付けます。
アプリはたくさんの Activity の集まりで構成され、他のアプリから呼び出されることもあります。
また、タスクとは、Activity の遷移の一連の流れを表します。
Intent とは、あるアクションを実行するために、様々なアプリへとアシストを要求するためのシグナルです。
アプリの中にある各種 Activity はそれぞれ、どのような Intent に応答するかを決めることができます。
例えば、以下の様なユーザの操作を考えます。
ユーザがあるアプリで、共有メニューから Gmail アプリを起動するタスクです。
このような場合、Back は以下のようにナビゲートします。
Gmail アプリでメールの送信をすると、送信画面は自動で終了し、共有メニューを選択した画面へと戻ります。
同じように、送信画面での Back ナビゲーションもまた、共有メニューを選択した画面へと戻ります。
一方、共有メニューから起動した Gmail アプリでの Up ナビゲーションは、以下のようになります。 Up はアプリに閉じたナビゲーションなので、Gmail の一覧画面へと遷移します。この場合の Back ナビゲーションは、そのままアプリを終了して端末のホーム画面へと戻るようになります。
共有メニューを選択したアプリは、バックグラウンドで待機しているので、ユーザはいつでもそこに戻ることができます。
Gmail アプリが既にタスクを終えた時、もう一度 Gmail アプリに戻ってきた場合には、終えたタスクは破棄され、新しいタスクで上書きされます。
