デスクトップとウェブ・アプリを結ぶかけ橋へ Part2―SSBとAdobe AIR

次の記事

$25M集めた後で、 MeeVeeが身売りを模索中

この記事は、ゲストのMatthew Gertnerの執筆によるもので、2008年3月22日の彼の投稿Mozilla Prism―デスクトップとウェブ・アプリを結ぶかけ橋への続編になる。

Matthewは、今年に入ってAllPeers閉鎖されるまで同社の共同ファウンダー兼CTOだった。現在Mozillaで、前回の投稿のテーマであったPrismプロジェクトに携わっている。彼のブログはこちらをどうぞ。


先週わたしが書いた単一サイト・ブラウザ(SSB)についての記事には、多くの人々が多少まごついたらしい。SSBは、一見したところでは、URLアドレスバー、戻る/進むボタン、タブ、その他多くの便利な機能がすべて剥ぎ取られた普通のブラウザにすぎないように見える。大いに退歩したように見えるこの代物になぜ大騒ぎしなければならないのだろうか?

わたしは、最近高まってきた関心の背景をさらに詳しく説明するため、Bubbles、Fluid、prosmという、3つの主要製品を取り上げることにした。さらに、これら3製品(多くの点できわめて近似している)を、これとはまた別のアプローチでデスクトップとウェブ・アプリの統合を目指す、さらに野心的な試みであるAdobe AIRと比較してみた。

Bubblesは、最初に生まれたの本物のSSBと言っていいだろう。3D3R Softwareによって開発されたが、最初のバージョンが発表されたのは2005年末、「単一サイト・ブラウザ」という用語が作られるはるか以前だ。同社のCEO、OhadEder-Pressmanからわたしが聞いた説明では、彼がBubblesを思いついたのは、その2,3年前、OutlookからGmailに乗り換えた時だったという。彼は、突然、メールを見ようとするたびにブラウザを起動してウィンドウを開き、必要なタブを見つけて選択するという、一連の手順を踏むことを余儀なくされた。そのうえ、新着メールがあるかチェックしたくても、デスクトップには目に見える表示がないので、その度に同様の手順を踏まなくてはならない。あらゆるウェブアプリはデスクトップともっと密接に統合されることによって大きな効果が得られると直感して、彼は数名のプログラマーに命じてこの仕事に着手させた。

たいへん小さなBubblesのインストーラ(わずか250kb)をダウンロードして実行すると、Bubbles のSetting窓が現れる。GmailやFlickerなどのウェブ・アプリがあらかじめ設定されたメニューもここにある。

そのリスト上でGmailの横にあるGOボタンを押すと「Bubble」(〔特定サイト専用の〕スタンドアローンの窓)が開く。そこには、Gmailのログイン・ページが表示されている。着信のお知らせやGmailへのクィック・アクセスを可能にするアイコンが、システムトレイに表示される。わたしが自分のいつも使っているGmailアカウントにログインすると、お知らせがポップアップして、受信トレイに3通の未読メールがあると知らせてきた。未読メールの数は、このアプリのタスクバーボタンとシステムトレイにあるアイコンのツールチップで、いつでも確認することができる。新しいメールが届くと、またお知らせがポップアップして、未読メール数が更新される。その他にも、ドラッグ・アンド・ドロップが使えたり(Flickerのbubbleで写真をアップロードするのに使われている)、サイト独自のシステム・トレイ・メニューなどもある。

当然ながら、Bubblesは、アプリケーションにこうした機能を付け加えるためには、特別な設定が多少必要だった。わたしはこれがどのように動くのか興味があったので、自分だけの独自のBubble化したウェブアプリを作ることにした。第一段階はいたって簡単で、BubblesのSetting窓の上部にあるURLボックスにサイトのアドレスを入力するだけでよかった。「www.techcrunch.com」と入力すると、予期したとおりTechCrunchが専用のウィンドウで現れ、そのTCのアイコンが自動的にシステムトレイに表示された。もちろん、これだけでは格別に便利だということはない。わたしは試しに、サイト独自のスクリプトを書き加えてみた。サイトごとに、Bubblesは「Smart Bubble」と呼ばれるXMLファイルを作成する。Gmailのスクリプトをひな型としてJavaScriptのスニペットを書き、TechCrunchのトップページが10分ごとに更新されるようにした。最後の更新の後に新しい投稿があれば、ポップアップのお知らせが表示される。これが正しく動くようにするには若干の試行錯誤が必要だったが、全体で30分しかかからなかった。関心があればここでわたしのスクリプトが手に入る。

