モバイルブラウズ

[アーティクル]
06/16/2015

モバイルブラウズエクスペリエンスを向上する

Steven Sanderson

近ごろは、どのような人がモバイルデバイスを使って Web にアクセスしているのでしょう。2005 年にモバイルデバイスを使ってインターネットにアクセスしていたユーザーは、裕福でマニアックな欧米人 (おそらくソフトウェア開発者) と考えられていました。多くの時間を費やして大きな携帯電話を低速データネットワークに接続し、極端に制限されたブラウズエクスペリエンスに耐え、そのために高いお金を支払う人々です。つまり、エッジケースにすぎませんでした。

現在では、モバイル Web アクセスが飛躍的に拡大し、世界規模での主流になっています。ヨーロッパや北米のコーヒーショップで、スマートフォンやタブレットデバイスを互いに見せ合っているティーンエイジャーや学生、さらには定年退職した人々を数多く見かけますが、それだけにはとどまりません。今日では、モバイルブロードバンドの加入者は約 "10 億" 人にのぼり、これは地球上の約 7 人に 1 人に相当します (さらに、なんらかの手段で定期的にインターネットを使用しているのは 7 人に 2 人です)。モバイルデバイスは順調に数を増やしているため、5 年以内には、Web アクセスに最もよく使用される唯一の手段になります。既に、最も成長の早い一部の国 (特にインド) では、多くの人々がオンラインになる唯一の手段がモバイルデバイスになっています。米国でも、モバイル Web ユーザーの 25% が、以前のように PC を使用して Web にアクセスすることは "なくなった"、または "ほとんどなくなった" と話しています (詳細については、「Mobile Web Access」(英語) を参照してください)。

Web サイトを構築して公開するのであれば、モバイルブラウザーのサポートについて考慮しなければならないことは明らかです。

モバイルブラウズが従来とは異なる理由

ご存じのとおり、ほぼすべてのモバイルブラウザーは、なんらかの形式の HTML をサポートします。特に iPhone や Windows Phone 7 といったハイエンドデバイスに搭載されている多くのモバイルブラウザーは、最新の HTML、CSS、および JavaScript 標準をサポートし、従来の PC ブラウザーで表示されていたコンテンツをピクセル単位に完璧にコピーしてレンダリングします。

モバイルブラウザーをサポートする最も安価なオプションは、何もしないことです。すべてのデバイス向けに同じデスクトップ指向のページを表示して、モバイルブラウザーがそのページを処理すると信じることです。しかし、このオプションを採用すると、いくつかの理由から、モバイルブラウズエクスペリエンスが著しく低下します。

携帯電話の画面は小さい: Opera Mini などの一部のモバイルブラウザーは、ページのレイアウトとスタイルを動的にフォーマットし直すことで、デスクトップ幅のページを処理します。その結果、デザイナーが思い描いていたような見た目になることはほとんどありません。iPhone の Safari や Windows Phone 7 の Internet Explorer といったその他のモバイルブラウザーは、デスクトップの幅でページをレンダリングしてから、ユーザーに拡大、縮小とパンを実行するように促して、ユーザーがテキストを読めるようにします。これは、閲覧者の忍耐を試していると言えます。
モバイルデータネットワークは低速な場合が多い: 閲覧者の帯域幅が、有線のブロードバンドユーザーの帯域幅と同じであると仮定しないでください。メガバイト単位で料金契約を行っている閲覧者もいるため、負荷の高いサイトは好まれません。
モバイルデバイスにはマウスやキーボードが付属していない場合が多い: デスクトップユーザーが使い慣れた操作メカニズムが、モバイルデバイスでも常に有効とは限りません。たとえば、短いリンクや小さいボタンのクリック操作は困難な場合があり、タッチ中心のデバイスでは間違いが起こりやすくなるだけでなく、アイテムを "ポイントする" という概念は存在すらしないことがあります。

したがって、モバイルブラウズに最高のエクスペリエンスを提供する場合は、エンジニアリングのスキルを適用して、デバイスの主な種類の差異を考慮する必要があります。

ASP.NET でのモバイルサポート

