scriptjunkie{}

Web をレスポンシブ Web デザイン対応にする理由

Rahul Lalmalani | 2013 年 3 月 28 日

モバイルの台頭

今日のサイト トラフィックの多くは、従来の PC に加えて、スマートフォンやタブレットといったモバイル デバイスから生じます。世界中のインターネット トラフィックの 12% をモバイル デバイスが占めるようになり、成長率ではデスクトップのインターネット トラフィックを凌いでます。スマートフォンの普及率が高い国では、モバイル Web トラフィックの割合はこれよりかなり高く、たとえば米国から発せられる Web トラフィックの 20% がモバイル ブラウザーからのものです。さらに、ハードウェア面やソフトウェア面でのスマートフォンの進化と成熟、南米、アジア、アフリカでの利用拡大により、この率は今後 10 年間にわたって大きく伸びることが予想されます。

サイトの所有者は、ここ数年この傾向への対応を始めており、Facebook、Hulu、New York Times といった人気のサイトで、ネイティブ モバイル アプリが主として利用されようになっています。Pulse や Flipboard などの新興 Web サービスでは、モバイル優先のアプローチが取られ、iOS やその他のエコシステム向けのアプリがビルドされてから Web サイト エクスペリエンスが構築されています。このようなネイティブ アプリがあるため、開発者はスマートフォン優先でタッチ操作に最適化された独特のエクスペリエンスを作成でき、ユーザーはカメラ統合、位置情報、オフライン データ ストレージといった機能を利用したコンテンツを操作できます。

モバイルのユーザーをターゲットにすることは、とりわけモバイル ユーザーの 50% 以上がスマートフォンを所有する米国では当然の流れです。モバイル アプリはサイトの所有者に多くの機会を提供します。たとえば、新しいフォーム ファクターを使うユーザーに接続する方法、複数のプラットフォームで収益化する新たな方法、ユーザーの力になり、ユーザーを楽しませるモバイルシナリオ中心のエクスペリエンスなどです。しかし、Web のユビキタス性や対象範囲に比べると、モバイル アプリが開発者に提供する機会は不完全なものです。これは、ネイティブ モバイル限定のアプローチに影響を及ぼす問題がいくつかあるためです。

問題 1: 複数のプラットフォームをサポートする費用

複数のプラットフォームに同じコンテンツやエクスペリエンスを作成する費用は高く、サイトの所有者は最適化するプラットフォームの選択が迫られます。また、他のプラットフォームからコンテンツにアクセスするユーザーの Web サイト エクスペリエンスを制限することになります。特に、開発への投資を優先する必要があるときはこれが顕著です。

"レスポンシブ デザイン" の Web サイトを利用すると、投資する費用に対処でき、ユーザーはすべての最新モバイル OS で一貫性のある有益なエクスペリエンスを楽しめます。

Allrecipes.comの元製品管理担当副社長で、モバイル製品開発の責任者も務めた Scott Scazafavo 氏は次のように述べています。

「(MSN や前職の Allrecipes.com で行ったように) ライブ データやライブ コンテンツを備えた "業界トップ" のサービスと渡り合えるネイティブ モバイル アプリの開発にまともに取り組むには、通常、ネイティブ アプリの要件定義、デザイン、エンジニアリングなど最低限の初期投資として約 2,500 万円かかります。その後、アプリを進化させ、高い機能性を維持して利用者の関心を引き付け、導入数を健全に保つためのネイティブ アプリの年間メンテナンス費用が、プラットフォームごとに 750 ～ 1,000 万円かかります。こうした費用は、製品を強化するサービス (API) の作成やメンテナンスを行うためのデザインやエンジニアリングに必要なすべて社内作業とは別にかかります」

「当社の TMX 製品を発表するために MSN (現在 IE10 で使用できる MSN.com の新しいタッチ操作優先版) で採用した HTML5 を使ったアプローチと、その製品をモバイル ブラウザー以外に、アプリ ストアにも供給できるようにするシンシェル アプリが必要でしたが、このためにかかった費用はこのアプリ製品を作成するために社内リソースにかかった初期投資をほんの少し増加させただけでした。(金額は) 各アプリのプラットフォーム 1 つあたり約 250 ～ 500 万円の初期投資になりますが、こうしたアプリにはその後のメンテナンス費用はほとんどかかりません」

同様に、レスポンシブ Web デザイン テクニック (Clipboard.com) を使用することで、プロジェクト開始時に予想していた開発費用の "半額" で、Windows 8 の Internet Explorer 10、iPhone や iPad の Safari といった小型モバイル デバイスの多くのブラウザーをターゲットにすることができました。

問題 2: エコシステムの断片化

