MozillaのFlashプレーヤーShumwayがAmazonのプロダクトビデオを再生

MozillaはAdobeのサポート終了に備えて、FlashプレーヤーShumwayを急遽自作した。そのコードはすべて、オープンスタンダードに基づいている。なお、Shumwayという名前は、あの猫を食べる毛むくじゃらのエイリアンとは無関係だ。このプロジェクトは2012年にスタートし、Mozillaの実験用のNightlyビルドには前から含まれていたが、Nightlyのユーザでさえ、気が付かない人が多かった。

しかし今日から(米国時間2/13)Mozillaは、AmazonのプロダクトビデオにShumwayで対応し、今後デフォルトではShumwayプレーヤーを使うことになる。ただし、Amazonの提供ビデオという意味ではなく、プロダクトビデオのみだ。AmazonのAmazon Instantのビデオは、Silverlightを使っている。

Shumwayの開発にはかなり時間をかけたとはいえ、これ自体、小さなステップにすぎないようだ。でも、Web上にFlashムービーがあるかぎり、今後はShumwayが使われることになる。

今はWindows(Vista以降)とOS Xだけだ。H.264のデコーダを使うので、LinuxやWindows XPでは使えないかもしれない(XPは、とっくに過去のものだけど)。

でも、Shumwayの互換性がもっと完全になったころには、Flashはほとんど使われていない可能性もある。MozillaのShumway担当プログラムマネージャChris Petersonも、ある程度そのことを認識している

“ShumwayはFlashがWebから消えていくときに登場した。でも、AdobeやブラウザがFlashプラグインをサポートしなくなっても、Flashコンテンツのロングテールは必ず残存する”、と彼はShumwayの未来的存在意義を述べている。.

Googleは、FlashファイルをHTML5のコンテンツに変換するSwiffyを提供し、MozillaのようにFlashの自社製代替ソフトを作っていない。デベロッパは、Webサイトを公開する前にFlashコンテンツをSwiffyを使って変換すればよい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


FirefoxがiOSにやってくるかもしれない


この一年Mozillaは、iOS版Firefoxは作らない、なぜならAppleはiOS上でMozillaのウェブエンジンを使うことを許さないからだと断言してきた。しかし新たなCEOを迎え、Mozillaの立場は変わりつつあるようだ。今日(米国時間12/2)オレゴン州ポートランドで行われたMozillaの社内イベントで、同社は自社ブラウザーをiOSに載せる必要があると語った。

「われわれは、われわれのユーザーがいる所にいるべきだ」とFirefoxのリリースマネージャー、Lukas Blakkが今日Twitterに書いた(MozillaのFirefox担当VP、Jonathan Nightingaleを引用したものと思われる)。「だからFirefoxをiOSで動かす」。

Appleは自社プラットフォーム上でサードパーティー製ブラウザーエンジンを動かすことに関して、ことごとく厳格である。例えば、現在ChromeやOpera等のサードパーティー製iOSブラウザーがiOS上で動作できるのは、Apple製のJavaScriptとレンダリングエンジンを使っているからだ ― あるいはOperaの場合は、サーバー上でレンダリングを行った後端末に送っている。

MozillaがどのようにFirefoxをiOSに持ち込むつもりなのかは不明だが、Appleがプラットフォームをサードパーティー製ブラウザーエンジンに開放するとは考えにくいので、Appleの技術を使うことになる可能性が高い。その場合でも、Firefoxアカウントやブックマーク同期ツール等、現在Android版Firefoxで提供している機能をサポートすることはできる。

来年はForefoxにとって重要な年になる ― そして同社のブラウザーをいくらかでも復興させたい年に。今どきのユーザーは、あらゆるデバイス上で同じブラウザーを使いたがる。そうすることによって、ブックマークやパスワードの同期が非常に簡単になる。一時MozillaがiOS用にFirefox Homeを提供していたのも正にこの理由からだったが、2年前にプロジェクトは終了した

本誌ではMozillaにコメントを求めているので、情報が入り次第この記事を更新する予定だ。

[原文へ]

