Latest topics 近況報告

Firefoxアドオンの開発を通じて考えるようになったインタラクションデザイン - Jun 30, 2011

あかつかだいすけさんのご紹介で、6月27日に慶応大学湘南藤沢キャンパスでインタラクションデザインについての講義を1時間ほどやらせていただきました。その際の発表資料はいつもの通り「高橋メソッド in XUL Returns」で作ったのですが、Remote XULがデフォルトで禁止されるようになったFirefox 4以降だとこれを見るためには色々と面倒が多いので、代わりに講義の内容を思い出しながら資料を引用しながらエントリにまとめてみたいと思います。

事前に伺っていたオーダーは、これまでのアドオン開発の中でUIという点についてどういうデザインポリシーを持って開発してきたのかを、また、コンセプトを実装する際の経験から得られた知見を語るというものでした。今までにもこの場やTwitter等で断片的に語ってきている事ではありますが、改めて整理するいい機会になったと思います。

自己紹介

まず簡単に自分の事をお話ししておきましょう。

僕は大阪出身の28歳で、Firefoxのアドオンとの関わりは「Firefox」というプロダクトが世に出るより前からなので、もうそろそろ10年になろうとしています。アドオンをやり始めた頃は大学1年とか2年とかの頃だったと思いますので、講義を聴いていただいた皆さんくらいの年の頃からということになります。卒業制作（僕のいた学科では卒論ではなく卒業制作、しかも選択制だったのです……）もMozillaの拡張機能で「2次元的にWeb閲覧の履歴を表現する履歴表示UI・兼・Webブラウズ用UI」という物だったので、余計に感慨深い物があります。

そういう僕ではありますが、今はクリアコードという受託開発の会社でプログラマとして勤務しており、最近はRubyでWebサービスを作るといった案件に関わっています。仕事の上でインタラクションデザインの事を考える事は実際の所ほとんどなくて、そういう事を実践する機会趣味のアドオン開発の場面くらいしか無いというのが実情です。（きちんとインタラクションデザインの事について学んでいる人に比べると、おそらく物凄く初歩的な事しか理解していない、本来であれば人前でインタラクションデザインについて一席打っていいような立場ではないとは思っています。）

自分はこの何年かで数だけはやたら多くのアドオンを開発してきましたが、インタラクションデザインという観点から語りやすそうな物として、以下の4つを特に取り上げて語ってみたいと思います。

• ツリー型タブ：タブバーをウィンドウの上ではなく左に移動して、タブを縦に並べて表示し、タブの親子お関係をインデント幅で表現する。
• マルチプルタブハンドラ：複数のタブをドラッグで選択して、まとめて閉じたりリロードしたりと言った操作を可能にする。
• Fox Splitter：Firefoxのウィンドウを複数の表示領域に分割し、複数のページを平行して閲覧できるようにする。
• セカンドサーチ：FirefoxのWeb検索バーにおいて、文字を入力した後で実際に使う検索エンジンを選べるようにする。

自分がUIをデザインする時に気をつけている事

5W1Hで目的をはっきりさせる？

ニュース記事を書く時の5W1Hという原則をご存じでしょうか。

• 誰が（Who）
• いつ（When）
• どこで（Where）
• 何故、何のために（Why）
• 何を（What）
• どのようにしたのか（How）

これらをきちんと抑えた文章にする事で、一体何の記事なのか、どういう事が起こったのか、という事を読者に過不足無く伝えられるという原則が5W1Hです。

僕は、UIのデザインにおいてもこれらの5W1Hが重要だと思っています。

• 誰が（Who）
• どういう利用局面で（When、Where）
• どういう目的で（Why）
• 何を（What）
• どのように操作するのか（How）

これらを満たす事のできるUIを考える、というのが出発点としては分かりやすいのではないか。闇雲に「何か新しいUIを」と考えるよりも、これらを意識した方がゴールを設定しやすいのではないか。という事です。

何事でも目的は大事です。特にソフトウェア開発では、無目的に「単に技術的に可能なので作ってみました」という風に生み出したプロダクトがあっても、自分で使わないし誰も使わないために、そのまま死んだプロジェクトになってしまう恐れがあります。

ただ、それとは逆の場合もあると僕は思っています。「単に技術的に可能なので作ってみました」という物を、試しに自分で使ってみたら案外使い勝手が良かった。常用するためにもっと改良したくなった。というケースが僕には実際にありました。ツリー型タブは、元を正せばそのようにして生まれたアドオンです。

ツリー型タブの誕生の経緯

かつて僕はタブブラウザ拡張（Tabbrowser Extensions、TBE）という、Mozilla SuiteやFirefoxの貧弱なタブブラウズ機能をなんとなくいい感じにパワーアップするというようなオールインワン型のアドオンを開発していました。

その頃既に僕は、10とか20とかの多数のタブを同時に開いてWebを閲覧するという使い方をしていました。そういう使い方だと、通常の横一列のタブバーだと、今見ているタブが画面外に吹っ飛んでしまったり、さっきまで見ていたタブがどこに行ってしまったのか分からなくなったり、という具合に色々困った事が起こります。それで僕は2つの機能をTBEに持たせていました。

• タブバーを多段表示して、1度に多くのタブを見えるようにする。
• タブを色分け表示して、どのタブからどのタブを開いたのかという親子関係を色で示す。

「多段タブ」は、僕がWindows 95を使い始めた頃から時々見かけていたインターフェースでした。Windowsのコントロールパネルで多数の設定項目を持つ項目を開いた場合に、そのダイアログが多段タブになっている場合があったからです。タブが多ければ2段や3段に分けて表示すればいい、というのは日常的に使うWindows自体の一般的なUIを見ていれば自然と思い浮かぶ発想でしょう。

タブの色分け表示は、元々は何か他のブラウザがそういう機能を持っていたのを真似て実装したような記憶があります。親となるタブと子タブとを同じ色で表示しておけば、タブの親子関係が一目で分かるようになります。IE7でもリンクからタブを開くとそれと同じようにタブが色分け表示されるようになっていましたが、当時としては、これもまたそう珍しくない機能だったのでしょう。

そこにツリー表示機能を加えるきっかけになったのは、malaさんが自身のブログで紹介されていたiRiderというIEコンポーネントブラウザでした。

livedoor Readerの開発者として知られるmalaさんは昔からJavaScriptで変態的な、もとい、他の人が思い付いたり実践したりしていなかったような先進的な試みを色々とやっている方なのですが、そのmalaさんが2005年に2005年もパクられてこなかったもの私的まとめベスト3というエントリを書かれていた際に、iRiderというブラウザの名前を挙げておられました。今では配布元のドメインが失効していて百式のエントリにあるスクリーンショットくらいしか様子を窺える物が残っていないのですが、あのmalaさんが（「あの」って付けるくらいに、僕はmalaさんの着眼点はいつも鋭いと考えているのです）名前を挙げているくらいなのだからさぞかし凄い物に違いない！と思ったので、興味本位に加えて腕試しにという思いもあって早速TBEに「タブの親子関係を色分けだけでなくツリー表示というシルエットの変化で示す」という機能、あと、リンク先のエントリでも触れられている「撫でるインターフェース」も併せて実装しました（実はこれが現在のマルチプルタブハンドラの原型だったりもします）。

iRiderのツリー表示というのは、実を言えば、「タブのツリー表示」ではありませんでした。ウィンドウの左に表示されているのはあくまで2次元的に表現されたWebページの閲覧履歴であって、それらの履歴項目をドラッグしたりクリックしたりするとウィンドウの右側でページを見る事ができる、というのがiRiderの挙動です。ただ、当時既にTBEが持っていた「全てのリンクを新しいタブで開く機能」「リンクから開かれたタブを現在のタブの子タブとして扱う機能」にいくつかの機能を加えさえすれば、（メモリの消費量等の観点ではオーバーヘッドはあるものの）表面的にはiRiderと同じような挙動を示すようになるだろうという見通しは立っていました。

ちなみに、タブに相当する物をツリーで表示するブラウザというのは当時既にいくつか存在していたようですが、僕はそれらの事を意識していませんでした。というか、ツリー？　一体何がおいしいの？　みたいな認識でした。そういうわけなので、この時はタブをツリー表示する拡張機能を作ったというよりも、iRiderの挙動をFirefoxで（無理矢理）再現するというのが、やった事の本質を正しく言い表しています。

そういう事でとりあえず技術的には可能だったから実装してみるだけしてみたのですが、タブを履歴の代わりに使うというのは当時の自分にはあまりに違和感が大きすぎましたし、iRiderの「履歴」と違ってMozillaのタブは開いていればその間ずっとメモリを消費する物であるという背景もあって、自分はこの時実装した機能のうち「タブをツリー表示する機能」だけを、せっかく実装したのだから……と、ずっと使い続けていました。

そしたら、これが案外便利だったんですね。

という事で自分自身がすっかりツリー機能に依存するようになってしまいました。その後メンテナンスしきれなくなったために僕はTBEの開発を中止しましたが、まずは「なでるインターフェース」の再現のために書いたコードを応用して、その機能だけを抽出して「タブを選択してから操作する」というコンセプトで再設計したマルチプルタブハンドラを公開し、さらに続いて、タブのツリー表示機能だけを抽出したアドオンをツリー型タブとして公開して、TBEの頃と同じような使い勝手を保ち続けて今に至っています。

自分が「良い」と思えるUIのデザインポリシーを逆算する

タブのツリー表示のどの点が便利だと感じたのか、自分自身でもそれと意識する事はなかったのですが、ツリー型タブをMozilla主催のアドオンコンテストに出品するにあたってアピール文を書こうとして、改めて「自分がツリー表示されたタブを使いやすいと感じた理由」を言語化してみる事にしました。

その時自分で分析して思いついた「使ってみて分かったツリー表示のいい所」は、以下のようなものでした。

• 一覧性が高い。（多数のタブを開いていても、縦に重ねた表示形態であればまだ全体を見通せる。）
• ページを閲覧してきた履歴がそのまま可視化される。（どのタブからどのタブを開いたのか、どのページからどのページへ遷移したのか、という事がツリーとして視覚的に、2次元的に表現される。）
• タブが自分の存在を主張してくる。（ブックマークフォルダの奥にしまい込んだ時のように、存在を忘れてしまわないですむ。未消化のタスクがタブとして溜まっていくと、タブバーをだんだん圧迫してきて、「片付けなきゃ」という意識を僕自身に喚起させる。）

これらをもっと突き詰めて一言にまとめると、「ツリー表示であればうろ覚えでも使える」からこそ自分は利便性を感じたからなのではないか。それが自分の辿り着いた結論でした。

うろ覚えで使える、とはどういう事か。もう少し具体的に考えてみましょう。

1. ボケーッとしてても使える。
   • どこに何があったんだっけ、という事を憶えてなくてもUIを見れば必要な情報がそこにある。
   • 且つ、それらがうるさく主張しすぎてもいないので、多すぎる情報を前にして迷う事がない。
2. 考えなくても使える。さあこれからこのタスクをこなそう！といちいち気張らなくても使える。
3. 初見でも使える。使い方を知らない状態で初めて使う時でも、戸惑わないで済む。
4. 忘れても使える。使い方を忘れてしまって、初めて使う時の感覚に戻ってしまっても、初見と同じようにすぐ慣れる事ができる。
5. 既存の物に似ている。それ自体の使い方を特別に覚えなくても、他の物からの類推で違和感なく使える。

1は、表示される情報が適切な量になっているという事だと言えると思います。2から5は、学習コストが低いという事です。どうやら僕は、これらの点を満たしている時に「良いUI」と感じているみたいです。

適切な情報量とは

この点はSFCでの講義では話せていなかった点ですが、このまとめでは書いておきます。

情報が適切に整理されている、という事は非常に重要です。例えばある家具屋さんの折り込みチラシを見てみましょう。 この種のチラシは「新春初売りセール開催中ですよ！」という事を顧客に告知して集客する事を第1の目的に、そして売り込みたい商品にどういう物があるのかをなるべく多く知らせる事を第2の目的にしていると考えられます。情報を見やすく整理するという事はあまり重視されていないので、余白を設けるよりも、少しでも多く情報を詰め込む工夫が為されています。顧客はこのチラシの中から目を皿のようにして安い商品を探す事になります。セールのチラシの場合は顧客には「そこにどんな情報があるのかをじっくり読み取る努力をするモチベーション」がありますから、多少の苦難は乗り越えられます。

しかしブラウザのUIは、使い手の側にそれほど強いモチベーションはありません。「さっきまで見ていたタブ」を見つけるためにいちいちこのようなゴチャゴチャした絵面の中を一生懸命探すのは、ただのストレスにしかならないでしょう。常用するUIがこんな感じではとても使えません。

視覚的な情報の量を調整するテクニックはいくつかあります。DTPのセオリーやWeb制作のセオリーなどを読んでもらうといいと思いますが、今自分でもぱっと思いつく物としては以下の4項目があります。

1. 適切な余白を設ける。要素と要素を詰め詰めに配置しすぎない。（詰め詰めに配置すると、誤操作の元にもなり得る。）
2. 同じ種類の要素は近くにまとめたり、同じ位置に揃えたりして、グループとして認識できるようにする。
3. 色を整理する。バラバラの色を混在させないで、同じような物は同じような色でまとめておく。そうする事で、特別な場合にだけ色を変えるという事が「特別」として活きてくる。
4. 色ではなくシルエットで判別させる。モノクロディスプレイだったり色盲だったりといった色の違いが分からない状況でも、シルエットの違いなら認識できる。また、一般的に色の違いよりも形の違いの方が人は認識しやすい（とどこかで聞いた気がする）。

ツリー型タブによる縦型タブバーの場合、2から4が特に顕著だと僕は考えています。

スクリーンショットを見ると分かりますが、縦にUI要素が揃う事で、左にアイコン（とインデント）、真ん中にタイトル、右に「タブを閉じる」ボタンが集まっています。 ここにサムネイルというUI要素が加わっても、縦に同じような位置に同じような物が並んでいるので、これはまとめて意識の外に置いておきやすいはずだ、と僕は思っています。実際、自分はこのようなタブバーの左の方を見ている時は右側を無視していますし、右側を見ている時は左側を無視している気がします。

逆に、横置きのタブバーでは、「アイコン、タイトル、クローズボックス、アイコン、タイトル、クローズボックス……」とそれぞれ異なるUI要素が一列に並んでいるので、「アイコンにだけ注目する」とか「クローズボックスにだけ注目する」という事がやりにくいと僕は思っています。

タブの親子関係は、タブの色分けではなく、インデント幅というシルエットの違いで表現されています。これなら、2段階以上のネストであっても状態を正しく把握できるでしょう。

視覚的な情報の整理の仕方はデザインの本を学ぶと色々と情報を得られると思います。自分は一時期Webデザイナーになりたいと考えていたので、DTP的な記事が多く載っていたWebデザイン雑誌も何度か目にしていたのですが、上記のような話はそういった所で仕入れた物のような気がします。

学習コストを低くするためには

ヒューマン・インターフェースのデザインのセオリーという物がいくつかありますが、それらはソフトウェアにおけるインターフェースのデザインにも適用できます。

見た目の工夫

何のための物か、何を表している物なのか、説明がなくても一目で分かるようなデザイン。形がそれ自身の役割を表す。これはUIのデザインでよく言われる事です。

