図１: GNOME タスクバーの代替案
EmptyPage.jp > Translations > 使える GUI デザイン > 即席 FAQ
2005年7月30日
Benjamin Roe さんの、Usable GUI Design: A Quick Guide for F/OSS Developers（拙訳「使える GUI デザイン」）の FAQ、Usable GUI Design: A Quick FAQ の M.Shibata による日本語訳です。
フリー／オープンソース・ソフトウェアのユーザビリティの問題を扱ったわたし (Roe) の記事は、多くの人の関心を呼ぶところとなり、読者からは数多くの興味深い指摘がなされることとなりました。それらのうちで重要なものについて、ここにわたしからの答えを添えてまとめておきました。
これについては、ある程度はあの記事でも論じたところです。記事の主張の多くを裏付ける証拠が実在していたとしても、多くのフリー／オープンソース・ソフトウェアのプロジェクトには詳細なユーザビリティ・テストを行なうだけの時間も資金も人材もありません。わたしだって、50 人のユーザーを座らせて SiEd（訳注: 著者が開発している Palm OS 向けのオープンソースのテキストエディタ）を使ってもらってるところを録画するなんてことはできないのです。わたしがいいたかったのは、だからといってそのことを理由にしてユーザビリティの問題をあきらめてはいけないんだということです。そのことが、ユーザーの予測される振る舞いを合理的で洗練されたものにしようとすることの妨げになってはいけないのです。経験から確証が得られたのであれば、それはもちろん活かされるべきですし、ユーザーからそうした確証を得る努力をわたしたちは惜しむべきではありません。
初版時の“OpenOffice 設定健忘症”の例は、わたしが OpenOffice の正しいインストール方法についてよくわかっていなかったせいでした。そこを Anjuta の例に置き換えたのはそれが理由です。GNOME のタスクバーの例については、ひときわ混乱を招いたようでした。わたしが考えていたのは図１のようなもので、これならこちらで余計なことをしなくても異なるタスクがはっきりとわかります。あそこであげた例は、あくまで論点を図示するためのものにすぎません。
図１: GNOME タスクバーの代替案
たくさんの人たちから、Konqueror はウェブ・ブラウザであると同時にファイル・マネージャでもあり、ツールバーのレイアウトはファイル・マネージャとして理にかなったものなのであるという指摘を受けました。まあそれはそうかもしれません。しかし、それで Konqueror は使いやすくなっているのかというと、必ずしもそうとはいえませんよね？ ウェブ・ブラウザであろうとなかろうと、異なるジョブもこなせるからといってブラウジングはしにくくするべきだということにはなりません。ファイル管理かウェブ・ブラウジングかによってツールバーのレイアウトを切り替えるというのは簡単なことだと思うのですが。
わたしの Firefox のモックアップがお気に召さなかった人もいるようです。わたしがアーティストとして失格だということはよろこんで認めますが、わたしは自分の主張については間違っていないと考えています。ツールバーのボタンはべつに同じ大きさに揃っている必要はないのです。均整のとれた配置がよく見える場合もあるでしょうが、わたしは多少の見栄えよりは使い勝手のほうを選びます。興味深いこととしては、マイクロソフトは Longhorn の新しい Internet Explorer の［戻る］ボタンをデフォルトでより大きくすることにしました。（追記: その後わたしは現在の Internet Explorer でもそうなっているということ、また Firefox でも同様のことを実現できるということを知りました。わたしは Windows は「バトルフィールド 1942」と「IL-2 シュツルモビク」を遊ぶときしか使わないので、IE はそんなに目にしないのです。）
多くの人が、わたしの Fitt の法則についてのコメントを、すべてのコントロールがスクリーン端に置かれるべきだという意味だと受け取ってしまいました。わたしがいいたかったのはそういうことではありません。わたしは単に大きいコントロールほどクリックしやすいということ、それからスクリーン端に接しているコントロールというのは実効上より大きいとみなせるということを指摘しただけです。このことは多くの証拠にも支えられています。いちばん明らかな例は Mac OS のメニューバーです。これはスクリーンの最上端に置かれていますが、こうなっているほうがアプリケーションごとにメニューバーが付いているよりもすばやく使えるということは間違いありません。スクリーン端の近辺にあるコントロール（ウィンドウの装飾、スクロールバー、そしてメニュー）は、つまりスクリーン端に接していたほうがずっと使いやすいのです。
「僕はウィンドウを最大化なんてしないしね」という意見については、大いに議論の余地があるといわねばなりません。わたしはウィンドウの境界線について話していたわけではありません。ウィンドウマネージャは、最大化していないウィンドウにはボーダーを付け、最大化しているウィンドウには付けないようにするということもありえるからです。わたしがいいたかったのは、アプリケーションの右端とスクロールバーの右端との間のことでした。例として、ここの間隔をゼロにしない GTK のテーマがたくさんあるということです。お望みでなければ、コントロールの外見に変更を加える必要さえありません。最大化時にコントロールがウィンドウの境界上で有効になるようにするだけでいいのです。あなたが個人的に普段ウィンドウを最大化して使うかそうでないかは問題ではありません。そうなっているだけで、使い勝手は大きく向上するのです。
この件ではもうひとつ、ウィンドウの体裁についても瑣末な議論がありました。アプリケーションを閉じるという動作は間違ってやってしまってはまずいことだから、［閉じる］ボタンはスクリーン端にはくっつけずに、押しにくくしておくべきだと考えた人もいたようです。しかし、これはちょっとおかしな指摘だと思います。ひじょうに一般的なアクションを、わざわざやりにくいように設計しようというのはおかしなことです。これについては２点反論ができるでしょう。
［閉じる］ボタンはウィンドウの右上端に位置しているので、マウスを大きく移動させることになります。誤ってそうしてしまうということはそう起こることではありません。上隅にボタンがあるということは、「ウィンドウを閉じる」という動作を、マウスを左上（ないし右上）に放るというきわめて特徴的なものにしています。ボタンを数ピクセル移動させておいたところで、［ファイル］メニューで操作を誤ってしまうなどといった、アプリケーションを閉じてしまうもっとありがちな他のケースの予防措置にはなっていません。記事にあるスクリーンショットの［閉じる］ボタンが［最小化］／［最大化］ボタンの近くには配置されていないことにも注目しましょう。
もしアプリケーションがあの記事の第 5 のポイントにしたがって終了時にその状態を記憶するようになっているのであれば、アプリケーションを終了させてしまったところでそれが一大事にはならないはずです。ユーザーはまたアプリケーションを立ち上げて、終了したところから続きをはじめればいいわけですから。
そうです。そのことはイントロダクションでも述べたとおりです。しかし、それほど単純にして自明のことだというのなら、他の聡明な開発者たちはどうしてこうも頻繁にこれを逸脱してしまうのでしょう？
No! あの記事は、HIGs (Human Interface Guidlines) を補足し、開発者にその分野（ユーザビリティ）についてよりいっそうの研究を奨励しようということで書いたものです。一貫性はユーザーインターフェースの重要な要素です、アプリケーションはユーザーのデスクトップにあるその他の部分から浮いていないよう努力しなければいけません。わたしは、HIG に完全に適合していながら、同時に最悪の使い勝手のアプリケーションというのもありうると考えているのです。インターフェースをデザインするにあたって無視してもよいガイドラインがあるというわけではありません。
あの記事は開発者に UI の問題について考えてもらうための手引きとして書いたものにすぎません。だからページの最初に「手引き」って書いてあるわけです。わたしは論題として５点だけを述べることにしましたが、それは UI デザインというのはそれについて膨大な著作がなされているほどの広範な領域であり、わたしがそのすべてを語るというわけにはいかないからです。何点かについては、いずれもう少し掘り下げた記事を書きたいとは思いますが、それも要点を短くまとめたようなものなるでしょう。
これはいかにもその通りです。しかしながら、それらについてはフリー／オープンソース・ソフトウェアの開発者でできることというのは多くありません。そもそも定義からして、ソースコードが手に入らないわけですから。わたしがフリー／オープンソース・ソフトウェアの開発者を対象に記事を書いたのは、それがもっとも効果的であると思ったからです。記事でも述べたとおり、フリー／オープンソース・ソフトウェアの開発者を中傷しようという意図に基づいたものではありません。単にそれらのプログラムのインターフェースを改善するアイデアを提供したかっただけなのです。
それからまた、じつはこれには下心もあるのです。わたしはフリー／オープンソース・ソフトウェアのソフトウェアを、終日毎日使っているので、その開発者をわたしがいつも使っているアプリケーションのインターフェースの改善に駆り立てることで、最終的には自分の時間を大幅に節約できないかと目論んでいるわけです。
もっともな話です。とはいえ、（わたしにとってはありがたいことに）掲示板ではこういう意見は目立ったものではありませんでした。たしかに、わたしはユーザビリティに関してなにか資格を有しているわけではありません。それどころか、コンピュータについての資格だって持っていません。しかしながら、わたしはそのどちらの領域に関しても広く読み漁ってきましたし、余暇を PalmOS のテキストエディタ、SiEd の開発に費やしてきています。160 ピクセル四方のスクリーンに 256 キロバイトのメモリに低速のプロセッサ、キーボードはおろかカラーのディスプレイすらその存在をあてにできないという環境に向けて開発することは、開発者をインターフェースについてひじょうに注意深く考察させるのです。わたしは SiEd に適切なインターフェースを備えることができたと思います——もちろんつねにさらなる改善の余地はあるものですが。こうしたことから、わたしは自分を技能を持ったアマチュアであると考えています。そしてもしよければ、わたしの助言を参考にしてもらえたらと考えているのです。
This work is licensed under a Creative Commons License and is Copyright Benjamin Roe 2004.
ご意見、ご感想、誤字・誤訳のご指摘等は M.Shibata まで Visitor's Voice よりお寄せください。この HTML のソースには原文がコメントとして埋め込まれていますので、ご指摘の参考にしてください。
誤字や言い回しの訂正などの小さな変更はここに掲載していなくても随時行っています。
Copyright (C) 2004 M.Shibata.
本翻訳は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。オリジナルの著作権は Benjamin Roe にあります。