(翻訳:Nob Takahashi / facebook


MozillaがFirefox Developer Editionをローンチ

Firefoxが今日(米国時間11/10)10歳を迎え、Mozillaはそのお祝いとして二つのプロジェクトを立ち上げた。それらはプライバシーに関する新たな取り組みと、Firefox Developer Edition(Firefoxデベロッパエディション)だ。後者は、デベロッパのためのツールを前面に打ち出したFirefoxのニューバージョンだ。

このDeveloper Editionに、革新的なブラウザを期待していた人は、がっかりするかもしれない。基本的にそれは、黒を基調とするテーマと角型のタブのあるFirefoxで、それまでアドオンとして提供されていたデベロッパツールがすべてある。まず、Android上のChromeとiOS上のSafariをデバッグするためのFirefox Tools Adapter(”Valence”と改名)、ブラウザ上でWebアプリケーションを開発できるWebIDEなど。それに、前からブラウザにあったデフォルトのデベロッパツールが、見つかりやすくなった。

Mozillaのデベロッパツール担当ディレクターDave Campが、今日の発表声明で次のように述べている: “デベロッパ用のブラウザがあることによって、日々のWeb閲覧体験をデベロッパ向けにカスタマイズできる”。彼によると、“デベロッパが開発やデバッグのためにいろんなプラットホームやブラウザを行ったり来たりしていると効率が非常に悪い”。Firefox Developer Editionを使えば、“開発のワークフローを一箇所に集中できる”。

デベロッパにとってありがたいことに、このバージョンは今あるFirefoxと並行にインストールでき、互いに干渉しない。

また実験的なリリースチャネルであるAuroraのユーザは、そのリリース過程でDeveloper Editionにリプレースされるから、とくに何もする必要はない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mozillaがデベロッパ専用の新しいブラウザを来週ローンチする

Mozillaが今日(米国時間11/3)、デベロッパ専用の新しいブラウザを来週リリースする、と発表した。具体的な詳細はなく、ただ匂わせただけだが、リリースは11月10日だそうだ。その日は、Firefoxの10歳の誕生日でもある。しかしMozillaによると、その新しいブラウザを使えばデベロッパは、ほかのツールをとっかえひっかえ使わなくても“Web全体を”デバッグできるのだそうだ。

発表文から引用すると: “Webのために何かを作るときは、お互いに相互運用性のない数多くのツールをデベロッパは使わなければならない。プラットホームやブラウザによっても使うツールは違うので、それが作業の足を引っ張り、生産性を損なう”。

この新しいブラウザでは、MozillaのWebIDEプロジェクトFirefox Tools Adaptorを使って、Firefoxの開発ツールをほかのメジャーなブラウザに対しても使えるようにする。ただし今回Mozillaが言っているのはそこまでで、詳細は来週にならないと分からない。

Mozillaはオープンソースの組織として、毎週のプロジェクト会議をストリーミングし、ユーザインタフェイスのアップデートの設計に関する研究も、もっとも実験的なリリースチャネルに出る前に共有することが多い。だから、今回の秘密めいた発表の仕方は、やや異様だ。

でも、おそらくFirefoxのフォークとしてデベロッパ専用のブラウザをMozillaが提供することは、理にかなっている。Mozillaはここ数年、デベロッパツールに重点投資をしてきたし、やや議論を招(よ)んだFirefox OSによるモバイルへの進出でも、さまざまなツールをローンチした。しかし外部ツールのこのような多産によって、ブラウザ内蔵のデベロッパツールが、おかしな立場になってきた。Firefoxの最新バージョンではブラウザのカスタマイズがずいぶん容易になったが、デベロッパツールにはますます陽が当たらなくなっていたのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


今度のFirefox BetaではデスクトップでWebRTCビデオチャット、AndroidでChromecastやRokuへのビデオキャスト

MozillaがデスクトップとAndroid向けのFirefox betaチャネルに今日(米国時間9/4)、最新のアップデートをローンチした†。このところずっと、それほどエキサイティングな変化はなかったが、今回のアップデートにはエンドユーザ向けのおもしろいツールが二つある。[†: 原注: 可利用になるのは数日後。]

Android上では、ブラウザの新機能、ビデオを“デバイスへ送る”を試せる。サポートされているデバイスは、RokuとGoogleのChromecastなどだ。デスクトップでは、Firefoxに内蔵されたWebRTCによるビデオチャットを試せる。Mozillaはこれを今年の初めごろから、実験的なチャネルでテストしていた

ブラウザがプラグインなしでオーディオやビデオを呼び出せる標準機能WebRTCは、Firefoxの上で簡単に使えるが、デフォルトでは露出していない。”customize”ウィンドウへ行ってスピーチバブルを探し、それをメインのツールバーにドラッグする(右図)。そしてそのバブルをクリックすると、誰かと共有できるリンクができ、相手もクリックすればチャットがスタートする(つねに無料だ)。

そのバックエンドではMozillaがWebRTCのスペシャリストTokBoxとパートナーしている。ビデオチャットはChromeとFirefox間でもできるが、ぼくが試したときには、接続がときどき落ちた。Mozillaはこの機能が未完成であることを承知していて、今のところ“実験的”のラベルをつけている。もちろん、それでも試す価値は十分にある。

Android上のアップデートの主役は、ChromecastやRokuに対するビデオのキャスティングだ。Flashを使わずHTML5でビデオをサーブしているCNNなどのビデオは、Androidのあるモバイルからリビングの(RokuやChromecastが生きている)テレビへストリーミングできる。Chromecastの場合はなんらセットアップは要らないが、RokuではFirefoxチャネルをインストールする必要がある。

なお、HTML5のビデオプレーヤーを独自にカスタマイズしているサイトでは、“Send to”アイコンがないことがある。でもその場合でも、ビデオをスタートするとURLバーに”Send to Device”アイコンが出るから、それをクリックするとよい。

以上はしかし、あくまでもベータだから、バグもきっとある。まあ、ベータテスターとして参加するつもりで試用し、問題を見つけたらここに報告するとよい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mozillaのasm.jsを使った初の商用ゲームDungeon Defendersが登場

あまりにも長年、Webのゲームといえば、それがブラウザ上でスムーズに動くためには必ず何らかの(往々にして怪しげな)プラグインをインストールしなければならなかった。最近はWebGLなどの新しい技術のおかげでやや変わってきたが、でもJavaScriptが元々スピード狂ではないために、プラグイン不要のゲームはなかなか普及しなかった。しかしMozillaは、この状況をasm.jsで変えようと努力してきた。このJavaScriptのサブセットは、Firefox上できわめて高速に動き、そして今日の発表によると、asm.jsを使った初めての商用製品としての3Dゲームがローンチの運びとなった。

その最初の作品はTrendy EntertainmentDungeon Defenders Eternity、同社の人気シリーズの最新作で、タワーディフェンス系にRPGの要素も加味したゲームだ。Webバージョンにアクセスするためには、Steamでデスクトップバージョンを買うか、今夜あたりAndroidバージョンを買うかしなければならない。そうすれば、playverse.comでWebバージョンを遊べる。

Mozillaによると、Webバージョンはビジュアルもゲームプレイもネイティブのデスクトップバージョンとまったく同じだ。 スピードもasm.jsのおかげでネイティブに近い。asm.jsのほかに、3DグラフィクスにはWebGL、位置感のあるオーディオはWeb Audioを使っている。

Trendy EntertainmentのCEO Darrell Rodriquezはこう言う: “Webはすでにカジュアルゲームでは大きな世界だが、でもMozillaのasm.jsがあれば、プラグインを使わないWeb上の本格的なゲームが可能だ。Dungeon Defendersは、URLをクリックしてからロードまでほんの数秒だから、ゲーマーたちも十分満足するスピードだ”。

今のところは一つだけだが、asm.jsとプラグイン要らずのゲームには業界全体の期待と取り組みがある。昨年はMozillaが初めて、asm.jsを使用する3Dゲームをデモした。でも本格的に普及するためには、主なブラウザのほとんどがasm.jsをサポートする必要がある。しかしGoogleは、今のところ無関心だ(ベンチマークにはasm.jsを含めたから、気にはしているらしいが)。Microsoftのstatus.modern.ieには、asm.jsの名前すら登場しない。当面はサポートする気がないのだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mozilla、開発中の高性能JPEGエンコーダーの最新版をリリース

Mozillaが、JPEGエンコードに用いるmozjpegイメージエンコーダーの最新版をリリースした。新しいバージョンは既にfacebook.comにてテストが行われた。ちなみにFacebookはMozillaに対してプロジェクトの継続を目的として6万ドルを寄付している。

読者の方はよくご存知のことだが、ウェブで用いられている画像フォーマットといえばPNGとJPEGがほとんどを占めるという状況だ。MicrosoftやGoogleは独自フォーマットをリリースしたりということもしているが、広く利用されるようにはなっていない。GoogleはChrome利用者向けに自サイトでWebPをアピールしているが、マウンテン・ビュー外部ではほとんど利用されていないといった状況だ。

Mozillaはバージョン2.0ではベースラインおよびプログレッシブの双方で、平均5%の軽量化を行うと主張している。画像によって圧縮率は当然異なるが、最大で15%の軽量化を見込んでいる。もちろん5%に至らないものもある。最初のリリース時にはプログレッシブJPEGのみに対応していたが、今回からはベースラインにも対応してきている。

MozillaのCTOであるAndreas Galは、WebPやMicrosoftのJPEG XR、あるいはその他のロイヤルティフリーの新フォーマットは、導入の手間などを考えればJPEGにとってかわるものとなり得ないと考えている。そのようなわけで、Mozillaは最も広く利用されている不可逆圧縮フォーマットであるJPEGに注力しているわけだ。

また、写真が多く投稿されるFacebookにとってみれば、ファイルサイズを小さくすることができれば、サイトの読み込み速度があがり、帯域確保にかかる費用が安くなるという意味がある。そのような観点からFacebookはプロジェクトへの協力を行なっているわけだ。

Facebookのソフトウェアエンジニアリング部門マネージャーのStacy Kerkela曰く「Facebookは、Mozillaが見た目を犠牲にすることなく、より小さなJPEGファイルを生成するエンコーダーを構築するプロジェクトを支援しています」と述べる。「mozjpeg 2.0により、画像のオプティマイズが行えるようになり、Facebook上での交流がさらに盛んになるだろうと期待しています」とのこと。

今年はじめに最初のバージョンをリリースしたときにMozillaが言っていたように、新たなバージョンではビデオエンコーディングで用いられてきたトレリス量子化を利用している。またインプットにJPEGを用いることができるようになっていて、既存イメージの再圧縮にも活用しやすくなっている。また、各種改良作業により、既存JPEGエンコーダーとの互換性もアップしている。

Mozillaが新たなフォーマットを採用すれば、そのフォーマットが広まるきっかけとはなり得る。しかしそうした動きを生むためには、新フォーマットが既存の形式に対して明白な利点を持つことが必要だ。WebPなどがJPEGではサポートしていない機能(アニメーションなど)を持っていることは認めるものの、しかしMozillaではそうした新形式を迅速にサポートしようとは動いていない。新形式を求める努力により、進化がもたらされるであろうことはGalも認めている。しかし新たなフォーマットを求める動きはパテントによって保護されているケースも多く、Mozillaとしても積極的なサポートには動きにくい状況であるのだ。そうした中、Mozillaとしてはビデオ圧縮フォーマットのDaalaのサポートの方が先になる可能性の方が高そうだ(静止画像にも適用可能なフォーマットだ)。こちらの方はXiph.Orgとのパートナーシップにより開発中だ。

原文へ

(翻訳:Maeda, H


MozillaのFirefoxブラウザにHTML5アプリケーションの開発環境WebIDEが一体化される

今日から(米国時間6/23)、FirefoxのNightlyリリースのユーザはWebIDEを試用できる。それは、HTML5アプリケーションのための開発環境で、それをブラウザ本体が内蔵しているのだ。

Firefoxを前から使っている人なら、Bespinという、やや似たようなプロジェクトを覚えておられるだろう。それもやはり、ブラウザが内蔵しているコードエディタだった。Bespinはやがて立ち消えになり、その後Cloud9 IDEのコアとして利用された。しかしBespinの視野は、かなり限定されたものだった。

Mozillaの主席デベロッパエヴァンジェリストChristian Heilmannによると、WebIDEは(エディタとしても優れているが)単なるコードエディタではない。むしろWebIDEには、デスクトップとモバイルのレスポンシブな(responsive, 反応性/応答性の良い)アプリケーションを作るための完全なツールチェーンがある。FirefoxOSのシミュレータまであるので、このOS用のアプリのテストは簡便にできるが、もちろんふつうの現代的なブラウザ用のアプリケーションも十分に作れる。

WebIDEにはアプリケーションのサンプルがあり、デベロッパはそれを自分の仕事のスタート台として利用してもよい。それを利用すると、ほんの数クリックで新しいWebアプリケーションがブラウザ上で動きだす。 そのサンプルアプリケーションには、どのアプリケーションでも必ず必要なコードがすべて書かれていて、アプリケーションに変更を加えて再ロードするのも手早く簡単にできる。アプリケーションの検証と再パッケージングは、WebIDEが自動的に行う。

Heilmannによると、今広く使われているIDEの多くがWebアプリケーションの開発に向けて最適化されていないので、デベロッパはセットアップや構成に苦労しなければならない。それはとくに初心者にとって障害になる。でもWebIDEなら、アプリケーションを書き始めるために必要なものはすべてブラウザに内蔵されている。

Mozillaでデベロッパツールを担当しているDavid Campによると、WebIDEのコードエディタはCodeMirrorをベースとし、コード分析フレームワークtern.jsを統合していて、たしかにこのIDEの中核ではあるが、ユーザであるデベロッパは自分の好きなエディタを使い続けても、いっこうにかまわない。

WebIDEのエディタを使わない場合でも、デベロッパはWebIDEのインタフェイスからランタイムの管理やアプリケーションの検証が十分にできる。そういう機能へのアクセスの仕方は三通りある: 1)WebIDE自身がコードの変化を監視する、2)デベロッパがコマンドラインでAPIを利用する(そのためのツールをもうすぐリリース)、3)サードパーティのIDEやエディタのベンダがこれらのAPIを使ってMozillaのサービスを自分の製品に統合する。

