Latest topics 近況報告

Minefield 3.1b3preの、タブのドラッグ＆ドロップへの対応 - Dec 02, 2008

ツリー型タブとマルチプルタブハンドラで、Firefox 3.1からの「ウィンドウ外にタブをドロップしたら新しいタブを開く」機能に対応した。子タブを持っているタブをウィンドウ外にドロップしたら子孫タブまで含めて新規ウィンドウに分離され、複数のタブを選択してウィンドウ外にドロップしたら選択されたタブすべてが新規ウィンドウに分離される。という感じ。ちょっと前の分割ブラウザの更新もこれに関係してる。

Minefield 3.1b3preでは、ブラウザのタブをドラッグした時はapplication/x-moz-tabbrowser-tabという型のデータがドラッグデータのリストの先頭に加わるようになった。今までは、ドラッグセッションの「ドラッグを開始した要素」をその都度参照していたようだったので、やっとまともな実装になったなーという感じだ。

分割ブラウザやツリー型タブでは、この型のデータも受け入れ可能なように修正した。そうしておかないと、「application/x-moz-tabbrowser-tab型のデータはドロップできないんだな」と判断されて、タブをタブバーや分割された領域にドロップできなくなってしまう。

Minefield 3.1b3preでの「ウィンドウ外へのドロップ」はどのように実装されているのかを調べてみた所、dragendイベント（ドラッグが終了した時に、「ドラッグが開始された要素」で発行されるイベント）のタイミングで、ドロップ操作に失敗した（ドラッグ操作終了時点でポインタの状態が「ここにはドロップできません」のポインタになっている）場合には「ウィンドウ外へドロップされた」と判断して、新しいウィンドウを開きそのタブとドラッグ元のタブを入れ替える、という風にして実現していた。

この時ドラッグ元のウィンドウでは、tabbrowser要素の_replaceTabWithWindow()メソッドにおいて、新規ウィンドウの第1引数にtab要素を渡して開くだけで処理を終えている。そこから先の「ドラッグ元のタブと新しいウィンドウの内容の入れ替え」は、新しく開かれたウィンドウの初期化処理（BrowserStartup()関数）の方でやってる。

なので、ツリー型タブとマルチプルタブハンドラでは、その両方の処理に割り込むようにした。_replaceTabWithWindow()を呼び出している_onDropEnd()メソッドで、_replaceTabWithWindow()メソッドを呼ぶ直前に割り込んで、切り離されようとしているタブの収集結果がそのウィンドウのタブ全部だった場合には操作をキャンセルしている。また、BrowserStartup()の方では、ウィンドウの第1引数がtab要素だった場合はまずツリー型タブとマルチプルタブハンドラに処理を渡して、何も行われなければ（渡されたタブが子タブを持っておらず、選択もされていないならば）Firefox本来の処理（単一タブの切り離し）に入る、という感じにしている。

ドラッグ元のタブ自身の上にドロップした時までウィンドウの切り離しになってしまうなど、Minefield 3.1b3preの当該機能自体がまだまだ作り込みが甘い感じなんだけど、そういう所にまで手を出すと収拾がつかなくなる＆Firefox 3.1正式版までの間に手を入れられたらまた作業のやり直しになるので、そこら辺は基本的に放置してる。ただし複数のタブを同時に閉じようとした時の問題だけは、閉じるのに失敗したタブが永遠に閉じられなくなるなどの致命的な問題を引き起こすので、ツリー型タブの側で対処している（提出したパッチと同じ事をやってる）。

初パッチ - Dec 02, 2008

だいぶ前に報告した、TabCloseイベントの前後でタブの数が変わることを想定してないせいで複数タブを一気に閉じられない問題は、他のバグにおける変更の影響で結果的にFIXEDになったようだったんだけれども、今日あたりのビルドで試してみたらまた同じ問題が……「何故そうなるのか」と「何が問題なのか」が開発者に理解されてないとこうなるってことですかね。

とりあえずMozillaBuild入れて最新のソースをチェックアウトしてパッチ書いて、モジュールオーナーと思われるmconner氏のメールアドレスをreview欄に書いてみた。

どっかで聞いたけど、こういうのって結局IRCで本人を突っつかないと放置食らう事が多いんですって？　英語チャットか……気が重いなあ。

ルーラーバーでエンコーディングの違いに対応したよ - Dec 01, 2008

英語で書かれた障害報告のメールに返信する時にルーラーがひどくずれていたのが気になってたけど放置してた件について、ルーラーバー 0.3.2008120101で修正した。

今まで、ルーラーの表示サイズの基準には編集領域のdocument.documentElementのfont-sizeを使ってたけど、こちらはエンコーディングが変わっても値が変化しない。それに対して、document.bodyのfont-sizeは、エンコーディングごとのフォントサイズの違いの影響を受ける。ということでbodyの方の値を参照するようにしたら、ルーラーの間隔はおおむね正しいものになるようになった。