ソフトウェアの場合は、まずそのOSにおける一般的なデザインの流儀に則ってUI要素をデザインしておけば、少なくとも「ここはクリックできる場所なのだな」といった事を伝えられます。その上で適切なアイコン画像を加えましょう。基本はやはり重要です。

見えているUI要素はそのまま使えるようにする、という事も大事です。「見えているのに使えない」「見た目通りには動かない」というのは、ユーザを惑わせるばかりの害悪です。例えば以下のような物は論外でしょう。

• グレイアウトされていないのに、クリックしても何も反応しないボタン。
• グレイアウトされているのに、クリックを受け付けるボタン。
• いかにも押せそうな風に出っ張った視覚的なデザインであるにもかかわらず、ボタンになっていない。

基本的に、人は他の場面で憶えたやり方を別の場面でも使いたくなるものです。タブを掴んで移動できる、という体験をExcelでやった後であれば、Firefoxのタブも掴んで移動できると考えておかしくないでしょう。UIの基本的なルールを統一しておく事の意義はそこにあります。

ですので、奇をてらってワケの分からないUIにするよりも、まずは既存の類似のソフトウェアの挙動に合わせる事、ユーザがこれまでに学習してきた事に反しないようにする事。これをまずは意識しておくのが大事です。AndroidアプリのUIガイドラインなど、各OSで何らかのデザインのガイドが提供されているのであれば、目を通しておいて損はないです。

ツリー型タブも、タブをドラッグ&ドロップした時の挙動はAdobe Illustratorのレイヤーの操作をモデルに整備しました。また、マルチプルタブハンドラも「Ctrl-クリックでタブの選択状態をトグルする」「Shift-クリックで複数のタブを一気に選択する」という、Windowsやなんかで一般的な操作で使えるようにしてます。こういうのも、既存の物に合わせている例ですね。

見た通りに使えるかどうか、という観点で「こりゃあかんわ、好きになれんわ」と自分が最近感じたUIは、以下の2つのアドオンです。

• Tile Tabs
• Tile View

これらはいずれもFox Splitterと同ジャンルのアドオンで、Firefoxのブラウズ領域を複数に分割してそれぞれに別々のページを表示できるようにする物です。

実際インストールして試してみると分かると思いますが、これらはどちらも、ウィンドウの上の方にあるタブバーやナビゲーションツールバーという操作UIが、タイル表示されたWebページの間で共有される設計になっています。下のペインで「戻る」操作をしたければ下のペインにフォーカスしてから上のツールバーの「戻る」ボタンをクリックする、という具合に、操作の対象と操作のために入力UIがバラバラに切り離されてしまっています。

また、タブと対応するWebページとが離れてしまっているのも問題です。どのタブをクリックしたらどのコンテンツ領域がフォーカスされるのか、どのコンテンツ領域をクリックしたらどのタブがフォーカスされるのか、今どのコンテンツ領域にフォーカスが当たっているのか（フォーカスされているコンテンツ領域の周りには枠が表示されますが、背景色によっては枠がとけ込んでしまう）、といった事を、このUIだとぱっと見て判断しにくいです。慣れれば使えるのかもしれませんが、これに慣れたくはないなあ、というのが僕の正直な感想でした。

UIが常時見えている事、表示UIが入力UIでもある事

入力UIが状態の表示のためのUIを兼ねる、というのもUIのデザインでよく言われるセオリーです。

• 音量のボリュームをいじるダイヤルは、回した角度が入力となり、また、ボリュームの角度がそのまま音量を示すインジケータになる。
• ガスコンロのつまみなら、回した角度が入力となり、同時にその角度が火の強さを示すインジケータになる。

ソフトウェアの場合もやはり同じ事が言えます。例えばクリックする度に機能の有効・無効を切り替えるトグル式のツールバーボタン（XULでは<toolbarbutton/>要素）であれば、これはチェックボックス型（<toolbarbutton type="checkbox"/>）としておきましょう。チェックボックス型のツールバーボタンは、1回クリックすると押し下げられたままの見た目で固定され、もう1度クリックすると出っ張った状態に戻ります。これは、入力装置であると同時に、見た目で今の状態を表すインジケータとなります。

ツリー型タブの場合も、タブという元々入力と状態の表示を兼ねたUIであった物を、そのまま少し形を変えて縦に並べています。

使用頻度の高いUIについては、常時見えている事も大事です。クリックしないと出てこない物は、そのワンステップが煩わしくてそのうち使われなくなってしまいます。Firefox 4から標準搭載されているPanoramaもこの問題を抱えていますし、Google Chrome版のTree Style Tab（※作者は僕ではないです）も、Chromeの拡張機能向けAPIの仕様上の制限でそのようになってしまっています。パネル型でもいいので、これを表示したままの状態に固定できるようにならないと、常用するUIとしてはちょっとキツいと自分は思います。僕が自分でツリー型タブをChrome向けに移植しないのは、この点をクリアする方法がまだないように見えるからという理由もあります。

カーソルを合わせたら自動で出てきて、カーソルを外したら自動で消える、という物は、場合によっては有用です。

• 意図しないタイミングで出てきてしまえばストレスになる。
• 出てきて欲しいのになかなか出てこない（例えば、表示するために1ピクセルの幅の領域の上を正確にポイントしないといけないとか）のもストレスになる。

「自動で隠す」系のUIは、WindowsのタスクバーやGNOMEのGNOMEパネルのような、画面全体の一番端に貼り付くUI以外ではあまり実用的ではないと僕には思えます。（余談ですが、UI要素は大きければ大きいほどそれを操作しやすく、画面の端であればどこでも反応するというボタンやUI要素は「無限の大きさを持っているに等しい」とよく言われます。Windowsでウィンドウを最大化した時に画面の右上にマウスのポインタを移動させてみれば、大雑把に指し示しただけで「閉じる」ボタンがハイライトされる事が分かると思います。）

モーダルよりもモードレス

これは1つ前の話とも少しかぶるのですが、「入力するモード」と「それ以外の操作をするモード」という風な排他的なモード切り替えは、極力避けるべきだというのが僕の考えです。設計を見直して、そもそもモードの切り替えが必要ないようにする、くらいに突き詰めていいと思います。

モーダルなUIは、ユーザの持つメンタルモデルの中にモードの違いがキッチリ組み込まれていればいいのですが、そうでない場合（ユーザのメンタルモデルの構築に失敗している場合）には混乱の元になります。いつもやっている操作を違うモードでやっても何も反応しない。でもユーザは、モードが違うせいでそうなっているという事に気付かない。「違うモードなのでその操作はできませんよ」と警告を出しても、根本的な解決にはなりません。

この観点で僕がどうしても好きになれないソフトウェアの代表例が、viとかvimとかVimperatorとかそのあたりという事になります。vi系のエディタはコマンドモードと編集モードを行き来しながら操作するという設計になっていて、この種のストレスを自分はしょっちゅう感じます。

単機能・明確なコンセプト

これは「UI」というよりも、もっと前の段階のテーマ決めの話になるかも知れません。

「何でもできる」という謳い文句は、「何をすればいいか分からない」という問題と表裏一体です。何をするための物なのかとか、どう使うべき物なのかとか、それを使う事で自分の生活がどう変わるのかとか、そういった事が伝わってこないとユーザは戸惑ってしまいます。先程、視覚的なデザインによって目に飛び込んでくる情報を制限して情報量を抑えるという事を述べましたが、コンセプトの設定にも同じ事が言えます。

「これができる」「これをする物だ」という事がはっきり見えていればいるほど、メリットが見やすくなるのと同時に、どういうデメリットがあるのかも見やすくなります。基本的にアドオンのインストールには多かれ少なかれデメリットがつきまとっていますが、そのデメリットを乗り越えてでも欲しい機能があるのだという人と、そういうデメリットがあるのであれば絶対に使いたくないという人とをきちんとスクリーニングできれば、ユーザを無駄に不幸にさせずに済むというのが僕の考えです。

カスタマイズ性の高い設計にしていたとしても、というか、カスタマイズ性が高い場合にこそ、既定の設定は重要です。第一に想定しているユーザ、この人にまずは使ってもらおうと思っている相手が、違和感なく使えるような設定をデフォルトにしておきましょう。インストールした後必ず自分に合わせた設定の変更を行わなくてはならないのでは、使い始める時の心理的コストが大きくなってしまいますし、そもそも、使う前から「どういう設定が望ましいか」をユーザが判断するというのが土台無理な話です。

また、最近はいろんな機能を1つのUIに統合する事が流行っているような感じがあると思いますが、「何でもできるUI」として1つのUIに2つも3つも機能を詰め込んでしまうと、実際の利用時に却って不便になる事もあります。

Firefoxのロケーションバーと検索バーを統合して「普通の単語を入力したらGoogleで検索して、URLっぽかったらタブを開いて……」という風な「文脈に応じた自動判別」を行うようにしたとして、「google.comという単語を検索したい」という意図をそのUIは正しく受け取れるでしょうか？　文脈の機械的な自動判別には今のところ限界があるので、誤判定、いわゆる「誤爆」の発生はゼロにはできません。

じゃあ考えられる候補をすべて一気に列挙してしまおう、というのも乱暴すぎる話です。入力欄に何か語句が入力されたら、検索結果を3件、その下に過去の履歴で入力とマッチした物を3件表示する、とした場合、ユーザが最初から「過去に見ていたページをもう一度見たくて」その入力を行っていたのであれば、最初に出てくる検索結果3件はただのノイズになってしまいます。ユーザがその時したい事に対して適切な結果が帰ってこないのは、単純にストレスですよね。

ある機能の利用頻度が特に高いのであれば、その機能には専用のUIを割り当ててやった方がいいです。よく使われている物を無理矢理他の物と統合するというのは、信頼性の低い自動判別を無駄に1枚噛ませるだけになったり、メニューを選ぶための手間を無駄に1つ増やすだけになったりという事になると思うので、僕はなるべくそういう事は避けたいと考えています。

Appleは、コンセプトをはっきりさせるという事を非常に強く実践しています。例えばiPodは非常に割り切った設計で「音楽を聴く」事に特化していて、関係ない要素をガンガン省いていました。それによって、「これは音楽を聴く物なのだ」という事が嫌でもユーザに伝わります。Appleの場合はスティーブ・ジョブズが「これがいい」と言った物を会社を挙げて製品にしており、製品の第1顧客はいつもスティーブ・ジョブズだと言えます。また、キングジム社のポメラも、会議の場で商品の企画が出た時にはほとんどの人が反対したけれど、1人だけ「買いたい」と言った人がいたので商品化できてヒットに繋がったといいます。（余談ですが、リンク先の記事によるとその1人というのは慶応大学の印南教授だそうです。何とも奇遇ですね。）

あらゆる人の方向を向こうとして誰の方向も向けないよりも、誰の方向を向いているのかがはっきり分かるようにした方がいい。100人を満足させようとしてみんなに「ふーん、悪くないね。まあ機会があれば試してみるかもね。」って言われて実際にはそのままスルーされてしまうよりも、99人にそっぽを向かれてもたった1人のユーザに「これすごくいい！！」と飛びついてもらえる、その人を確実に満足させられる方がいい。というのが今の自分の考えです。これだけ物や情報が溢れている世の中では、そうやって製品の特色をはっきりさせないと、評価してもらう前の段階で埋没してしまうのではないでしょうか。

これらの点で僕が「駄目だなー」と思っているのが、かつてのTBEやTab Mix Plusといったオールインワン型の多機能アドオンです。メリットを一言で説明しにくいから紹介する側も「とりあえずこれ入れとけ」という風な言い方にならざるを得ず、紹介された側はどこが具体的にどう変わるのか・どのようなデメリットがあるのかをきちんと把握できず、それのせいでトラブルが起こったとしても「何をするためのアドオンを入れたからこうなった」という事が全く分からないから原因を切り分ける事もできず、という負の連鎖が起こってしまいます。

先に入力を受け付けておいて、どうするかは後で選べるようにする。思考を途切れさせない。

僕が持ってる携帯電話は、待ち受け状態で数字をぽちぽち入力すると、その数字を電話番号として電話をかける以外にも、電卓機能を起動したり、積算メモ（簡易家計簿）に記入したり、という風な事ができます。メニューから「電卓」を起動して数値を入力するのでも、積算メモ機能を起動してから金額を入力するのでもなく、数字をぽちぽち入力したら画面の中で「この数字を電卓に流し込みたい時はこっちのボタンを押す」「この数字を積算メモに記録したい時はこっちのボタンを押す」という誘導が行われるんですね。

僕はどうも、そういうUIが好きみたいです。セカンドサーチは、Web検索バーで文字を入力した時に「既定の検索エンジンで検索するの？　Amazonで検索するの？　それとも英和辞書？」という具合に利用できる検索エンジンをポップアップで列挙して、文字入力からそのままスムーズに検索エンジンの選択に移れるようにする……というアドオンですが、前述の携帯電話のUIと考え方は共通していると思います。（なお、僕がセカンドサーチを作ったのはこの携帯電話を使い始めるよりずっと前でした。）

思い返してみると、セカンドサーチを作った動機は、「検索エンジンを選んでから検索して、また元のGoogleに戻して、という操作が死ぬほどめんどくさい。やってらんない。」という不満からでした。

エンジンを切り替えるのが面倒だから、大抵既定の検索エンジンで済ませちゃう。たまに検索エンジンを切り替えて使うと、その後無意識のうちに既定のGoogleで検索したくなって、しかし検索エンジンを切り替えたという事実をすっかり忘れていて、うっかり別の検索エンジンで検索してしまう。そういうのが鬱陶しくて、僕は結局Googleしか使わなくなってしまいました。でも、せっかくOpenSearchとかで検索エンジンを追加登録できても、それらを使う機会が全く訪れないなんて、こんな勿体ない事があっていいはずがない。そう思って、「先に検索エンジンを選ぶのと、後で元に戻すのがめんどくさいんだ」と判断して、「後から検索エンジンを選べて、既定の検索エンジンに戻す必要がない」という操作ができるようにしてみたんですね。

こういう傍目から見てアホとしか思えない行動を取ってしまう人はけっこういるんです。Web検索バーに文字を入力する時には、入力しようと思っている語句に注意がいっているから、「どの検索エンジンが選択されてるか」という事に注意が向かないんですね。そういう風な思考ができあがっている時に、期待通りの結果が得られないと、「なんでやねん」とストレスを感じてしまうわけです。

そういうミスに対して「それはあんたの使い方が悪いんだ」と責める人もいるでしょうけど、道具は使う人のためにデザインされるべき物と考える限りにおいては、人がそういう行動を取ってしまうのなら、その行動に合わせて道具をデザインした方がいいと僕は思っています。

ユーザの行動や入力をトリガーにする

1つ前の話を別の観点からもう1回語ってみます。

金額の事だけで頭がいっぱいになっていて、とりあえず無意識に数字を入力し始めてしまう、という僕の行動をトリガーにして、僕の携帯電話はよさげな機能をサジェストしてくれるわけです。同じようにセカンドサーチも、頭の中が調べたい単語の事でいっぱいになっていてとりあえず無意識に単語だけ入力してしまうという僕の行動をトリガーにして、適切な検索エンジンを後から選べるようにサジェストしてくれます。このように、無意識の行動を起点にして各機能を呼び出せるようになっていると、「機能をどこから呼び出すのか」を改めて考えなくて済みます。

機能をどこから呼び出すのか、というのは結構重要な問題です。