ある 1 つのプラットフォームを考えても、デバイスの形状とサイズ、サポート対象のプラットフォームのバージョンなど、多数のバリエーションが存在します。そのため、サイトの所有者はよく似たディスプレイ サイズや解像度を対象にいくつもデザインするだけでなく、複数のアプリ ストア (Kindle ストア、Google Play、Nook ストアなどの Android プラットフォーム) に登録を申請する必要があります。同じプラットフォーム内で複数のアセットを管理すると、サポート マトリックスの複雑さが増します。ネイティブ アプリのレイアウトのバグを Nexus 7 用に修正したら、今度は Kindle Fire アプリでもその修正が必要になるかもしれません。つまり、すべてのユーザーが同じ機能セットを備え、同じようにバグが解決された同じバージョンのアプリを利用しているわけではありません。

同じように (iOS アプリのエコシステムの中でさえ)、ESPN、Spotify、Angry Birds Space といった人気のアプリや、App Store 自体も iPhone 5 のリリース時に画面全体を占有するように正しく表示されず、アプリ画面の上下に黒い線が表示されました。iPhone 5 の追加リリースにより、開発者はアプリの更新プログラムを提供してこの単純なレイアウト バグに対処することが求められました。

また今もなお、ベンダーは巨大画面などの "新しいフォーム ファクターについて実験" している段階です。たとえば、2,500 万人以上いる Xbox Live ユーザーは、リビング ルームのテレビ画面で Internet Explorer 10 にアクセスできるようになり、ポインターだけでなく、Kinect や Xbox SmartGlass のような人間を主体とするメカニズムを使って画面を操作しています。今日、技術上の意思決定者は、ユーザーの日常生活に組み込まれているデバイスが断片化され激しく変化する状況に直面しています。

統一アプローチ: レスポンシブ Web デザイン

レスポンシブ Web デザインの目的は、市場に出回っているあらゆるデバイスに最適な表示と利用のエクスペリエンス ("最低限のサイズ変更、パン、スクロールでの簡単な読み取りやナビゲーション") を提供し、"今後登場するデバイスでもサイトが古めかしくならないようにする" ことです。Web には、サイトをよりレスポンシブにするために役立つ個々のテクニックに関するさまざまなチュートリアルが既に存在します。今回のシリーズは、レスポンシブ Web デザインに対する統一アプローチを提供することだけではなく、意思決定者や開発者に、自身のサイトへのアクセス戦略の一環としてすぐにレスポンシブ デザインの採用が必要だと感じてもらうことが目的です。modern.IEによって、人気のある 5,000 の Web サイトをクロールしたところ、レスポンシブ デザインの形式になっているのは約 14% だけでした。開発者がレスポンシブ デザインの検討を面倒な作業だと考える理由はわかります。

図 1をご覧ください。一般的なスマートフォンとタブレットの Web ブラウザーの相対的な画面解像度を表しています (各デバイスを表 1に示します)。デバイスの解像度と、ハードウェア ピクセルに対する CSS ピクセルの比率 (第 3 部で説明予定) は、ウィキペディア(英語) からの引用です。各四角形が 100 x 100 ピクセルの Web コンテンツに対応し、1 倍の光学ズームでレイアウトされます。

図 1 いくつかの最新デバイスの解像度の見本(クリックすると画像が拡大されます)

表 1 対応するデバイス

A	iPhone 4
B	iPhone 5
C	Samsung Galaxy S3
D	Nokia Lumia 920
E	HTC 8X
1	Kindle Fire、Nook Color
2	Kindle Fire HD
3	LG Nexus 7
4	Kindle Fire HD 8.9
5	iPad および iPad mini (ハードウェアの解像度は違いますが CSS ピクセルの数は同じです。詳細については、第 2 部を参照してください)
6	Microsoft Surface

では、これに対するソリューションは、クロスブラウザー、クロスデバイス コードなのでしょうか。

従来は、OS 固有のアプリにすることで、位置情報などの有益なユーザー情報、オフライン ストレージ、さらにはカスタム インターフェイス用のカスタム フォント サポートを利用できるため、より洗練されたユーザー エンゲージメントを提供できました。

ただし、Internet Explorer 10、Google Chrome (バージョン 22)、Safari 6、Firefox (バージョン 17) などの最新のブラウザーでは、このようなエクスペリエンスの大半が HTML5 と CSS3 のサポートの一環として提供されるようになります。HTML5 は、本来、人が一連の文字情報をインターネット経由でエンコードおよび配信できるように設計されていた以前の HTML とは大きく異なります。HTML5 の目的は、開発者が 21 世紀にふさわしいリッチな Web ベースのアプリを作成できるようにすることです。HTML5 と CSS3 を併用すると、かつてはネイティブ機能だったメディア クエリ、位置情報、カスタム フォント サポート、タッチ イベントにアクセスできるようになります。その結果、さまざまなサイズのハードウェアに異なる外観とレイアウトを用意し、ユーザーに位置情報対応のサービスを提供し、インターネットが切断されたときでも有益なエクスペリエンスを提供することができます。

