UI を分解する
本記事は STORES.jp アドベントカレンダー の22日目の記事です。
@tttttahiti です。自分はフリーランスとして Web フロントエンドの開発や研究技術同人誌の執筆などを主にしているのですが、STORES さんとはかれこれ1年以上取引させていただいております。この度は人事の近藤さんよりお声がけいただき、外部の人間ではありますがアドベントカレンダーに参加させていただくことになりました!ありがとうございます。こういうオープンなところが STORES(hey) さんの好きなところです。
STORES さんではフロントエンドの開発を主に行う UI 改善チームの一員としてお手伝いをしています。UI 改善チームはエンジニアで構成されたチームですが、デザイナーとの連携も頻繁にあり、日々 UI についての議論が活発になされています。UI の開発は奥が深く、一つの部品について何度も考え直したり、作り直したりすることもあります。 この記事はそんな日々の中で UI の分解についてぼんやり考えていることを個人的に考え直してみるための記事です。至極当たり前なところからスタートしていきますので、冗長な内容になっているかもしれませんが、自分が悩んだときに立ち返ってみたいポイントを書きながら整理していきたいと思っています。
UI とは
UI とは、インタフェース(日本語に訳すと接点、ある領域とある領域を介する部分といった意味になります)というものの中でもユーザという役割が存在するケースにおけるものを指して使われる単語です。インタフェースは至るところに存在し、またユーザという役割が誰になるかといった解像度によって何がインタフェースとなるかの捉え方も変わってきます。基本的にはオブジェクトからオブジェクトに対して使用するという繋がりが生まれたら、そこには UI が存在するといって差し支えないと私は考えます。
具体的な例えとして、ある商品を売る会社があるとします。経営者から労働者への指示として使われる言語は UI です。そして、労働者が商品を売るときにレジを使うとすれば、レジは UI です。 そして、ある商品を売る会社が STORES というオンライン通販サービスを使っているとします。STORESで商品登録するには具体的に以下のような行動手順を踏みます。
- パソコンをマウスで操作し、 Web ブラウザを立ち上げる
- Web ブラウザの URL バーにキーボードを使って https://stores.jp と入力し、STORES にアクセス
- ナビゲーションに沿ってアイテムリストページに遷移し、アイテムを追加ボタンを押下
- ページ内の各種フォームに商品情報を入力
上記の行動の中でも UI として捉えられる部品が多く出てきました。
- マウス
- Webブラウザ
- URLバー
- キーボード
- ナビゲーション
- ページ
- ボタン
- フォーム
これらは STORES のユーザから見たら全て UI です。さらに言うのであれば、これらの部品を使うために我々が動かす手や目などの器官ももちろん UI です。
UI が何を介しているか
物を売る商売の中でも色んな UI が出てきました。しかし、ざっくり全て UI だと言えるとしても、それぞれ全く異なるものであることは明らかだと思います。部品を整理する上で一つ一つを比べて異なるポイントを挙げたり、ラベリングしたりするのも一つの手だと思うのですが、時間が多くかかりそうです。今回、冒頭でオブジェクトからオブジェクトに対して使用するという繋がりがあればそこに UI が存在する、と言ってみたので、まずは今回の状況で出てきた各部品について使用する側のオブジェクトと使用される側のオブジェクトについて考えてみましょう。
部品名 | 使用する側 | 使用される側 |
---|---|---|
マウス | 人 | コンピュータ |
Webブラウザ | 人 | インターネット |
URLバー | 人 | Webブラウザ |
キーボード | 人 | コンピュータ |
ナビゲーション | 人 | ページ |
ページ | 人 | ページ内の情報 |
ボタン | 人 | ページ |
フォーム | 人 | 商品情報 |
お気付きかと思いますが、使用する側が全部人になっています。これは上述の行動が全て労働者の視点で書かれているからです。使用される側には色々なものが出てきましたが、UIの部品としても挙げられているものも出てきました。あるオブジェクトに接するまでに複数のインタフェースを介している状態であることがわかります。労働者の目的が商品登録であるのに対し、労働者が直接データベースを変えることができない以上、複数のインタフェースが導線として介在しているとも言えます。もちろん、この表は決して汎用的なものではなく、この状況においての役割分担のみを示しています。
UI が提供するアクション
前述の図で見たところ、使用する側と使用される側が同じものがあります。例えば、マウスとキーボードはどちらも人とコンピュータを介する UI です。その違いは UI が提供するアクションです。マウスは手で動かすことで、画面上にあるカーソルを動かします。キーボードはキーを押下することでテキストなどを入力します。
どちらも人からコンピュータに対して入力するデバイスであることに違いはありませんが、入力したい対象物と操作方法が異なります。
部品 | 対象物 | 操作方法 |
---|---|---|
マウス | カーソル | 手で動かす |
キーボード | テキスト | キーを押下 |
仮に対象物を入れ替えてみるとします。キーボードでカーソルを動かすなら、矢印キーで1pxずつ移動させたり、あるいはカーソルを動かすためのスクリプトを用意して座標を入力するなどの方法が考えられます。マウスでテキストを入力するなら、画面上にテキストのボタンを用意して一つずつ選択するなどが考えられます。想像するに、どちらも慣れ親しんだものではないと思います。
なぜカーソルを動かすのにマウスが適しているのか、あるいはテキストを入力するのにキーボードが適しているのかは我々がこれまでに経験的に学習してきた動作との関連性が強いからだと考えられます。それはアフォーダンス*1と呼ばれるものです。マウスは手のひらで握りやすい形になっており、キーボードのキーはそれぞれテキストが書かれたボタン形状をしていることがほとんどでしょう。アフォーダンスにより操作方法を経験から連想させるものは、直感的な使いやすさを提供します。それは同時に汎用性を失うことでもあります。キーボードからテキストの印字を無くせば、テキスト以外の入力も想起できるようになるでしょう。しかし、押下後に引き起こる反応はわかりにくくなり、直感的な操作性は下がります。
UI の成立条件とアイデンティティ
マウスは握って動かすだけではなく、ボタンもついています。それは、カーソルを移動したあとに選択(及び実行)という動作を後続する必要があるからです。単純に何かの選択という動作だけに絞るのであれば、キーボードに選択ボタンを設けたほうが短い操作で済みます。しかし、タイプマシンのような単純な機械ならまだしも、現代のコンピュータの機能を全てキーボードにアサインすることは難しいでしょう。そのために GUI*2 が開発され、それを操作するためにカーソルがあり、カーソルを動かすのに適した UI としてマウスがあります。ですので、マウスが UI として成立するための条件としてはカーソルを動かせる機能と、選択するという機能の2つが少なくとも必要になりそうです。
この2つを比べてみたとき、選択するという操作については、キーボードのキーの代替やマウス上のボタン自体の役割であるという見方もできると思います。ですので、マウスの機能条件の中でどちらがメインかとすれば、カーソルの移動がメインであると考えます。この機能はキーボードによって代替することが難しい機能でもあります。よって、マウスのアイデンティティとはカーソルの移動にあるといえるでしょう。
まとめ
UI を分解して、大きく以下のような事柄を挙げてみました。
- UI が介するオブジェクト
- 使用する側のオブジェクト
- 使用される側のオブジェクト
- UI が提供するアクション
- 入力及び出力する対象物
- 使用する側のオブジェクトが対象物をどう操うかの方法
そしてこれらから、
- UI の成立条件
- UI のアイデンティティ
を考えてみることになりました。世の中に溢れる UI について、できる限り当てはめられるケースを広げて話をしようと思ったので、当たり前なことに行き着いてしまったのですが。日々の開発で「もう面倒くさいから、『○○をする』ボタンを置いておくか!」なんてことにならないように、何をどうしたいのか、それを介するために本当に必要な UI ・機能はなんなのかをきちんと整理し続ける、そんな基本の姿勢は保ちたいですね!ちなみに私はマウスよりトラックパッドが好きです。
明日は Shuto Araki さんです!