メニューを何階層も辿った奥にある機能というのは使うのが億劫なので、だんだん使わなくなってしまいます。しかし、だからといって階層の浅い所にメニュー項目を増やしていったり、ツールバーのボタンをどんどん増やしていくと、機能が増えていった時に収拾が付かなくなってしまいます。

WindowsのコマンドプロンプトやLinuxやMac OS Xのターミナル（端末エミュレータ）のようにコマンドを入力させる形式なら表示領域を悔いませんが、今度は、ユーザが「どんなコマンドが使えるのか」という事を常に頭の中に入れておかないといけないようになってしまいます。コマンドだけじゃなく、今どこのディレクトリにいるのかとか、ログインしているユーザが誰なのかとか、いろんな「モード」を把握してないと使えません。僕はそんなの全部は覚えてられないので、CUIでコマンドライン入力というのは基本的に好きじゃないです。

表示領域も食わないし文字列のコマンド入力よりも直感的、という事でマウスジェスチャ（リンクをドラッグしたままマウスを上下左右に動かすと、その軌跡（ジェスチャ）がコマンドとして解釈される機能）はどうなんだ？　っていう話になってきますけど、マウスジェスチャも「ジェスチャを覚えないといけない」という問題はやっぱりあります。上上下下左右……みたいなややこしいジェスチャを全部覚えてられるかというと、まあ無理な話です。実際、マウスジェスチャを使ってる人でも「憶えてるのは上下左右の各方向にマウスを動かす単純な動き程度でそれより複雑な物は全然使わない」と言ってました。

という話の中にも出てきていますが、ごく簡単なジェスチャだったらアリだと言えます。リンクを引っ掴んで適当にぽいっと投げたらそれをタブで開く、とか、その程度の大雑把さなら苦になりません。ただ、この場合は「ジェスチャを入力している」と言うよりも、「リンクというオブジェクトを掴んで何かしようとしている」という場面だと解釈した方が正しいでしょう。

僕が「ユーザの入力をトリガーにする」という言葉で表現したかったのはそういう事です。何かキー入力を始めたとか、何かオブジェクトがドラッグされたとか、そういう行為そのものをトリガーにするっていう事であって、「どういう文字が入力されたのか」とか「どういう風にマウスを動かしたのか」とかの細かい所を情報として使うという話ではないんです。もちろん、入力された内容にそぐわない機能を除外した上でサジェストする（例えば数字だけが入力されていたら英和辞書は候補に出さないとかの）工夫はあってもいいと思いますが。

「冷蔵庫に卵とトマトがある事を確認して、それからクックパッドで卵とトマトを使ったレシピを探そう」という風な理路整然とした行動計画を、現状から目指すゴールまでを最初から完全にきちんとイメージできる人ばかりではないんです。というか僕自身がそういう事ができない方なんですね。おなかすいてとりあえず冷蔵庫を開けてみたとか、そういう無駄な事をやってしまう方です。

そういう最初のアクションを無意識レベルで起こした結果、機能がサジェストされたり視覚的なフィードバックがあったりして、そこからさらに「そういえば自分はこういうことをしたいんだった」と次の行動が喚起される。（もっと言うと、その時の既定の挙動が一番利用頻度の高い物になっている。）という風な誘導がウザくないレベルで働くようなUIが、僕にとっての「良いUI」なんでしょうね。

ブラウザのUIはゲームのUIではない

ちょっと話はズレますが、ストリートファイターとかの対戦格闘ゲームを考えてみましょう。この種のゲームは、技を出すための複雑なコマンドを覚えたり、覚えたコマンドを適切なタイミングで正確に入力できるようになったり、という努力の末の「上達」が「勝利（報酬）」に結び付くというゲームのデザインになっています。勝てるようになれたら嬉しくて、負ければ悔しくて、なのでみんな必死になってコマンドを覚えるし、正確に入力できるようになろうとする、そういうモチベーションがある。

翻ってブラウザのUIという物を考えてみると、誰が好きこのんで複雑なコマンドを覚えたくなるの？　ブラウザを上手く使えるようになる努力をして、上達して、それのどこが嬉しいの？　って話なんですよ。普通のユーザにとって、ブラウザとかUIとかってそんな努力を費やす対象ではないです。勉強しないとまともに使えない斬新な文房具とか包丁とか、使いたくなりますか？　なりませんよね。普通の人にとってのブラウザって、そういうレベルの物でしかない。

UIをデザインするんだ！って思って頑張る時に勘違いしてしまいやすいのはそこなんですよね。こんだけ頑張って斬新なUIを考えました、他に類を見ないUIになりました、ただし使うのにはそれなりに慣れが必要です、っていって作った物をユーザに見せても相手にされないですよ。そんなの作り手の自己満足でしかない。自分にとって物作りそれ自体が楽しくなってきた頃に犯しがちなミスです。

実用品のUIと、娯楽だったり趣味の物だったりのUIとは、別の物として考えて欲しいです。日常的な利用にゲーム性を加えてみましたとか、普段の利用がちょっと楽しくなりますとか、たまにありますけど、それで本来の用途に支障をきたしたりストレスが増したりするようになってしまっては本末転倒です。

自分の部屋とかキッチンとか

自分が生活する部屋や、日常的に使うキッチンの事を考えてみて下さい。

• よく使うものは奥にしまわない。流しの下を開けたらすぐそこに包丁があるとか、毎日使う茶碗は引き出しの手前に入れておくとか、そういう風に自然となってる。逆に、奥の方にしまい込んだ鍋とかは、出すのが面倒でほとんど使わないという事も結構ある。
• どこに何があるか、自分にとって分かりやすいような配置に落ち着いてるはず。
• どこに何を置いたか、だいたいは把握できている。こういうことをしよう、と思った時にどこに手を伸ばせばいいかは無意識に判断できる。

ソフトウェアのUIも基本は同じだと思います。

よく使うものを手前に置くとかの話はここまでで述べた話に通じています。ここで新しく述べたいのは、「どこに何を置いたかだいたい把握してるはず」という部分です。

ロケーションバーと検索バーの統合という風に、最近は（主に表示領域を広く取るために）複数のUIを1つにまとめる風潮があるみたいなんですが、そうすると使う時に余計なステップが増えてしまいかねないというデメリットがあります。UIをどんどんまとめていくという事に固執しないで、時にはUIを分けるという判断も必要だと僕は思っています。「使い方を頑張って覚えなきゃいけない様なUIは駄目だ」という風な事を前述しましたが、並んでる物を使い分ける程度の事は大抵の人にはできるはずです。あんまりユーザをなめんなよ、ということですね。URLを入力したい時にはロケーションバーをクリックして、検索したい時は検索バーをクリックして、という事をユーザが無意識にできるのであれば、そこはUIの設計に組み込んで活かしてもいいはずです。

あと、キッチンに例えるついでに言うと、キッチンを清潔に保った方がいいのと同じでソースコードも清潔にした方がいいです。詳しくは実装の話で述べますが、生ゴミを放っておくと腐って虫が湧くように、汚いソースコードも放置すればバグの温床になりますので。

人は自分の行動パターンを変えようとしないという事

一般的に言って、フツーの人は「どうしても必要だ！」という強烈な動機がない限りは新しい物の使い方を積極的には覚えようとしませんし、いつも取っている行動のパターンも変えたがりません。というか、無意識のうちに同じ行動を取ってしまいます。そこから意識して外れようとすると、これはストレスになります。何度も述べていますが、「素晴らしいUIを作ったから、ユーザは使い方を覚えるために苦労してくれるはずだ」というのは作り手の傲慢なんですね。そんな物は、そのうち使われなくなってしまうのがオチです。

ただ、あんまり人間の順応性をナメすぎてもいけません。最初は違和感があった「いつもと違う行動パターン」でも、そのうち慣れちゃうというのは結構あります。そこを考慮から外してしまうと、常用するのがウザいUI（例えば、いつまで経っても毎回馬鹿丁寧に「どうしますか？」と聞いてくるような）になってしまいます。

• 今まで慣れ親しんできたものと同じ要領で使えるようにする。
• 同じ要領では使えないものでも、なるべく早く慣れる事ができるようにする。
• 慣れてしまった人に余計なストレスを与えないようにする。

これが大事なんだ、「どこまで丁寧にやってどこからはユーザの慣れに期待するか」のバランス感覚が必要だ、と僕は思っています。

この観点から、僕はKDEでのファイルのドラッグ＆ドロップの操作は「馬鹿丁寧すぎ」の方に入るのかなーと思っています。Linuxのデスクトップ環境の1つであるKDEでは、ファイルを別の位置にマウスの左ボタンでドラッグ＆ドロップすると、必ずメニューが出てきて「コピー」「移動」みたいなその時可能な操作を選べるようになっています。これ、最初はいいなって僕自身思ってたんですが、使ってるとだんだんうざく感じるようになってしまいました。「上の階層のフォルダにドロップしたんだから、コピーじゃなくて移動したいに決まっとるがな！」「新しくフォルダ作ってそこにドロップしたんだから、移動したいに決まっとるがな！」と、自分の場合は少なくとも、ファイルのドラッグ＆ドロップは「移動」のためにやる場合が圧倒的に多かったんですね。それなのに毎回「コピーですか？　移動ですか？」って訊かれる。これがそんなにストレスになるとは、実際使い続けてみるまで僕には分かりませんでした。

なので、セカンドサーチは何も検索エンジンを選ばなければ既定の検索エンジンで検索しますし、マルチプルタブハンドラも、「グッ」と押し込む感じで敢えて長くタブの上でボタンを押し続けない限りはタブの選択操作が始まらないようになっています（このタブ選択操作の挙動はユーザからの提案で実装したものですが、採用して大正解だったと思ってます）。

ユーザの「言う事」に振り回されない・惑わされない

「ユーザからの提案を取り入れて正解だった」と書いた直後に述べるのも何ですが、ユーザの提案を何でもかんでも呑んでしまうのは避けた方がいいと僕は思ってます。

ユーザは基本的に自分の不満を素直に言ってくるもので、その提案を取り込んだ結果他のユーザにどういう影響があるかとか、実装がどう変わるかとか、そんな事までは考えてないと思っていいと思います。そういう提案をどんどん取り込んでしまうと、最初に定めたはずの「これは何をするためのソフトウェアだ」というゴール設定がブレてしまう事にもなりかねません。なので、僕はユーザからの提案に対しては、最初に決めたコンセプトに沿っているか・既存の物を壊してしまわないかという事をなるべく考えて、折り合いが付かなければ「それは取り込めない」と回答するようにしています。

タブブラウズの機能を何でもかんでも拡張するTBEというアドオンを作っていた時は、僕はわりと何でも提案を取り込んでしまってましたが、その結果どうなったかというと、ソフトウェアが肥大化するわUIが複雑化するわコードがごちゃごちゃになるわで散々でした。これは、当時の僕が名誉欲だとか人に感謝されたい欲だとかに突き動かされていたからという理由だけでなく、ソフトウェアのコンセプトが曖昧だったので、何を入れて何を外せばいいのかという判断がそもそもできなかったせいでもあるんじゃないかと、今では思ってます。

コンセプトがはっきりしていると、寄せられた意見を取捨選択しやすいです。意見を退ける時も、「それはコンセプトに合わないから」とはっきり言える。好き嫌いだとか意地悪だとかで言ってるんじゃないという、ある意味では言い訳を自分に対してできるんですね。八方美人タイプだと人の頼みを断る事自体がストレスになってしまいますが、こうすれば罪悪感を感じなくて済みます。

ということでNOと言う事の大事さを散々説いたのですが、かといって頑なになりすぎるのも良くないです。ユーザ1人だけが言ってきているのならまだしも、同じ要望・不満が別々のユーザ10人から飛んでくるようだと、これはユーザの使い方ではなくてUIの方が（ひょっとしたらコンセプトも）悪いという可能性を疑った方がいいでしょう。「なんでみんな理解してくれないんだ、こんなに素晴らしい物なのに！！」という思い上がりに囚われてしまってはいけません。

あと、意見を取り入れる時も、取り入れ方は工夫する必要があると思います。例えば「ここにこういうボタンが欲しい」という要望が来た時に、本当にそのまま言われた通りにボタンを追加する前に、なんでそこにボタンが欲しくなったんだろうかという事を考えるという事です。そこで考えた結果、やっぱりボタンを追加した方がいいという結論に辿り着くかも知れませんが、ボタンを追加しなくても別の方法で解決できるという事が分かるかも知れませんし、コンセプトの見直しを図るきっかけになるかも知れません。

余談ですが、Microsoftは製品を開発する時に、ユーザの言葉を聞くんじゃなくて、ユーザがその製品をどう使おうとしたかという様子を観察して製品にフィードバックするという事をやっている、という話を以前にどこかで読みました。ユーザ自身が自分の要望や不満を100％正しく言語化できるわけではない、ユーザ自身が気付いていない問題や視点があるのかも知れない、恥ずかしくて嘘をついているかも知れない、だから行動を見る……という話だったと思います。

Microsoftと同じ事をやるにはお金も手間もかかるのでそのままマネするのは難しいですが、そういう考え方は持っておいていいと思います。

セオリー

僕がここで述べた事は、多分UIのデザインのセオリーと言われるような事ばかりです。名前を挙げた自作のアドオンも、最初からそういう理屈を考えて作ったというよりも、試行錯誤してるうちに辿り着いた結果を後から分析してみたら案外セオリーに則っていた、という感じです。もっとちゃんと体系立ててUIのデザインの理論を勉強してから臨んでいたら、もっと少ない労力で答えに辿り着けたのかも知れないなあと思っています。

セオリーにはセオリーと呼ばれるだけの理由がちゃんとあると思いますので、我流で突っ走る前に一応は基本を抑えておくといいんじゃないでしょうか。

実装上の工夫やテクニック、コンセプトを具現化する時の注意点

プログラムとしての作りやすさに引きずられない

人にやさしい・使いやすいUIを実現するためには、プログラムとしては複雑な物になってしまいがちです。逆に、プログラムとして簡単な物にしようと思うと、エンドユーザにとっての使いやすさが犠牲になってしまいがちです。

「Now Loading…」系の物なんかは、その代表例ですよね。プログラムを作る側としては、必要なデータが全部揃うまで待ってから最後に一気に処理した方が、コードとしてはシンプルに書けます。しかし、これではエンドユーザは待たされている間何もできません。今では考えられない事でしょうが、昔のブラウザもまさにそういう設計でした。ページの内容を全部インターネット経由でダウンロードしてくるまで、ページの描画をしてくれなかったのです。

今のブラウザはそんなことは無いですよね。読み込みが少しずつ進行するに従って、ダイナミックに表示を更新して、現在までに読み込みが完了した部分から順次表示してくれます。多少作るのが面倒であっても、こういう風な設計を心がける事はとても大事だと思います。

ただ、そのようにユーザにとっての使いやすさを追求するために、プログラムとしてのコードの綺麗さを犠牲にしすぎるのも良くないです。コードの見通しが悪くなってしまうと、いざ挙動がおかしい所を見つけたとしても、どこをどのように直せば良いのか見当が付かなかったり、ある所を変更したせいで別の所に意図しない影響が発生してしまったりするため、それ以上コードに変更を加えられない（ちょっとでも変更したらぶっ壊れてしまう）、みたいな事になってしまいます。

ユーザにとっての使いやすさを大事にする事と、プログラムとしての見通しの良さを高く保ってメンテナンスしやすくしておく事は、頑張り次第で両立できます。そのためのノウハウを、ここで少しだけご紹介しようと思います。