HTML5 の神話

世の中には HTML 5 に関する神話がいくつかあります。それらを次に示します。

HTML5 は収益化できない

HTML5 サイトは、ほぼ間違いなく、アプリ バージョンより収益化の機会が多いと言えます。今日では、アプリの収益化にアプリの購入も含まれます (とは言え iOS アプリ ストアの大半のアプリは無料から 100 円の範囲です)。おそらく、HTML 5 サイトのエクスペリエンスで直接収益化ができないのはアプリ自体の購入だけです。それ以外の広告収入やアプリ内購入やサイト内購入に関しては、開発者が多くを制御できます。さらに重要なのは、多くのアプリはユーザーが行えるナビゲーションの量を制限する傾向があることです。たとえば、大半のリーダー アプリや新聞/雑誌アプリはテキスト コンテンツを提供しますが、Web の "リンク特性" を提供しません。Web の "リンク特性" により、ユーザーは現在の Web ページを利用しながら関連コンテンツに移動できます。

レスポンシブ デザインを実装する Web サイト エクスペリエンスでは、Web 本来の "リンク特性" を保持し、ユーザーのインプレッション数を高めることができます。

HTML5 はオフラインにできない。

HTML5 には、オフラインでの優れたユーザー エクスペリエンスを確保するためのソリューションがいくつかあります。まず何よりも、Web ページでは、(アプリ キャッシュを使用して) インターネットから切断された状態でも利用できるようにするアセットを指定できます。 その結果、オフライン時でも引き続きそのページを操作できます。また HTML5 では、localStorage および IndexedDB を使用して、ユーザー情報や入力をローカルに保存できます。ローカルに保存したデータはユーザーがブラウザーを閉じた後も存続し、後にユーザーが Web ページを再度呼び出した時点で、サーバーと同期して戻すことができます。

こちらのオフライン計算機(英語) のデモを参照してください。ユーザーは、初回のアクセス時にだけ Web に接続する必要があり、それ以降はオフラインでアクセスすることができます。さらに、ユーザーの計算と結果はローカル ストレージに保存されるため、いったん終了しても、後から計算を続行できます。

HTML5 に関するいくつかの一般的な誤解を取り除く出発点としては、Mozilla ハック ブログ (英語) をお勧めします。ネイティブ アプリはデバイス固有パフォーマンスに最適化される API を使用することに注意が必要です。ただし、HTML5 と CSS3 では、さまざまなフォーム ファクターで魅力的なエクスペリエンスを構築するためのツールが提供され、他のプラットフォームからアクセスしてくるユーザーを逃さないようにすることができます。

CanIUse.com(英語) は、具体的な HTML5 機能と CSS 機能について利用可能なブラウザー サポートを理解するための優れたリソースです。

メディア クエリとレスポンシブ デザイン

レスポンシブ Web デザインに役立つ CSS3 の新しいツールの 1 つが "メディア クエリ" です。メディア クエリにより、さまざまなユーザーに同じ HTML コンテンツを提供できます。ただし、ブラウザーがデバイスのサイズ制約を (ピクセル単位で) 検出できるようにして、同じコンテンツを適切な方法でレイアウトを変えて表示します。特定のデバイスのユーザーにとって適切と考えるエクスペリエンスに応じて、テキストや画像のコンテンツ幅の伸縮や新聞紙スタイル レイアウトの段組数の増減に加えて、一部の情報を完全に非表示にすることさえ可能です。

コンテンツのレイアウトを指示するメディア クエリと、ユーザー エクスペリエンスの追加制約 (大画面 TV で Xbox 360 を使ってサイトを操作する場合など) を特定するブラウザー検出を組み合わせることで、ユーザーのニーズを把握でき、ユーザーがコンテンツにアクセスしている現状 (さまざまな機能を備えたデスクトップからの利用、タブレットでのタッチ操作、外出先でスマートフォンを使った流し読み) に合わせて適切なエクスペリエンスを提供できます。いくつか Web テクノロジを使えば、これをスムーズに行うことができます。

最もすばらしいのは、最新モバイル デバイスの大半が HTML5 と CSS3 をサポートしている点です。そのため、ネイティブに近いエクスペリエンスをブラウザー内で直接生み出すことができます。DRM サポートがないことや、デバイス特有の特定のハードウェアを利用できないことを除いて、HTML5、CSS3、および JavaScript を利用して提供できるエクスペリエンスの種類に制限はありません。レトロな Atari のビデオ ゲーム (英語) を確認すると、標準準拠の Web テクノロジーだけを使用してビルドできる魅力的なエクスペリエンスがわかります。