HeilmannとCampご両人によると、今作業を進めているのは、WebIDEとFirefoxのRemote Debugging Protocolの統合だ。これによりデベロッパは、わざわざエミュレータを使わなくてもデスクトップやモバイルのブラウザ上で、今書いているアプリケーションを容易にテストできるようになる。今のところそれは、デスクトップとAndroid上のFirefoxと、Firefox OS用のアプリケーションが対象だが、今後はプロトコルアダプタを作ることによって、Chrome for AndroidやSafari on iOSでも使えるようになる。プロトコルアダプタは、Campによると、いろんな難題の打開のめどはすでに立っているから、数か月後には完成品を提供できるという。

今のところWebIDEは隠れ機能になっているので、Firefox Nightlyをインストールしたらabout:configをURL欄に入力し、devtools.webide.enabledを’true’にする。Mozillaによると、数週間後にはWebIDEをデフォルトで有効にし、そして数か月後にはFirefoxの正規安定版にも搭載される予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


MozillaがWebRTCプロバイダのTokBoxと組んでブラウザ本体に汎用コミュニケーション機能を持たせる実験を開始

Mozillaが今日(米国時間5/29)、WebRTC APIのプロバイダTokBox提携してブラウザ本体にWebRTCによるコミュニケーション機能を持たせる実験を開始する、と発表した。当面その実験は、FirefoxのNightlyリリースに実装されるだけなので、一般ユーザの利用はまだ先の話だが、たいへん興味深い取り組みであることは確かだ。