Firefoxのアドオン開発における、避けるべきパターン

Firefoxのアドオン開発では、XMLとJavaScriptの組み合わせで「要素の振る舞い」を定義しておくXBLという技術によって「独自のタグ」のようなものを定義できます。しかし、メンテナンス性を高く保つという観点からは、XBLの利用はあまりお勧めできません。使い所をわきまえればXBLはそれなりに便利な技術ではあるのですが、「Firefoxのアドオン」の開発においては、便利さよりもデメリットの方が大きいと僕は思っています。

実際、僕は上述したアドオン「Fox Splitter」の旧バージョンをXBLを多用して開発してきましたが、XBLのせいで全体として見通しが悪くなってしまっていたり、開発時の構成に強く依存したコードがJavaScriptとXBLに散らばっていたせいで調べなければいけないコードの範囲が無駄に広がってしまったりしていたせいで、ドツボにハマってもはや自力ではメンテナンスできなくなってしまい、1年半もの間完全に放置することになってしまいました。

前述した話ともかぶりますが、不必要な多機能化も避けた方がいいです。ある機能Aと別の機能Bとで共通の処理があるから、AとBと共通の処理を1つのアドオンにまとめておこう、という風な考えに至るのはごく自然な発想だと思いますが、しかしAとBがそれぞれ全然関係の無い機能なのであれば、共通の処理を2回書く事になったとしても、AとBは別々のアドオンとして分けて開発する事を僕は強くお勧めします。

今はAとBで共通の処理を使っているとしても、Aの機能とBの機能のそれぞれのコンセプトを突き詰めていくと、共通の処理にできる部分はほとんどなくなってしまうかもしれません。にもかかわらず、「AとBとそれらの共通部分」という構成のコードがあると、この構成を維持する事に発想が囚われてしまって、AもBもコンセプト的に中途半端なままになってしまうのではないでしょうか。別々のアドオンに分けて開発していれば、そういう風に今ある実装に引きずられないで、コンセプトを突き詰めた開発をしやすいと僕は思っています。

他に思いつく事としては、ありきたりですが、プログラミングにおいて一般的なアンチパターン（これはマネしちゃいけない、という反面教師的なパターン）を避ける事がやはり大事だと思います。

例えば、1つのクラスに2つも3つも関係のない機能をまとめてしまうと、これは先ほど述べた「アドオンの多機能化」と同じような問題に繋がりかねません。それを避けるには、個々のクラスの実装が受け持つ機能の範囲を定める形で、実装を適切な粒度に分けておく事が大事です。

また、3項演算子や、論理演算子の優先順位を逆手に取ったプログラミングなどのトリッキーな書き方も、あまり多用するべきではないです。トリッキーなコードは芸術的で見ていて美しいものですが、あまりに芸術的すぎるコードは、非常に限定された条件下でしか正しく動かず、手を少し加えただけで動かなくなってしまう事もあったりして、その後の機能拡張やメンテナンスに対して脆弱になってしまいます。芸術品を作るのではなくて、実用品を作ろうとしているのだ、という事を常に念頭に置いておく事を僕はお勧めしたいです。

1年後の自分が読んでも意味が分かるようなコードにする事を心がける

1つのプログラムを1人で集中して開発している時は、プログラムの全体像が頭に入っていますから、多少読みにくいコードでも開発する事ができます。

しかし、誰かに手伝ってもらうとしたらどうでしょうか。あるいは、1年間そのプログラムの事を全く考えずにいて、1年後に急に開発を再開する事になったとしたら（1年後の自分なんて、はっきり言って他人も同然です）。読みにくいコードになっていると、「この関数は何のための物なんだろう……」とか「なんでこんな設計になっているんだろう……」といった感じで、全体像を把握できなくて何も手出しできなくなってしまいます。また、そういう状態で不用意に既存のコードを書き換えると、思わぬ副作用が発生して、今まで動いていたものが全く動かなくなってしまうかも知れません。これでは開発になりません。

前述した「1つのクラスに2つも3つも機能が入ってしまっているコード」や「あまりに芸術的すぎるコード」も、そういう問題を引き起こしがちです。そういった問題を避けるための、「1年後の自分が読んでも分かるようなコードにするテクニック」をいくつか紹介しましょう。

変数名やメソッド名、クラス名を分かりやすくする

変数やメソッド、クラスの名前は、それが何を表しているのか・何をするための物なのかをきちんと表す物にしましょう。例えば以下のようなコードは最悪ですね。

var bool = true; // 変数名が「真偽値である事」だけしか表していない

function f() { ... } // 関数に適切な名前が付いていない

これは、以下のような書き方をした方がいいです。（これはあくまで例です。表す内容がこれとは違う場面であれば、その都度適切な名前を付けましょう。）

var enabled = true; // 変数名から「何かの機能が有効か無効かを示すものだ」という事が分かる

function openTabAndInitialize() { ... } // 関数名が処理の内容を表している

ただ、名前に動詞や形容詞、前置詞などが2つも3つも入ってくるようだと、いくら処理の内容をきちんと言い表していても駄目です。関数や変数に簡潔明瞭な名前を付けられないのは、そもそも設計が悪いからと考えられます。きちんと設計してあれば、関数や変数には大抵の場合、ちゃんと簡潔明瞭な名前を付けられるのです。ですから、この例のopenTabAndInitialize()だと以下のように設計し直す事になるでしょう。

function openTab() { // 2つの小さな処理単位からなる、1つの大きな処理単位
  var tab = openNewTab();
  initializeTab(tab);
}

function openNewTab() { ... } // 新しいタブを開く、という1つの小さな処理単位

function initializeTab(aTab) { ... } // タブを初期化する、という1つの小さな処理単位

Rubyというプログラミング言語の開発者のMatz氏の言う「名前重要」というスローガンは、この事を指しています。変数や関数に名前を付ける時はちゃんと考えてから付けないと駄目で、名前付けに困る時は設計を見直す事も視野に入れるべき、という事ですね。

データに意味を持たせない。

データを表す時に、配列の1個目の要素が名前で、2個目の要素がデータの数を表して、3個目の要素がアイコンのサイズを表して……という風な作りにしてしまう事があります。

var data = ["foo", 11, 32];

こういうデータの設計はやってはいけません。「何番目のデータがこういう意味である」という風な、データの順番などがそのまま意味を表すような設計だと、順番をいちいち細かく覚えてられませんから、うっかりミスで間違えてしまいやすいです。また、こういうデータの設計だと、データ構造も変えにくいです（最後にどんどん新しい情報を付け足すというような、やっつけ仕事の解決策しか取れない）。

こういう物は、連想配列とかハッシュとか言われる形式でデータを表現する方がよいです。

var session = {
      title     : "foo",
      tabsCount : 11,
      size      : 32
    };

連想配列やハッシュであれば、ハッシュのキーがその値の意味を表すメタ情報になります。

引数の多い関数を作らない

1つ前の話と同じ事なのですが、以下のように関数の引数が3つも4つもあるような関数は作るべきではないです。関数を呼び出す時に、何番目にどの情報を渡せば良いのかを間違えやすくなってしまいます。

function load(uri, title, size,
              referrer, ...)

こういうものは、ハッシュを1つだけ引数に取り、そのハッシュの値が個々のパラメータを表すという設計にしておきましょう。

load({
  title    : "foo",
  uri      : "http://...",
  size     : 32,
  referrer : null
})

このようになっていれば、引数の順番を意識しなくて済みます。

自動テストを作っておく

自動テストとは、ある関数や機能について「どういう呼び出し方をした時に、どういう結果が返ってくるか」という事を確認するためのプログラムです。具体的には、以下のような「テスト関数」が沢山連なったものが「自動テスト」というプログラムになります。

function test_getMessage() {
  // 実装を実際に呼び出してみる
  var result = getMessage();
  // 返り値は期待値と一致しているか？
  assert.equal('expected message', result);
}

ある機能Aがあって、そのAに依存するBという機能があって、Bに依存するCという機能がある時に、Cが正しく動かなかったら、さてどこに問題があると考えれば良いでしょうか。Aが壊れているのかも知れないし、Bが壊れているかも知れないし、Cが壊れているのかも知れない、このままだと何が原因なのかは分かりません。

しかし、機能AとBは自動テストでちゃんと期待通りの動作をする事を保証されていて、今まさにCを開発している場面なのだとしたら、これはCに問題がある可能性が高いと言えます。このように、自動テストがある事で複雑なプログラムであっても一歩一歩着実に開発を進められるのです。

また、自動テストは、その関数や機能が期待通りに動くかどうかを検証するものであると同時に、その機能はどのようにして使う物なのか、どういう結果が返ってくる物なのか、といった事の例にもなります。

遅延処理、非同期処理

プログラムは、上から順に1行ずつ読んで処理の流れを把握できるようになっている物ばかりではありません。ユーザの入力を待ってから次の処理を行うとか、読み込みが完了するまでの間別の処理を走らせておいて読み込みが完了したら画面を切り替えるとか、このような「人にやさしい挙動」を実現しようと思うと、上から順に1行ずつ読んだのでは処理の流れを追う事ができないような、分かりにくいコードになってしまう事を避けられません。

Firefoxのアドオン開発の場合は言語はJavaScriptを使う事になりますが、JavaScriptでは非同期処理や遅延処理が関係する場面だとコールバック関数（ある処理を呼び出す際に、その処理が終わった後で実行されるべき処理を関数として定義して渡すという物）を使わざるを得ません。そのような処理を2つも3つも連携させようとすると、コールバック関数を何十にも重ねる事になってしまいがちです。

例えば「新しいウィンドウを開いて、そのウィンドウの読み込みが完了したらコールバック関数を実行する」という例は以下のように書けます。

function openAndWait(aCallback) {
  var win = window.open(...);
  win.addEventListener('load', function() {
    win.removeEventListener('load', arguments.callee, false);
    aCallback(win);
  }, false);
}

これを使って「ウィンドウを1つずつ500ミリ秒おきに順番に3つ開いていく」という処理を書こうとすると、以下のようにコールバック関数をどんどんネストしていかないといけません。

openAndWait(function(aWindow) {
  aWindow.move(...);
  window.setTimeout(function() {
    openAndWait(function(aWindow) {
      aWindow.move(...);
      window.setTimeout(function() {
        openAndWait(function(aWindow) {
          aWindow.move(...);
          ...
        });
      }, 500);
    });
  }, 500);
});

2階層や3階層ならまだしも、これが10階層や20階層も重なると、インデント幅が増えすぎてワケが分からなくなってしまいます。また、開き括弧と閉じ括弧の間に沢山のコードが入るため、コード全体の見通しも悪くなります。

このような問題に対処するための機能が、jQueryにはdeferredという名前で搭載されていますし、同様の機能だけを提供するJSDeferredという軽量なライブラリもあります。ここではJSDeferredの使い方を少しだけ解説したいと思います。

JSDeferred

先の openAndWait() という関数は、ウィンドウの読み込みが終わった後に次の処理としてコールバック関数を実行する物でした。これをJSDeferredを使って書き換えてみた物が、以下の例です。

function openAndWait() {
  // (1) Deferredクラスのインスタンス（Deferredオブジェクト）を作る。
  var deferred = new Deferred();

  var win = window.open(...);
  win.addEventListener('load', function() {
    win.removeEventListener('load', arguments.callee, false);
    // (3) 読み込みが終わったら、返したDeferredオブジェクトの
    //     call()メソッドを呼ぶ。
    deferred.call(win);
  }, false);

  // (2) Deferredオブジェクトを返り値として返す。
  return deferred;
}

このように書き換えた関数は、以下のようにして「次の処理」を記述できるようになります。

openAndWait()
  .next(function(aWindow) {
    aWindow.moveTo(...);
  });

それどころか、さらにその先にもまだまだ「次の処理」を続けて記述できます。

openAndWait()
  .next(function(aWindow) {
    // 読み込みが終わったら実行
    aWindow.moveTo(...);
  })
  .wait(0.5) // 500ミリ秒待つ
  .next(function() {
    // 次のウィンドウを開く
    return openAndWait();
  })
  .next(function(aWindow) {
    // 読み込みが終わったら実行
    aWindow.moveTo();
  })
  .wait(0.5) // 500ミリ秒待つ
  ..

JSDeferredを使うと、何個も処理を重ねる場合でもコード上のネストがあまり深くなりません。また、コールバック関数を重ねる場合と異なり、コードを読む時に上と下を行ったり来たりする必要もありません。コールバック関数を1個目の引数に受け取るのか2個目の引数に受け取るのか、といったインターフェースの違いも意識しなくて済みます（全ての非同期処理を統一的なインターフェースで利用できるようになる、とも言えます）。

詳しい事はJSDeferred開発者のcho45氏自身による解説を読んで下さい。JSDeferredを使いこなせるようになると、表現の幅がぐっと広がります。

先に名前を挙げたアドオンFox Splitterも、JSDeferredに強く依存しています。Fox Splitterは新しいウィンドウを開いて位置や大きさを制御するという事をやっていますが、ウィンドウが開かれるのを待って次の処理に進んだり、ウィンドウの位置が確定するのを待って他のウィンドウの位置を調整したり、といった感じで「前の処理の完了を待ってから次の処理を行う」場面が非常に多いです。僕はJSDeferredのおかげで、そういった処理の前後関係を意識しないで複数の機能と機能を連携できるようになったために、Fox Splitterを無事完成させることができました。

前述した「ユーザの入力を一旦受け取って、入力が完了した後に次に進む」というような事も、JSDeferredを使えば比較的簡単に処理を記述できるでしょう。人にやさしいUIを作る上で、JSDeferredのようなライブラリは非常に役立ちます。

とりあえず作ってみるという事

UIのアイディアを思いついたら、あれこれ計画を練って検討するのもいいですが、さっさと実際にプロトタイプを作ってみることを僕はお勧めしたいです。

コンセプトを形にする事は重要です。形にして実際使ってみて初めて分かる事もあります。プランを練っている時には「素晴らしい」と思っていても、実際使ってみると「アレ？」って事はよくあります。手早くプロトタイプを形にして、コンセプトが正しかったかどうかを初期段階で確認して軌道修正をするのが、後で痛い目を見ないで済むようにするコツです。問題点の発覚が遅れれば遅れるほど、取り返しが付きにくいです。

ブラウザのアドオンは、そういう意味では格好の実験場だと僕は思っています。

これは、大学の卒業制作でMozillaの拡張機能として「こんなUIがあってもいいんじゃないか？」という物を作った時に考えた理屈なのですが、ブラウザのアドオンとしてプロトタイプを作る事にはいくつかのメリットがあります。

• 既にあるソフトウェア資産を流用できる。いちから自分でブラウザを作るのは大変だが、アドオンとして作るのなら、ネットワークの通信だとかそういった部分を考えなくても済む。
• ユーザに使ってもらう時の障壁を低くできる。今まで使ってきたWebブラウザの延長線上として、全く新しい別の物を使い始めるのに比べれば少ない学習コストで使ってもらえる。

Firefoxのアドオンの場合、ソースコードがオープンソースなライセンスで公開されている場合が多いというのもいい所です。分からない所があれば、やりたい事に近い事をやっているソフトウェアのソースコードをそのまま参考資料として参照できますし、ライセンスが定める条件に従ってさえいれば、そのままソースコードを流用する事すらできます。