モバイルブラウザーをサポートするための主な側面には次の 2 つがあります。

特定の閲覧者が使用しているデバイスの種類を特定する: ASP.NET には、ブラウザーを検出するための組み込みサポートがあります。この後、このメカニズムを説明し、カスタマイズと拡張の方法についても紹介します。
検出したデバイスで適切に機能する出力を作成する: 先ほどの課題にもう一度目を通すと、使用しているテクノロジプラットフォームで自動的に処理できるものではないことがわかります。モバイルサポートは、主に、ユーザーエクスペリエンス (UX) デザインの問題であり、マークアップの問題ではありません。後半では、さまざまなデバイス向けに異なる出力を生成する技法を説明しますが、複数のモバイルデバイスにそれぞれ異なるレイアウトとユーザーワークフローを設計および実装するかどうかは開発者しだいです。

2005 年にリリースされた ASP.NET 2.0 の頃までは、モバイルデバイスで機能するように出力を生成することはマークアップの問題でした。というのも、当時よく使用されていたデバイスでは、特殊なプロトコルとマークアップ言語 (WAP、WML、および cHTML など) が使用されていたためです。ASP.NET 2.0 には、それらの形式をサポートするために "モバイルコントロール" が含まれていました。しかし、現在は、すべての主要ブラウザーで HTML が使用されるようになったため、こうした形式は完全に廃止され、ASP.NET モバイルコントロールも廃止されました。

ブラウザーの検出

Web フォームとモデル - ビュー - コントローラー (MVC: Model-View-Controller) の両方の基盤となる ASP.NET のコアプラットフォームには、ブラウザーを検出するための組み込みサポートがあります。Request.Browser.IsMobileDevice というブール型プロパティを使用して、閲覧者がモバイルブラウザーを使用しているかどうかを検出できます。ただし、この検出が機能した場合でもその正確さにどの程度制限があり、どの程度影響を受けるかを理解しておいてください。

ASP.NET は、着信する要求の userAgent ヘッダーの文字列と、一般的なブラウザーを記述する XML ファイル内の一連の正規表現とを比較することにより、要求を発行しているブラウザーの種類と、そのブラウザーの機能 (画面サイズ、JavaScript のサポートなど) を判断します。

これらの正規表現 (および対応するデバイスの機能に関する情報) は、C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers フォルダー (または対応するインストールフォルダー) の .browser ファイルのセットに格納されています。たとえば、標準の iphone.browser ファイルには、図 1 のようなコードが含まれています。

図 1 iphone.browser ファイル