WebRTCは、ブラウザ間でリアルタイムデータやオーディオ、ビデオなどをプラグイン不要で送受するための規格で、FirefoxとChromeはすでに通常バージョンでサポートしている。Microsoftのブラウザはこれをサポートせず、独自の規格をスタンダードとして提案している。

MozillaのFirefox担当プロダクト管理部長Chad Weinerによると、同社は現在のコミュニケーションおよびソーシャルネットワーキングの市場が分断化されていることを懸念している。

Weinerは次のように語る: “Mozillaなら、それらの壁を壊してあげることができるのではないか、と考えた。つまり、とてもたくさんの人が使っているブラウザの本体に、オープンで相互運用性に富むコミュニケーション機能が備わっていれば、よいのではないか”。

またWeinerによると、長期的な展望としてはMozillaがWebRTCのエコシステムを作って、それがすべてのデバイスとオペレーティングシステムを横断する、ないしカバーする形にしたい。そもそもWebRTCのねらいが、それだから。WebRTCを使ったサービスはすでにいろんなものが、完成製品に近い形で作られてはいるが、どれもまだ実験段階だ、と彼は言う。

Mozillaがこの機能の実験のためにパートナーとしてTokBoxを選んだことは、意外ではない。TokBoxは2012年にスペインのキャリアTelefonicaに買収されたが、長年、WebRTCの世話役のような役割を担ってきた。現状のWebRTCのプロトコルは帯域の変動に対する自己調整機能がない、マルチユーザチャットがサポートされていない、などの短所があるので、TokBoxのような有能な第三者が介入して、そういう高度な機能を構成し提供する必要があるのだ。TokBoxのビデオチャットがFirefoxのサポートをローンチしたのは、1年あまり前だ

ぼくが見たかぎりでは、その新しい実験的WebRTCアプリケーションはまだNightlyに登場していない(隠れ機能になっているのか…)。NightlyのURLはここなので、いずれ近いうちに、ダウンロードできるようになるだろう。安定版ではないことを十分承知のうえで、試してみられることを、おすすめしたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Firefox OSのデベロッパ向け標準参照機Mozilla Flameが170ドルで予約受付を開始

Firefox OSはこれまで、いろんな形のローンチを経験してきたと思われるが、何はともあれ今回は初めて、公式の“参照機”(reference device)というものを提供することになった。それは機種名がMozilla Flameで、T2MobileとMozillaのパートナーシップから生まれた。今は予約受付中で、アンロック、全世界送料無料で170ドルだ。

Mozilla Flameは中級機に属し、プロセッサは1.2 GHzデュアルコアQualcomm Snapdragon、画面は4.5インチ854×480ピクセル、リアカメラ5mp、フロントカメラ2mp、内蔵ストレージ8GB、デュアルSIMをサポート。しかし最大の売りは、256MB–1GB(可変)のRAMだろう。可変というのはデベロッパが構成可という意味だから、一台でアプリのメモリサイズ適性をテストできるわけなのだ。

したがってこのFirefox OS機は、これまでのデバイスよりも広い対象を視野に入れており、“オフィシャル”を名乗っていることも相まって、Firefox OSの標準機、デベロッパにとって文字通りの参照機なのだ。Firefox OSそのものは未だにモバイル市場で影が薄いが、姿勢としては、あなどれないと感じさせる。発売は、4週間後の予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mozillaもついに折れる: HTML5のDRMをFirefoxに実装と発表

Mozillaが今日(米国時間5/14)、同社のFirefoxブラウザにHTML5のDRM規格を実装する、とためらいがちに発表した

インターネット上でストリーミングされる著作権物コンテンツが、このところますます増えているので、権利者たちはFlashやSilverlightなどに依存することなくHTML5本体にDRMが標準的に実装されることを心待ちにしていた。しばらく前にMicrosoftとGoogleは、反対論者も少なくないW3CのEncrypted Media Extensions(EME, メディア暗号化拡張機能)の実装を決め、それにより彼らのブラウザのHTML5がDRMコンテンツを扱えるようにした。

しかしMozillaは一貫して態度を決めず、前CTO(そして短命のCEO) Brendan Eichはブログに強い口調で、HTML5の現在のDRM規格はユーザとデベロッパにとって不利である、と書いた。彼はMozillaがEMEを実装しないという決定はしなかったが、社内の大勢としては、Content Description Module(CDM, コンテンツ説明モジュール)という標準性のないプラグインの実装をHTML5内に必要とするW3Cの規格に反対だった。W3Cはブラウザが用いるCDMを特定していないので、Eichは、“各ブラウザがそれぞれ独自のシステム使うようになってしまう”、と主張した。

本日の発表でMozillaの会長Mitchell Bakerは、この新しいDRMソリューションには、“古いシステムと同じ深刻な欠陥がある”、と認めている。Mozillaから見るとそれは、“個人を保護することと、デジタルコンテンツを保護することとのあいだの、正しい均衡を欠いている。コンテンツプロバイダはシステムの重要部分をクローズドソースにしなければならないので、それはMozillaの長年の基本姿勢に反する”。

Mozillaがそれほどまでに言う規格を、では、なぜ実装するのか? それが、市場の大勢だからだ。MozillaがそのブラウザにEMEを実装しなかったら、いずれユーザはNetflixやHuluなどのコンテンツを見るためにほかのブラウザに乗り換えるだろう。“今の状況としては、MozillaがW3CのEMEを実装しなければFirefoxのユーザは、DRMに縛られているコンテンツを見るためにほかのブラウザに切り替えざるをえない、という段階に来ている”、とMozillaのAndreas Galは書いている。“DRMのない世界やWebが理想ではあるが、ユーザが、自分が望むコンテンツにアクセスするためにはそれが必要なのだ”、という典型的な必要悪説。

MozillaとAdobeのパートナーシップにより、後者がFirefoxにCDMを提供する。AdobeはDRM国のボス的存在だから、このパートナーシップは賢明だろう。Galによると、CDMはサンドボックスの中で実行されるから、ユーザのデバイスを特定する情報を得ることはできず、そのハードディスクやネットワークにアクセスすることもない。