ちなみに、「オープンソースの物を流用したら、その成果もいきなり全世界に公表しないといけないんでしょ？　それじゃ秘密裏に実験的な事ができないじゃないか」という風に思う人がいるかもしれませんが、それは誤解です。例えばGPLなどのライセンスでは、ソースコードを流用して作ったソフトウェアのユーザに対してソースコードを開示する義務はあっても、ソフトウェアを渡されてもいなければ存在も知らないような人相手にまでソースコードを開示する義務はありません。安心して下さい。

デバイスの進歩について

質疑応答で少し話しましたが、ソフトウェアのUIとハードウェアの進歩は切っても切れない関係にあると思います。

「複雑なマウスジェスチャは覚えられないから使い物にならない、シンプルな動き以外はまともに使えない」という風な事を前述しましたが、MacやiPhone、iPadで可能な2本指・3本指でのジェスチャ（マルチタッチ）は、その制限を乗り越える技術です。指2本を開くような動き（ピンチアウト）で画面の拡大、指2本を閉じるような動き（ピンチイン）で画面の縮小、という風に、簡単でありながら表現力豊かなジェスチャ操作が可能です。これはハードウェア側のサポート無しには成り立たないUIです。

Panoramaはモーダルなせいでいまいち使いづらいですが、これはPCの画面が狭いという現在のデバイスの制約による所が大きいと僕は思っています。もしPCの画面が物凄く広ければ、あるいは、画面の外に空中に映像を投影するような技術があれば、Panoramaはモーダルにしないで常時表示しておけるかもしれません。

今あるハードウェアの限界の中で使いやすいUIを考える事も大切ですが、できない事はやっぱりできないので、そこは潔く諦めてハードウェアの進歩を待つといった判断も必要では無いかと僕は思います。あるいは、ハードウェアの制限に合わせる形でもっと別のUIを考えてみるとか。いずれにしても、今あるハードウェアの上では使いにくいと言わざるを得ない物を「理論的には使いやすいはずなんだ」みたいな感じでごり押しするような事はしないで、柔軟に考えるようにして下さい。

ターゲットユーザを誰にするのかという割り切り

僕の場合は、今は自分自身が第1のターゲットユーザだと考えています。自分自身が常用するものだからこそ、クオリティを維持して快適な状態を保ちたいと思える。というのが今の僕の考えです。

自分以外の人をターゲットユーザに想定するのもありだとは思いますが、僕の場合は既に20を超えるアドオンを開発していて、それぞれにバグ報告が来て修正のためにてんてこ舞いになっているというのが実情で、自分で使う物についてすら十分なメンテナンスをできていない状態にあります。自分自身を第1のターゲットユーザとして考えるというのは、コンセプトをブレさせないための方法論でもありますが、ユーザから寄せられる大量の要望から距離を置いて自分の身（精神）を守るための手段でもあるんですね。

誰をターゲットにする場合であっても、基本的な所はセオリー通りにやる事が大事なのだと僕は思っています。その上で、例えばお年寄りのための物にするなら文字を大きくするとか、使う言葉を平易にするとか、応用を組み合わせていく事になるのだ……と、僕は思っています。

道具を自分に合わせないと我慢できない人と、道具に自分を合わせるのが苦にならない人がいる（11時20分追記）

カスタマイズ性の高いブラウザだからみんなカスタマイズしたくなるかというと、そうとも言えません。統計として、Firefoxのユーザの全員がアドオンを使っている訳ではなく、また、アドオンを使っている人でもインストールしているアドオンの数は片手で数えられる程度である場合がほとんどだというデータが、過去のMozillaの調査で出ていました。カスタマイズ性の高い設計になっている事と、実際にカスタマイズして使われる事とは、あくまで別の事なんですね。（この調査結果は、Firefoxの初期状態が普通の人にそれなりに使いやすい形になっている事の顕れと言えるとも思います。）

僕自身は、ペンタブレット（ペン型の入力装置を使って、ペンで字や絵を描くのと同じ感覚で入力を行えるデバイス）を使う時に、指に当たって痛いなーと思ったらペンの軸に何か巻いてみたりプロテクターのような物を作って付けてみたりと、DIYで「カスタマイズ」して使っています。漫画家の人の中には、ペンの軸が長すぎるからとノコギリでぶった切って使っている人もいるそうです。

でも、そういう風にしない人もいるんですよね。使いやすいと思えるありものの製品を別に探したり、使いにくいから使うのをやめてしまったり。そもそも、自分が使いやすいと思うようにカスタマイズするという発想が無いという人もいるのだと思います。

僕自身、あまり拘りを持っていない分野ではそういう行動を取っている気がします。僕は料理をする事が好きで好きでたまらないという人ではないので、調理器具は買ってきた物をそのまま使っていますし、少々使いにくいと思っても面倒だからそのまま放置しています。カスタマイズしてでも使い続けるかどうかは、「なんでもカスタマイズしたがる性格」の有無以外にも、使いにくさを乗り越えてでもそれを使い続けるに足る動機があるのかどうか、どれだけそれを切実に必要としているのか、という事も影響しているのかもしれません。

そう考えると、カスタマイズ性を高くしておきさえすれば万事オッケーとは言えないのだと思います。僕自身、車や自転車にそれほど強い関心があるわけではないので、「タイヤをこれに替えるともっと快適だよ」と言われても「ふーん、そうなんだ。まあ面倒だから僕はそのまま使い続けますよ。」って思ってしまいますし、そのまま使い続けるのが辛いくらいに合わなければ、カスタマイズを検討する前に他の車や自転車に乗り換えてしまうのではないかと思います。同じように、Webを見る事に対してそれほど切実な動機を持っていない人に「カスタマイズすればもっと使いやすくなるよ」と言っても、「面倒だし別にいいよ」って多分言われてしまうでしょうし、その人が「なんかこれ使いにくい」って言ってる時に「カスタマイズすれば解消できるよ」と言っても、「自分で手を入れなきゃ使いやすくならないの？　そうなんだったらもう最初から使わないでいいや……もっと別の物を探すよ」と言われてしまうと思います。

ほとんどの「ユーザ」はそういう物だ、と僕は考えるようにしています。だからこそ、デフォルト設定を使いやすくした方がいいとか、初見で使えるようにした方がいいとか、そういう事を言ってるんですね。

ブラウザのアドオン、である理由

今プログラマ的にアツい分野というとHTML5とかWebサービスとかクラウドとかっていう話になると思うんですが、僕がWeb開発じゃなくブラウザのアドオンの開発をやり続けてる理由は、インターフェースとして、より人に近い部分で動く物を作れるからなんだと思います。

ユーザの何気ない無意識での入力をトリガーにして適切な次の処理をサジェストするというのは、普通のWebページやWebアプリの枠を超えた部分の話です。サジェストされる選択肢の1つとしてWebサービスに誘導するのはもちろんアリだと思いますが、起点になるのは特定のWebサービスの画面ではなくて、ブラウザのUIだったりスマートフォンのホーム画面だったりという、もっとユーザに近い部分になるはずです。

そこの所への関心が強いから、僕はWebアプリよりもアドオンを作るのが好きなんでしょうね。

Firefox 4のTabs on Topを受け入れられないのは頭が硬直化している証拠 - Jun 28, 2010

タイトルは半分は釣り。

Firefox 4のUIのモックアップでそれが目標として示されて以降、「タブがツールバーの上に表示されるようになる」という変更に対しては色んな人が反対の意を示しているようだ。以下もそのひとつ。

• Mozilla Firefox Thunderbird の拡張あれこれ-MEMO（2010年6月-7）

反対意見があまりに多いためか、Mozillaもわざわざ動画まで用意して Tabs on Topの正当性を必死で主張している。

この件に関して僕は一貫して、タブをツールバーの上に移動するという決定には賛同している。というか、できる事ならもっと前の時点でそうするべきだったと思っている。今の（Firefox 3.6の）UIのデザインを「この方が優れている」という論調で肯定する意見は、ちゃんちゃらおかしいとしか言いようがない。

何故そう言い切れるかというと、今のUIのデザイン（タブがツールバーの下にある）は、言っちゃあ悪いが、実装者の都合に基づくやっつけ仕事の積み重ねの末にある結果でしかないからだ。Firefoxの前身であるPhoenixが出てくるより前、初めてMozilla本体でタブブラウズ機能を実装し始めた頃から見ていたら、それはもうはっきり分かることだ。

そもそもなんでタブがツールバーの下にあったのかと言えば、それまでのタブが無いUI（Netscape Navigator由来）の中にタブを組み込みつつ、他の部分のコードとの互換性を最大限保つために、変更箇所を最小限にとどめる形で実装が行われたからだ。最初のタブブラウズ機能は、それまで「ブラウズ領域」を確保するために用意されていたbrowser要素（iframe要素の高機能版と思って貰えばいい）と入れ換える形でtabbrowser要素という物を置き、タブに関する変更は全部そのtabbrowser要素の中で完結させるという方向性で実装された。それ以後Firefox 3.6に至るまで、根本的な設計はずっと当時の物を引きずってきた。

ここで重要なのは、タブがコンテンツ領域の真上に置かれたこと、ツールバーの下に置かれたことに、ヒューマンインターフェースのデザインの観点からの理由は全く無かったという点だ。理由があってそうしたのではなく、単に「そうするのが実装上簡単だったから」でしかないのだ。

さて、「使いやすい」UIの設計にはいくつかのセオリーがある。

1. 持って欲しい所は持てそうなように、押して欲しい物は押せそうな形に、見た目を作ること。
2. 見た目が現在の状態を示すようにすること。
3. 行う操作と、その結果との関係性を分かりやすくすること。
4. 他の物に合わせること。

まず第一に、望ましい操作、やって欲しい操作にユーザを誘導するような見た目にするということ。例えば、棒のように突き出た部分があれば人はそれを掴んでみようとするだろう。ぽちっと出っ張った部分があれば人はそれを押してみようとするだろう。見た目は人の行動を誘発する。WindowsでもMac OS Xでもなんでも、ボタンが出っ張った見た目をしているのはそのためだ。

第二に、見た目から状態がすぐに分かるようにするということ。ボタンが「押し込まれた」ような見た目をしていれば、それはもうこれ以上押せないと分かる。オブジェクトの影が他の物の上に落ちていれば、そのオブジェクトが他の物よりも上（手前）にあると分かる。Windows VistaでもMac OS Xでもウィンドウに影が落ちているのはそのためだし、Aero Glassで下のウィンドウが透けて見えるのもそのためだ。

第三に、それを操作したら何が起こるかがはっきり分かるようにするということ。包丁を見たら、取っ手を持って振れば刃も一緒に動く事が分かる。ハサミを見たら、取っ手を握れば刃も動く事が分かる。そういう風に構造が見て取れるものでないなら、何らかの方法で「これを触ったらここがこうなりますよ」って事を分かりやすく示さないと行けない。飛行機のコクピットで着陸脚を操作するためのハンドルがまさに着陸脚そのものの形をしているのは、そのためだ。

最後に、既に似たものがあるのならそれに合わせるということ。今まで使っていたものに似ていればそれだけすぐに使えるし、今まで使っていたものと違っていたらそれだけで操作ミスが増える。自動車のブレーキとアクセルの並び順が、ある車種ではブレーキが左・アクセルが右で、別の車種ではブレーキが右・アクセルが左、なんて事になっていたら、これで事故が起きない方がおかしい。

翻って、今（Firefox 3.6）のタブはどうだろう。

タブ単体の見た目は、悪くない。フォアグラウンドのタブとバックグラウンドのタブはそれなりに見分けやすいし、選択されているタブが他のタブより手前にあるように見えるのも悪くない。押せそうな形をしているし、押せばタブが切り替わる。つまめそうな形をしているし、つまめば並べ替えもできる。

でも、「タブを操作したら何が起こるのか」は致命的に分かりにくい。

• タブをクリックしたら、タブの上にあるナビゲーションバーの内容と、タブの下にあるコンテンツ領域の内容が変わる。
• ウィンドウの真ん中あたりにあるタブを閉じる操作をしたら、タブだけでなくウィンドウまで閉じられる。（これなんかは、あまりに酷すぎて僕自身ボロクソに貶しもした。）
• そもそも、タブが開かれたという事に気づきすらしない人もいる。リンクをクリックしたらボタンっぽい物が1個増えた、でもそれが何なのか分からないし、どうして増えたのかも分からない。

タブをツールバーの上に置くのは、「タブを操作したら何が起こるのか」を視覚的にはっきり示すための一番ストレートで確実な方法なんだ。

とはいえ、今Tabs on Topが非難を浴びているのもまた、上に書いたセオリーの通りではある。「他の物、今までの物に合わせる」ということ。比較の対象は「今のFirefox」に他ならない。

「他の物、今までの物に合わせる」、これは他のすべてを覆しかねないほど重要な事だ。なんだかんだ言って、人は自分の行動を変えようとしないし、今の物と違う物には拒絶反応を示す（上に挙げたそれ以外のセオリーは言わば、「今までの物がどうして使いやすかったのか」を分析する事で、「合わせる」先の既存の物が無い時に新しい物をどう設計するかの指針を示したものと言える）。今までの物に合わせないで別の物を提示するという事には、今までの支持を失うリスクがある。新しい物に絶対の自信がなければ、「今の物と違う」という理由でついて来れなくなる人よりも、新しい物の「分かりやすさ」によって引き付ける事のできる人の数の方が多いと信じていなければ、新しい物は取り入れられない。

要するにMozillaは、今までの支持者を失うリスクよりも、新しいUIで取り込める層の方が多いと見込んだという事だ。あるいは、失った支持者すら、新しいUIの分かりやすさによってもう一度取り込め直せるだろうと見込んでいるのだろう。それだけMozillaは新しいUIに自信を持っているのだろう。

ただ、どうしても受け入れられないという人のためにTabs on Topを無効にするオプションも用意しているあたりが、Mozillaらしいと言えばらしい譲歩ではある。例えばジョブズあたりはこの辺もっと割り切っていて、新しい物を出したら古い物はバッサリ捨てるという風に容赦がない（iMacでのレガシーインターフェース一掃やiPadの有線LAN非対応などはそのいい例だろう）。

まとめよう。

不幸な事にMozillaは、それまであまり知られていなかった「タブブラウズ」という概念を取り入れるにあたって、UI設計のセオリーをまるで無視した実装上の都合からタブブラウズのUIを作ってしまった。

しかし今は違う。メジャーなブラウザはいずれもタブブラウズ機能をサポートし、タブの位置についても、Tabs on Topを採用した例はOperaに続いてGoogle Chromeがある。Firefoxを除けば、タブをツールバーの下に置いているのはIEとSafariだけだ。そしてそのSafariは、タブの連結方向を下ではなく上に向ける事で、少なくともツールバーはタブに従属するものという事を視覚的に示している。採用している実装の数だけを言えば、ツールバーをタブに従属させるデザインの方が多数派になったとすら言える。昔の実装の負の遺産を断ち切るにはそろそろいい頃合いだ。

Tabs on Topに対する非難ははっきり言って、「今までの物と違う」という事それ自体に対する拒否反応でしかない。だから、それを正当化するために「今の配置の方が合理的なんだ」なんておかしな事を言う必要はない。そんな屁理屈を用意しなくても、あなたがTabs on Topを受け入れられない理由は「今までの物と違うから」それだけで十分だ。それは恥ずかしい事じゃあない。「新しい物を作る時はなるべく今ある物に合わせろ」というのが鉄則になるくらいには、人類みな頭が固いんだ。