ところが、その後Bubblesはレーダー画面から姿を消してしまう。ウェブサイトのコンテンツも2006年以来ほとんどアップデートされないままの時期が続いた。Ohadが私に説明したところによると、この製品はリリースされた当初、時代に先駆けすぎていて、広く一般公衆の興味をひくように説明するのが不可能に近かったということだ。ただ比較的少数(Ohadによると数万のユーザーがいるという)ではあっても熱心なユーザーによるコミュニティーが形成されている。今やPrismとFluidの登場によってSSB(シングル・サイト・ブラウザー)という概念がポピュラーなものになりつつある。3D3R はそこで再びボールを拾いあげ、Bubblesの次のバージョンを開発すべく開発チームを結成した。次期バージョンは1ヶ月以内にリリースされるものと見られている。現在このサービスはWindows版のみでで、ウェブページのレンダリングにはInternet Explorerのエンジンが用いられている。Ohadが私に語ったところによると、Mac版も開発中だが、Appleが使っているWebKitレンダリング・エンジンを採用するために若干の手直しが必要かもしれないという。

一方、FluidはMac版のBubblesだ。(Mac OS X 10.5 Leopardが必要)�
�3MBのZIPファイルを解凍してFluidを実行すると「特定サイト専用ブラウザ(Site Specific Browser)を設定する」という簡単なダイアログボックスが現れる

Bubblesとは違って、すぐ使えるようにあらかじめ特定のサイトが設定されてはいない。その代わり、Google Codeを利用したユーザー・コミュニティーのレポジトリが存在し、他のユーザーが投稿したスクリプトが利用できる。(現在は Campfire、Gmail、Google Readerなどが利用可能)。スクリプトのスタイルはBubblesとほとんど同一だ。通知窓をポップアップさせたり、ドック・メニューにアイテムを追加したり、ドック・アイコンにバッジやサウンドを付加したりする機能が利用できる。Fluidがデフォルトで使っている低解像度のファビコンでは満足できない場合、Flickrのグループに人気サイトの100以上の高解像度のアイコンが投稿されている。

3番目のPrism だが、ダウンロードのサイズは3者の中で群を抜いて大きいことが目をひく( 30Mb近くある)。しかし、これはFirefoxのエンジンがまるごと含まれているためだ。PrismはOSがデフォルトで使用するブラウザのコンポネントを使わない。逆にFirefoxのユーザーであれば、500kBのエクステンションをダウンロードするだけでよい。Prismのアプリケーション設定は既存のウェブ・ブラウザ内から直接行う。この場合も最初のステップはダイアログボックスに必要なURL、生成したいアプリケーションの名称などを入力するところから始まる。Prismの最大のメリットはマルチプラットフォームのサポートだ。Prismは Windows、Mac、Linuxで作動する。逆に機能の面ではいささか物足りないかもしれない。ドックやシステム・トレイのメニューをカスタマイズする機能もない。(ただし、これについては次のバージョンで追加される予定)。

現在のところ、この3者を比較したかぎりでは、どれが決定的に優っているとも決めにくい。Fluidは通常のブラウザに一番近い使い勝手だ。それぞれのアプリケーションごとに、メニュー、管理の履歴、ブックマーク、ユーザー・スクリプトなどの機能がサポートされている。Firefoxのユーザー、あるいはマルチ・プラットフォームのサポートが必要なユーザーにはPrismだろう。Bubblesはアップデートが必要な箇所もあるが、一番完備したAPIを提供している。何人ものデベロッパーが積極的に活動しているので、次のリリースでは大幅な機能の強化が実現すると期待してよいだろう。これら3種のSSBに共通した最大の課題は、人気のあるウェブサイトをアプリケーション化するためのユーザー・スクリプトのライブラリーが不足していることだ。この点、単に所望のサイトを一つの窓の中で実行するだけでは意味が薄いという批判は正しいだろう。(1クリックでアクセスできるのはそれでもメリットではあるが)。ロケット科学者でななければ独自のスクリプトが書けないというわけではないが、それでもあなたのお祖母さんにお勧めするわけにもいかない。したがってこういった製品がメインストリーム・マーケットに食い込んでいくためにはカスタム・スクリプトのライブラリが必須である。この点で進歩の足を引っ張ることになっているのがBubble、Fluid、Prismがそれぞれに似ていながら微妙に互換性のないAPIを設定してしまったことだ。各社がAPIの標準化について協議することが望まれる。スクリプトを共通化して、一度コードを書くだけで同時にすべてのアプリケーションで作動するということになれば、大いに開発者のインセンティブが上がるものと思われる。