<browsers>
  <!-- Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ 
       (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 -->
  <gateway id="IPhone" parentID="Safari">
    <identification>
      <userAgent match="iPhone" />
    </identification>
    <capabilities>
      <capability name="mobileDeviceModel" value="IPhone" />
      <capability name="mobileDeviceManufacturer" value="Apple" />
      <capability name="isMobileDevice" value="true" />
      <capability name="canInitiateVoiceCall" value="true" />
    </capabilities>
  </gateway>
  ...
</browsers>

このファイルでは、次の要素で、着信する userAgent ヘッダーの文字列と比較する正規表現を定義します。

<userAgent match="iPhone" />

システムが、一致する userAgent 正規表現を検出したら、残りの XML データでそのデバイスの種類と機能を指定します。

このシステムに制限があるのは明らかです。ASP.NET 4.0 が最初にリリースされたときに既に知られていて、これらのファイル内に記述されているモバイルデバイスしか検出できません。残念ながら、これには Opera Mobile や Google Android の既定のブラウザーなど、現在よく使用されているブラウザーは含まれていません。それらのブラウザーに対しては、Request.Browser.IsMobileDevice が誤って false に設定されます。

ブラウザー検出のカスタマイズと拡張

既定のブラウザー検出機能の制限を克服する主なオプションは 2 つあります。

独自の .browser ファイルを指定して新しいデバイスを表現する
サードパーティのブラウザー検出ライブラリを使用する

1 つ目のオプションを使用するには、Visual Studio ソリューションエクスプローラーでプロジェクト名を右クリックし、[追加]、[ASP.NET フォルダーの追加] の順にポイントして、[App_Browsers] をクリックします。次に、そのフォルダーに .browser ファイルを追加します。たとえば、C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers フォルダーから既存のファイルをコピーして、その ID となる正規表現とデバイス機能の記述を編集して、目的のブラウザーを表現します。

新しくリリースされた何百ものすべてのモバイルブラウザーを把握して、.browser ファイルを最新の状態に保つことを望まない場合は、2 つ目のオプションとして、サードパーティのブラウザー検出ライブラリを使用します。

現時点では、51degrees.Mobi Foundation をお勧めします。これは、CodePlex (51degrees.codeplex.com、英語) でホストされているオープンソース (MPL ライセンス) ライブラリです。このライブラリは、.browser ファイルを使用しません。代わりに、デバイスを Wireless Universal Resource File (WURFL) データベースと照合して、デバイスを特定します。このデータベースは、商用アプリケーションでも商用以外のアプリケーションでも無料で使用できます。WURFL の詳細については、wurfl.sourceforge.net (英語) を参照してください。

51degrees.Mobi Foundation を Web フォームまたは MVC プロジェクトに最も簡単にインストールするには、NuGet パッケージマネージャーを使用します。ASP.NET MVC 3 を実行している場合は、既に NuGet がインストールされています。それ以外の場合は、Visual Studio 拡張機能マネージャー ([ツール] メニューにあります) を使用して、NuGet を検索してインストールします。NuGet をインストールしたら、[ツール]、[Library Package Manager] (ライブラリパッケージマネージャー)、[Package Manager Console] (パッケージマネージャーコンソール) の順にクリックして、コンソールで次のコマンドを実行します。

Install-Package 51Degrees.mobi

このコマンドにより、プロジェクトに次のものが追加されます。

WURFL データベースの最新のコピーが、プロジェクトの /App_Data/wurfl.xml.gz に追加される
ライブラリのメインアセンブリ (FiftyOne.Foundation.dll) への参照が追加される
51degrees.Mobi Foundation を有効にするための Web.config エントリが追加される

51degrees.Mobi Foundation は、ASP.NET の標準 Request.Browser API にプラグインし、これを拡張します。パッケージをインストールするだけで、Request.Browser.IsMobileDevice の結果がはるかに正確になります。これは、最新バージョンの WURFL データベースにより、Opera Mobile ブラウザーや Google Android ブラウザーなど、現在よく使用されているモバイルブラウザーを検出できるためです。

既定の 51degrees.Mobi Foundation の Web.config 設定では、モバイルブラウザーからのすべての要求が ~/Mobile/Default.aspx という URL にリダイレクトされるよう構成されるため注意が必要です。多くの場合 (特に ASP.NET MVC アプリケーションの場合)、これは望ましい動作ではありません。パッケージが Web.config ファイルに追加する <redirect /> 要素をコメントアウトするか削除して、リダイレクトを無効にします。必要に応じて、/Mobile/Default.aspx ファイルを削除することもできます。

モバイルのスタイル設定

モバイルブラウザーを確実に検出する方法がわかったので、モバイルブラウザー別にページのレンダリング方法を制御する主な方法について説明します。その後、レンダリングしたマークアップをデバイスの種類ごとに変化させるための、アーキテクチャ上のオプションをいくつか説明します。

iOS の Safari や Windows Phone 7 の Internet Explorer などの最新モバイルブラウザーの多くは、レンダリングしたページを、デスクトップブラウザーと同じように表示しようとします。これらのモバイルブラウザーは、ほとんどのページが幅約 1,000 ピクセルの画面向けにデザインされていて、デザイナーがそれよりはるかに小さい幅を考慮していない可能性が高いことを把握しています。

これを解決するために、モバイルブラウザーは一般に、ページを "ビューポート" という仮想キャンバスにレンダリングします。ビューポートの仮想幅は、通常約 1,000 ピクセルです。その後、ブラウザーは、その仮想キャンバスの表示を適宜倍率変換して、ユーザーが拡大、縮小とパンを実行できるようにします。図 2 に、この調整を示します。

A Mobile Browser Rendering a Desktop-Width Page onto a Virtual Viewport

図 2 デスクトップ幅のページを仮想ビューポートにレンダリングするモバイルブラウザー

これでデザイナーが意図したとおりにページをレンダリングできますが、ユーザーがテキストを読めるようになるまで拡大したときに、ページ幅全体を表示できず、水平方向にスクロールしなければならないという、ユーザビリティにかなりの難点が生じます。

ビューポート幅の制御

小さい画面向けのページを実際にデザインしたことがあれば、ページを幅約 1,000 ピクセルの仮想ビューポートにレイアウトしたいとは考えません。実際の画面と同じ幅のビューポートにページをレイアウトして、水平方向がきちんと収まり、拡大しなくても済むようにします。

最もよく使用されるモバイルブラウザーの多くは、非標準の "viewport" メタタグをサポートし、仮想ビューポートの幅を制御できるようにしています。たとえば、次のコードをページの <head> セクションに追加すると、ブラウザーは、幅 320 ピクセルのビューポートにページをレイアウトします。

<meta name="viewport" content="width=320"/>

これは、通常、携帯電話とよく調和します。

一部のモバイルデバイスの画面では、水平方向の解像度がはるかに高くなります。たとえば、iPhone 4 では、行ごとの物理ピクセル数は 640 です。ただし、約 320 ピクセルの仮想ビューポートを使用するのには理由があり、これ以上少なくすると、表示されるテキストが小さすぎて拡大しないと読めなくなります。

次の構文を使用して、使用するデバイスに応じて仮想ビューポートを変更します。

<meta name="viewport" content="width=device-width"/>

一部のモバイルデバイスは、文字通りのデバイス幅を提供しないので注意してください。このようなモバイルデバイスは、"デバイスの幅" を "製造元が考える最も望ましい結果をもたらす仮想ビューポートの幅" だと解釈します。したがって、たとえば、iPhone 4 は、物理解像度が高いにもかかわらず、デバイスの幅を 320 ピクセルと定義します。

マークアップの推奨事項

モバイルブラウザー向けにページをデザインするときは、常に、次の点に注意してください。

viewport メタタグを使用して、ビューポートが画面の水平方向の幅に収まるようにします。
狭い画面幅を考慮して、ページ、レイアウト、CSS スタイルなどを調整します。閲覧者が水平方向に拡大したりスクロールしたりする必要がなければ、そのページは、そのデバイス向けにデザインされたネイティブアプリケーションのように感じられ、はるかに優れたエクスペリエンスを提供できます。
不正確にタップしても大丈夫なように、リンクやボタンを大きくします。指先は、マウスポインターの先端に比べてはるかに大きくなります。
解像度が非常に高い画像や大量の JavaScript ファイルを使用しないことで、必要な帯域幅を最小限に抑えます。

アーキテクチャ上のオプション

これまで、モバイルブラウザーの検出方法について説明し、モバイルブラウザーに合ったマークアップの推奨事項についていくつか説明してきました。ここで、さまざまなブラウザーの種類に合わせて異なる出力を生成するアプリケーションを構築するための、3 つの簡単なオプションについて説明します。

ブラウザーの種類に応じて、マークアップのセクションの表示と非表示を切り替える
ブラウザーの種類に応じてマスターページを切り替える
ブラウザーの種類に応じて、まったく異なるコンテンツを表示する

これらの各オプションには利点と制限事項があるため、要件に合ったアプローチを選択するのは開発者です。

マークアップの表示と非表示

ブラウザーの種類に応じて、メタタグや CSS ファイル参照を含めたり含めなかったりするだけで済めば非常にシンプルです。たとえば、Web フォームのマスターページで、<head> セクション内に "if" ステートメントを追加できます。

<head runat="server">
  <title>My site</title>
  <link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />

  <% if (Request.Browser.IsMobileDevice) { %>
    <meta name="viewport" content="width=device-width"/>
    <link href="~/Styles/MobileSite.css" rel="stylesheet" type="text/css" />
  <% } %>
</head>

ASP.NET MVC 3 アプリケーションの Razor のレイアウトで同じような指定を行うと、次のようになります。

<head>
  <title>@ViewBag.Title</title>
  <link href="@Url.Content(
    "~/Content/Site.css")" rel="stylesheet" type="text/css" />
  @if (Request.Browser.IsMobileDevice) {
    <meta name="viewport" content="width=device-width"/>
    <link href="@Url.Content(
      "~/Styles/MobileSite.css")" rel="stylesheet" type="text/css" />
    }