ただ、これでもカーソル位置の強調表示のずれは残る。フォントサイズだけでなくフォント自体もエンコーディングによって変わる可能性があり、フォントサイズだけ合わせても、実際の編集領域とカーソル位置検出用の非表示のフレームとでフォントが違ったら、ピクセル単位で位置を拾った時に微妙にずれが発生する可能性がある。そこで、非表示のフレームの方にもエンコーディングの変化を適用させるために、SetDocumentCharacterSet()のタイミングで非表示のフレームの方のエンコーディングも変更するようにした。エンコーディングの動的な変更の方法はこんな感じ。

// this.calculator は非表示のフレームのbrowser要素
var docCharset = this.calculator.docShell
      .QueryInterface(Components.interfaces.nsIDocCharset);
docCharset.charset = aCharset;
var webNav = this.calculator.webNavigation;
webNav.reload(webNav.LOAD_FLAGS_CHARSET_CHANGE);
var self = this;
this.calculator.addEventListener('DOMContentLoaded', function() {
   self.calculator.removeEventListener('DOMContentLoaded', arguments.callee, false);
   // 読み込みが終わった段階でルーラーの表示を更新する（カーソル位置の検出をやり直す）
   self.updateRulerAppearance();
}, false);

最後にリロードしないと表示が変わらない、のかな？（リロードしなかった場合の挙動については未検証）

もっと良い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が英語的・関数言語的な語順を前提にしているのに対し、日本語に対応するのは逆ポーランド記法的な解釈にも対応するっていう事になるのか、と考えると、プログラムの作り事態に関わる話になってきそうで興味深いと思った。

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

UxUを使った、自動テストを伴うデバッグ手法の実践 - Nov 18, 2008

UxU（UnitTest.XUL）を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)

XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。

リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。

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だけでなく、セカンドサーチの「目的語を入力したら動詞を自動で提案する」という方向についても意見を聞いてみたい。

Ubiquityの事を少し見直した - Nov 17, 2008

Firefox Developers Conference 2008に行ってきた。

モバイルとか次世代のWebとかそういうのがメインの話題という風に聞いていたので、僕が行ってもあんまり得る物は無いのかなー、と思ってたんだけど、逆に今まで全然関わり合いがなかった分野の話を聞く良い機会になった。

Ubiquityについては、vimperatorと同類なんじゃね？　誰が喜ぶのこんなの？　という感じにしか思ってなかったんだけど、実際に見てみるとなかなかぶっ飛んだ感じの物だった。入力が英語だったから日本語圏の人間からはそれこそvimperator等と見分けがつかないけど、英語ネイティブの人にとっては、自分が話す言葉でFirefoxに指示を出せるようにする画期的な仕組み、なのだと思う。

他の言語への対応、特に日本語のように英語とはルールが全く違う言語を解釈させるためには、Mozillaだけで全部解決しようとするよりは、Anthyなりprimeなりをライブラリとして利用するような方向の方がまだ現実的なんじゃないかと思った。あと、IMの問題（Enterキーの事とか、そもそもIMを使って入力するから全然インクリメンタルじゃないとか）の解決のためのヒントになるんじゃないかと思って、懇親会の時にAza氏にXUL/Migemoの事を売り込んでおいた。

最大の問題は、これが「能動的に操作する人」「目的語よりも動詞を先に思い浮かべる人」を強く志向しているという事だろう。これについては講演を聴く前後で認識が変わらなかった。「受動的に操作する人」「動詞よりも目的語を先に思い浮かべる人」のためにはどういうUIが良いのか？　という事についてのAza氏の考えを聞いてみたいところだ。「そういう人はそもそもPCを使うべきではない（そういう人のために設計されるのが、単機能に特化した物、例えば電子辞書であるとかデジカメであるとかメール送受信専用端末であるとか）」ってのも、まあ、一つの考えだと思うけど。

それ以外の話。

パネルディスカッションでMozillaのえらい人が「日本の状況は他と違うと思うか？」みたいな質問に対して「すごく違う」と答えていたけれども、「stupid」ではなく「different」と言っていた事に気がついて、ああこれが政治的に正しい喋り方っていうものなんだなあと、本題とは関係ないところで感心した。

組み込みの話が進まない理由について、組み込み屋さん的には「一緒に頑張って仕組みを作っていきましょう」みたいに協力的な態度で来られれば「よしやろう」と思えるけど、Mozillaみたいに「いい物作りましたんで後はみんなが勝手に開発して使ってね」という態度だと使う気になれない、みたいな。Mozillaが高飛車すぎるのか、日本の組み込み屋さんがベッタリ甘々な関係に慣れすぎているのか……まあ企業対企業という観点で見るとMozilla何様のつもりやねんって感じだけど、Mozillaは理念と利益だったら理念の方を取る（むしろ、取らなければならない）団体だということを考えると、当然の事かなー、と。