我々が"構造"について話すとき、それはどういう意味なのか。みなさんが最初に思いつくのは建築の図面ではないでしょうか？ここでの構造は、各スペースが何を意図しているものか決め、また行いたい活動をどうサポートするか提供します。構造は直接見えるものだけではありません。骨は私たちの体の構造を提供しています。骨により筋肉や内蔵を適切な場所に収めることができます。
"Does your app have good bones?"
我々のアプリケーションはこれらの例両方に似ています。空間を定義し、適切な場所に機能を取り付ける必要があります。
よく構造化されたアプリは少なくとも次の３つの特徴があります。
- 何かを行うのが簡単かつ効果的
家ではドアの幅は出入りするのに適切なサイズだし、床は硬いし、何かを行うのに適切な光量がある
- 関連する項目は一緒にし、関連しない項目は離す
近接の効果を利用する。台所とダイニングは繋がっていて、ガレージで区切られていたりはしない
- 積極的に一貫性のあるナビゲーションを通して複雑さを管理する
フロントの部屋はすべて互いに繋がっているが、客室は共通の廊下につながっている
どうやってアプリケーションのための自然な構造を見つけるのか。その説明として Barkeeper という近くのバーを探せるアプリのデザインを例に説明します。
"What does my app do?"
形は機能に従うという何度も繰り返された教訓を聞いたことがあると思います。まず、"このアプリは何をするのか？"をはっきりさせましょう。これに答えることによって、アプリでの作業を支えるために必要な構造を考えやすくなります。
この答えはバズワードで飾られたエレベータピッチのようなものではありません。また、機能のリストでもありません。機能のリストは低レベルすぎてユーザーのゴールからかけ離れています。この２つのちょうど中間のものが必要です。幸いなことにモデリングテクニックがあります。
ユースケース : あるタスクを達成するためのシステム（= アプリ）とアクター（= ユーザー）間のインタラクションの流れ
物語の説明としてユースケースを記述するとこんな感じになります。
BarKeeper にはバーを見つけるというユースケースがあります。これに入る前に、このユースケースの主なアクターが誰で、どのようなことが起こらなければいけないのか識別しておきます。ここでのユースケースのコアはアクターとシステム間の対話です。 これをいろいろ拡張できます。このタスクのバリエーション、例えば近くのバーを見つける、を考えたり、成功や失敗などの事後条件を考えたり。とてもシンプルの保つのがいいと思います。これの価値はフォーマットではなくコンテンツにあります。
ユースケースダイアグラム
アプリケーションの構造にとても役立つのですが、しばしば見落とされることがあります。ダイアグラムのコンポーネントは、アクター、ユースケース、関係を表す矢印、の３つだけです。
BarKeeper のユースケースダイアグラムはこんな感じになります。
ユースケースダイアグラムはとても簡単に描けます。これを使うととても早く概要を把握することができます。 ユースケースダイアグラムを描くステップ
- 1. Inventory
必要なアクターとユースケースを用意する。物語としての説明はいらない。ユーザーの観点からアプリにさせたいことが必要。
- 2. Prioritize
大雑把な優先順位をつける。High, Medium, Low でいい。ユースケースの優先順位付けで重要なのは、どれが一番重要なユースケースで、どれがそれほどでもないのかを見つけること。アプリでもっとも頻繁にすることは何か、最も重要なことはなにか、という視点から始めるとよい。
- 3. Sequence
個別のアクターからどのユースケースに直接行きたいのか、どのユースケースは他のユースケースの拡張なのかを順序付ける。
- 4. Decompose
幅広い、漠然としている、多くの基礎をカバーしている、と感じるユースケースがあるなら、それを分解する。
優先度に応じてストロークを変えてみます。優先度の高いものは太く、優先度の低いものは点線にします。アプリのキーになるパスがわかるようになります。
階層については何か言えるだろうか？
"Breadth"
アクターがいくつもの同じ優先度のユースケースに繋がっていて、それらがすべて合理的な開始ポイントであるなら、ある開始ポイントから他の開始ポイントへ簡単に遷移できるようにしたいです。
"Focus"
一方、ユーザーケースの中でよりフォーカスされたもの、他のより重要なものが１つだけある場合、他のユースケースは少しアクセスしにくくします。
"Statefulness"
ユーザーによって、優先度の高いユースケースが異なる場合があります。例として Android の Phone アプリがあります。起動した画面に Dialer, Call Log, Favorite の３つのステートがあります。これらは異なるタイプのユーザーの振る舞いと紐付いています。
"Depth"
完全に分離されたユースケースの深いつながりがある場合、特に重要です。
ユーザーが他のセクションに簡単に移動したい場合があるなら、アプリはそれを考慮しないといけません。
"Interconnectedness"
ハブのような複数のスレッドから集まるユースケースがある場合、それはとても重要な機能です。
ユースケースダイアグラムを90度回転し、それぞれのユースケースを画面に見立てます。アプリの階層を考えるうえでいいスタートポイントですが完璧ではありません。ユースケースの詳細度によって、１画面にとっては詳細すぎたり、大雑把すぎたりします。
階層のパターンについて
一般的なブループリントの例
トップレベル
アプリのエントリーであり、アプリに応じて１スクリーンだったり、マルチスクリーンだったりします。アプリの主なユースケースが何か、いくつあるのかに依存します。重要なことは、ユーザはここでカバーされている主なユースケースを見つけ、あるタスクを完了するための次のステップに導かれるということです。
トップレベルは、アプリの広い機能について示し、アプリのアイデンティティを構築します。 例を見るとわかるように、ひと目で "このアプリが何なのか" 理解することができます。
カテゴリーは階層や機能により深く入るために、トップレベルとボトムレベルをつなぐ部分です。 アルバムやフォルダーなど組織的な階層です。
詳細はタスクを完了したり、データを消費したりする部分です。あつかうデータタイプによって様々な画面になります。
構造を決定する上でトップレベルが一番重要です。
ここでの決定によって、ユーザーがここでカバーされている主なユースケースをうまく見つけられるか、次に進もうと思うようにユーザーを満足させられるかが変わってきます。
トップレベルはユーザーとのコミュニケーションであり、アプリの機能についてユーザーにエレベータピッチするところです。このアプリの目的のみならず、機能の広がり（他に何ができるのか）も紹介します。
Phone アプリでは、電話をかけることができるという主な機能の他に、Call Log と Favorites があることをタブで示しています。
このような情報は可能な限り早く開示し、ここでのコミュニケーションは簡潔にする必要があります。 トップレベルはユーザーとの対話であるということを心に留めておいてください。
ユーザーがトップレベルの機能を探せるようにすることは、全てのユースケースがカバーされていることを確認するうえで決定的です。
Android では、このようなアプリの異なる面に切り替えるためのいくつかの確立したパターンを提供しています。
Six-pack
階層の一番上の単一画面で、本質的にはメニュー画面です。ユーザーはメニュー画面を通して深いレベルに入っていきます。常にこの画面を介さないといけないので、複数の面を探したり、自分のユースケースのためにはどこに行けばいいかわからないときに一つづつ試すことができます。
利点
・直線的でシンプル
・全ての面のトップレベルが並んで見えている
欠点
・見てもあまり面白くない
・データがない
・ナビゲーションの努力がユーザーに必要
時間がたてばユーザーは構造を理解するので、タスクに入るまでのジャンプが余分になります。また、ある面から別の面に移動するにはここまで戻ってくる必要があるので、ユーザーがたくさんナビゲーションを行わなければなりません。
Fixed-tabs
Android では一般的なパターンです。横に並んだ３つのトップ画面があります。素早く効果的に別の面に移動できます。
トップレベルを簡単に素早く切り替えられるように、サイドスワイプでタブを切り替えるようにしてください。
利点
・全てのトップレベルが並んで表示される＝他の選択肢が見つけやすい
・ものすごく効率的
欠点
・３つまでに制限される
・縦の領域を専有する
・階層の下のレベルからアクセスできない
Spinner
スピナーはより多くのアクションがある場合にタブの代わりに利用します。タブでは２つか３つまでですが、それ以上の選択肢を与えられます。ActionBar の中にスピナーが入るのでタブが専有する部分がなくなります。 一方で、スピナーが閉じている状態ではアプリの構造があまり明らかになっていません。
利点
・３つより多くのトップレベルを持てる
・コンパクト
欠点
・トップレベルが並んで表示されない
・階層の下のレベルからアクセスできない
Navigation Drawer
いくつかのアプリはすでにこれを実装しており、これまではコミュニティドリブンのパターンでしたが、Navigation Drawer を正式に Android Design Guide の一部にしました。
Navigation Drawer : Android Design
Creating a Navigation Drawer : Android Training
Navigation Drawer はアプリの最も重要な画面へのメニューパネルです。左上の Navigation Drawer アイコンをタップするか左端からスワイプすると、スライドしてきてコンテンツの上にオーバーレイされます。Navigation Drawer は "navigation hubs" を含み、ユーザーは頻繁にここにくるでしょう。ハブだけでなく下位階層へのナビゲーションも含めることができます。
下の階層の画面からでもトップレベルにアクセスできますし、別の面の下位の階層にアクセスすることもできます。 トップレベルでは ActionBar のアプリケーションアイコンの左に、ーが縦に３つ並んだ Navigation Drawer Icon が表示され、下位の階層では UP アイコンが表示されます。
Navigation Drawer のいいところは、コンテンツを作るためのスペースがあることです。アイコンを表示したり、ディバイダーを使ってセグメントを分けたり、アップデートなどのカウンターを表示したり、下位レベルのコンテンツをグルーピングしたりできます。
利点
・多くのビューを表示できる
・コンパクトで閉じることができる
・下位の画面への遷移も入れることができる
・どの画面からでもアクセスできる
欠点
・トップレベルが並んで表示されない
どのパターンを使うべきか - 実例
例1 - Calendar
現在カレンダーはスピナーを使っています。日、週、月、予定の関係をユーザーはしっかり理解しています。コンパクトで、上部にきちんと収まっていて、タイトルに合っています。
Navigation Drawer も可能です。表示するための特定のタイトルも提供できます。ただし、4つ以上のオプションが増えることはなさそうなので、タブレットなどのデバイスでは空間が目立つでしょう。
タブはよくない選択です。 タブは頻繁に切り替えるようなアプリではいいのですが、カレンダーではある人はよく１日のビューを使い、ある人はよく１週間のビューを使っているのではないでしょうか。さらに、タブによってカレンダーの領域が狭くなってしまいます。一番重要なことは、望ましくないジェスチャーを紹介しないといけないことです。ユーザーはスワイプによって日を切り替えられると期待しますが、タブを使うと日の切り替えとタブの切り替えが衝突してしまいます。
six-pack も同じように良くない選択です。毎回データを見るまでトップ画面を介さなければならないですし、カテゴリーを変更するために毎回トップに戻らなければなりません。
例2 - Clock
Clock は他の機能面とうまくコミュニケーションするためにタブを利用しています。ただの時計だけでなく、タイマーとストップウォッチがあることをほのめかしています。すぐに時計だとわかるのでアプリの名前などを表示する ActionBar をなくすかわりに、時計画面では split action bar を使っています。縦の領域は問題ではないので split action bar は適切な選択です。
スピナーを使ってもいいでしょう。ここでは時計画面にあったアラームを４番目のアイテムとして置くことができます。他の面への移動は少し操作が増えます。タイトル部分が増えるので、もとのデザインのシンプルさが少し損なわれます。
Navigation Drawer はスピナーと同じような感じです。
ナビゲーションとしては3つのパターンが使えますが、ビジュアル的なシンプルさではタブが一番いいでしょう。
例3 - Gallery
ギャラリーはスピナーを使っています。カレンダーとは少し異なる方法です。ここでは"同じデータをどのような方法で表示するか"を選択するために使っています。
Navigation Drawer でもいいでしょう。例えば下位階層として個別のアルバムへの遷移を入れることもできるでしょう。ただし、ここにはアルバムのサムネイルが表示されないため、有効な手段かどうかは疑問が残ります。
タブはだめです。タブの多すぎるし、カレンダーと同じスワイプジェスチャーの問題があります。
例4 - Drive
Drive ではアカウントの切り替えようにスピナーを使っていました。アプリ内でアカウント切り替えが頻繁にある場合、スピナーで行うことはいい選択です。ただし、Drive ではトップレベル切り替えの問題があり、コンテンツ領域のトップレベルにファイル階層を持ってくることでそれを解決していました。正確にはファイル階層ではなくスタティックリンクですが。本質的にはカスタマイズした six-pack です。
アプリを開いたときに直接データにアクセスするために、例えばスピナーをカスタマイズするという方法があります。Gmail では同じような方法をとっています。この方法は、スピナーが本来どうあるべきかを薄めてしまいます。スピナーは本来ある1つの項目を選択するためのものです。
Navigation Drawer は Drive にとって素晴らしい選択です。すぐにデータを表示でき、アカウントの選択もでき、トップレベルの切り替えもできます。
Shifting structure
アプリの進化よって直面する挑戦があります。Play Store にアプリを公開しているなら、アプリのライフスパンに応じて多くのデータや機能を追加するでしょう。その場合、常にアプリの構造が適しているか気に留めてください。
例えば、スポーツの結果を表示するシンプルなアプリがあるとします。公開したときに開発者が興味をもっている US で人気のある3つのスポーツに特化しています。
人々はこのアプリのシンプルさを気に入りますが、変更も頼んできます。一度アプリを公開するとフィードバックが来ます。例えば「ホッケーはないの？」とか。
そこで、ホッケーとサッカーを入れたり、Notification を追加したり、お気に入りのスポーツを登録できたりするようにしようとします。
最初に考えるのが、すでにあるトップナビゲーションに追加することです。なぜなら、ユーザーはすでにその方法に慣れ親しんでいるからです。しかし、この場合タブにこれ以上アイテムを追加するのはいい方法ではありません。
Navigation Drawer を使うと、多くのスポーツへのトップレベルを提供でき、設定画面への Overflow メニューも用意できます。
まとめ
- 適切な構造を選択することはアプリの体験にとって非常に重要
- "このアプリは何なのか"を理解し、異なるユーザーにどのように提供するのか
- ナビゲーションパターンを選択するときは全てのオプションを考える
0 件のコメント:
コメントを投稿