</head>

これはきわめて基本的な技法ですが、追加の CSS 規則を別の MobileStyles.css ファイルに追加するだけで、既存のマークアップを小さい画面に収まるように適合させることができれば、この方法でも十分です。もちろん、マスターページやビューのほかの場所でこれと同じメカニズムを使用して、ブラウザーの種類に応じて出力を変更することも可能です。

まったく新しい Web サイトを構築し、使用する CSS だけを切り替えてデスクトップ画面とモバイル画面の両方に合うようにマークアップをデザインできる場合は、この技法が最適です。その場合は、必要となる追加の開発作業は非常に少なくなります。多くのサイトにとっては、このシンプルな技法では対応しきれません。そのため、マスターページを切り替える方法と、異なるコンテンツを表示する方法の 2 つの代替策があります。

マスターページの切り替え

既存のコンテンツページを変更しないで、異なるマスターページや異なるレイアウトを使用して、単に小さい画面用にレイアウトを適合させることも可能です。たとえば、Web フォームアプリケーションを構築する場合、標準ページの基本クラスを定義して、マスターページを動的に切り替えます。

public class PageBase : Page
    {
      protected override void OnPreInit(EventArgs e)
      {
        if (Request.Browser.IsMobileDevice)
            MasterPageFile = "~/Mobile.Master";
      }
    }

