タグ: モバイル

[抄訳]
Facebookが今日（米国時間5/12）、数か月前から噂のあった“Instant Articles”を公開した。これはFacebookのNews Feedの中でパブリッシャーのオリジナルコンテンツをネイティブにホストする、というもので、ユーザがリンクをクリックしてWebサイトがロードされるのを待つ必要がない。今日載ったのはThe New York TimesやBuzzFeed、National Geographicほか6誌（紙）のリッチメディアや記事で、世界中のどこからでもFacebookのiPhoneアプリで見られる。

Facebookはユーザのアクセスデータを独占せず、パブリッシャーと共有する。またInstant ArticlesはcomScoreやOmniture、BuzzFeed、Google Analyticsなどのオーディエンス計測および帰属ツールと互換性がある。広告は、パブリッシャーが売ったものなら売上の100%がパブリッシャーへ行き、Facebookが売った広告なら、Wall Street Journalが前に報じたように、Facebookが標準定率の30%を取る。

Instant Articlesがそのフォーマットを理由に、FacebookによるNews Feedのソートで特別扱いされることはない。しかしユーザがInstant Articlesをほかの記事よりも多くクリックしたり、like（いいね！）したり、コメントしたり、シェアしたりすれば、そのほかの人気記事と同様に、上の方に表示されることもありえる。そうすると、Instant Articlesのフォーマットに最初から合わせようとするパブリッシャーが増えるかもしれない。

Instant Articlesの記事はロードが速いだけでなく、オリジナルのHTMLやRSSがそのまま使われるので、パブリッシャーのWebサイトのような感じになる。ただしパブリッシャーはFacebookが提供している写真ズーム、ビデオ、オーディオキャプション付きの地図、“環境ビデオ”（記事に味付けをする動く画像）などのヴィヴィッドメディアオプションを活用してもよい。Osofskyは、“デベロッパと同じツールをパブリッシャーも使える。モバイルWebの制約に縛られる必要はない”、と言っている。

Instant Articlesは、テストの結果が良好なら数週間後にパブリッシャーの数を増やすつもりだし、最終的にはどんなメディアでもFacebook上で記事を共有できるようにする予定だ。

tl;dr – Facebookは、ユーザがそこから逃げ出した穴を塞ごうとしている。モバイルWebでは記事のロードが遅いので、Facebookアプリを使わなくなったユーザもいる。今回の、オリジナル記事の埋め込みによるスピードアップで再びみんなが、Facebookで友だちと会ったり、コンテンツを見つけたり、広告を見たりするようになるだろう。

デザインはPaperから学ぶ

FacebookのニューズリーダーPaperはユーザ数が千万のオーダーに達しなかったから失敗だ、と見なす人が多いが、しかしCameraやSlingshotなど、そのほかのFacebookアプリと同様に、それはユーザの行動に関するインサイトを得てサービス本体に反映させることが目的だった。Facebookが写真のフィルタやステッカーなどを思いついたのも、そういうインサイトからであり、PaperはFacebookに、パブリッシャーが提供したいと望んでいる、一定のフォーマットによるリーディング体験について教えた。

Instant ArticlesはFacebook Paperが開拓したメディアブランド付きの報道記事を借用している

Paperは今後もサポートされるが、そのチームのプロマネMichael ReckhowやデザイナーのMike MatasはInstant Articlesの制作に加わった。Rechowは、一定のフォーマットの記事とか、パブリッシャーのブランドを匂わせるフォントの選択など、Paperから学んだことは多い、と言っている。

Instant Articlesのプロジェクトは、モバイルでいちばん重要なのはスピードである、という命題を抱えてスタートしたが、それには、iOS上のFacebookアプリが2012年にスピードを倍にしてユーザが大きく増えたことが影響している。

その後Facebookでは、モバイル上のあらゆるものを、しらみつぶしにスピードアップする取り組みが行われたが、最後まで残ったのが、ニュースの記事のロードだった。“ブランクスクリーンが表示されて、そこに何かがロードされるまで、平均8秒はかかっていた”、とMatasは言う。モバイルのユーザにとって8秒は永遠と等しく、多くの人が、フラストレーションのあまりアプリを閉じてしまうのだ。