CDMはAdobeが配布し、デフォルトではFirefoxに含まれない。そしてユーザがこれから見ようとするコンテンツによっては、ブラウザがそれを自動的にダウンロードして有効化する。ただしユーザはいつでも、CDMの有効化をoffに設定ができる。

実装の日程はまだ決まっていないようだが、当初はWindows、Mac、そしてLinuxのデスクトップブラウザだけが対象だ。

DRMのようなものをもともと思想的に毛嫌いしている人たちは、Mozillaの決定を敗北とみなすだろう。反対には、当然の理由がある。Eich自身も、昨年こう言っていた、“DRMは次の三つのものに激しく敵対している: ユーザ、オープンソースソフトウェア、そして、自らがDRMベンダではないブラウザベンダ”。

しかし結局のところ、Mozillaとしても、ユーザが減ってもいいとは言えない。見たいコンテンツを見られなければ、ユーザはほかのブラウザへ移るだろう。多くのユーザにとって、WebのオープンでDRMフリーという理想はどうでもよいこと。彼らは猫のビデオや過去の19 Kids And Countingを見たいだけだ。オープンソースを貫いてきたMozillaにとっては不快な状況だが、誰もFirefoxを使わなくなれば、その高邁なミッションも枯渇してしまう。

画像クレジット: Mozilla in EuropeCC 2.0のライセンスによる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


人気トップのゲームエンジンUnityがWebGL + Mozilla asm.jsでWebへポート

UnityMozillaが今日(米国時間3/18)、 WebGLとMozillaのasm.jsを使ってUnityのゲームエンジンをWebに持ち込む、と発表した

200万名あまりのユーザのいるUnityは、今もっとも人気の高いゲームエンジンの一つだ。

今日サンフランシスコで行われるGame Developer’s Conferenceで両者は、人気の3DシューティングゲームDead Trigger 2のWebポートをFirefox上でデモする。今のところ、asm.jsをサポートしているブラウザはFirefoxだけなのだ。今年の終り頃リリースされるUnity 5.0で、WebGLのサポートが、Unityのアーリーアクセスベータのアドオンとして可利用になる。

これまでは、Unityをブラウザ内で使うにはプラグインが必要だった。そのプラグインはきわめて有能でとても人気があるが、今後はますます、ブラウザ内でネイティブに動く(プラグイン不要の)アプリケーションが主流になる。asm.jsはJavaScriptのサブセットだし、WebGLは現代的なブラウザのすべてがサポートしているから、asm.js向けに最適化されているゲームでも、そのほかのブラウザで動かせる。やや遅くはなるが。

Mozillaの技術部長でWebGLの作者でもあるVlad Vukicevicが今週初めにぼくに語ったところによると、UnityとMozillaはUnityをWebに持ち込むために密接に協力してきた。これまでの2年間、MozillaとUnityのチームが週末や勤務時間外に頻繁に会って、UnityのWeb化に努めてきた。Mozillaでゲームプラットホームを担当しているMartin Bestによると、両者が一つの目標の実現に向けて協力してきた。

彼によると、これまで多くのデベロッパがUnityのWebGLポートを求めてきたし、いつごろ実現するのかと何度も何度も聞かれた。ただし今回の発表ぶんはあくまでも最初の第一歩であり、WebGLに関してもasm.jsに関しても、今後まだまだやるべきことは多い、と。

Unity TechnologiesのシニアデベロッパRalph Hauwertも同様のことを述べ、でも最初のバージョンが出たら、その後の開発はUnityとMozillaだけでなく、デベロッパのコミュニティが参加して進められるだろう、と言う。

どこかで聞いたような話だなぁ、と思われた読者もおられると思うが、実は先週Mozillaは、EpicのUnreal Engine 4がWebGLとasm.jsをサポートする、と発表したばかりだ。たしかに、JavaScriptをネイティブに近いまでに高速化するソリューションであるasm.jsに対しては業界全体としての支持もあり、またゲームデベロッパたちも、自分たちのゲームがプラグイン不要でWeb上で動くことには、並々ならぬ関心がある。

しかしなぜか、ハイエンドのゲームをブラウザに持ち込む方法としてNative Clientに賭けているGoogleからは、最近音沙汰がない。

Unity 5.0とそれが提供する機能の詳細は、本誌の別記事に書かれている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


EpicとMozillaが共同でUnreal Engine 4をWebにポート, Webゲームの高速化いよいよ本番

EpicとMozillaが今日(米国時間3/12)、Unreal Engine 4をWebにポートすると発表した

昨年のGame Developers ConferenceでMozillaは、Unreal Engine 3のポートを発表し、多くのトリプルAゲームの基盤になっているグラフィクスエンジンがブラウザ上でも動くことを見せつけた。それは多くのデベロッパにとって目覚まし時計が鳴る音になり、数年前までにはWebとブラウザには不可能だった高度なゲーム体験を、今やプラグインなしで提供できることを自覚させた。

それを可能にするMozilla側のツールが、JavaScriptを高速化したasm.jsと、C/C++のコードをasm.jsのコードにコンパイルする(==どのブラウザでも動くようにする)コンパイラEmscriptenだ。いずれももちろん、WebGLが必要である。Firefoxの今の安定バージョンはasm.jsをサポートしているので、コンパイル後のC++のコードをネイティブで動かす場合の1.5倍のスピードをブラウザ上で実現できる。

Mozillaの技術部長でWebGLを作ったVladimir Vukicevicによると、1年前のUnreal Engine 3のデモはまさに単なるデモだったが、今回のUnreal Engine 4でEpicは、Webをゲーム開発のためのメインのプラットホームにしてしまうエンジンとしてデベロッパたちに紹介するつもりだ。今のところは文字通りのデモがあるだけだが、もうすぐデベロッパが実際に利用できるようになる。

MozillaのCTOで技術担当SVPでもあるBrendan Eichは今日の声明の中で、“これからはWebのリンクをクリックしてすぐに遊べるゲームと、時間をかけてダウンロードしインストールしなければならないゲームが、見分けがつかないほどのほぼ同じ体験になる。Emscriptenを使ってCやC++をasm.jsへコンパイルすると、ブラウザ上にネイティブに近いスピードが実現するので、Webをそのほかのプラットホームと同格に遇することができる”。

以下は、EpicがGame Developers Conferenceで見せたデモのビデオだ(SoulとSwing Ninja):

【中略】