次に、デバイスの種類に応じてレイアウトを変更するページで、通常の System.Web.UI.Page ではなく PageBase から継承するように分離コードクラスを設定します。続いて、/Mobile.Master にマスターページを作成します。このマスターページのレイアウトと CSS スタイルを、モバイルデバイスに合わせて最適化します。

Razor のレイアウトを使用している ASP.NET MVC 3 開発者にとっては、これはさらに簡単です。次のコードが含まれるように /Views/Shared/_Layout.cshtml ファイルを編集すれば、すべてのビューでレイアウトを動的に切り替えることができます。

@{
  Layout = Request.Browser.IsMobileDevice 
             ? "~/Views/Shared/_MobileLayout.cshtml"
             : "~/Views/Shared/_Layout.cshtml";
}

次に、/Views/Shared/_MobileLayout.cshtml に新しい Razor のレイアウトファイルを追加して、モバイルデバイスに希望どおりに適合するように、このレイアウトファイルの構造と CSS スタイルを変更します。

これにより、CSS とマークアップのセグメントだけを必要に応じて変更すればよいので、先ほどの技法よりも柔軟性が高まりますが、依然として、基本的に同じ情報をデスクトップとモバイルの両方のページに表示し、同じ対話メカニズムを使用しなければならないという制限があります。

異なるコンテンツの表示

異なる CSS やマスターページとレイアウトを使用するだけでは、モバイルデバイスに合うようにデスクトップページを適合させることはできないアプリケーションもあります。その理由は次のとおりです。

ビジネス要件が多すぎる: 真に洗練されたモバイルエクスペリエンスを求めるならば、モバイルデバイスごとに異なる (おそらく少ない) 情報を表示することをお勧めします。その結果、ユーザーを異なるワークフローに導ける可能性が高くなります。たとえば、ユーザー登録プロセスの手順を少なくすれば、モバイル閲覧者に関して収集する情報も少なくなります。これは、CSS で対処する問題ではありません。
さまざまな変更を受け入れにくいレガシコードを使用している: たとえば、既存のマークアップで要素のサイズとスタイルがハードコーディングされている場合があります。CSS や異なるマスターページを使用してこれを変更することができない場合や、マークアップがさらに複雑になって管理しにくくなる場合があります。