そして、今までの物を覚えるのに苦労した分だけ「またあんな苦労をして新しく覚え直さなきゃならないのかよ！」と言いたくもなるだろうが、それは杞憂だ。Tabs on Topな新しいUIは、今までの物を覚えるのに要した時間よりもっと短い時間で慣れる事ができる。何故なら、今までタブを使った事がなくてもそのはたらきが見た目で分かる、そういう所を目指したデザインなんだから。

ブラウザのタブの改革 - Firefox.nextへの道：タブをより良くする。 - Jul 30, 2009

Mozilla Corporationの中の人であるAlexander Limi氏が次世代のFirefoxのタブインターフェースをどのように改善するかについての議論の叩き台となるエントリを6月に公開されている。その中にツリー型タブへの言及もあった。だからというわけでもないけど、英辞郎とExcite翻訳に頼りながらどうにかこうにか日本語に訳してみた。誤訳があったらごめん。

なお、翻訳を公開することについてはご本人の許諾を得ております。

---

ブラウザのタブの改革 - Firefox.nextへの道：タブをより良くする。

よく知られた技術ニュースサイトのスクリーンショットから話を始めましょう。「Digg」ボタンを押したくなる気持ちはよく分かりますが、押さないように。何も起こりませんからね。

さて、ここで何が起こっているか？　以下のようなことが言えます：

• ブラウザ上で複数のページを扱うための現在の手法は、十分であるとは言えません。少なくとも、先進的なユーザ以外にとっては。
• 複数のページを一度に開いて操作するのに「これさえあれば十分」と言えるアドオンは無いようで、タブの挙動を変えるために途方もない数のアドオンが存在しています。

タブがブラウザの中に登場した時――OperaとFirefoxがその急先鋒だったわけですが――、Web（とコンピュータも）は今とは非常に異なった状態にありました。人々は1つのウィンドウの中だけで6つか7つほどのページを同時に扱えるというだけでも、ことのほか幸せでした。

2009年に時計の針を進めると、多くのユーザが、一度にいくつのページを開けるかという点でブラウザの限界を打破しようとしています。この新たな試みは大量のメモリ容量とCPUパワーを必要とします――しかし、ユーザーインターフェースにおいて、これよりも明らかな課題はありません。大量のタブを扱う方法については、複数行表示（Opera）から現在開かれているタブのプルダウンリスト（FirefoxやSafari）まで、ブラウザごとに色々な方法がとられています。これらのアプローチのいずれも、いまいち上手く機能していません。これが、今Mozillaが複数のページを管理するための別のアプローチを探している理由です。

目次

長大な投稿ですので、あなたが興味がある所から読めるように、節ごとのリンクを用意しました：

• 壊れていないのなら、直さない
• 現存しているアプローチ
• 測定についての覚え書き
• 提案：Firefoxのためのいくつかの調査のステップ
• 初心者/中級者向け：サムネイルの見直し
• 上級者向け：QuicksilverとFirefoxの出会い
• 今すぐパワーユーザ向けのUIを試す
• 組み合わせ
• 議論に参加する方法

壊れていないのなら、直さない

私たちはタブ機能こそが、多くの人々がFirefoxに乗り換えた最大の理由であることを認識しています。私たちが別のアプローチを探しているということを明らかにした時、人々が最初に言うのはだいたいこういう事です。「でも、私はタブが好きだ。タブ機能をなくさないでくれ！」

ですので、はっきりとこう言っておきましょう。私たちは、タブは未だ健在だと思っており、タブをなくそうとは考えていません。タブは現在の物と似た形で残り続けるでしょう。なぜなら、ほとんどの人にとってタブは大変有効に働いているからです。ユーザの大多数はタブについて特に問題意識を持ってはおらず、あなたがタブの限界に挑もうとしない限り、タブは複数のページを扱うための非常に自然且つエレガントな解決策と言えます。

その上で私たちがしたいのは、多数のページを管理するのに現在タブを使っていて不満を感じていたり不幸せになっていたりする人々のための、より良い解決策を見つけ出すことです。タブに関して、この議論のために、ユーザをいくつかの大まかなグループに分類しましょう：

初心者

このグループはタブを全く使っていません。これらの人々は、私の祖母に似ています。技術に精通したおばあちゃんでも、彼女は4つか5つほどのWebサイトしか訪れておらず、タブは全く使っていません。

中級者

このグループの人達は、現状のタブに満足しているユーザです。彼らはたいてい5～10個前後のタブを開いています。

上級者/パワーユーザ

このグループのユーザは多数のタブを開いています。ブラウザの中で100を超えるタブを開いており、ページを全く閉じないで、代わりに新しいタブを開いていく、というタイプの友人を誰もが持っています。あるいはあなたがまさにその人かもしれません。

これらの分類のためにありがちな名前を使っていることについてはご容赦下さい。みんな十人十色で、人によっては「うちのおばあちゃんは……」と言いたくなるかもしれませんが――これらは単に議論を分かりやすくするための分類です。

現存しているアプローチ

当然ながら――先ほどのスクリーンショットが示しているように――タブ周りの状況を改善するための試みについては、様々な努力がすでにあります。Mozilla LabsでもSummer 2009 Design Challengeという企画を主催しており（Reinventing Tabs in the Browser）、1つ前のSpring 2009 Design Challengeでは、可能な限りの最小のユーザーインターフェースでどのようにWebブラウズを行うかを思い描いてもらいました。

最近パワーユーザの間で評価されているFirefox用アドオンの1つが、ツリー型タブアドオンです。

人気の理由は分かりやすく、このアドオンはパワーユーザの要求によく合っています：

• このアドオンはタブを、水平表示の代わりにサイドバー風の縦長表示で表示します。その結果、見えるタブの数が最大化されます。
• ワイドスクリーンのモニタが新製品の主流になってきているために、より多くのユーザが水平方向の画面スペースを利用できるようになってきていますが、このアドオンはその水平方向のスペースを活用します。（例えば、2006年第1四半期のノート機向け出荷台数では、ワイドスクリーンモニタの出荷台数は普通のモニタを超えました。）
• このアドオンは、そのタブがどこから開かれたかに基づいてタブを自動的にグループ化します。例えばあなたがGoogleの検索結果から別れる形で新しいタブを開いたのなら、そのタブは上のスクリーンショット内の「Apple」タブのように、入れ子の形で表示されます。現在、他のブラウザを使っている人々は、関連するタブをグループ化するために異なるウィンドウや色分けされたタブを使っています――そして、望んだとおりのグループ分けを行うためにウィンドウの間でタブをドラッグ＆ドロップしています。この解決策は、それよりもエレガントです。
• このアドオンは、ホイールスクロールというほとんど労力のいらない操作によって、画面に収まりきらないタブをより簡単に操作できるようにします。

---

もう1つの注目に値するアプローチは、Safariでタブを操作するためのSafariStandアドオンが取っている道です。

SafariStandが提供する機能の一部は以下のようなものです：

• ツリー型タブと同じように、このアドオンは画面の中に収まりきらないほどのタブがある時に、ホイールスクロールによって多数のタブを簡単に扱えるようにします。
• タブは非常に視覚的で、簡単に識別できます。
• タブはクリックに反応する大きな領域を持っています。
• 最も重要な事として、SafariStandは、私たちがMozillaにおいて部分的サムネイルと読んでいる機能を含んでいます。

ページのほとんどがテキストである場合には特に、ページ全体のスクリーンショットのサムネイルはページを識別するためにはそれほど便利ではありません。ページの左上の角（ロゴとページのタイトルの一部を含むのに十分な大きさの領域）のスクリーンショットを取ることによって、部分的サムネイルはあなたがページを探すために識別する上で、飛躍的により便利になります。上のスクリーンショットでは、もしあなたが他に3つほどWikipediaのページを開いていたとしても、「User Interface」のWikipediaのページを識別することができます。

---

先のアプローチが正しいことを検証するために、Opera 10ベータ版の場合を見てみましょう。このブラウザはタブを表示する方法として似たアプローチを取っていますが、しかし他の物に比べて、この実装には色々と問題があります：

• あなたはここで、ページ全体のサムネイルが何故使いにくいのかを示すいい例を見ることができます。このスクリーンショットでは、サムネイルにおいて、あるWikipediaのページは他の異なるWikipediaのページと見分けることができません。
• サムネイルを横ではなく上に置くことによって、タブがコンテンツ領域からより多くのスペースを奪っています。Chromeや――最近までの――Safari 4がウィンドウ枠自体をタブを表示するための追加のスペースとして使っている（それによってWebページのためにより多くのスペースを確保している）ように、あなたはすでに、ウィンドウの上の部分を可能な限り細くしたいと望んでいるでしょう。
• ここでは見えてこない問題が1つあります。もしあなたが多数のタブを追加すると、サムネイルはタブの幅に合わせて縮んでしまい、あなたが探しているタブを見つけ出す上での視覚的な材料としては役に立たなくなってしまいます。
• この実装があなたに対して、マウスのホイールを使うことで横方向にスクロールできる機能を――あなたが40個のタブを開いた時に、サムネイルが2ピクセルの幅になってしまう代わりに――提供していたとしても、多くの人はそれを試しすらしないでしょう。縦方向のホイールスクロールを横方向のスクロールのために使うでしょうか？

あなたが見たとおり、Operaは既存のいくつかのアドオンが取っているアプローチに似た試みをしていますが、残念ながら、それらのアドオンの便利さの元となっている多くの細かいポイントを見落としています。

念のために言っておきますが、私はOperaの長年の大ファンです。私の近しい友人の一人はつい最近までリードUIデザイナーとしてOperaで働いてすらいました。私はここでOperaのあら探しをしているのではなく、単にこの議論の実によい例示だったから挙げただけなのです。

測定についての覚え書き

私たちが検討したいと思っているいくつかの話題に移る前に、調査と統計の側面から以下のことについて手短に述べておきます：

タブについて考えるためには、タブの利用のされ方のデータが多ければ多いほど助かります。幸いなことに、Mozilla LabsのTest Pilot測定プロジェクトが、実際にどれだけの数の人がFirefoxを使っているのかを計測するためにブラウザに測定ツールを取り付けるという目標において先行しています。

このツールを使って、私たちは有益な数字――どれだけの人々が2～5個/10～20個/50個以上のタブを使っているのかという風な、Test Pilotのユーザの間でのタブの使われ方の分布などのような――を得ることができます。私は、5～10個よりも多くのタブを開いているユーザはそう多くないと確信していますが――しかしもちろん、50個以上のタブを開いている人達が本当にFirefoxに最初の段階で乗り換えてきたパワーユーザであって、私たちは彼らの生産性が高まるようにするべきとも考えています。

あなたは実際に、Jetpack用のアドオンであるTab Grapherを使うことによって、利用時間の経過に応じてあなた自身のタブの利用状況をグラフ表示することができます。あなたがタブの利用頻度の上記の尺度の中のどの位置にいるのかを知りたければ、この拡張機能を使うことは、それを明らかにする面白い方法となるかもしれません。

データは多ければ多いほどよいです。近い将来により多くのデータを収集するために、Firefoxをより良くするためにすべての人が私たちの助けになってくれることを願っています。

提案：Firefoxのためのいくつかの調査のステップ

上記の通り、あらゆる種類のユーザのためにタブの欠点を解消するたった1つのアプローチというものはありません。私たちがするべき事は、あなたが好みのタイプの操作方法を選べるようにして、それらの間をシームレスに移行できるようにすること、そして、以下に詳しく述べるような自然な移行のポイントを提供することです。

また、今はバージョン3.5の出荷を間近に控えている（訳注：元文書が書かれた日付はFirefox 3.5正式版リリースの直前にあたる2009年6月16日）状況なので、これは私たちがこれからFirefox.nextに向けて今後の数ヶ月の間により詳細に描き出していく予定の非常に大きな絵のうちの、小さな一部分に過ぎないということを心に留めておいてください。その時には、この最初の投稿よりもはっきりとした提案が世に出ていることでしょう。

初心者/中級者向け：サムネイルの見直し

既存のタブインターフェースが中級者のユーザに適しているのであれば、何故それにも関わらずインターフェースを変える必要があるのでしょうか？　主な理由は、この中間層のグループに分類される人々は、ユーザとしてどんどん注文が厳しくなってくるからです。彼らはより多くのタブを使い始め、そして彼らのうちの半数以上はすぐに、私たちが数年前にパワーユーザと定義した領域に突入します。

これは、タブのUIを自動的に移行するより良い方法、もしくは、最低でもせめて人々に対して以下のようなインターフェースの間を可能な限りシームレスに移行できるようにするオプションを、私たちは必要としているということです。

初心者⟷中級者の理想的なインターフェースは、以下の特徴を持つことでしょう：

• ごくわずかなWebサイトとほんの2～3のタブだけを使うユーザのために、良い体験を提供する。
• 1つのタブだけを使っている状態を卒業して複数のタブを使うようになるのが、現在のそのステップよりももっと容易である。
• 最近のワイドスクリーンのディスプレイを効率的に利用しつつ、低解像度のディスプレイのためのオプションも有している。
• そのインターフェースで扱うことのできるタブの数を超えようとした時、次のレベルのUIに切り替える手段を提供する。

今までの所私たちが検討してきた解決策の中では、サイドバーベースの解決策が新しいオプションとその可能性を示しています。

固定されたサイドバーというアプローチが有効でない人もいる――画面上のあまりに多くの領域を占めてしまうために――ということには気をつける必要があります。これに対する1つの解決策となり得るのが、Mozilla Labsでプロジェクトの1つであるJetpackの一部として検討されており、また現在FennecモバイルブラウザのUIとして利用されている、スライドバーというコンセプトです（「サイド（side）」ではなく「スライド（slide）」であることに注意してください）。基本的なコンセプトは通常のサイドバーと同じですが、スライドバーの場合は常時表示されるのではなく、画面の端を使って、パネル自体を内容と一緒に横にずらして見えなくすることができます。これはあなたが低解像度の環境を利用している場合には良い解決策となり得ます。他の似た解決策がOperaのサイドバーに見られ、こちらはクリックされた時に展開されます。いずれにしても、サイドバーを一時的に隠すための方法には様々な可能性があります。

これらのワイヤーフレームは様々な機能について検討しています：

• 開いている複数のページの間を切り替えるための主な方法として、サイドバー内に表示される部分的サムネイルによるSafariStand風のインターフェースを取っかかりとしています。
• TVの「チャンネル選択」とコンセプト上の類似点があります――初心者はおそらく、彼らの好みのサイトをサイドバーに常時表示させておくだけの使い方をするでしょう。そのページがまだ開かれていない場合はそのページを開き、すでに開かれている場合はタブを切り替える、という物になるでしょう。
• RSSアイコンやスターなど、いくつかのインジケータやボタンがサムネイルの中に追加され得ます――とはいえ私たちはそれを最小限にとどめるべきでしょう。
• そこには大きな空のタブがあり、それによって、新しいタブをどうやって開けばよいかに気付きやすくします。
• また、新しいタブには、タブから直接検索を実行して、タブが有効化される時に検索結果のページに切り替わるというオプションもあります。
• 一旦、開かれているページの数が、部分的サムネイルを表示するのにもはや適切でないという閾値に達した時には、ツリー型タブのファビコン＋タイトルというアプローチに遷移します。これにより、次のレベルのタブの管理の仕組みに気付きやすくなります。
• もちろん、最上部に表示されるモード切り替えのUIによって、明示的にモードを切り替えることもできます。
• 表示されるタブのリストをページのタイトルや内容によって絞り込むことができる、検索ボックス状の「タブを絞り込む」UIが備わっています。
• 同様に、あなたの環境が低解像度であるなら、サイドバーの挙動をスライドバーへ任意に変更することができます。画面の横端をポインタでタップすることによって、ページ全体の表示がスライドアウトするでしょう。Fennecがそうしているように、これは小さな画面のデバイス向けの既定の挙動となると考えられます。