Web サイトでメディア クエリを使用して異なる固定幅のレイアウトを 3 つだけ構築すれば、今日の一般的な画面サイズ (デスクトップ、タブレット、スマートフォン) をターゲットにすることはできます。ただし、「これは真の意味でレスポンシブ Web デザインではありません」。どの幅にも当てはまらないデバイスを使ってサイトにアクセスするユーザーは、最適なエクスペリエンスを得られません。新しい形状やサイズを持つ "新たな" デバイスの登場に備えることにもなりません。

ビルドも配置も 1 回

サイトのエクスペリエンスに取り組むのであれば、小型スマートフォンのタッチスクリーンから、映画館の巨大スクリーンやテレビ画面まで、複数のフォーム ファクターに対応してスケール変換される 1 つのエクスペリエンスを HTML5、CSS3、および JavaScript を使って設計します。実装の詳細については、シリーズ後半で詳しく説明します。ただし、魅力的な新機能で楽しませたり、高度なセキュリティ更新プログラムで保護したりするために、対象にするユーザーを選ぶ必要はまったくないことだけは覚えておいてください。

この手法には、コード ベースやサポート マトリックスが簡単になること以外に、次のようなメリットがあります。

メリット 1: すべてのユーザーをターゲットにできる

主なモバイル プラットフォームを 1 つか 2 つ選んで強力なネイティブ アプリを作成すると、競合相手が範囲を広げてすべてのプラットフォームで実用的な Web エクスペリエンスを提供した場合、獲得したユーザーの一部がそちらに流出することになります。

メリット 2: 広告ストーリーの統一

サイトの収益が広告に依存する場合、ユーザーが本格的な Web バージョンを利用しているか、制限のあるアプリ バージョンを利用しているかによって、ビジネス パートナーとの関係構築や、販売する広告が断片的なものになりかねません。また、モバイル デバイスでの広告のクリックスルー率はデスクトップ PC よりも下がります。この場合、パートナーとの関係構築、ネイティブ アプリ用広告アセットの作成、およびアプリ固有の広告スペースの販売に追加でかかる費用と利益増加との整合性が取れなくなります。たとえば (世界中の市場に向けて、メディアクエリベースの統合型 HTML5 Web サイトの本格展開を開始した) MSN.com では、すべての種類のデバイスの広告パートナーシップ ストーリーを統一できるようになりました。

さまざまなフォーム ファクターに反応してスケール変換される 1 つの HTML5 エクスペリエンスにより、1 件の広告クライアントに、リビング ルーム、職場のデスク、外出先などさまざまな利用デバイスに同じ組み合わせの広告アセットを提供できます。

メリット 3: サイトのエクスペリエンスを直接アプリのエクスペリエンスにアップグレード

場合によっては、デバイス独自のハードウェアを利用して優れたモバイル エクスペリエンス提供することを考えると壁にぶつかることがあります。たとえば、スマートフォンを振動させて新しいコンテンツが利用できるようになったことをユーザーに知らせる場合などです。この場合はデバイスの加速度計にアクセスする必要があります。

さいわい、サイト コンテンツにラッパーを適用することでネイティブ アプリを作成し、必要なコードを記述すれば、スマートフォンの新たなハードウェアを操作できます たとえば、iPhone の場合、WebViewController 内でサイト コンテンツをホストしてレスポンシブに表示がスケール ダウンされるようにし、objective-C ネイティブ コードで accelerometer イベントをリッスンするだけです。

つまり、解決策や機能を Web 層内に構築しておけば、アプリのアップグレード時に問題になることはありません。

「どのように始めるか」

ここからは、レスポンシブ Web デザインの "ハウツー" について説明する必要があります。これについてはシリーズ第 2 部から始めます。拡張が続くオープン JavaScript ライブラリのサポート、HTML5 のリッチなデバイス統合、CSS3 の高品質のレイアウトとグラフィックのサポートと、なじみのある Web テクノロジで記述した単一のコード ベースから成るコンテンツを使って、長期にわたるメリットをユーザーに提供するチャンスを理解していただければと考えています。このようなチャンスを活かさないとしても、急速に増加するデバイスの一覧 (図 1) を常に振り返るようにしてくだしさい。

この記事は、Internet Explorer チームによる HTML5 技術シリーズの一部です。3 か月間無料の BrowserStack クロスブラウザー テスト (https://modern.IE) を使って、この記事の概念をお試しください。

執筆者紹介

Rahul Lalmalaniは、マイクロソフトでエンジニアとしての勤務経験があり、現在はフリーランスでアプリと Web 開発を行っています。ホームページは RahulJL.com(英語) で、連絡先は@quasirahul(英語) です。

コメント (0)

コメントを残すにはサインインしてください。