モバイル サイト開発: マークアップ
Web の閲覧に使用されるデバイスが増えるにつれて、モバイル向けに最適化した Web サイトを運営することが企業にとって重要な要素になっています。現状を見ると、最新のスマートフォンでさえ、デスクトップ サイトの閲覧にはかなり問題があります。コンテンツをきちんと理解したり、リンクをたどるには、パンやズームが必要です。確かに閲覧は可能ですが、すばらしいユーザー エクスペリエンスとは言えません。
スマートフォンでもデスクトップ サイトが閲覧されます。モバイル版のサイトがあっても、好んで完全版サイトが閲覧されることがよくあります。これには大きな理由があり、多くのモバイル サイトが、デスクトップ サイトのように適切にデザインされていないためです。サイトをよく利用するユーザーなら、きっとどのようなメディアを使ってサイトにアクセスしていても、すべての情報が見つかることを期待します。モバイル ユーザーの状態はさまざまで、移動中のこともあれば、急いでいることもあります。また接続が不安定かもしれません。しかし、モバイル ユーザーの現状がどうであっても、モバイル デバイスを使ってサイトにアクセスするときは、まったく同じレベルのサービスが受けられることを期待します。
これがまさに、モバイル サイトの設計者と開発者が直面する課題です。モバイル サイトの最大の問題は、必ずしも機能の実装自体にあるのではありません。モバイル サイトは、一般にデスクトップ サイトと比べてページあたりの機能や動作が少ないため、コード行数も少なくなり、問題の発生も少なくなります。ところが、優れたユーザー エクスペリエンスを提供するため、通常、要求される機能にはデスクトップ サイトよりも高い緊急度が求められます。モバイル デバイスで優れたユーザー エクスペリエンスを確保することは難しく、多くの場合、チームにはきわめて巧妙なコーディングやデザインのソリューションが要求されます。
また、モバイル サイトは、幅広い種類のデバイスに対応する必要があります。数年前まではさまざまなデスクトップ ブラウザーに対応することが悩みの種でしたが、モバイル空間について考えると、数千にも及ぶデバイス プロファイルに対応することが問題になります (ただし、バージョンを変えたページを数千種類用意する必要はなく、数千のデバイス プロファイルを、異なる処理が必要な数種のデバイス クラスに減らすだけです)。
今回のコラムは通常のテクノロジに重点を置くアプローチではなく、異なる観点からモバイル サイト開発にアプローチするシリーズの第 1 回です。大半のモバイル サイト開発は、多くの場合、ユース ケースの検討やコンテンツ構造の変更には時間を掛けず、特定のフレームワークとそのソリューションに関連付けられます。今回は基本から始めます。つまり、モバイル マークアップから始めます。
ブラウザーとビューポート
今日のほとんどのモバイル ブラウザーの既定では、デバイス画面の実際のサイズよりはるかに大きなビューポートにページが描画されます。ビューポートの実際の幅はブラウザーによって異なりますが、通常、1,000 ピクセルほどです。たとえば、iPhone の Safari と Internet Explorer 9 は 980 ピクセル、Android WebKit は 800 ピクセルです。モバイル開発者は、まず、ビューポートの役割と起源を理解します。図 1 に、モバイル ブラウザーでビューポートが使用されるしくみを示します。
図 1 モバイル ブラウザーでビューポートが使用されるしくみ
ビューポートとは固定幅の領域で、ブラウザーによってすべてのコンテンツがここに描画されます。ビューポートのサイズは、必ずしも画面の物理サイズには関係しません。2 つのサイズの違いはデスクトップ ブラウザーにとってはたいした問題ではありませんが、モバイル デバイスのきわめて小さな画面にとっては問題になります。多くのブラウザーは、内部ビューポートのサイズを考慮しないでページを描画します。このようなブラウザーはビューポートを表示する際、コンテンツ全体が実際の画面サイズに収まるようにビューポートを縮小します。
ユーザーに与える実質的な影響として、コンテンツにたどり着くために縦横へのスクロールが必要になります。または、コンテンツを読み取れるようにするために、さらに重要なこととして、リンクをたどることができるようにコンテンツの拡大が必要になります。ブラウザーでのビューポートの内部実装の詳細については bit.ly/bZYlKb (英語) を参照してください。
ビューポートとマークアップ
モバイル サイト開発が始まったころは、デスクトップ サイトとは異なるマークアップが使用されていました。歳月をかけて、ワイヤレス マークアップ言語 (WML) から compact HTML (cHTML)、モバイル向け extensible HTML (XHTML) へと移行してきました。いずれのマークアップの場合も、明確な Multipurpose Internet Mail Extensions (MIME) の種類がブラウザーに提供されます。この MIME の種類を基に、受け取る予定のコンテンツの種類を判別し、その種類に応じてコンテンツを描画します。iPhone の登場により、モバイル デバイスとノートパソコンの機能にそれ程違いはなく、少なくとも Web ページの描画についてはほぼ同等であることが明らかになりました。しかし、モバイル ブラウザーとデスクトップ ブラウザー向けに同じマークアップを使用すると、画面サイズの違いから問題が起こり、モバイル ユーザーには適宜コンテンツを強制的に拡大縮小することになります。
デスクトップとモバイル双方の要求に同じ MIME の種類 (text/html) が使用されると、その MIME の種類を使って、コンテンツがデスクトップ サイズとモバイル サイズのどちらのビューポートにレイアウトが設定されるかをブラウザーに指示できなくなります。そのため、Apple Inc. は数年前に viewport メタ タグを導入しました。現在では viewport メタ タグは業界標準となり、モバイル ページにするつもりであれば、このメタ タグを設定します。以下に、viewport タグの代表的な使い方を示します。
<meta name="viewport" content="width=device-width" />
このメタ タグの content 属性には、数個のプロパティにアドホック値を設定できる式を指定します。指定できるプロパティのうち最も重要なのが width です。ブラウザーはこの width プロパティを使用して、ビューポートのサイズを動的に決定します。width プロパティには、具体的なピクセル数、または上記の例のような特殊な式を設定できます。上記の例の値 device-width は、ピクセル単位の画面幅を示します。このコンテキストでのピクセルとは、デバイスに依存しないピクセル (CSS ピクセル) を意味します。高密度のピクセルを備えたデバイスの場合、ブラウザーは強制的にスケールを変更します。このようなデバイスでは、100 ピクセルの幅で約 150 ~ 200 の物理ピクセル数に対応できる可能性があります。図 2 に、viewport の式でサポートされるプロパティを一覧します。
図 2 viewport 式のプロパティ
プロパティ | 説明 |
width | デバイスに依存しないピクセル単位でビューポートの希望する幅を示します。明示的な数値 (240 など) も指定できますが、device-width などの相対値が推奨です。 |
height | デバイスに依存しないピクセル単位でビューポートの希望する高さを示します。明示的な数値 (320 など) も指定できますが、device-height などの相対値が推奨です。 |
initial-scale | ページを最初に読み込むときに、希望するズーム レベルを示します。値 1 は、まったくズームしないで、本来のサイズのままページを描画することを示します。値 2 は、ページのサイズを 2 倍にすることを示します。以降同様です。"1.0" のように小数値も使用できます。 |
minimum-scale | ページで許容される最小ズーム レベルを示します。値 1 は、ユーザーがページを本来のサイズよりも小さく縮小できないことを示します。 |
maximum-scale | ページで許容される最大ズーム レベルを示します。最大値は 10.0 です。 |
user-scalable | ユーザーがページをズームできるかどうかを、"yes" か "no" で示すプロパティです。 |
上記以外のプロパティをサポートするブラウザーもあります。具体的には、Android ブラウザーで target-densitydpi プロパティを使用でき、開発者はページにとって望ましい画面解像度をブラウザーに伝えることがができます。Android のブラウザーはこのプロパティを使用して、画像などのピクセルベース リソースを最適なスケールに設定できます。target-densitydpi プロパティには具体的な数値、または device-dpi などの特殊な値を設定できます。
以下に viewport メタ タグの具体的な設定方法を示します。
<meta name="viewport"
content="width=device-width, user-scalable=no, initial-scale=1"/>
height プロパティはあまり使用しません。通常、height プロパティを使用するのは、画面下部に配置する要素があるとき、またはビューポートの高さによって変化する位置に配置する要素があるときです。最後に、user-scalable に "no" を設定し、そのページでのピンチやズームを禁止しています。
今日では、viewport メタ タグが非常に一般的になりましたが、過去には同様の目的に、HandheldFriendly や MobileOptimized のようなメタ タグを使用するブラウザーもありました。
<meta name="HandheldFriendly" content="true" />
<meta name="MobileOptimized" content="320" />
World Wide Web コンソーシアム (W3C) は viewport 要素を標準化する仕様を策定中です。現在の草稿については、bit.ly/AavTG5 (英語) を参照してください。
HTML と XHTML Mobile Profile
viewport などのメタ タグの最終目標は、開発者の意図どおりにコンテンツが描画されるビューポートのサイズを示すことです。モバイル ブラウザーにプレーンな HTML マークアップを提供する場合は、メタ タグを使用します。なんらかの理由があってモバイル マークアップを提供するのであれば、メタ タグを使わずに、ドキュメントに XHTML Mobile Profile (MP) DOCTYPE を記述するだけでもかまいません。
<!DOCTYPE html PUBLIC
"-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
"http://www.openmobilealliance.org/tech/DTD/xhtmlmobile12.dtd">
XHTML MP を示す MIME の種類は “application/vnd.wap.xhtml+xml” です。プレーンな HTML の表現能力に比べ、XHTML MP は、ドキュメント オブジェクト モデル (DOM) の操作、CSS と JavaScript のサポートなどの重要な分野に制限があるため、時代に即していません。
今日のデバイスの大部分が機能する最新標準は、HTML と viewport タグを併用するものです。ところが、HTML や viewport タグをサポートしない古いデバイスなど、サイトは実にさまざまな種類のデバイスから開かれる可能性があります。この状況には、どのようにすれば対応できるでしょう。
率直に言うと、このような場合は、モバイル ブラウザーの機能に関する情報を格納する特別なデータベースの助けが必要です。このようなデータベースを Device Description Repository (DDR) と呼びます。Wireless Universal Resource File (WURFL) は、Facebook で使用されている DDR です。この WURFL には preferred_markup というプロパティがあり、サーバー (たとえば ASP.NET アプリケーション内) からこのプロパティを照会して、ページを要求しているデバイスに提供するのに最適なマークアップを判断できます。WURFL の詳細については、wurfl.sourceforge.net (英語) を参照してください。今後のコラムでは、WURFL と、51Degrees のような他の DDR も取り上げる予定です。
HTML5 とモバイル ブラウザー
HTML5 は、少なくとも現状の標準において、最新のモバイル ブラウザーがほぼ適切にサポートするマークアップ言語です。このことは、Fennec (Firefox のモバイル版) や Opera Mobileのような外部ブラウザーだけでなく、スマートフォンの組み込みブラウザー (iPhone と iPad の Safari、Android WebKit、Windows Phone の Internet Explorer 9) にも当てはまります。
特に、mobilehtml5.org (英語) では、各種モバイル ブラウザーの HTML5 対応状況を詳しく比較した情報を調べることができます。ほとんどのデバイスがキャンバスと SVG をサポートしていることがわかります。一方、モバイル ページにとって重要な input 要素は iOS 5 では適切にサポートされていますが、Android WebKit の現バージョンではサポートされていません。ローカル ストレージ、地理位置情報、マルチメディアもほぼすべてのブラウザーでサポートされます。
スマートではない
モバイル サイトとは、既存のデスクトップ サイトを基に作成するものと単純に考えられる場面が多すぎます。そのような考えから、クライアントはデスクトップ ブラウザーと同様に "スマート" (高機能かつ強力) であると想定し、ほとんどがデスクトップ サイトの視点からデザインされます。しかし、スマートフォンはノートパソコンのように "スマート" ではありません。このように大幅に劣っている点がモバイル サイト開発の重要な側面です。このため、モバイル サイト プロジェクトに着手するとき最初に検討する点は、対応するユース ケースと対象とするデバイスです。その後で、サイトで使用するテクノロジを考えます。今後のコラムでは、モバイル特有のユース ケースを見極めるテクニック、モバイル開発のパターン、およびデバイスの種類によって描画を変更する方法について取り上げていきます。
Dino Esposito は、『Architecting Mobile Solutions for the Enterprise』(Microsoft Press、2012 年) と 『プログラミング Microsoft ASP.NET MVC ASP.NET MVC 3 対応版』(日経BP社、2012 年) の著者であり、『Microsoft .NET: Architecting Applications for the Enterprise』(Microsoft Press、2008 年) の共著者です。Esposito はイタリアに在住し、世界各国で開催される業界のイベントで頻繁に講演しています。Twitter (twitter.com/despos、英語) で彼をフォローしてください。
この記事のレビューに協力してくれた技術スタッフの Shane Church と Steve Sanderson に心より感謝いたします。