Month: Jan 2013

HTML5にはアプリケーションキャッシュやストレージなど、オフラインアプリケーションを実現するための機能が用意されていますが、そもそもオフラインアプリケーションって何なんだろうって考えてみたいと思います。なぜかというと、オフラインアプリケーションと一言で言っても、どこまで「オフライン」である必要があるのかに差があるからです。

まずWebサイトを分類したいと思います。

1. 閲覧をメインとしたサイト： WikipediaやAsahi.comなどの新聞サイトがこれに該当します。
2. 個人用にカスタマイズしたコンテンツをメインにしたサイト： Facebook, Twitter, LinkedInなどがこれに該当します。
3. データ入力や加工をメインにしたサイト： GmailやGoogle Docsがこれに相当します。

以下、それぞれについて考えていきます。

閲覧をメインにしたサイト

1の閲覧をメインにしたサイトについてはオフラインへのアプローチは２通り考えられます。一つはサーバから帰ってくるHTMLをそのままキャッシュすることです。もう一つはAPIでデータをJSONなどの形式でダウンロードし、これをキャッシュすることです。そして画面に表示するときはJSONデータからDOMを作ります。

どっちを選択するかに関わらず、このようなサイトに共通しているのは、ブラウザ側ではModelを持つ必要が無いということです。保存する内容はページの内容だけですので、ModelはせいぜいPage一つです。わざわざクライアントサイドのMVCフレームワークを用意する必要がありません。

このようなサイトで一番大きな問題はデータ量ではないでしょうか。Wikipediaであればすべてをローカルに保存するわけにはいかず、一部だけをダウンロードすることになります。それでも数千ページを保存すれば相当な容量になります。このデータを効率的にサーバから出力し、ブラウザ側で処理し、ローカルに保存していくかは簡単ではありません。

個人用にカスタマイズしたコンテンツをメインにしたサイト

実際問題、こういうサイトではオフラインの閲覧はほとんど実現できていません。例えばHTML5をやめてnative Appを開発していくということで話題になったFacebookのiPhone用アプリですが、オフラインで見られるのは以前に閲覧した内容のキャッシュです。先読みしてローカルにページを保存することはしません。したがってオフラインでやれるのは見直しだけです。

Twitter, LinkedInのiPhone用Nativeアプリも同じです。

ただ「いいね！」などはオフラインでも押すことができて、オンラインになるとその変更がサーバに送られることを期待しましたが、テストしてみたところ反映されていませんでした。

もともとこのようなソーシャルネットワークアプリはタイムラインを中心としたUIなので、タイムラインさえキャッシュすればほとんど用が足りると発想をしているのだと思われます。いずれにしてもオフラインではたいして使えないのが現状です。

このようなサイトを実現する方法は「閲覧をメインにしたサイト」とよく似ています。サーバから帰ってきた内容をキャッシュすれば良いのです。ただし内容が変更されることが頻繁にあるので、ネットワーク接続があれば積極的にデータを更新することになります。

データ入力や加工をメインにしたサイト

GmailやGoogle DocsはもともとデスクトップのemailクライアントやMS Officeをウェブ用に作り替えた製品であり、完全にオフラインで動作するようにGoogleがかなり開発をしてきた製品です。

これらの特徴は、様々に加工した後に作られるドキュメントが非常に独立していることです。デスクトップのアプリであればドキュメントはファイルシステム上のファイルであり、属性としてはタイムスタンプやフォルダー名、ファイル名、そして権限ぐらいです。Facebookの書き込み、コメント、いいねと違い、複雑なリレーションがありません。

このようなWebサイトはデータを加工するのには複雑なJavascriptを使う必要がありますが、一方でサーバとやりとりするデータはかなり境界がはっきりしていて単純です。この際に便利なのがクライアントサイドのJavascript MVCフレームワークです。ブラウザの中で複雑な処理が行われデータが加工されていきます。上述の「閲覧をメインにしたサイト」「個人用にカスタマイズしたコンテンツをメインにしたサイト」と異なり、ブラウザはデータに対して受け身ではなく、積極的にデータを作り、改変します。ブラウザ内での処理が複雑になりますので、MVCフレームワークの必要が出てきます。

このように、どのようなWebサイトでオフライン閲覧を実現しようとしているかによって、どこまでやるべきか、どこまでやれるかがかなり分かれます。

さて私が考えているのはソーシャル機能を持ったオンライン抄録集ですので、1, 2の機能を併せ持ったものになります。それを実現するために何が必要かを考えていきます。

