デザイナーに知っておいてほしいリストUIの基本

当たり前の基本的な話だけ。

リストUIの話。なんらかの「物」を一覧して選ばせたり操作させたりする、あのUI。結論から言うと、リストUIは基本的に、というか、構造としてはほぼ100%この形になる。

解説を組み入れると、こう。

 

1. 一つの「物」に対する操作実行UI

すでに存在する「物」に対する操作を実行するためのUI。厳密に言うと「着目」「処理」「処理へのショートカット」の3種類がある。

1−1.「物」への着目実行UI

もっとも代表的な操作例は「編集」または「表示」

一般的には、このUIを実行するとその「物」を1つだけ表示した画面に遷移する（詳細確認画面とか情報入力画面とかそういうの）

タップ、HTMLリンク、ダブルクリックなど対象のプラットフォームにおける「選択」に対応する操作体系を割り当てるのが一般的。

1−2. 「物」に対する処理操作実行UI

もっとも代表的な操作例は「削除」

ここにどんな操作が分類されるかは「物」の特性にかなり依存する。メールのリストだったら「返信」「転送」とかだろうし、ツイートのリストなら「返信」「リツイート」「お気に入り」などだろう。

一番ありふれたUI例は、リストUI項目内に配置されたボタン

1−3. 1−2操作群のショートカットを呼び出すUI

一般に1−2の操作群は多数にわたるため、リストUI項目内には全ては入りきらない。が、かといって1−1の機能を使った「着目後」の画面で機能提供するだけでは操作手順が多くなって利便性が損なわれる、というジレンマが往々にして起こりうる。これを解決するためのUI。

UI例は、プラットフォームに依存する。イメージとしては右クリックコンテキストメニュー的な何か。

2. 「物」を新しく作る操作実行UI

もっとも代表的な具体例は「新規作成」

他にも「コピーして作成」とか「インポート」とか。ともかく、今ないものを作るための操作を実行するUI。当然だが、未だないものを作成するUIなので、リスト項目内に表現することはできない。

一番ありふれたUI例は、リストUIの外に配置されたボタン。

3. 複数の「物」に対してまとめて行う操作実行UI

もっとも代表的な操作は「削除」と「上へ」「下へ」

対象となる「物」を選ばせたのち、実行操作を選択させるUI。当然、どこが「選ばれている」かを表現する手段が必要になる。

一番ありふれたUI例は、リスト項目内のチェックボックス＋リストUI外のボタン

デザイナーに知っておいてほしいこと 

リストUIのデザインとは、並べる「物」に対する操作(＝提供する機能)を上記3種類に分類して、状況やプラットフォームに最適なUI表現に当てはめ直すだけってこと。

例えば、1−1.はWebならHTMLリンク、Windowsアプリならダブルクリック、スマホならタッチになるのが一般的でしょう。1−3はWindowsなら右クリック一択だし、スマホなら一時期はロングプレスだった気がしますが、最近はリスト項目上のスワイプが流行りです。

リスト上のスワイプによるコンテキストメニューの表示 via Boomerang: Email App for Gmail : もう忘れたくない！大切なメールはあとでもう1回受信！無料Androidアプリ | オクトバ

写真アプリであれば並ぶのは冒頭例のようなリストではなくて正方形のサムネイルがタイル状に並ぶでしょう。「できる操作」の数が多くなればボタンの羅列ではスペースがたりないので、プルダウンメニュー＋実行ボタンというUI表現になるかもしれません。流行りのフラットデザインを取り入れるのも良いでしょう。操作手順短縮の要件があるなら、1−1.の操作結果を画面遷移ではなく、画面内ミニウインドウにするといったUI表現に変わるでしょう。

どのUI表現をとるかは状況や要件次第です。どの表現を採用するかで、デザイナーのセンス・能力が問われます。

しかし、大事なのは、いずれも３つの要素が「違う形」で表現されているにすぎないということです。UIの違いとは表現違いであって、根本は何も変わっていないということです。いくら状況や要件や時代性とか流行りが変化しても、3要素以外のカテゴリを新しく作ったり、それぞれを混同する必要性は全くないのです。

これは「物を並べて選ぶ」という行為の根幹に関わる問題です。並べられた「物」に対する操作カテゴリは、これ以外に存在しません。webだろうがスマホだろうがFinderだろうがなんだろうが、そもそもコンピューターシステムですらなくても、並べられたものを操作する、という行為の本質から考えて、それしかありえないからです*1。

もし、ちゃんと整理してもどうしてもあたらしい概念を追加しなければならないなら、リストUIでそれをやろうとすること自体が間違ってることを疑ったほうがよいでしょう。

「基本」はずっと前から共有されて提供されている

リストUIの基本は今突然発見された話ではなく、周知の事実です。

その証拠に、ほとんどのプラットフォームやフレームワークで「基本」に基づいたリストがすでに提供されています。ほとんどのリストには"selected"という概念があるし、プラットフォーム固有の右クリック機能などがそこに組み込まれています。

via View Controller Basics

iOSのリスト。リストの外に、新しく物を追加するための「＋」ボタンがある

via About List-View Controls (Windows)

.net frameworkのリスト。selectedや右クリック対応などはデフォルトのリストが機能として持っている 

via blinq part 2: comparing rails scaffolding

ruby on railsの雛形で生成されるリスト。各行に「表示」「編集」「削除」の「物」への操作が並び、下部に「物を作る」ボタンが並ぶ 