そこで9か月前にFacebookはInstant Articlesのプロジェクトを開始した。Instant Articlesでは、ユーザがNews Feedでそれを選ぶと、実際に記事がセレクトされる前に画像や記事がFacebookのネイティブアプリの中へプリロードされる。

一つをタップすると、ブラウザのウィンドウが開いてWebサイトがロードされるのを待つのではなく、コンテンツが横からすべるようにさっと現れる。Matasによると、そのロードは“モバイルWebの10倍速い”。ぼくがデモをWiFi上で試してみたときは、1/4秒ぐらいのロード時間だった。これなら、退屈してFacebookを去る人はいないだろう。

【後略】

これ以降の節は以下の二つ:

パブリッシャーを満足させる

—comScore、Google Analytics、BuzzFeedなどとの互換性

モバイル優先のニュースアプリ

—ユーザに負担をかけない軽快なUIと豊富な対話性

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

[筆者: Anders Lassen]
編集者注記: Anders LassenはFuseのファウンダでCEO。初めての、デザイナーとデベロッパの両方のためのネイティブアプリツールだ。

Facebookがこのほど、モバイルアプリを構築するためのフレームワークReact Nativeをオープンソースにした。React Nativeでは、デベロッパがJavaScriptでプログラムを書けば本物のネイティブのユーザインタフェイスができあがる。こんな説明では、技術系以外の読者は肩をすくめるだけだろうが、でもわれ思うに、この発表には重大な意味がある。React Nativeはやがて、モバイルアプリの開発という業界の業態を完全に変えてしまうだろう。そしてそれは、スマートデバイスのオーナー全員にも影響を及ぼすだろう。

HTML対ネイティブという戦争の終わり

長年モバイルアプリのデベロッパは、ほかのデベロッパには無縁な、独特の困難な選択をつねに迫られていた。AppleやGoogleのネイティブツールを使ってアプリを開発すべきか、それとも、何らかのクロスプラットホームなソリューションを使ってアプリを作るべきか？

最良のユーザ体験を作り出したいなら、ネイティブツールを使うべし、これが、これまでの定説だった。ネイティブアプリは速いし無駄がないから、ユーザの期待を裏切らない。欠点は、ネイティブツールは勉強がたいへんだし、またユーザにとっても、Webなどの標準的なインタフェイスに比べると、いちいち使い方をおぼえなければならない。プログラミング言語も各ネイティブプラットホームごとに独特だから、同じアプリを異なるプラットホームごとに二度も三度も書かなければならない。今日はiOS、明日はAndroid、と。したがってネイティブアプリは開発コストが高くつき、それが業界全体の頭痛の種だった。

一方、クロスプログラムなソリューションは、多くの場合、HTMLとCSSとJavaScriptという三種の神器から成るWebの技術だ。モバイルのプラットホームはいろいろあっても、Webページを表示する機能はどれにもある。だからWebの標準技術〜標準言語でアプリを書けば、プログラムはたった一度だけ書けばよいし、開発の費用や時間も少なくてすむ。

しかしそうやってWebの標準言語(HTML, CSS, JavaScript)で書いたプログラムはネイティブに比べると遅く、また言語の実装がプラットホームごとにやや違ったりする。しかも、素早くてなめらかなネイティブインタフェイスと違って、ユーザ体験がぎごちなくなりがちで、さらに、電力を食うので電池を酷使する。派手な要素を多く散りばめたWebアプリが、往々にしてとろく感じられるのは、そのためだ。