ソーシャル機能を持ったオンライン抄録集ではブラウザ側のMVCは必要ない

オンライン抄録集は根本的には「閲覧をメインにしたサイト」ですので、各ページのデータをローカルに保管すれば十分です。ソーシャル機能については「個人用にカスタマイズしたコンテンツをメインにしたサイト」と同じように考えますので、普通に考えればオフラインでソーシャル機能を提供する必要はありません。したがってサーバのレスポンスをキャッシュするアプローチで十分です。

もし一歩先を行って、「いいね！」などをオフラインでも可能にしようと思うと、ブラウザの中にModelを作っていく必要が出てきます。しかしModelの数は少なくて済むと思われますので、全面的にクライアントサイドMVCを導入するのは無駄だと考えられます。

残念ながら適当なフレームワークがない

残念ながらこういう目的のJavaScriptフレームワークは存在しないのが現状です。Sencha Touchはローカルにデータを保存することができますが、完全なクライアントサイドMVCフレームワークなので今回の目的に合いません。

jQuery Mobile, jqMobiなどはサーバ側にHTMLの生成を任せているフレームワークで、クライアントサイドにModelを持つ必要の無いものです。しかし主眼はNativeアプリと似たようなUIをブラウザ内で実現することであり、ページをローカルにキャッシュする機能はありません。

現在取りかかっているプロジェクトと関連しますので、ローカル（オフライン）でも使えるWebサイトを作るためのポイントをまとめてみました。

データをため込むにはHTML5のアプリケーションキャッシュとストレージを使う

ローカルで使えるWebサイトを作るには、データをローカルに保管することが必須です。HTML5では保管方法がいくつか用意されていて、大別するとアプリケーションキャッシュとストレージになります。

静的なファイルはアプリケーションキャッシュで

完全にローカルで使えるWebサイトを作るためには、HTML5のアプリケーションキャッシュを使う必要があります。最初に問い合わせるURLはこのアプリケーションキャッシュに入れます。これをやらないと、URLを入力した時点でブラウザはサーバに問い合わせをし、ネットワークが繋がらなければエラーになります。

アプリケーションキャッシュは便利ですが、例えば1ページでも更新されるとキャッシュ全体をクリアしなければならないなど、頻繁に更新される内容には不向きです。あくまでも静的なファイルに使用します。

ただし、Webサイトのトップページはしばしば動的なページです。更新情報やお知らせなどを掲載することが一般的です。そうなると最初に問い合わせるURLは静的ではなくなります。

この問題を解決するためには、最初に問い合わせるURLではウェブページのフレームワークだけを返し、更新情報などはストレージから読み込むんで、Javascriptで埋め込むことになります。

HTML5 History APIは使わない

Javascriptを使ってページ内容を更新する場合、backボタンやブックマークを正常に動作させるためにURLを書き換える必要があります。その方法はURLのハッシュフラグメントを書き換える方法と、HTML5のHistory API (pushStateなど)を使う方法があります。

pushStateを使うとハッシュフラグメントではなく、URLの本体を変更します。この方が従来のWebと親和性が高いという理由などから、現在ではHistory APIを使った方法が推奨されています。

しかしこれはローカルWebアプリには使えません。最大の理由はアプリケーションキャッシュがうまく使えないからです。

例えばhttp://my_server.com/をアプリケーションキャッシュに保管しいても、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2というURLにアクセスしようとするとアプリケーションキャッシュのページは使われません。通常通り、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2をサーバに要求します。

それに対してhttp://my_server.com/#!path_to_page_1, http://my_server.com/#!path_to_page_2のようなURLになっていれば、まず最初にアプリケーションキャッシュのhttp://my_server.com/が呼び出されます。そのあとpath_to_page_1やpath_to_page_2のコンテンツはストレージから読み込むか、あるいはAJAXでサーバに問い合わせることができます。

その他、Androida 4.0のデフォルトブラウザがHistory APIをしっかりサポートしていないという問題もあります。

ストレージの選択

ストレージはいくつもAPIが用意されていますが、ブラウザのサポートを考慮すると実際に使えるものは限られています。

一番広くサポートされているのはwebStorageです。これは非常に単純なkey/value型のストレージです。IE8でさえサポートされています。しかしwebStorageの大きな問題は容量の少なさです。Safariだと5Mbyteが上限です。これでは日本分子生物学会の抄録などは収まりません。経験的に数百演題の学会であればwebStorageでも十分ですが、1000を超えたらwebStorageでは不十分です。