こうしたシングルサイトブラウザと共に語られることの多いのがAdobe AIRである。ウェブとデスクトップ・アプリケーションのギャップを埋めようという、基本的に同じニーズ応えようとするものだが、そのアプローチの仕方は根本的に異なる。まず、ユーザーはダイアログボックスの中に自分で何か入力をして、ユーザー自身のスタンドアロンのWebアプリを生成するためにAdobeAIRをダウンロードすることはできない。そのかわりAdobeは、プログラマーが既存のWebアプリやWebサービスの上に、洗練されたAIRアプリケーションを作ることができるよう、高度なデベロッパー向けツールを提供する。

したがって、骨組みだけのアプリケーションにユーザーがスクリプトのスニペットを書いて機能を拡張したりする手法に比べると、AIRは古典的なソフトウェア開発に近い。また、AIRは2つのオプションを提供する。標準的なウェブ開発手法―HTMLプラスJavaScriptなど―を利用するか、アドビ独自の強力なFlashエンジンとFlex言語を利用するかだ。Adobeプラットフォームのエバンジェリスト、Ryan Stewartは、この2つのアプローチの違いをメールで説明してくれた。

どういう場合にFlashを使い、どういう場合に標準的なWeb開発手法を使うかは、AIRの場合簡単です。自分の知っている方を選べばよいのです。もしデベロッパーがHTML、CSS、JavaScriptを利用して説得力あるすばらしいサービスを作れるのであれば、なにもFlashやFlexを無理に使う必要はありません。ただわれわれは、それら両方のコミュニティをAIRでサポートしたいと考えています。AIRのよい点は両方同時にアクセスできる点です。Flashには、写真やビデオの編集ができるグラフィックスの操作などで多くの利点がありますが、AIRを使えばHTMLアプリケーションの中にJavaScriptをエンベッドせずに、そういった機能を直接実装できます。AIRのJavaScriptから直接こうしたFlashAPIをコールして、自分のHTMLに適用することもできます。これでいろいろ面白いことができる可能性が広がります。逆にもしユーザーがFlashのデベロッパーであれば、ウェブ上に大量に公開されているサードパーティのJavaScriptライブラリをすべてAIRで使えますし、Flashから直接コールすることもできます。つまり両者の「いいとこ取り」で、最良の組み合わせを使うことが可能でしょう。標準規格に基づく開発手法だけを利用したいのであっても、AIRの中でもちろん可能ですし、推奨もされています。

AIRは�
��Adobeが全力を挙げて開発し、プロモートしている。ツールのサポートもすばらしく、ウェブの世界でも関心が高い。もし十分な数のベンダーがAIRの利点に納得し、自社のWebアプリにデスクトップ機能を付加するため採用することを決めれば、他のSSBにとっては厳しい競争となるだろう。どんな結果になるか、この点、APIの標準化が鍵となりそうだ。もし単一サイト・ブラウザー(SSB)共通のデザインのAPIが設定されれば、ベンダーがデスクトップ用のコードを直接Webアプリに取り込むようになることにも現実性が出てくる。もしこれが実現すれば、たとえばGmailやFlickrのようなアプリケーションをBubblesやFluid、Prismにロードすると、使いやすいメニューやポップアップ、通知など便利な機能が面倒なカスタマイズを一切必要とせず、始めからそのまま使えるだろう。ユーザーがスタンドアローンのアプリケーションをダウンロードしてインストールすることをますます好まなくなっていることを考えると、これは強力なメリットになるかもしれない。

[原文へ]

(翻訳:Namekawa, U)