いずれの場合も、最終的な解決策は、さまざまなデバイスの種類に合わせて、まったく別個のロジックとマークアップを使用することです。2 つのバージョンを管理しなければならないことが欠点ですが、2 つの動作を望みどおりに個別に変化させることができるのが大きな利点です。Web フォーム開発者にとっての実装は、通常、モバイル固有の一連の ASPX ページになり、MVC 開発者にとっての実装は、通常、モバイル固有のコントローラーとビュー向けに新しい領域を作成することになります。どちらの方法でも、アクセスする閲覧者を、デバイスの種類に応じて適切なページにリダイレクトするためのロジックが必要です。

コードサンプルでは、Web フォームと MVC の両方で出力キャッシュとフォーム認証との互換性がある方法で、リダイレクトのロジックを実装する方法を示しています。この詳細については、bit.ly/gHT3Ap (英語) のホワイトペーパーを参照してください。

結論と最終的な推奨事項

今回は、次のことについて説明しました。

モバイルブラウザーがますます重要になっている理由
優れたモバイルサポートは、マークアップが異なるというだけの問題ではなく、主に UX デザインの問題である理由
ASP.NET のコアプラットフォームが既定でモバイルブラウザーを検出するしくみ
既定のブラウザー検出アプローチの制限事項と、検出アプローチの拡張または置き換えの方法
モバイルブラウザーが小さな画面にデスクトップサイズのページを表示するしくみと、そのしくみに影響を与える方法
さまざまなブラウザーの種類に対して異なる出力を送信するためのアーキテクチャ上のオプション

アプリケーションとエンドユーザーにとって最適になるようにこれらの技法を組み合わせて選択するときは、"ユーザビリティを優先" して "テスト" することをお勧めします。最終的に、ユーザーに不適切なブラウズエクスペリエンスを提供することになるのであれば、モバイルサポートを実装しても無意味です。次の点を考慮してください。

モバイルユーザーに通常のデスクトップビューに戻す方法を提供する: 一般に、ページ上部に "デスクトップビューに切り替える" というリンクを配置します。この切り替えを実装する方法はアーキテクチャによって異なり、単純に特定の URL のデスクトップバージョンにリンクしたり、標準のブラウザー検出メカニズムよりも優先される cookie を設定したりすることもできます。

モバイルページに表示する情報をデスクトップページに表示する情報よりも少なくする場合、パワーユーザーは、モバイルページにあると思っている情報や機能にアクセスできないとストレスが溜まるため、この機能が特に重要です。

モバイルビューにリダイレクトする際に情報が失われないようにする: アクセスするモバイル閲覧者が要求しているページとは無関係に、モバイルホームページに閲覧者をリダイレクトする Web サイトもあります。これはユーザーにとってきわめて苛立たしいことで、事実上、ほぼすべての着信リンクが機能しなくなります。ユーザーが要求しているページのモバイルバージョンがなければ、そのページのデスクトップバージョンを表示します。

実際のデバイスまたはエミュレーターを使用して実装を検証する: モバイル対応のレイアウト、CSS、およびメタタグが、想定どおりに処理されないデバイスもあります。実際のデバイスかエミュレーターでのテストが必要です。よく使用されるモバイルデバイスのエミュレーターの一覧については、asp.net/mobile/device-simulators (英語) を参照してください。

小さなことから始める: サイト全体のすべてのページと機能をモバイル向けに最適化したバージョンを、一度に作成する必要はありません。多くのビジネスにとっての価値の大部分は、モバイル対応のホームページを用意することと、おそらく、その他のいくつかの重要なユーザーワークフロー (登録やカタログの閲覧など) のページを用意することからもたらされます。

一部のイントラネットアプリケーションなど、モバイルデバイスをサポートすることが適切でない場合があります。しかし、インターネットサイトをパブリックに公開し、今後数年間適切な状態を維持するつもりであれば、ほぼ確実に、モバイルブラウザーを検討する必要があります。

Steven Sanderson は、ASP.NET MVC、Web フォーム、NuGet、およびその他の Web 関連の利点を提供するチームのプログラムマネージャーとして、マイクロソフトに勤務しています。

この記事のレビューに協力してくれた技術スタッフの Scott Hunter に心より感謝いたします。