asm.jsで実際に商用開発を行っている企業の一つがTrendy Entertainmentで、そのゲーム事業部の名前はNomNom。NomNomが初めてデモしたWebベースのゲームMonster Madnessは、昨年12月にリリースされた。今では同ゲームのユーザの半数がWebバージョンをプレイしている。

Googleは、ハイエンドの3Dグラフィクスをブラウザに持ち込むための技術として、Native Clientを押している。Mozillaのasm.jsがJavaScriptであるのに対し、Googleはネイティブコードをブラウザ内で動かそうとする。でもこの技術は、ほかのブラウザがサポートしていないだけでなく、Chromeでもデフォルトではoffだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mozilla、収入の安定を求めてFirefoxの「新しいタブ」に広告表示を検討

オープンソース・ブラウザのFirefox公式ブログで、「新しいタブ」ページに広告を表示することを検討していることを発表した。パブリッシャーは通常のショートカットタイルの横に表示される広告タイルを購入することができる。このタイルには「広告」というはっきりしたラベルが付加されるという。

現在、インストールして最初に立ち上げたFirefoxでは、「新しいタブ」ページはFirefoxサイトへのタイルをのぞいて白紙だ。他のブラウザのスピードダイヤル機能と同様、Firefoxもユーザーのウェブ履歴をベースにして「新しいタブ」ページにリンクを追加していく。履歴がクリアされると「新しいタブ」ページも白紙に戻る。

そこでMozillaではユーザーの居住地域でもっともポピュラーなサイトへリンクするタイルを予め設定しておくことにした。これらのタイルのいくつかを広告枠にしようというのが今回の計画だ。

おそらくMozillaでは全面的に広告表示を行う前に、まず一部のユーザーで実験して反応を確かめるだろう。

現在Mozilla財団は財政を主としてGoogleからの広告収入に頼っている。 MozillaはGoogleをFirefoxの既定の検索エンジンに設定するという契約を結んでいる。また両者はFirefox上に表示されるGoogle AdWords広告の収入を分配することでも合意している。.

このGoogleからの収入がMozillaの年間売上高の90%を占めている。Firefoxのシェアが減少を続けているため、Mozillaは新しい収入源を探す必要に迫られていた。Mozillaは以前はGoogleの主要なパートナーだった。しかしGoogleの独自のブラウザ、ChromeがFireoxよりはるかに大きなシェアを獲得した現在、Mozillaが契約を更新を望んでも条件の大幅ダウンは避けられないだろう。

またこの数年Mozillaと広告業界は緊張関係にあった。Mozillaがターゲット広告を無効化するdo-not-track(トラック禁止)という機能を実装したためだ。ユーザーがこの機能を有効にすると、サードパーティーのクッキーを一切拒否するようになるので、ターゲット広告の表示が非常に困難になる。さらに昨年はユーザーが初めて訪問するサイトのクッキーを自動的にブロックする機能も追加されている。

しかし、必要に迫られてMozillaは広告主とうまくやっていくことに決めたようだ。新しいユーザーに広告タイルを表示し始める時期は不明だ。いずれにせよMozillaはまず広告主と交渉しなければならない。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Firefox 27が公開。ソーシャルAPIを改善、SPDY 3.1を新たにサポート

本日(米国時間2/4)Mozillaは、Firefox 27を公開した。新バージョンのブラウザーは、FirefoxソーシャルAPIに主要な改訂があり、旧世代のWeb 2.0ソーシャルブックマークツール、Deliciousや、インドの音楽サービス、Saavnをサポートした。しかし、もっと重要なのは、ソーシャルAPIで1ユーザーが複数のサービスを同時に使えるようになることだ。

FirefoxのソーシャルAPIは、ソーシャルネットワーク、チャットサービス、ニュースサイト等が、ブラウザー内の固定位置にポップアップ通知を表示できるようにするために作られた。2012年に公開され、昨年Mozillaがデベロッパーに開放したが、各社が挙ってソーシャルAPIを統合をするという動きは感じられなかった。

しかしこのサービスの大きな問題は、同時に1つしか統合アプリを動かすことができず、複数使いたい場合は少々面倒な切り替えを強いられることだった。このたびその制限が外されたことから、今後いくつか新しい統合が見られるかもしれない。

他の大きな新機能としては、GoogleのSPDY 3.1プロトコルのサポートと、Transport Layer Security (TLS) バージョン 1.1および1.2がFirefoxのネットワーキングの選択肢に加わったことだ。これらは、良く知られているSSL暗号化プロトコルの事実上の後継にあたる。

Androidに関して、今回Firefoxチームはわずかな変更を加えただけだった。モバイル版もTLS 1.1および1.2をサポートし、 標準フォントが読みやすいものに変わった他、ユーザーインターフェースにいくつか小さな改善が施された。

[原文へ]