おっと、私たちはこのワイヤーフレームの中に戻る/進むボタンやアドレスバーなどを敢えて描きませんでしたが、もちろんそれらは引き続き存在し続けるでしょう。私たちはこれらの部分についていくらか変更を加えるつもりで、それについては今後の記事の中で詳細を語っていく予定なので、問題をややこしくしないためにこのワイヤーフレームからは除外しました。

このことから1つの素晴らしい結論を導き出せます。それは、開いている複数のページ――「タブ」――とブックマークは、シンプルな利用のされ方においては同じ物となり得るということです。Mac OS XのDockはアプリケーションが現在起動しているかどうかを気にせずに利用できますが、それに似ています。この話題も私たちが今後の記事の中でさらに語っていくであろう話題の中の1つですが、議論に集中するために、今はテーブルの上に載せたままにしておきます。

私たちは、私の祖母のような人達のためにほぼ確実に、既存のインターフェースよりもより良い形へと切り詰められており、また、タブの数が8～10個ほどという限界を超えようとした時には次の段階へシームレスに移行することができる、というインターフェースを持っています。

上級者向け：QuicksilverとFirefoxの出会い

私たちがパワーユーザを観察していて気がついたパターンとして、彼らはブラウズ用のインターフェースを可能な限り多く取り除く傾向があります。彼らはしばしば、すべてのツールバーやボタンを隠します――それらはすべて、ページの内容を表示するためにより広い領域を確保し、邪魔な物を最小限にするためです。なぜなら、彼らはほとんどすべてのことをキーボードショートカットを使って行うからです。彼らはブラウザの機能を示す物理的なリマインダ（ツールバーのボタンやタブなど）が全く無くても困らず、ただページの内容を表示するためのスペースを可能な限り広く取ることを望んでいます。

あなたがアプリケーションランチャ（※Mac用のQuicksilverやLaunchBarのようなツール、OS X（のSpotlight）やWindows Vistaの物のようなアプリケーションの起動と検索が一体化したインターフェース、あるいはLinuxにおける様々なアプリケーションランチャ）を使ったことがあれば目にしたことがあるかもしれませんが、もう1つの興味深いパターンとして、パワーユーザは彼らのファイルやアプリケーションがコンピュータ内のどこかにあるということだけを覚えていて、それらが実際にはどこに置かれているかについては気にしないでいても不満を感じない、ということをあなたはおそらく知っているでしょう。

この事は、以下のようなことを示しています：

• パワーユーザは、UIが「脇に寄っていて」可能な限り最小限であることを好む。
• パワーユーザは、どのページで何をしていたのかの詳細を彼らの頭の中で記憶しておくことが苦痛でなく、それらを保持しておくためのUIを必要としない。

手元にある情報に基づいて、私たちはパワーユーザ向けあるいはフルスクリーン表示用のインターフェースをこのように想像することができます：

• あなたが新しいURLを入力するためにCtrl-Lまたは⌘-Lキーを押すまで、そこには全くUIがありません。タブもボタンもありません。
• Ctrl-Lまたは⌘-Lキーを押すと、アドレスバーが出現します（もちろん、Ctrl-スペースまたは⌘-スペース、あるいはそれに似た別のショートカットを指定する方法も存在するべきです）。
• すでに開かれているページは項目の横にインジケータが表示されており、プルダウンリストからその項目を選択すると、現在のタブにそれを読み込む代わりに、そのタブへジャンプします。
• そこには選択されたページを新しいタブで開くための簡単な方法もあります。

これによってパワーユーザは、何百というページを一度に開いてブラウズするのに素晴らしいUIを手に入れ、同時に私たちはフルスクリーン表示――TVやプロジェクタなど――でWebブラウズするための良いUIを手に入れます。

開かれているタブの間の切り替えは、このように動作するでしょう：

1. Ctrl-Lまたは⌘-Lキー（あるいは、自分で定義したショートカット、ウィンドウ上部におけるスライドバーのようなジェスチャなど）を押してアドレスバーを出現させ、
2. タブの名前をアドレスバーに入力し始め、
3. あなたが入力した内容に該当する開かれているタブがアドレスバーのプルダウンリストの最初の結果として提示され、
4. その項目を選択するとそのタブに切り替わる。
5. または、普段そうしているように、Ctrl-Tまたは⌘-Tによって新しいタブが開かれる。

どのようにしてパワーユーザ向けのモードを有効にすればよいのでしょうか？　そこにはモードの切り替えという概念は無く、単にページ上であなたにとって不要な要素の表示をオフにするだけでよいでしょう。もしあなたがアドレスバーの表示をオフにしたら、ワイヤーフレームで描かれているような形で機能するようになるでしょう。

今すぐパワーユーザ向けのUIを試す

だいたいの所を把握するために、これがどのように機能するのか――「UI無しでのブラウズ」――を実際に試してみるには、Firefox 3.5を使って以下のようにして試してみることをお勧めします：

1. すべてのツールバーを「表示」メニューからオフにする。
2. ステータスバーを非表示にする。
3. 新しいURLを入力するためにCtrl-Lまたは⌘-Lを使い、新しいタブを開くためにCtrl-Tまたは⌘-Tを使う。

現在のバージョンのFirefoxにおいて、私たちがパワーユーザとフルスクリーンモード向けに使いやすくするために修正するべきである、現状において欠けている点は以下の通りです：

• 現状では、あなたはタブバーを隠すことができません。これは可能になっているべきです。
• フルスクリーンモードはMac OS Xでは動きません。これは修正される必要があります。
• （訳注：フルスクリーンモードにおいて）新しいURLを入力するためにCtrl-Lまたは⌘-Lを使った時、アドレスバーはURLの入力が終わった後も残り続けます。つまり、もう一度手動でそれをオフにする必要があるということです。これは、元の状態を覚えておいて、それが隠れていた状態であったのなら自動的に再び隠れるようになっているべきです。追記：これはFirefox 3.5で動きますが、Firefox 3.0では動きません――フル機能のスマートロケーションバーの代わりに小さなダイアログを得るにも関わらず。それでも、さしあたって実験の上では（訳注：その小さなダイアログは）十分よく働き、将来のバージョンでは可能であれば、スマートロケーションバーの全機能をあなたに提供するようになるでしょう。
• アドレスバーはすでに開かれているタブの名前にも反応するべきです。これは大きな問題です。もしこの機能を加えることができればすぐに、あなたはSlashdotを表示したタブがどこにあるのかを気にしなくても良くなり、タブの名前を入力し始めるだけで、Firefoxばブラウザ上であなたが開いている200以上のタブからそれを見つけ出し、それに切り替えるでしょう。

組み合わせ

絶対に明らかなことがあります：あなたは上で述べられている可能性の中であなたのブラウジングスタイルに合う物を任意に選ぶことができます。

• パワーユーザだが、開いているページの一覧を常に表示させておきたい、という場合には？　LOLcat（訳注：lolcat翻訳機などを参照のこと）の200個のタブを一覧表示するための「閉」モードのサイドバーを除いて、他の物を非表示にするといいでしょう。
• 4つのサイトしか見ないおばあちゃんのようなユーザのために設定をしたい時は？　URLバーを隠して4つのサイトをサイドバーに置いておけば、おばあちゃんはそれをテレビのように使えるでしょう。

……などなど。ここに見られるように、これらの改善はあなたのWebブラウズ用ツールに対して強力な新しい機能と能力を加えます。

議論に参加する方法

Mozillaプロジェクトは、あなたの参加を歓迎します。私たちはその向こうに多くの素晴らしいアイデアが生まれてくると確信しています。私はAlex Payneの彼のブログにおける方針と同じ理由で、個人的にこのブログ（訳注：原文が掲載されているAlexander Limiのブログ）のコメント機能を有効にしていませんが、議論に参加するための最良の方法としては以下の物があります：

• Firefoxのタブがどのように働くべきとあなたが考えているかについての記事を書いて、あなた自身のWebサイトに載せて下さい。あなたが私のサイト（訳注：原文が掲載されているAlexander Limiのサイト）へリンクし、私宛に言及していれば、私はそれを見つけて読むでしょう。いや、本当に。私の前の雇用主はGoogleで、物事を探すことは私たちがしていたことです。
• Mozilla LabsのSummer 2009 Design Challenge（Reinventing Tabs in the Browser）に参加して下さい。
• コメントが短いのであれば、あるいは書かれたことに対して単に何かを付け加えたい場合は、dev.apps.firefox Google Groupでそれらを投稿したいと思うかもしれません――Usenetのニュースグループや古典的なメーリングリストの形でも。
• もしあなたが何らかのモックアップやワイヤーフレーム、あるいはこの議論に関連する図を作成したなら、FlickrやTwitter、あるいはその他のサービスにおいてmozconceptタグを付けてください。私たちはそれを見るでしょう。
• もしあなたが誰もが見ることのできる場所で意見を公開することを望まないのなら――もしくは単に、Firefox User Experience Teamから私が新しいウェルカムパッケージとして受け取った新しい難燃性スーツを試してみたいなら――limi@mozilla.com宛にメールを送って下さい。

聞いて下さってありがとうございます！　次世代のFirefoxのタブをより良い物とするために皆さんがどんなアイデアを思いつくのか、楽しみにしています。

シンボリックリンク（ジャンクション）があるとデータの吸い出しがうまくいかない…… - Feb 28, 2009

リンク作成シェル拡張で作ったシンボリックリンク（うちの場合はフォルダのリンクなので、正確にはジャンクション？）があると、ファイルのコピーが途中で止まってしまう……

かつてWindows 2000でCドライブとDドライブだった物が、今FドライブとGドライブとして認識されてるんだけど、この状態でフォルダのリンクを含むフォルダ群をVista上で普通にコピーしようとすると、リンク切れ状態のリンクを処理しようとして詰まってそこで後のファイルのコピーも全部キャンセルされてしまう。仕方がないので、先にFとGからリンクの残骸を探して削除して回ってからコピーをやり直してみてるけど、見落とした物があるとまたそこでやり直しなのでうんざりだ。

関係ないけど、Vistaのファイル移動やコピー時の上書き確認関係のダイアログは、なかなかよくできてるっていうか丁寧だなと思う。「どういう操作を選ぶか」じゃなくて「結果的にどうしたいのか」を提示してる、というかなんというか。

Gimp嫌われすぎワロタ - Dec 21, 2008

そういえばAza Raskinさんとも「GimpのUIはひどい！」で合意してしまいました。

Twitter / TAKESAKO: ちなみに「GIMPがあるからPhotoshopいらないじゃん」とか言ってる自称オープンソースプログラマー（の最適化能力とUIデザインセンス）は信用しないようにしている。

確かに本気で言ってる人がいるとしたらそうだなあと思う。

ただ、人に「こういうことがしたいんだけど」とか言われた時には、ついGimpの方を勧めてしまうなあ。そういう人達に対してPhotoshopは明らかにオーバースペックなのに、Photoshopのように「なんでもできる」事を望んでいて、それでいて出費はしたくない、そんなケース。そういう人って多分、細かい使い勝手とか作業効率とか気にならないと思う。だから問題にならない。あくまで「機能」しか大事じゃないから。それでGimpの解説本を1冊買って渡す。あとはシラネ。みたいな。

個人的にGimpが使い物になるのは、全ての作業をGimp上で完結させる場合か、SAI等で編集中の画像の一部のレイヤだけを切り出して加工して結果をSAIにもう一度取り込む、という場合かなあ。自分としては補助的な使い方をする分には我慢できるけど、メインで使うのはストレスフルすぎて辛い。慣れの問題？　いえいえ、フィーリングの問題です。

InkscapeとIllustratorでも同じ事が言えるかも。部分的にはInkscapeの方が高機能なんだけど、仕事で使うのはちょっと……というかなんというか。以前SAIの解説本にコラム書く時に、普段イラレでやってるようなことをInkscapeだけで再現してみたけど、半透明やドロップシャドウを使いまくってると、重くて重くてとても辛かった。という性能的な問題もあったけど、それ以上に、ツール類を出してるとボタン類がやたらでかくて、気持ちよく作業できなかった。これもまたフィーリングの問題。

もっと良いAutoPagerize - Nov 25, 2008

新はてブとAutoPagerizeの競合のことで色々もめているようですが、個人的にはこの間Aza氏に見せてもらったUIデザインのモックアップみたいなのがいいなーと思いました。Azaはタブの代わりに使いたいと思ってたようだけど、AutoPagerize的な用途に使うのが現時点では有用なんじゃないかなあ。

イメージしづらいと思うけど、XULのbrowserとframesetとframeでそれっぽく表現するとこんな風になるかな。

<xul:browser height="600"><!-- ←この要素がスクロールバーを提供する -->
  <html:frameset rows="*,*,*" height="6000">
    <html:frame src="今見ているページ（ページ1）：ページの長さ＝2000px"
                 height="2000"/>
    <html:frame src="ページ1のrel=nextのリンク先のページ（ページ2）：ページの長さ＝2000px"
                 height="2000" />
    <html:frame src="ページ2のrel=nextのリンク先のページ（ページ3）：ページの長さ＝2000px"
                 height="2000" />
  </html:frameset>
</xul:browser>

本物のXHTML 1.0 Framesetとは違う嘘マークアップであることに注意。あくまで雰囲気だけ見て欲しい。こういう作りなら、AutoPagerizeの原理的な問題の一つである「ページを動的に継ぎ足すせいで、継ぎ足された内容に対してユーザスクリプトが実行されない」という問題は起こらなくなるはずだし、想定されない内容改変によるページのレイアウト崩れも起こらないはず。その代わり、広告が二度も三度も表示されるという問題は起こるけど。

ちょっと作ってみようかな、そういうの。

エイザを囲む会 - Nov 21, 2008

Aza Raskin飲み会行ってきた。

普段あまり顔を合わせることがないplus7さんが来られていた。plus7さんは最近タブレットPCを使われているそうなのだけれども、タブレットPCはキーボードが無い。そういう環境で便利に使えるUbiquity的なUIはどういうものか？という事についてのアイデアをAza氏に解説されてた。

それはどういうものかというと、逆ポーランド記法の計算が「演算対象のデータをスタックに溜め込」んでから「演算の種類を決定する」という形で行われるのと同じように、リンクやら文字列やらをドラッグ＆ドロップでどんどん「スタック」に溜め込んでからコマンドを選択する、というものだ。溜め込まれるデータ自体が持つコンテキストであるとかメタデータであるとか（Microformatsもそう）をキーにすれば、その時提示される「コマンド一覧」について最も適切と思われるものをサジェストできるのではないか？とか、色々と夢が広がる。セカンドサーチで、ページ内の文字列を選択→検索窓にドラッグ→ポップアップが出てくるのを待つ→ポップアップから検索エンジンを選んでドロップ　という風な操作をよくやってる僕としては、このUIが実現されれば結構使えるかも？と感じた。片手がふさがったままでも色々できるし。

