iPadでHTML5でWebアプリを作ってみました。現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。JavaScriptの設定を変更する方法はこちらHomeテクノロジーBlogiPadでHTML5でWebアプリを作ってみました。トップ全記事一覧テクノロジー2010.06.16iPadでHTML5でWebアプリを作ってみました。LatLongLabの河合(@inuro)です。iPadが日本でも発売されましたね。入手された方もたくさんいらっしゃることかと思います。ヤフーではこのiPad国内発売にタイミングを合わせ、Yahoo!ラボで「yubichiz」というiPad専用の地図Webアプリを公開しました。地図に書かれた文字(大塚家具、とか紀伊國屋書店、とか)をタップするだけでその店舗の詳細情報が表示されます地図を指でなぞるだけで、なぞったラインの距離を測定できます同様に地図を指でなぞるだけで、道沿いのお店を検索できますといった特徴があります。Storeからダウンロードするいわゆる「アプリ」ではなく、HTML5を用いてiPadのSafari上で動作するWebアプリとなっています。今日はyubichizを作る上でいろいろと試行錯誤した内容について、少しご紹介させていただきます。開発サイクルが速いリリースサイクルが速い挑戦的であるの3点が挙げられます。開発サイクルが速い、はWebアプリ全般に言える特徴で、コードを更新すれば即座にブラウザから挙動を確認しフィードバックをもらえます。アプリケーションやサービスの開発においては、フィードバックサイクルのオーバーヘッドや機能不全が開発コストの大半を占めます。今回、短い期間で設計・実装のみならずブラッシュアップを行いリリースするためにはWebアプリでなくては困難でした。ユーザによるDLを経るネイティブアプリより遥かに速いことは大きな利点です。最後に挑戦的であるということですが、これはもう単純に「アプリだと普通だよね」「アプリじゃなくHTMLでどこまでできるんだろうね」「HTMLでアプリみたいだったらいかすよね」というノリと勢いです。制限の中で何ができるのかを模索するのは楽しいですよね。iPadでのUIデザインで気を付けるべきことさてiPadでWebアプリを作ろうと考えた場合、特にUIのデザインでは気を付けるべき点が幾つかあります。iPadは大きいiPhoneではない固定サイズ、固定環境ステップ数はできるだけ少なくiPadは大きいiPhoneではない「iPadなんて大きいiPhoneだろ?」はユーザの視点からはそういう捉え方もありますが、開発者の視点からは明らかに間違いです。人間の手のサイズ、眼の解像能力が一定である以上、デバイスの大きさの違いは最も本質的な違いです。電話の設計が耳から口までの距離に拘束されるのと同じです。iPadの場合は、画面が広いためインタフェースを配置する余地が充分にあります。後述のステップ数の話とも関連しますが、iPhoneではスペースの制限上メニュー→機能選択→さらにオプション、と多段にならざるを得ない操作も、iPadであれば1タップで呼び出せるボタンとして配置することが可能になります。yubichizではなるべく多くの機能に1タップでアクセスできるように、ボタンをフラットに配置しています。試しにyubichizをiPhoneで表示すると、以下のようにボタン類がまったく収まりません。iPhone向けとは根本的に異なるUI設計が必要です。マルチタッチのインタフェースはiPhoneでも同様ですが、3.5インチのスクリーンサイズでは実際にはオペレーションのメインはシングルタッチになります。多くの指や両手で操作しようと思っても、指が邪魔で画面が見えません(なおこれがマウスなどの間接ポインティングデバイスと直接ポインティングインタフェースであるタッチの大きな違いのひとつです)。iPadであれば、左手でモードを指定しながら右手で操作する、といったインタフェースが有効に機能するでしょう。yubichizには「なぞって測定」機能がありますが、これもモード切り替えではなく定規アイコンを左手で押しながら、右手で地図をなぞればその間だけスクロールではなく測定を行うという操作にすれば、再びモードをスクロールに戻す、という1ステップを省略することができます。yubichizにも実際に実装したいと思っています。固定サイズ、固定環境Webサービスの開発者は、ブラウザウィンドウの大きさが可変である・ブラウザの実装が様々である、という状況にすっかり慣れていると思います。「あのブラウザさえ無ければ」と呟いたことがある方も少なくないと思います。user-scalable=no">と記述すれば、ビューのサイズもほぼ固定で考えることができます。よって、Safariの実装をフルに生かした仕様で、ブラウザ側のリサイズによるレイアウト崩れなどを気にすること無くインタフェースをデザインすることができます。yubichizでは、機能を切り替えると左上にこのような帯が斜めに表示され、選択された機能をアナウンスします。この処理は、CSSで以下のように指定して実現しています。rotateZ(-15deg);}このCSSは、iPadで期待通りに表示されることしかテストしていません。実際Firefoxなどでは斜めになりませんし(-webkit-transformしか指定していないので当然ですが)、透過の具合やフォントもブラウザによって微妙に異なりますが、iPadで良ければそれで良し、としています。このように、1つの環境での最適化に集中すれば良いというのは、開発サイクルの高速化にも非常に大きな効果があります。ステップ数が多いだけでストレスを強く感じるのは、例えばiPhoneのTwitterクライアントを使い比べた方などは経験されているのではないでしょうか。タッチはマウスよりも直感的で、狙うとか外すといった要素がほとんどありません。マウスであれば「カーソルをボタンの位置に正確に動かす」というステップが暗黙の内に含まれています。1ストロークで狙った位置に動かせるわけではなく、ミスや微調整がそこに加わります。ところがタッチであれば、狙ったボタンを一発で押すことができます。動作自体にミスがほとんど介在しないため、マウスより圧倒的に操作のリズムが速くなります。それだけにステップが増えたり、1つのステップに時間が掛かったりすると大きなストレスを感じます。ステップ数の多寡がユーザ体験の良否に直結します。yubichizでは前述のように機能をなるべくフラットにボタンとして展開し、少ないステップ数でシナリオを実現するように心がけています。「なぞって測定」も、地図の上で距離を測る最もシンプルな方法は何か、を考えた結果生まれた機能です。「ジャンル検索」機能がありますが、これもよく使う検索を2ステップで実行できるようにしてあります。「よく使う検索」は当然ユーザによって異なるので、検索するジャンルを設定できるように改良する予定です。OS(4からはiOSですね)のホーム画面は、1ステップ、遅くとも2・3ステップで主要なアプリにアクセスできるようになっています。余談ですがこのアプリアクセスへのコストが著しく低いからこそ、iPhoneのアプリはPCのアプリとは異なり単機能アプリが多く、またそれが受け入れられてもいると言えます。Webアプリは、Safariを起動しブックマークボタンをタップしブックマークを選択し(場合によってはスクロールしたりフォルダを追ったり)、と遥かにステップ数は多くなります。Clipという仕組みを利用します。ClipはWebページをネイティブアプリの様にユーザに見せることができる仕組みです。Clipに対応したWebページをホーム画面に追加すると、そこから起動したWebページはSafariのツールバーが表示されず、まるでネイティブアプリの様にフルスクリーンで表示されます。Clipを有効にするためには、以下のmetaタグを記述します。Guideを参照してください。Clipには様々な利点があります。画面を広く使える不用意な「戻る」「進む」などでページが切り替わる危険がないSafariで走らせるよりもちょっと速い(気がする)最後はあくまで体感でありまだ検証していないのですが、特にSafariで複数ページを開いていると顕著に感じられます。Clipに戻るともういちど最初から起動しなおしになるというものです。Clipになるとそこは一切面倒を見てもらえません。Clipで快適なユーザ体験を提供するためには考え方を切り替える必要があります。アプリケーションキャッシュによる高速起動まず1つに、HTML5のアプリケーションキャッシュの仕組みを用いてデータをローカルにキャッシュし起動を高速化することが効果的です。Clipは毎回最初から起動しなおしになるので、画像やスクリプトなど固定的なファイルはなるべくネットワークからではなくローカルから高速に読み出したいです。Note詳しくは各種サイトを参考にして頂くとして、簡単に説明するとMIMEタイプを「text/cache-manifest」としたマニフェストファイルを用意する上記ファイルに、キャッシュさせたいリソース、させたくないリソースなどを記述するhtmlタグのmanifestアトリビュートに上記ファイルを指定するすることでアプリケーションキャッシュが有効になり、指定されたリソースをローカルに保持するようになります。yubichizの例をもう少し具体的に見ると、まずマニフェストファイルは以下のようになっています(内容は分かりやすいように一部変更・省略してあります)。manifest...NETWORK:https://map.yahoo.co.jp/CACHE:#scriptsjquery.jsipad.js#stylesheetsipad.css#imagesimages/ruler.pngimages/scroll.pngimages/search.png#で始まる行はコメントです。CACHE:のラベルに続くファイルがキャッシュ対象とするファイルです。ここでは使用しているスクリプト、スタイルシート、画像などを軒並み記述してあります。逆にNETWORK:のラベルに続くファイルは、必ずネットワークから取得することを指示するファイルになります。ここでは地図のタイル画像は必ずネットワークから取得するように設定してあります。このファイルを「cache.manifest」というファイル名で保存し、MIMEタイプを適切に設定した上で、htmlファイル冒頭に以下のように記述します。manifest="cache.manifest">これで、マニフェストファイルが変更されない限り(あるいは設定→Safariから削除されない限り)、指定されたリソースは全てローカルに保持され、高速に読み出されます。Clipはページの状態を一切保持してくれないので、ネイティブアプリと同様の体験を提供するためには自前で状態のシリアライズとデシリアライズを行う必要があります。実はyubichizはシリアライズにまだ対応できていません。早期に対応したいと考えています。シリアライズのバックエンドとしては、LocalStorageを利用します。LocalStorageは「あたしルートラボ」の記事でもご紹介したように、ドメイン単位でユニークなクライアントサイドのKey-Valueストアです。ページを閉じてもデータを保持することができるので、基本的には終了時に状態をLocalStorageに書き出し、起動時にまたLocalStorageから書き戻す、という実装でシリアライズが実現できます(実はそう上手くはいかないことについては後述します)。データビューモード(地図、リスト、グリッド)検索モード(AUTO、場所、店舗)操作モード(地図、測定、なぞり検索)といった辺りを持ちますので、これらのモデルからLocalStorageに格納できる形でデータを書き出します。LocalStrageはKey-Valueストアで単純な文字列の格納しかできませんので、オブジェクトをJSONで書きだすのが適当です。書き出したデータは、起動時にLocalStorageから読み出してevalし値をコピーします。スケルトンとしてはこんな形になります。jsonstr);}}ここでjsonizeはそれぞれのオブジェクトで実装すべき適切なJSON化メソッドです。典型的にはtypeofがfunctionではないメンバーについて、JSONとして書き出すことになると思います。ここでひとつ問題があります。アプリの終了をフックすることが実は困難です。よってモデルの状態が変化するたびに都度シリアライズを行うしかありませんが、地図をスクロールするたびに処理を行っていてはUIの軽快性を損ねかねません。快適なユーザ体験のためにはこの辺りをうまくチューニングする必要があります。OSはようやくその本来のポテンシャルを発揮できたとも言え、iPadでのWebアプリは上述のように制限や課題も多いものの非常に挑戦的で魅力的な分野だと思います。iPhoneではWebアプリの存在感は残念ながらそれほどありませんでしたが、iPadではぜひWebアプリが盛り上がって欲しいと思います。yubichizおよびこの記事がその一助となれれば幸いです。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。