次にサポートされているのはWeb SQL Databaseです。50M byte以上のデータをため込むこともできます。またSQLでクエリが書けるので、いろいろな使い方ができます。ただしWeb SQLは今後は規格を更新しないことが決まっています。Web SQLの大きなポイントは、FirefoxやIEなどのデスクトップ用ブラウザではサポートされていないものの、スマートフォンのブラウザで広くサポートされている点です。

最も期待されるのはWeb SQLに変わるIndexed DBですが、こっちはまだサポートするブラウザが少なく、特にスマートフォン用ブラウザではサポートされていません。

上記を考えると、ストレージとしては第1にWeb SQL Databaseを優先させ、サポートしたいブラウザや保管したいデータ量を考慮してIndexedDBもしくはwebStorageをサポートするのが妥当な選択だと言えます。

まとめ

完全にローカルなWebサイトを作るために必要なコンポーネント、どのHTML5テクノロジーを使うかの話をしました。特に重要なのは、一般的に推奨されている History APIは使えないということだと思います。

もちろんコンポーネントを選定しただけではまだまだ話は始まったばかりです。解決しなければならない問題はたくさんあります。これについてはこれから少しずつ紹介していきます。

解決しなければならない問題のリスト

1. ハッシュフラグメントのフォーマット
2. out-of-dateになったページをどうやって更新するか
3. データの同期をどうやって行うか

iPad miniの登場でタブレットに最適化されたウェブサイトが必要になってきました

スマートフォンとiPadなどのタブレットが急速に普及したため、同じコンテンツを異なるスクリーンサイズに合わせてデザインする必要が出てきました。その中でもスマートフォンは先に普及し、またスクリーンサイズがPCと大きく異なるため、スマートフォン専用のサイトを用意したり、あるいはスマートフォン専用のアプリを用意することが多くなりました。

一方でiPadなどのタブレットでは事情が複雑です。

iPadのSafariは横幅が980pxのウェブサイトであれば縦向きの画面に納められるようにデザインされています（実際のピクセル数は768pxしかないのですが、980pxのサイトを768pxに圧縮します）。しかしこれだとリンクが非常に小さくなるので、リンクをタップするときにかなり神経を使います。AppleのiOS Human Interface Guidelinesではボタンのサイズを44px x 44px以上にすることが推奨されていますが、それよりもずっと小さくなります。

今までの10インチのiPadであれば、それでも何とかなりました。神経を使えばリンクをクリックすることができました。しかし7.9インチのiPad miniになるとさすがに難しくなります。画面の拡大縮小をしないとPCウェブサイトのリンクはクリックできません。

そろそろタブレットに最適化されたウェブサイトが必要になってきたのではないでしょうか。

タブレット専用のサイトを作るべきか、それともPC用のウェブサイトを作り替えるべきか

国内のスマートフォンの普及率はまだ50%以下です。したがってすべてのユーザをカバーするようなウェブサイトを作るためには、1) PC用, 2) スマートフォン用, 3) フィーチャーフォン用のウェブサイトが最低でも必要になります。さらにタブレット専用のウェブサイトを作るとなると４種類のウェブサイトを作ることになり、かなりつらくなってきます。

やはりタブレット専用のウェブサイトを作るよりは、PC用ウェブサイトと共用のものが作れれば楽です。そうなると7.9インチのiPad miniでも快適に見られるようなPC用ウェブサイトを追求することになります。

PC用のウェブサイトは無駄だらけ？

以下に示すのはasahi.com用のiPadアプリの一面です。

以下はPC用ウェブサイトのトップページです（赤枠は私が付けました）。

内容を比較するとiPadアプリの一面の内容はPC用ウェブサイトの赤枠だけです。ざっと見たところ、PC用ブラウザの画面の1割程度だけがiPadアプリの一面に使われています。PC用ウェブサイトの赤枠以外は、iPadアプリではすべて省かれているのです。

なぜiPadアプリではPC用ウェブサイトのコンテンツの9割を省くことができたのでしょうか。PC用ウェブサイトのトップページコンテンツの9割は無駄なのでしょうか。

PC用ウェブサイトはナビゲーション用リンクが異常に多い

先ほどのPC用ウェブサイトのトップページを内容ごとに色分けしました。