組長に、現状のUbiquityにおける日本語対応用コードの内容というのを教えてもらった。曰く、「で」とか「に」とかの助詞をデリミタとして文を分割するという物だそうな。単純に作るとそうなるよなあと思うんだけど、実際の日本語の文章ではこれはまずマトモに動かないことが予想されるわけで……やはりきちんとした形態素解析の仕組みは欠かせないと思う。それか、ローマ字入力で分かち書き入力するという前提で、XUL/Migemoの応用によって、例えば「miru」という入力に対してマッチするコマンドをコマンド一覧から探し、「見る」と「診る」の両方をサジェストの候補として出す、という風にするとか。

ATOKダイレクトのAPIがオープンになっていること、PerlとRubyに対応していてSDKが公開されていることをAzaに伝えると、「Pythonは無いの？」とAza。そこから、何故Pythonが日本であまり流行らないのかという話になった。最初に出た訳本が微妙だったからじゃないかとか、名前の元になったモンティ・パイソンが日本であまり知られてないからじゃないかとか、PHPやPerlやRubyがすでにデファクトスタンダードとなってしまっているからじゃないかとか……

モンティ・パイソンの話から、コメディは文化に強く依存するのかもしれないという話にもなった。Azaが紹介してくれた「far side」というアメリカの漫画は、日本人に見せても「何が面白いのかよく分からない」と言われがちだという。モンティ・パイソンも組長曰く「ギーク受けするような内容」とのことで。でもサウスパークは日本人にもウケてる気がする。直接的なギャグ、は日本でも受け入れられるということなんだろうか？

日本語入力といえば、IME上でEnterで変換を確定するとUbiquityのコマンド実行として扱われてしまうという問題。これにはAza本人も参っているとか……誰かパッチを公開してたはずだ、という話をその場でもしてたけど、今調べたらFireMobileSimulatorの堀川さんだった。このあたりの、キー入力とIMEの組み合わせの問題を回避するノウハウは、Find As You TypeがC++からJavaScriptに移植された後に中野さんが頑張って直したFindToolbarの実装（今だったらfindbar.xml）に詰まっているので、Azaにもおすすめしておいた。

Azaは日本語がしゃべれるということで、みんな普通に日本語ベースでしゃべっていたけど、日本語ネイティブでないAzaにはちょっと辛いんじゃなかろうか？　と、勝手に気を回してしまって僕はなるべく英語を使うようにしようとしてみたんだけど、基本的な語彙力がないからやっぱり日本語混じりの怪しい英語にしかならなくて、あの場では僕が一番アホな喋りになっていたんじゃないかという気がする。

その後、終電までの短い時間だったけどカラオケにも行った。Azaは「津軽海峡冬景色（石川さゆり）」「花火（AIKO）」「First Love（宇多田ヒカル）」を歌ってた……って、ちょ、どこで憶えるんだそんなラインナップ？！

そんな感じの会。いろんな人が色んな知識やアイデアを持ち寄って話すのも大事だなということを改めて思った。こういう機会を設ける提案をしてくれた組長に感謝せずにはいられない。組長はかなりの量のウィスキーにビールにワインに色々飲んでいてカラオケの時には呂律も回らなくなってヤバイ状態に見えたけど、無事会社まで辿り着けたんだろうか。心配だ。

ところで、帰ってきてから気付いたけど、ATOKダイレクト開発者ブログで前のエントリが紹介されてる。UbiquityにはATOKダイレクト開発者の方も以前から興味を持たれてたとのことで、みんな似たようなことを考えるものなんだなあと感慨を憶えた。……ATOK 2008（for Windows）買いそびれててすみませんすみません　ATOK X4（？）での改良に期待してます。

Ubiquityの先にある未来についてAza氏と直接話せた - Nov 19, 2008

所用でMozilla Japanオフィスに行った際、とても幸いなことに、Aza氏と話すことができた。

ちょうどPCを持っていたので、XUL/Migemoのデモをお見せした。IMを使わずに日本語を検索できる様子というのは、なかなかインパクトがあった……っぽい。と思う。

結論から言うと、僕の理解は大筋ではそう間違っていなかったようだ。「translate "english sentence" to japanese, and email to jono」や「『別れたい』をググってマスダる」みたいな複数の「動詞」の組み合わせ（チェインとかパイプとかそういう感じのもの）は、Ubiquityの将来のバージョンで入れる予定があるとも言っていた。セカンドサーチやLookpickやinquisitorについては、悪くないけどいまいち、という風に言っていて（……だと思う。英語不得意なので曖昧）、Aza氏はむしろもっともっと先を目指しているようだった。「動詞」を人間がいちいち入力しなくても、例えばSocial IMEやGoogleやYahooがそうしているように、多くのユーザの行動傾向をベースにして統計処理により精度の高い推測を行うようにする、という風なことも考えているとのことだった。

UbiquityはFirefox上で動作するものだけれども、もっと言えばデスクトップ環境のどこでも動作するようにできれば一番イイ、とも言っていた。彼がUbiquityの前に作ったEnsoがまさにそうで、デモしてもらった様子を見たら、デスクトップ上で特定のホットキーを押すとUbiquityのような物が起動してUbiquityのようにコマンドを入力できる、という物だった。

そういった一連の話を経て僕が思い浮かべたのは、ATOKダイレクトだ。ユーザが語句の入力を行うフロントエンドにいつも存在していて、デスクトップ環境のどこででも動作して、おもむろに始めた入力操作から「乗り換え案内」や「辞書検索」といった多様な機能をシームレスに呼び出すことができる。（それに、日本語圏のユーザなら基本的にいつでもIMEを使っているから、UbiquityやEnsoのように「それを使うためにモードを切り替えるぞ！」という気負いをしなくていい。そういう意味で、こういった操作系に馴染みやすいのはもしかしたら日本人や中国人の方なのかもしれない。）

Aza氏は、ATOKがプロプライエタリな製品であるということを残念がっていた。僕はUbuntu上のATOK X3で変換候補から同音異義語の説明が出る様子を見せたけど、これがもっとオープンな物だったら……と彼は言っていた（この時僕は、PerlやRubyからATOKダイレクトAPIを簡単に呼べるということを完全に失念していたので、そのせいもあるとは思う）。オープンソースの環境で、完全にオープンなソフトウェアだけで、IMから追加コマンド（アドオン、プラグイン）まで全部まかなえれば、もっと自由度が高くなってイノベーションが産まれるかもしれない、と。

ATOKダイレクトのようにどこでもシームレスに使えて、Ubiquityのように簡単に機能を追加できて、Webの向こう側にあるサービスと連携できる。そういう物がAza氏の当面の目標なのかもしれない。

ただ、IMをこれから新しく作るというのは、特に日本語や中国語のユーザのためにそうするというのは、さすがに無謀だと僕は思う。Ubuntu環境では最初からSCIM Anthyが使えたにもかかわらず、Firefox 3 Hacksを執筆するにあたって、大量の文章を入力する時に誤変換によるストレスが尋常でなかったため、慌ててATOK X3を購入することにした。という自分のエピソードも引き合いに出して、日本語圏のユーザにとってIMは空気のように欠かせない存在であって、その品質が日常の生産性にダイレクトに影響する、だから生半可なIMでは使ってもらえない公算が高い、ということをつい熱く語ってしまった。まあ、やるとしても、Anthyのようなすでにある開発コミュニティと協力し合って進めるのがまだ現実的だろうと思う。

ところでATOK 2008を買いそびれてしまったためというのもあって僕は全然知らなかったんだけど、ATOKダイレクトって想像以上の物みたいだ。HowTo記事によると、プラグイン作るのも関数を1つ定義するだけでいいという簡潔さだし。ATOKダイレクト開発者ブログでは色々ユニークなプラグインが紹介されている。これは20日にでもAza氏に補足として伝えておかないといけないなあ。阿波徳島マジパネェ。

余談だけど、GIMPのGUIはほんとひどいな！という所でAza氏と意気投合できたのは愉快だった。実際にそのツールを使って何かをする人の立場に立って、実際に使う場面でのフィーリングを大事にする、ということの重要性をAza氏も気にしていた。日本語圏でUbiquityのような物を使おうとする時に、キーボードを使って言葉を入力するということ自体がもう大多数の日本人にとってとてもストレスフルだという事を思い、僕は、日本人のフィーリングに合うUIの設計の難しさというものを改めて実感した。

20日のアレに先んじて、抜け駆けのようになってしまったけれども……色々話せたのはとても良かったと思う。この時の会話で深まった理解を還元したくて、こうして書いてみた。

Ubiquityにも、コマンドを作る人というのよりももっと深いレベルでこれからコミットできればなあと思う。

Ubiquityは天才じゃないと使えないのかもしれない。あと、Forth、Mind、日本語プログラミング。 - Nov 18, 2008

熱く色々書いてみたけど、書いたら書いたで落ち着いてきてまたネガティブな見方が増してきた。

複数の動詞を繋げて……と書いたのはやっぱり僕の考えすぎ・妄想しすぎだったっぽい。がんがんコミットしてそういう方向にこれから持って行く、っていうことは可能かもしれないけど、Aza氏の想定はそういうことじゃなかったって事のような気がしてきた。やっぱりもっと単純な考えだったのか？　と。

アイコンより言葉の方が分かりやすいんじゃね？という発想。アイコンをたくさん並べていちいち見比べるよりも、言葉を直接入れちゃえばよくね？という発想。その前提にあるのは「沢山の言葉が頭の中に入っていて、瞬時に適切な物が思い浮かぶ」っていうことだ。「頭の中に入って無い」のも「瞬時に思い浮かばない」のも、Ubiquityを使うためには致命的な問題となる。（だから、前のエントリの最後でもセカンドサーチ的な「動詞の提案」という案を書いたんだけど。）

そう考えると、そういう発想が出てくるのはAza氏が天才だからじゃないのか？　天才が考えたツールは凡人には使えないんじゃないのか？　という疑念がムクムクと膨らんできてしまう。

タイトルが釣りっぽくて誤解されそうだけど、僕だって自分のことは凡人と思ってる。前のエントリに書いたような物が実現されたとしても、自分が使える「動詞」は10個にも満たないだろう、下手したら5個とかそのくらいだ。それ以上はとてもじゃないけど憶えられたもんじゃないだろうと思ってる。いざ使おうとしても「あー、あれ何だったっけなあ、えーと、うーんと、もうここまで（ノドのあたりを指しながら）出てきてるんだけどなああああ」とウンウン唸ってるんじゃないかって気がする。

勝手に妄想補完して勝手に舞い上がって、そしてこうして勝手にまた落ち込んでる自分が恥ずかしいなあ。

という風に考えていた所でplus7さんのコメントに気がついて、plus7さんが紹介してくださったForthというのを見てみた。おおお……これってあの日本語プログラミング言語の「Mind」の元になった物だったのか。こんな物があったとは知らなかった。そうか、「逆ポーランド記法」って、こうして見てみると確かに日本語の文法に似てるんだなあ。

上述した「根本的な問題」＝天才にしか使えないのかもしれない、という点はさておいて、現状のUbiquityが英語的・関数言語的な語順を前提にしているのに対し、日本語に対応するのは逆ポーランド記法的な解釈にも対応するっていう事になるのか、と考えると、プログラムの作り事態に関わる話になってきそうで興味深いと思った。

そういえば、英語式語順は自然な思考の順番に反する（英語ネイティブの人間でも、身振り手振りで説明させると順番が「主語」「目的語」「述語（動詞）」になる）という話もあったなあ。これも何か関係してるような気がしてきた。

Ubiquityが「コマンドラインツール」と書かれているのを見て悲しくなる - Nov 18, 2008

入力が英語だったから日本語圏の人間からはそれこそvimperator等と見分けがつかないけど、英語ネイティブの人にとっては、自分が話す言葉でFirefoxに指示を出せるようにする画期的な仕組み、なのだと思う。

と書いたけど、Firefox Hacks：ブラウザの新境地？　Ubiquityが変える衝撃のブラウザ体験 (1/2) - ITmedia エンタープライズとか完全にギーク向けと評されているのとかを見るにつけ、その思想の伝わっていなさに改めて悲しくなった。いや、僕自身も、昨日本人が喋ってデモしてる所を生で見るまで、全く同じ誤解をしてたんだけども。

確かに、英語で使ってる所を見たら、そう誤解してしまっても仕方がない。でも、操作の様子を注意深く見て欲しい。「email jono」じゃなくて「email this to jono」であることに気がついて欲しい。昔のお粗末なハリウッド映画でありがちな、何故か「コマンド」じゃなく「自然言語」で入力する、今となってはお笑い種のシーン、あれを現実のものにしようとしてるってことに。

昨日のデモの受け売りだけれども、Ubiquityはそれ自体で「万能」は目指していない。また、全てのユーザが自分でコマンドを定義して使うという風なあり方も、想定していない。Firefoxとアドオンの関係のように、必要に応じてさまざまな「動詞」を憶えさせて使うというシステム。それでいて、アドオンに比べてはるかに作るのが簡単だから、「開発者」の数も段違いに増えて、その結果として、エンドユーザが受ける恩恵もずっと大きくなる。これがUbiquityのしようとしている事だと、僕は受け取った。

Googleのトップページに行けば「ググる」という「動詞」をインストールできて、Tumblrのトップページに行けば「たんぶる」という「動詞」をインストールできて、はてな匿名ダイアリーのトップページに行けば「マスダる」という「動詞」をインストールできて、ニコニコ動画のトップページに行けば「ニコる」という「動詞」をインストールできる。そして、「ミクをニコってたんぶる」と入力すれば、ニコニコ動画で初音ミクの動画を検索した結果を自動的にTumblrに投稿できるようになる。「別れたいをググってマスダる」と入力すれば、「彼氏が○○だった。別れたい・・・」のテンプレを見つけてきて増田にエントリを書けるようになる。そういう、動詞の連結による可能性の追及が、Ubiquityのしようとしている事だと、僕は受け取った。（←妄想補完しすぎ？）

という所まで理解できるとなおのこと、このUbiquityという試みが日本語圏で満足に利用できるようになる日の遠さがよく分かってしまうのも、辛い所なんだよなあ……

まず障壁になるのが日本語という言語の特性。分かち書きじゃないテキストを形態素解析しなきゃいけないし、異常に多い同音異義語や語尾の変化にも対応しなきゃいけない。

入力方式も問題だ。前のエントリにも書いたけど、IM経由で入力するっていうだけで操作は全然インクリメンタルじゃなくなってしまう。

文化の違いもある。日本では、自分で入力して何かをするよりも、メニューからぽちぽち選ぶというスタイルの方が主流だ。そのスタイルに慣れた人にとっては、何か入力しなくてはならないということ自体が「面倒」ということになる。（ああ……そういう意味では、そもそも、Firefoxのアドオンもそういわれているのと同様に、自分で何かを組み合わせて使うという発想自体がギーク志向すぎるのか……）

それに、上の文章を書いてて思ったけど、日本語には、サービス名が動詞になるっていう例が少ない気がする。「ググる」はその珍しい「成功例」だ。「ヤフオク」も「ミクシィ」も、「名詞」としてまでは認知されるんだけど、そこから先、「ヤフオクる」とか「ミクる」とかいう風な「動詞」にまではなってない。そういう点もまた、Ubiquityのコンセプトが日本語圏にマッチしにくい所なのかなあ。

とりあえず近々また話せる機会がありそう？なので、その時にはXUL/Migemoだけでなく、セカンドサーチの「目的語を入力したら動詞を自動で提案する」という方向についても意見を聞いてみたい。