Material Designに従ってリスト周りのUIを考えてみた

この投稿は[モバイルファクトリー Advent Calendar](http://qiita.com/advent-calendar/2015/mobilefactory)の21日目のものです。

この記事ではMaterial DesignにおいてどのようにリストのUIを設計するかについて述べていきます。ListViewやRecyclerViewがどうこうなどの実装の話はしません。

# Material Designとは

スマートフォンやデスクトップなど様々なデバイス間で、情報を伝えるために視覚的な相互作業をどう設計すればいいかを示したガイドラインです。
大まかなコンセプトは[よくわかるマテリアルデザインの設計コンセプト](http://fladdict.net/blog/2015/05/material-design.html)を見ればすぐに掴めるでしょう。

近頃はMaterial DesignらしいAndroidアプリも増え、アプリのUIデザインを行う際は[Material Design Guidelines](https://www.google.com/design/spec/material-design/)の内容を把握しておくことが必須になってきました。
現在も更新が続けられているようですので、できればこちらを定期的にチェックするのがオススメです。

全て英語で日本語訳がないためとっつき難いかもしれませんが、画像も多いですしGoogleの日本語翻訳で大体意味はつかめるでしょう。私の場合は毎週定期的に行われている勉強会で、みんなで英語の解釈を確認しつつ読み進めています。

今回はガイドラインの中の一つ、リストについて取り上げます。

# リスト

![list_example.png](https://qiita-image-store.s3.amazonaws.com/0/53934/7e2b5b2d-59c6-7a17-c245-e192be0a0c30.png)


リストはUI設計でも特によく使われるものの一つでしょう。ガイドラインでは[Components - Lists](https://www.google.com/design/spec/components/lists.html)で定義されています。

ガイドラインの冒頭でリストのポイントが示されていますが、実際にアプリのUIを設計してみて、個人的に大事だと思ったポイントを加え以下の4点について話をしたいと思います。

- 要素の配置とアクション
- リストとカード
- リストとグリッドリスト
- リストとスワイプジェスチャー

## 要素の配置とアクション

![list_actions.png](https://qiita-image-store.s3.amazonaws.com/0/53934/e2f97309-4d5c-b94c-ee70-30703a7f6f6e.png)


リストの仕様は以下のように定義されています。

- リストの大部分は主要なアクション専用にする
- 左側に向かって優先度の高いコンテンツを配置する
- 複数行の場合、一行目に優先度の高いコンテンツを配置する
- 補助アクションは右側に配置する

基本的には以上のルールですが、チェックボックスのように**アクションからリストを使う**場合は右側にアクションを示すアイコンを配置する場合もあります。
ここで定義するものはリストからアクションを行う場合のリストについてと考えられます。

### 【実例】実際にあった困った状況

補助アクションは右側に配置しなければならないため、例えば曲一覧に再生機能をつけたいといったときは以下のような見た目になります。

![list_play.png](https://qiita-image-store.s3.amazonaws.com/0/53934/fabb632b-f71f-64c5-4408-ab7bdfe259f2.png)


しかし、困ったことに一昔前によく使われていたページ遷移を示すシグニファイアに似てしまいました。

そのため、以下の選択を迫られます。

- 誤解は許容し、ガイドラインに従う
- 誤解を解くために「再生」などのラベルをつける

新しいUIを徐々に学習してもらうため、まずは後者の選択し、慣れたところでラベルを廃止するといった対応もありでしょう。
現実問題、ガイドラインに完璧に従うことは難しいので、UI設計者は段階を追って理想に近づけていくことを求められます。


## リストとカード

始めはシンプルなリストでも、サービスを運用していると表示テキストやアクションを増やしたくなることがあると思います。

リストでは主要アクションと補助アクションを定義することができますが、リストはあくまで並列のコンテンツを**一覧**するために用いられます。
遷移無しに色々できたほうが便利かもしれませんが、一覧性が損なわれてしまうことは避けなければなりません。
ガイドラインでも3行以上のテキストがリストに必要な場合は、代わりに[カード](https://www.google.com/design/spec/components/cards.html)を使うように述べられています。

したがって、要素に変更がある場合は

- 一覧性を低下させてでも追加する必要があるか
- 要素の追加に伴い、削ることができる他の要素はないか
- アクションを追加する場合に統合することはできないか

などを検討してみるといいでしょう。

![list_ui.png](https://qiita-image-store.s3.amazonaws.com/0/53934/7ebd7b48-1b3a-9cf9-8868-f3babdbfc3cc.png)


それでも全ての要素を維持する必要があればリストからカードに変更することになります。
実装が変わり工数が増えるかもしれませんが、煩雑なUIになることを避けましょう。

![list_card.png](https://qiita-image-store.s3.amazonaws.com/0/53934/a67c8545-4d2e-c048-511a-7cd62f78c2c9.png)

## リストとグリッドリスト

画像を用いるUIを考える際、サムネイルを見せるため以下のようなスタイルを作りたくなるかもしれません。

![list_sum.png](https://qiita-image-store.s3.amazonaws.com/0/53934/dfebba4d-dcc2-73f9-2a4c-d28d092c03ca.png)

しかし、この場合は主要な情報が画像となるため[グリッドリスト](https://www.google.com/design/spec/components/grid-lists.html)が適切と考えられます。

![list_grid.png](https://qiita-image-store.s3.amazonaws.com/0/53934/c03cfa5c-76e3-35f6-cd82-39d368167cfe.png)

画像が小さいからと言って領域を大きくしたりしても、余白の大きさがガイドラインから外れてしまいますので、できるだけグリッドリストを使いましょう。
欠けてしまうと困るのは画像とテキストどちらなのかを基準に考えるといいと思います。

## リストとスワイプジェスチャー

ガイドラインでは述べられていませんが、リストにはスワイプジェスチャーで削除のようなアクションを割り当てる場合があります。メール一覧で「既読にする」といったアクションです。
しかし、タブを使う場合はタブの移動にスワイプジェスチャーを使うため、リスト操作に割り当てられない点に注意が必要になります。

![list_tab.png](https://qiita-image-store.s3.amazonaws.com/0/53934/f5e7b7c1-01e7-ba7b-9680-921c8425fd3b.png)


「既読にする」というアクションのような主要なアクションは、スワイプジェスチャーに割り当てることが優先されることもありますので、その場合はタブを使わない設計に変更しましょう。

# まとめ

UIにリストを使う場合のポイント

- 領域の大部分は主要アクションに割り当て、補助アクションが必要な場合は右側に配置する
- 3行以上のテキストや複数のアクションがリストに必要な場合は、代わりに[カード](https://www.google.com/design/spec/components/cards.html)を使う
- 主要なコンテンツが画像で構成されている場合は[グリッドリスト](https://www.google.com/design/spec/components/grid-lists.html)を使う
- リストにスワイプジェスチャーが必要な場合はタブを使えない

以上、実際にUIを考えるときにつまづきそうな話を絡めつつ、リストについて簡単に説明しました。
他にも細かな仕様がありますので、是非ガイドラインを読んでみてください。

明日は[@yashims85](http://qiita.com/yashims85)さんです！