GUIかTUIか、開発者がどちらを選ぶべきかという話は、昔から何度も蒸し返されてきました。今回の元記事は、その議論に対して「GUIはマウス前提である必要はない」と強く言い切ります。しかも単に好みの話としてではなく、ユーザー体験の設計としてどう考えるべきかを、かなり実務寄りに語っています。今この話を取り上げる意味は、見た目の新しさより操作のしやすさが軽く扱われがちな中で、GUIの弱点がどこにあるのかをあらためて照らしているからです。
元記事は、Hacker News で話題になった別の投稿から始まります。その投稿は、アプリ開発者に対して、TUI、つまり terminal user interface を増やすのではなく、GUI、graphical user interface に集中するべきだと促していました。この記事の著者は、その投稿が HN の front page に載って活発な議論になったことにも触れつつ、まずは両方の立場に一定の理解を示します。GUI のほうが表現力の面では TUI を包含している、という考え方には理があるし、普段から terminal をよく使う人間としては、できるだけ terminal の中にとどまって済ませられる TUI の便利さもよく分かる、と述べています。
ただし著者は、TUI 側の支持理由として繰り返し出てくる「TUI は keyboard-driven だから優れている」という主張には異を唱えます。ランダムに GUI と TUI のアプリを一つずつ選べば、後者のほうが完全にキーボードだけで使える確率は高いかもしれない。けれど、それは TUI を選ぶ決定打にはならない、というのが著者の見方です。むしろそこで見えてくるのは、多くの GUI アプリで keyboard navigation が不十分だという事実だ、と整理します。著者の言いたいことは単純で、GUI だからキーボード対応が弱くていいわけではない、という点にあります。
ここで著者は、GUI でも完全に keyboard-driven にできるし、TUI と同じくらい、あるいはそれ以上にうまく実現できるはずだと書きます。実際、多くの GUI framework のガイドラインは、アプリのすべての機能に keyboard からアクセスできるべきだと明言しているそうです。例として GNOME Human Interface Guidelines を挙げ、ポインティングデバイスでできることはすべて keyboard でも実行できるべきだし、UI のどこへでも keyboard で移動し、操作できるべきだと紹介しています。著者自身もユーザーとして、予測可能で直感的に keyboard だけで GUI を行き来できると、そのアプリを選ぶ理由になると語ります。
さらに著者は開発者の立場に話を移し、自分の最初の GUI アプリである Klisi では、利用可能な操作の広い範囲に keyboard shortcuts を実装するために時間をかけた、と明かします。keyboard navigation は多くのケースでそこまで難しくなく、全体としての user experience を良くする、と断言します。問題は実現可能かどうかではなく、開発者がその気になるかどうかだ、という結論です。最後に著者は、アプリで提供する体験を妥協するな、できるだけ直感的にしろ、そのために full keyboard navigation を軽視すべきではない、と締めています。
この文章で面白いのは、著者が「GUIかTUIか」という二項対立に乗りつつ、争点を少しずらしているところです。本当に言いたいのは、TUI を残すべきかどうかではなく、GUI の側が keyboard accessibility をどこまで真面目に扱うか、という点だと思います。ここは重要で、TUI を好む人の中には「キーボード操作が気持ちいいから」という感覚を持つ人が少なくありません。でもその快適さは、必ずしも terminal という器に由来するわけではない。操作が予測でき、移動先が分かり、毎回同じルールで動くことが気持ちよさの正体です。ならば GUI でもそれは作れるはずだ、という著者の反論はかなり自然です。
私が引っかかるのは、現実の多くの GUI がそこを軽視してきたことです。メニュー、ダイアログ、一覧、設定画面、検索窓。こうした要素は本来 keyboard で一巡できるはずなのに、実際には Tab の順番が崩れていたり、フォーカスがどこにあるか見えにくかったり、ショートカットが限定的だったりします。つまり問題は「GUI では不可能」ではなく、「GUI を作るときに最後まで設計されにくい」ことです。著者が言うように、これは feasibility の問題ではなく will の問題だ、という指摘はかなり痛いところを突いています。機能が足りないのではなく、優先順位が低いのです。
GNOME Human Interface Guidelines の引用も、この文章の芯を支えています。ポインティングデバイスでできることは keyboard でもできるべきだ、というのは、きれいごとに聞こえるかもしれません。でも実際には、これは accessibility の話でもあり、作業効率の話でもあります。マウスを使うほうが速い場面は確かにあるし、著者もそれを否定していません。ただ、ある操作が keyboard でしかたどれない、あるいは mouse でしか届かない状態は、使う人を不必要に縛ります。片手がふさがっている人、細かなポインティングがしにくい人、あるいは単純に keyboard での連続操作に慣れている人にとって、その差はかなり大きいはずです。
ここで大事なのは、keyboard-driven にすることが「上級者向けの便利機能」ではなく、アプリの基本品質に近いという点です。GUI は見た目の自由度が高いぶん、逆に操作経路がばらけやすい。だからこそ、すべての操作を keyboard でなぞれるかどうかを最初から設計に入れておかないと、後から穴を埋めるのが難しくなります。著者が Klisi で keyboard shortcuts を広く入れたという話も、単なる武勇伝ではなく、最初からその方針を持っているかどうかで完成形が変わることを示しているように読めます。
一方で、この主張をそのまま受け取るだけでは少し危ういとも思います。GUI を完全に keyboard-driven にすることと、実際に使いやすいことは同じではありません。ショートカットを増やせば増やすほど良くなるわけでもないし、覚える負担が大きすぎると、かえって初心者を遠ざけます。理想は、マウスでも迷わず使え、慣れれば keyboard で高速に扱える、という二段構えでしょう。著者の記事はその点に深入りしていませんが、現場ではここが一番難しいところです。
また、すべての GUI に同じレベルの keyboard 操作を求めるのも少し乱暴かもしれません。画像編集、地図操作、3D モデリングのように、精密なポインティングが強く効く領域では、mouse や tablet のほうが自然な場面が多いからです。著者自身も、dexterity を得られる mouse が今も preferred、あるいは required な作業があると脚注で認めています。だからこの話は「マウス不要論」ではありません。むしろ、keyboard を後回しにする言い訳をなくそう、という提案に近いと受け止めるべきだと思います。
この文章が実務的なのは、倫理や理想だけで終わらず、開発者の手元に話を戻しているからです。keyboard navigation は user experience の一部であり、そこを整えることは accessibility の向上にもつながるし、ヘビーユーザーの生産性にも直結します。しかも著者は、それが大工事ではないと見ています。ここは重要で、もし実装コストが非常に高いなら、どんなに正しくても採用されにくい。しかし著者は、少なくとも多くのケースではそこまで難しくないと考えている。だからこそ、やらない理由は技術的制約よりも、最初から設計に含めなかったことにある、という指摘になるわけです。
私はこの点にかなり同意します。UI の良し悪しは、派手なアニメーションや新しい見た目より、毎日の小さな操作で決まることが多いです。Tab で移動したときに迷わない、Enter で意図した動作が起きる、Esc で自然に戻れる。こうした地味な一貫性があるだけで、アプリの信頼感は大きく変わります。著者の主張は、その地味さこそが GUI の競争力になる、という話でもある。TUI が得意としてきた快適さを、GUI が本気で取りに行けばいい。そう考えると、この文章は単なる好みの表明ではなく、GUI 開発の標準を少し厳しく見直せという提案として読むのがいちばんしっくりきます。