(翻訳:Nob Takahashi / facebook


パナソニック、Mozillaと提携してFirefox OS搭載のスマートTV開発へ

CESでLGがOperaのweb OSを搭載したスマートTVを発表した直後にPanasonicもモバイル連動テレビの計画を明らかにした。

パナソニックはMozillaと提携してFirefox OS (FFOS)とオープンWeb標準の精神に準拠したスマートTVで居間の大画面の制覇を企てる。

今のところFirefox OSはブームを起こしているというには遠い。ヨーロッパや南アメリカの市場で安価な携帯電話に多少使われている程度だ。 このHTML5ベースのモバイルOSのGoogleのAndroid OSと競争できるようになるのは困難が山積している。そこでMozillaがモバイル・デバイス以外の分野にエコシステムの拡張を図るというのはある程度納得できる。

はたしてFFOSのUIが消費者にパナソニックのスマートTVを買う気を起こさせ、オープン・プラットフォームの旗印がデベロッパーにアプリ開発に参加させるだけの魅力があるかどうかは今後に待たねばならないだろう。

「MozillaとPanasonicは共同でFirefox OSとそのオープンなエコシステムの普及に努力する」 と両社は今朝(米国時間1/6)のプレスリリースで述べた。このプロジェクトはパソコンやモバイル・デバイスの世界ではすでに広く採用されているHTML5と各種のウェブ・テクノロジーをスマートTVに拡張し、消費者が放送と同時にウェブ・サービスを通じたコンテンツを簡単かつ幅広く利用できるようにすることが狙いだ。

パナソニックのAVCネットワークス社,のテレビ事業部長、Yuki Kusumはプレスリリースで「Mozillaとの提携はわれわれのスマートTVの接続性と対話能力を家庭の内外で強化することが目的だ」と述べた。

来るべきFFOS搭載のパナソニック・スマートTVはMozillaのWebAPIを搭載しているため、インターネットに接続可能な他のデバイスやスマート家電製品をモニタしたり制御したりすることが可能だ。

この記事の執筆時点ではMozillaはFFOS TVのスクリーンショットをまだ公開していないが、 プレスリリースによればFFOS搭載テレビではEPGのような基本機能も専用の内蔵プログラムではなく、HTML5で書けるようになり、サードパーティーのデベロッパーが多様なアプリケーション容易に開発できるようになるとしている。

「パナソニックがわれわれのFirefox OSを採用したことをたいへん嬉しく思っている。Firefox OSとオープン・ウェブによるプラットフォームへの参加者は増えつつあり、スマート・スクリーンの普及に向けて大きな力となっていくだろう」とMozillaのアジア事業部のモバイル・デバイス担当上級副社長、Li Gong博士は述べた。

パナソニック自身もモバイル・デバイスのメーカーではあるが、昨年、スマートフォン市場からの撤退を決定しており、生産の努力をスマートTVのような別分野に向けることにしたものだろう。パナソニックはFirefox OS搭載の次世代テレビだけでなく、Firefox OSとオープン・エコシステムの普及に関してMozillaと幅広く協力していくと述べている。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Mozillaのasm.jsがさらにネイティブコードのスピードに近づく

Mozillaのasm.jsはJavaScriptの厳密なサブセットだが、Firefox上の処理系/実装系はそれを、通常のJavaScriptのコードよりも相当高速に動かせる。すなわち、Firefoxが内蔵しているJavaScriptエンジンにはOdinMonkeyと呼ばれるモジュールがあって、そのおかげで今年の3月にはasm.jsのコードがネイティブコードの約2倍の所要時間で動くことを実証した*。そして今週のMozillaの発表 では、多くのベンチマークにおいて、ネイティブの1.5倍以下という遅さ(速さ?)にまで接近した。〔*: 約2倍;ネイティブよりもちろん遅いのだけど相当接近した、という意味。2倍よりは1.5倍の方が、もちろん速い。〕

GoogleはNative ClientでWebアプリケーションが、コンパイラを通ったまさにネイティブのコードを実行することをねらっているが、MozillaはJavaScriptをネイティブに近い速さで動かす方に賭けている。両者のやり方は相当違うけど、共通しているのはどちらも、デベロッパがまずCやC++でコードを書き、それをブラウザ内で動かすことだ。Mozillaはそのために、LLVMからJavaScriptへのコンパイルを行うコンパイラEmscriptenを使用する。

ゲームエンジンはCやC++で書かれているものが多いので、asm.jsも主にゲームをねらっている。実際、Mozillaが初めて公開したasm.jsのデモの一つは、ブラウザ内でネイティブに走るEpicのUnreal Engine 3だった。

かつての2倍遅いから今回の1.5倍遅いへの改良は、asm.jsとコンパイラEmscripteの両方をすこしずついじって達成された、とMozillaのAlon ZakaiRobert Nymanが発表の中で言っている。また、FirefoxのJavaScriptエンジンの改良の効果も大きい。ZakaiとNymanによると、中でもとくにスピードアップに貢献したのは、一部の浮動小数点数演算のの最適化だ。

asm.jsが2倍とか1.5倍と言っている対照のネイティブコードは、C/C++によるオリジナルをgccやclangでコンパイルした結果である。それを、Emscriptenとasm.jsによるコードと比較している。

下図は、最新の結果だ:


〔ブラウザ~HTMLがサイズを縮小しているので、クリックして別画面で見ると原寸で(大きく)見れます。〕

asm.jsは今のところMozillaのプロジェクトだが、GoogleのChromeチームはかねてから気にしていて、最近そのOctaneベンチマークの一員に加えた。Chrome本体がasm.jsを近々サポートすることはないと思うが、asm.jsのコードは、ふつうのJavaScriptコードとしては今のどのJavaScriptエンジンでも動く。Firefoxの上ほど速くないけど。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


HTML5/JavaScriptでFlash Playerを置換するMozillaのShumway, 最新Firefox Nightlyに登場

WebネイティブでFlashファイル用の効率の良いレンダラーを作ろう、というMozillaの実験的技術Shumwayがついに、Firefoxの最新のナイトリービルド登場した。製品としての完成はまだまだ先だが、このプロジェクトはFlash Playerを完全に置換して、HTML5とJavaScriptでSWFファイルを表示することをねらっている。

90年代の後期には、MacromediaのFlash Playerを使ってWebにサウンドやビデオやアニメーションを導入できたが、しかし今では、Flashはたぶん、いちばん嫌われているブラウザプラグインの一つだ。でもそれは、今でも至る所で使われており、モバイルブラウザの多くがもはやサポートしていない中で、デスクトップ上では依然として必須アイテムだ。

Mozillaがこのプロジェクトを開始したのは2012年の初めだが、同団体がこのプロジェクトについて詳しく語ったのはその年の11月で、それ以降は音沙汰がなかった。そのときの説明によるとShumwayの目標は、“SWFやそのほかのリッチメディアフォーマットのためのランタイムプロセッサを、ランタイムの実装のないプラットホーム向けに提供すること”、とされていた。また、リッチメディアフォーマットをブラウザ内で表示する方法を改良し、プロプライエタリなソリューションを不要にすることによって、オープンWebを一層前進させたい、とも言っている。

今のところShumwayはブラウザのエクステンションなので、最新のナイトリービルド(バージョン27)のデフォルトの機能ではない。しかし、about:configへ行けばアクチベートできる(ただしFlash Playerがインストールされていることが必要)。

また最新のFirefox Nightlyをインストールしなくても、MozillaのShumway Inspectorでその能力を見ることができる。まだ、Flashを使っている商用アプリケーションのすべてを動かせるわけではないが、提供されているデモのレーシングゲームやベーシックな2Dフィジックスエンジンなどは、この技術のポテンシャルを見せている。今後Flashのすべての能力を完全に置換できるようになるのか、それはまだ未知数だが。

MozillaがAdobeの技術を置換しようとする大規模プロジェクトは、これが二つめだ。この前同団体はPDF.jsでAdobe Readerを置換し、ブラウザ内でPDFファイルを表示するための新たなデフォルト技術を提示した。

なお、同種の試みはMozilla以外でも行われている。たとえばGoogleが2011年に立ち上げたSwiffyは、SWF→HTML5コンバータだった。その後今日まで情報はないが、今でも活発に開発が行われているプロジェクトであるようだ

Adobe自身も、このところFlash離れを進めている。同社の最近のWebデベロッパ向けのプロジェクトはほとんどすべて、WebスタンダードとHTML5ベースのサイトの制作に関連している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Web Componentsのバスに乗り遅れたくないMozillaがpolyfillコンポーネントライブラリBrickをローンチ

Web Componentsは近い将来、Webアプリケーションの作り方を変えるだろう。Web Componentsの中核的な機能は、まるでライブラリのように、デベロッパがユーザインタフェイスの独自の部位/部品(コンポーネント)を作り、それらをHTML上で、デベロッパが命名した任意の名前のタグ(たとえば<datepicker>)で再利用できることだ。そんなWebコンポーネントを作るのは簡単ではないが、基本的にはHTMLとCSSとJavaScriptの知識だけあればよい(”Shadow DOM”に関する知識もあった方がよいかも)。Web Componentsの標準化プロセスはまだまだ時間がかかりそうだが、GoogleとMozillaはその前からいろんな取り組みを開始している。

しかし、まだほとんどのブラウザがサポートしていないのに、Web Componentsはどこから手出しをしたらいいのだろう? そこで、polyfillというコンセプトが登場してくる。また、GoogleのPolymerフレームワークや、Mozillaの地味な名前のpolyfillライブラリx-Tagというものもある。polyfillというコンセプト自体は、かなり前からある。その考え方は、ブラウザがネイティブに持っているAPIをJavaScriptなどで複製して、クロスブラウザで使えるようにすることだ(それをまだネイティブでサポートしていないブラウザ上でも)。それは要するに Modernizrなどが使ってるのと同じコンセプトだが、GoogleとMozillaのプロジェクトは同じ低レベルのWeb Components用polyfillsを共有している。

Googleは今年初めのI/OカンファレンスでPolymerフレームワークを紹介したが、それは明らかにGoogleが今後長期にわたって推進したいと考えているコンセプトだ。Mozillaもこのバスに乗り遅れたくないので、このたび、x-TagベースのクロスブラウザなライブラリBrickをローンチした。それは、説明によると、“一般的によく使われるユーザインタフェイスパターンを、使いやすく柔軟性に富みそしてセマンティックなWeb Componentsに抽象化する、新しいカスタムHTMLタグ集”、を提供するものだ。

Brickを使うことによってデベロッパは、ベーシックなインタフェイス成分、たとえばヘッダメニュー日付指定カレンダーなどや、もっと複雑なアニメによるトランジションのあるスライドデッキなんかを、単純にBrickのスタイルシートやJavaScriptライブラリへのリンクをドキュメント(Webページ)に書き、それからカスタムのHTMLタグを使って、それらの新しいインタフェイス成分を呼び出せるようになる。

Mozillaも認めるように、それまでは、そういう新しいユーザインタフェイス成分を使うためにはjQuery UIみたいなものを使い、定型的でノンセマンティックなマークアップをHTML中に置いて、初期化や管理もJavaScriptで明示的に書く必要があった。またそういうタグの多くは、カスタマイズしようと思うと大量の属性を加える必要があった。

将来的には、Web ComponentsはデベロッパによるWebアプリケーションの作り方を変え、UI成分の再利用や共有を容易にするだろう。MozillaとGoogleが積極的にその開発を支援しているから、やがてpolyfillsは、レガシーブラウザをサポートするためにのみ、必要なものになってしまうと思う。ただしメジャーなブラウザのすべてがWeb Componentsをサポートするのは、さらに先かもしれないが。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


アプリストアをもっと楽しい場所に…Mozillaの取り組みはAppleやGoogleも参考にすべきでは

アプリストアは破綻している。そこは、何千何万ものがらくたに占領され、良いアプリやおもしろいアプリを見つけることがほとんど不可能だ。各カテゴリのトップテン以外にも、良いアプリはあるはずなのに、それを簡単確実に見つける方法がない。Appleの”Genius”機能はすごくおバカだったのでiOS 7では下ろされ、さらにつまらない”Apps Near Me”機能に代わった。それは、あなたの周辺にいる人たちが今使っているアプリを、教えてくれる機能だ。Microsoftは、トップテンの愚かさに代わるものとして、Windows 8.1では人間が編集した情報を提供するようになったが、そこでもまだ、単純なランキングの支配力は強い。

Mozillaは、Firefox OSでごく最近モバイルゲームに参戦したばかりだが、過去数年間競合他社たちがやってきたことを、反面教師として(やってはいけないこととして)学ぶことができた。今現在のFirefox OS Marketplaceは、それほど革命的でもないが、Webアプリに力を入れる姿勢には新鮮さがある。そしてMozillaが先週発表したアプリストアプロトタイプの計画には、先行各社が参考にすべきものがあると思う。

Mozillaは次のように論ずる: “今のアプリストアでは、そこのメンテナーたちが任意に選んだものしか見ることができない。そこには、自分との個人的な関連性がない。新しいアプリを探したくても、どうやって探したらいいのか、分からない。せいぜい、友だちの言うことや、どこかの記事で読んだことを、参考にするぐらいだ”。

これらに対しFirefox OS Marketplaceのプロトタイプでは、個々のユーザに合わせたニューズフィードみたいな形で、アプリストア体験を個人化しようとする。それは、“フォロー”のような面倒な仕組みを実装しなくても、ユーザが関心のあるコンテンツを追っていける方法だ。プロトタイプでは、ユーザはハート型の小さなアイコンをクリックして自分の関心を指定する。すると、その関心分野の今後のアップデートや関連コンテンツを見られるようになる。

しかしMozillaが長期的に考えているのは、フィードそのものをユーザ自身が編集できる方式だ。その具体的なやり方は未定だが、今すでに一部のサードパーティのアプリストアがやってるような方式かもしれない。でもそれは、既存のメジャーなアプリストアがほとんどやらなかった試みであり、いわばアプリストアをソーシャル化するものだ。Androidのストアも、友だちがダウンロードしたアプリを教えてくれるが、その友だち自身が編集したリストが送られてくるわけではない。

Mozillaのチームは、このところユーザのアプリストアにおけるエンゲージメントが低下傾向だ、と言っている(ぼくも個人的にそのことを実感する)。つまり、今のアプリストアは、楽しいから訪れる、というものになっていない。Mozillaは、ちょっと風変わりなマイクロコピーやアニメーションでユーザを釣ろうとしているが、しかしいちばんかんじんなのは、ユーザがここでいろんなアプリやコレクションや記事やリビューやビデオ、などなどを発見できる、というコンセプトだ。Mozillaは、アプリストアを楽しく長居できる場所にしようと努力している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))