フロントエンドのテストの話をする時に、どのようなツールを使うのか、どのようにCIに組み込むかといった話ばかりされる。もちろんそれらも大切だけれど、それと同じぐらいフロントエンドの操作性の向上も重要だと思う。
テストの自動化を進めても、表示をスクリーンショットで目視確認するようにしたとしても、優れたサービスを使ったとして、精度と柔軟性という観点ではユーザーが実際に操作をするテストに勝てない。またフロントエンドの操作性の向上はテストだけではなく製品の品質向上やユーザーの満足度の向上に繋がる可能性もある。そういう意味でもこれらをもっと進めたほうが良いが、扱っているソフトウェアを考えるとなかなかそこに行き着かない。
高いフロントエンドの操作性は2つの構成要素で成り立っていると思う。1つ目はユーザーがそのフロントエンドを思った通りに操作できることだ。どのボタンを押したら何ができるのか、一連の作業を自動化するにはどうすればよいか、表示を変更できるかということについて、ユーザーがどの程度それをできるかということだ。2つ目は多くの人が良いと思える操作方法や表示方法だ。言い換えると、1つ目はユーザーに許される操作と表示の自由度、2つ目は操作と表示に関する良い感じのデフォルト値と言える。
良くある構成としては、2つ目の構成要素である良い感じのデフォルト値が強制されている状態だ。強制されている以上もはやデフォルト値ではない。UIの表示、操作などを「ああでもない」「こうでもない」とサービスの提供者が工夫し、それを実装し、画一的にデプロイしてしまうというのは、万人にとって良い感じのデフォルト値を探し続け、各々の主観でかろうじて良いと思えるものをユーザーに押し付けている状態だ。万人にとって良い感じのデフォルト値なんてものはないし、それを押し付けられるのはたまったもんじゃない。あるユーザーが身体的な特別な理由により、特殊な操作方法をしていることなど、ソフトウェアやサービスの提供者が把握できるわけがない。もちろん良い感じのデフォルト値を提供することは素晴らしいので、それは行うべきだが、気に入らないと感じたユーザーは、その操作をカスタマイズできるようにしなければならない。
「こういう人が一般的だから」や「この層のユーザーが多いから」というのは良い感じのデフォルト値を探す時の手掛かりであって、それを理由に少数のユーザーを切り捨てよい理由にはならない。なぜサービスの提供者が、それを使用するユーザーを選べるということになるのか。もちろん完全に全てを受け入れることは難しいが、できるかぎり努力すべきだと思う。
ではどのような機能を提供すればそれらが満たせるのかということを考える必要もある。その答えの一つにホットキー(ショートカット)だろう。ただ、それについて最適解ではないと考えている。ホットキーはソフトウェアの利用者が決めることであって、その仕様をソフトウェアやサービスの提供者が強制するべきではないからだ。どのキーを押せば、どのようなことが起こるかということは、ユーザー自身が決めるべきであり強制されてはいけない。
ホットキーはコマンドであり、表示やリアクションはフックと考えられる。そして何かしらの処理というのは関数であり、関数には名前が付けられていて、それが何をする関数なのかというのは、その関数の定義の近くに文書化されている。ユーザーは自分がどんなことがしたいのかを知っている。だから、そこから類推して関数に辿りつき、その関数を直接呼び出せるようなインターフェースが必要ということになる。Emacsには execute-extended-command があり、通常 M-x にバインドされている。Blenderにも完全ではないが同様のインターフェースがあり、スペースキーを押すと機能を呼び出すためのUIが表示され、機能名を入力することでそれを呼び出せる。機能を指定して呼び出したり、関数を上書きすることで表示を変更できるようにすることと、ホットキーへのバインドの仕組みを提供できればよい。これは私が考えた1つの答えだが、それらをフロントエンドに実装することは、それほど難しくないように思う。
操作テストを行う人は、そのシステムのヘビーユーザーと考えることもできる。当然、人それぞれの工夫があるし、その工夫を取り込めるほうが効率が上がる。だからどうか自動テストとか、ツールとか、そういう小手先の事を考える前に、独りよがりな「僕が考えた最強のUX」にならないように、フロントエンドの操作性の向上についてしっかり考えた方が良い。