React Nativeは、ネイティブの良いところとWeb言語の良いところを“良いとこ取り”したような、新しいツールだ。デベロッパは、今や誰もが使っていて、プログラミングの初心者でも書けて、すべてのモバイルデバイスが実装しているJavaScriptでアプリを書く。しかしそれで作られるユーザインタフェイスは、本物のネイティブの部品が使われている。だからそれは、デベロッパにとって魅力的なライフラインだ。ネイティブアプリを書くためには各プラットホーム固有の言語…Objective-C, Swift, Java, …と固有のライブラリ(API)を勉強しなければならない、という恐怖から彼らは解放される。

今後成熟すべき余地はまだ十分にあるものの、React Nativeを使えば基本的に、HTMLかネイティブかという二者択一はなくなる。できあがるユーザインタフェイスは高品質なネイティブだが、それを慣れ親しんだJavaScriptで書けるのだ。

無駄な苦労を忘れ、アプリそのものをもっとおもしろく創造的に

React Nativeをちょっと使い込んでみると、JavaScriptでネイティブインタフェイスを書けるという表面的な利便性を超えた、深い思想があることに気づく。Facebookが１月に行った詳細なプレゼンテーション*を見ていただくとお分かりと思うが、とにかく、ワークフローがまったく新しい。これまで、大きなプロジェクトでは何時間もかかっていたようなプロセスの多くを削り取り、アプリのデベロッパが十分に納得できる開発体験を作り出している。 〔*: このビデオのコメントがおもしろい。〕

これまで、Webで開発する場合は変更の結果をすぐにブラウザの画面で見ることができたが、ネイティブ開発の場合はコンパイルしてデプロイしてモバイルデバイス上にローンチする、という待ち時間があった。それは、時間がかったるいだけではなくて、創造性とか、新しい試みの実験とかの、‘乗り’を失ってしまうのだ。デベロッパは独創的な試みを我慢して抑え、まあまあのレベルで妥協しなければならない。いろんなことをトライしていると、途中で夜が明けてしまうから。

React Nativeが導入したのは、ネイティブなユーザインタフェイスと、ユーザインタフェイスを動かすロジックを、それぞれ別立てにする（分離する）ことだ。そのために、一般的にリアクティブアプローチ（日本語参考記事）と呼ばれている方法を使っている。ユーザインタフェイスは各モバイルデバイスに固有だが、それを動かすロジックは普遍的だ…ブラウザの動作が共通的で普遍的であるように。だからデベロッパは、Web開発のときと同じようなツールとワークフローを使える。コードに変更を加えると、結果がすぐにデバイスまたはエミュレータ上で見られる。アプリの制作が早くなり、新しいアイデアをいろいろトライできる余裕が生まれる。

この記事を読んだだけで、JavaScriptとブラウザツールに乗り換える気になった人は、あまりいないかもしれないが、でもツールのデベロッパには、React Nativeは大きなインスピレーションを与えたはずだ。モバイルアプリの市場は爆発的に拡大しているから、デベロッパとその時間はますます希少財だ。変更のたびに、アプリをコンパイルしてデプロイを待つという時間は、過去へと葬り去る必要がある。

新しいモバイル時代のインスピレーションを与えるオープンなコードベースを

React Nativeのコードベースは、これからは無料で誰にでも入手/利用できる。だからそのコードとアイデアが、ほかのツールや開発プラットホームにも浸透していくだろう。React Nativeの前身React.js（Webベースのユーザインタフェイスを作るためのフレームワーク）でも、それが起きた。React.jsは、それ自身が人気者になっただけではなく、そのほかのフレームワークにも強い影響を与えた。

そしてアプリのエンドユーザにとっては、よりクリーンで応答性の良い（レスポンシブな）アプリがこれからはどんどん多くなる。ほとんどお金をかけられなかったアプリでも。逆に高品質なアプリ開発はそのコストが下がり、アプリのデベロッパの生産性と創造性が高まる。

スマートフォンの登場によって、アプリ産業が経験したさまざまな苦痛は、今でも続いている。iOSとAndroidという二度手間、使いにくいツール、遅い開発サイクル。でもこれからは、React Nativeと、これからインスピレーションを得たいろんなツールにより、オープンソースのコードベースを軸とする新しいアプリ開発の時代が始まる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）