念のため言っておきますが、これは、プログラミングを意識してデザインしろといった類の話ではありません。プログラムを知識がないデザイナーdisといった話でもありません。物の本質を見据えてデザインすべきという話です。

リストはGUIの基本中の基本です。リストがないアプリケーションはないというくらいの基本UIです。どのプラットフォームでも状況に依存しない汎用パーツとして“普通”に提供されていて、見た目以外はほとんどリデザインする必要がないはずなのです。

残念事例

こいつは一体なぜこんな当たり前のことを長々と説明したのか、と思ったひとも多いとおもいます。が、実際には「基本」がわからないデザイナーからトンデモUIが提示されることがあるのです。

残念事例1

「顧客の利便性のためUX統一します、全リストはこれで統一」とか言われたんだったかな？それで持ってこられた例がこれ。

• もっともよく使うであろう「編集」操作が1手→2手になってしまう
• 「まとめて削除」機能が失われる

ぱっと見だけで上記2点がデグレする上に、このUIにして改善することがひとつもない。「物を作るボタン」と「既存の物を操作するボタン」を無自覚に並べてることからも、基本が理解できてないと思われる好形。

残念事例2

事例1と似てるけどさらにわけわからん状態になっている。これも、デザイナーが提示した「基本デザインガイド」的なものがこんなんなってた。

多分事例1と同じような感性の人が「まとめて削除」に対応しようとしてこうなったと思われる。なお、複数チェックした状態で「編集」を押すと、「複数選択されているから編集できません」的なダイアログが出て編集ができないというストレスマッハ仕様。

恐ろしいことにこういう残念事例は1人のダメデザイナーの1事例というわけではないのです。何日もかけて出てきたデザインがこのレベルということがしょっちゅうあります。「これは物に対する操作だからここにあるのはおかしいよね」「この状態でもしxxって機能が増えたらこのUI破綻するよね」とかしょっちゅう言ってます。

正直、こういうのの相手は非常に疲れるので、リストUIの基本くらいは知っていてほしいなあ、と。お互いそのほうがハッピーだし。こんな経緯で、筆を取った次第でございます。

かしこ

以下とりとめのない雑記(大体愚痴)

• 個人的な感覚でいうと、この失敗事例みたいなデザインをする人間はプロとして最低限のレベルに達してないので即時クビにしていいと思う。からむのがめんどくさい
• ていうかデザイナーの教科書とかないの？教科書の1ページ目に書いてある内容だと思うのだが
• そもそも、一体どこから失敗事例のような発想が出てくるのか、確立したUIがあるのになぜ劣化版の新UIを考えて自信満々にUX改善などと言えるのか理解できない
• このほか、ペインとかタブとか、その手の画面の一部を切り替える系のUIも「トンデモ」が出がちである。エリアとその切り替え、という基本概念が理解できていないと思われる。しかしこれは世に出ているUIもかなり酷いのが多い。facebookとか

• おそらくデザイナーという職種に対して、能力のミスマッチが起きていると思われる。GUI構築に必要なのは、論理に基づいて不整合のないデザインを行えるインダストリアルデザイン的な能力を持った人材
• しかし、実際は感性に基づいて一枚絵を美しくデザインする能力を持った人材が多く登用されてる気がする。だから「動き」を考慮したデザインすることができない
• 雑誌の紙面レイアウトやお菓子のパッケージデザインの仕事であれば一枚絵の才能が活かせるが、GUIデザイナーにはその能力では無理だ。つまり採用ちゃんとしろ

• ハード系のインダストリアルデザイン教育では素材とその特性を学習する機会があるようだ。この学習の仕組みをGUIの理解に応用するとすると、さしずめ素材＝GUIコンポーネントとなるのかな？
• それぞれのGUIコンポーネントがどんな機能性を表現していて、何故その形になってるのかは把握しててほしい

 

• Twitterとかfacebookとかに顕著だけど、同種の物を並べてタブ的な物で切り替える昔ながらのリストではなく、「状況」がタブで分かれていて、その中に異種の物が並べられるというUIが増えている、つまりより複雑化したUIが増えている。そのような複雑リストに慣れ親しみすぎているのも「基本」がおろそかにされる原因にあるのかなと思ったり
• 異種の物を並べるリストはかなり難度が高い。そもそも「くくり」がユーザーの期待と合っていないと即「使いづらい」と言われてしまう。バージョンアップによる拡張などもしづらくなる。あまり成功事例をみたことがない
• 異種の物を並べるリスト、成功例はわからないけど、失敗例はみんな知ってる。MSのリボン
• リボンは論外としても、OSのリストボックス＋メニューバーの構成等は厳密には「基本」に従っていないものが多い。Windowsでいえば、「ファイル」に作成系、「操作」に既存物操作系が並んでいるのが正だと思われるが、厳密には混ざっている。ツールバーもそう。お手本となるべきOSがこんな状況なのはよくない。しかし歴史的経緯もあるのでしょうがないか

• デザイナーに限らず、プログラマが適当に考えたUIも「基本」に則ってないものが多い。なぜだ。自分が実装することとか、リストフレームワークに食わせる内容とかを考えないのだろうか
• railsのscaffoldのように、「プログラム上のあるべき姿」を絶対正として考え、UXに無頓着なプログラマは、プログラマとしては優秀であることが多い*2。ぐちゃぐちゃのUIを適当に考え出すプログラマはプログラマとしても無能というか大体コードもスパゲッティであることが多い

*1:まあ厳密には「抽出(フィルタリング)する」「並べ替える(ソーティング)」というのもありそうだけどひとまずおいとく

*2:ただし性格はめんどくさい系