赤がiPadアプリの一面にもあった、いわゆる「新聞の一面記事」です。青はナビゲーションです。カテゴライズしたナビゲーションではなく、「もしかしたらこんなことに興味があるんじゃないかな？」ということでリストアップされたものです（カテゴライズしたナビゲーションはトップメニューにあります）。そして緑が広告です。さらに黄色は他のページ（この場合は社会欄）の抜粋リンクです。

こうしてみると青のナビゲーションリンクが異常に多いことがわかります。また下にスクロールしていくと、黄色の他ページ抜粋リンクが延々と続きます。

青のナビゲーションリンクの目的は、人気記事を前面に出すことです。少しでも読者におもしろがってもらえる内容を早めに見せておくためのリンクです。

黄色の他ページ抜粋リンクは、トップメニューを経由しなくても、下にスクロールするだけで他ページの内容が見られるようにした工夫です。クリックするよりもスクロールした方がユーザは楽だろうという配慮です。これもナビゲーションリンクの一種です。

iPadアプリにはこういう青と黄色のリンクに相当するものがほとんどありません。

PC用ウェブサイトもナビゲーションリンクを減らせば簡単にiPad向けになる

PC用ウェブサイトのナビゲーションリンクを省き（青と黄色のリンク）、そのページ固有のコンテンツに絞ればフォントサイズを大きくすることができ、iPad miniでも簡単に操作できるものになります。そのためには以下のことを考慮すれば良いはずです。

1. トップナビゲーションメニューを経由したページ切り替えを楽にし、黄色の他ページ抜粋リンクを不要にする。
2. 青色のリンク（ランキングなど）は別のページにまとめ、これもトップナビゲーションメニューから簡単に移動できるようにする。

トップナビゲーションは必要か

実はトップナビゲーションメニューも不要かもしれません。Asahi.comのiPadアプリではトップナビゲーションメニューは前面に出さず、実際の新聞の紙面のページを送る間隔で、１ページずつ、すべてのページを切り替えていくのがメインのナビゲーション形式です。ページ切り替えは素ワイプジェスチャーで行います。

このナビゲーションは全体を眺めることに重点を置いています。ナビゲーションメニューの中から特定のカテゴリーを選んで、そのページに移動するのではなく、すべてのページをざっと眺めながら興味を引いたコンテンツを見るのに向いています。このナビゲーションをうまく実装できればメリットは明確です。いままでコンテンツをつまみ食いしていたユーザが、全体を眺めてくれるようになるのです。

トップナビゲーションを無くしたインタフェースを実現するためには、２つのことが必要です。

1. 素早くて滑らかなページ切り替え
2. 大きくて目立つ見出し

このうち2番目の大きな見出しについては、各ページの余計なコンテンツ（主にナビゲーションリンク）を減らせば実現できます。しかし1番目は現在のウェブサイトの作り方では難しいところがあります。今のウェブサイトはロードするのに時間がかかりすぎるからです。逆に言うとページのロード時間を十分に減らすことができれば、トップナビゲーションを無くしたウェブサイトのデザインは実現可能になってくるかも知れません。

現在のウェブページのロードを早くするためには

iPadアプリはまず最初にすべてのコンテンツをダウンロードするので、ページ内容はすべてローカルに保存できます。だからページの切り替えが非常に素早くできます。HTML5にはブラウザ内のデータをため込むための方法がいくつか用意されていますので、これを使うとページ切り替えがかなり早くできます。

またページをロードするのにかかる時間の大部分は、実はコンテンツではなく、JavascriptやCSSだったりします。このあたりも要改善です。

直感的なページ切り替えの操作

今までのウェブサイトはページを続けてざっと眺めるのに適したUIを用意してきませんでした。ページ切り替え用のボタンを用意するものはありましたが、ボタンは小さく、マウスを移動させてクリックするのは面倒でした。それに対して、iPadアプリで使われるスワイプジェスチャーは非常に直感的で、簡単にできます。同じぐらい簡単な操作をPCでも実現できればトップナビゲーション不要なUIが作れるかもしれません。

まとめ

以上、いろいろな話をしました。まとめると以下の通りです。

1. iPad miniの登場で、PC用のウェブサイトであってもiPad miniに最適化する必要が出てきました。
2. iPad miniに最適化するときに重要なのは、無駄なナビゲーションリンクを減らすこと。
3. ナビゲーションリンクを減らす中で、トップナビゲーションメニューの役割すら再検討するべきです。
4. ナビゲーションリンクを減らすことと、ページロードのスピードを上げることは密接に関わっています。必要に応じてHTML5のデータ保存機能を活用しながら、ページロードスピードの向上に努める必要があります。