はじめに

新しい技術には、革新的な人々が新しい可能性を開拓しようと努力するなか、急速な進化を遂げる期間があります。それは、問題に対するいくつかのソリューションが、人々の心と市場シェアを勝ち取ろうと競い合うからです。モバイル・ユーザー・インターフェース (UI) 技術は、このような進化の段階の真っ只中にあります。現在、Apple の iOS (iPhone、iPod Touch、iPad)、Google の Android、Blackberry のオペレーティング・システム、HP の webOS、および Windows Phone 7 モバイル・オペレーティング・システムを使用する電話とタブレットのすべてが、多種多様な UI 設計手法を提示しています。

UI の多様性は、意図的なものです。プラットフォームが市場シェアを獲得するためには、他のプラットフォームとの差をつけなければなりません。Android プラットフォームに至っては、通信事業者および通信機器ベンダーがそれぞれの製品を差別化しなければならないため、さらなる多様性が生まれています。その結果としてもたらされる製品の多様性は、競争力を強化するためには必要ですが、これらの機器を対象にアプリケーションや Web サイトを作成している開発者およびデザイナーにとっては難問となります。さまざまなタイプの機器でネイティブに動作するアプリケーションを作成するには、開発チームに以下のことが求められます。

• 多種多様な開発技術におけるスキル
• 広範で、しかも次々と追加されていく一連の機器の機能についての知識
• さまざまに異なる UI スタイルの慣例および標準に関する知識
• 複数のプログラミングおよび相互移植への取り組み
• 費用のかかるマルチデバイスおよびマルチプラットフォーム・テストへの取り組み

モバイル Web技術は、さまざまな機器のプラットフォームで使用できるアプリケーションをコスト効果の高い方法で開発できるようにします。Dojo Mobile、jQuery Mobile、Sencha Touch などの新たに開発された JavaScript ライブラリーを使用することで、モバイル UI 開発者は「Write Once, Run Anywhere (一度書けば、どこでも実行できる)」アプリケーションを作成することができます。開発者がプラットフォームによって異なるフレームワークの数々を学ぶ必要も、サポートされるプラットフォームごとにアプリケーションを開発し直したり、移植したりする必要もありません。インストールは一切必要でないという Web アプリケーションの特性は、ユーザーにとってもメリットになります。ユーザーは常に最新バージョンのアプリケーションを使用することになるため、オンライン・アプリケーション・ストアから更新をインストールする必要はありません。さらに、アプリケーションのデプロイヤーにも、同じアプリケーションの異なるバージョンを実行するユーザーをサポートする心配がなくなります。

その一方、高品質のモバイル Web アプリケーションの設計には、特有の複雑さがあります。第一に、モバイル・ユーザー・インターフェースは以下の理由から、基本的にユーザー操作の新しいパラダイムであると言えます。

• 小さいフォーム・ファクター
• タッチ・インターフェース
• 加速度センサー
• 向き認識
• アニメーションの多用
• 物理的な動きのシミュレーション

第二に、Web UI は、機器のサイズ、フォーム・ファクター、さらには機能セットに関係なく、あらゆる機器で動作しなければならないため、デザイナーは従来のデスクトップ Web アプリケーションを設計する場合よりも多くの可変要素を考慮する必要があります。

この記事では、モバイル Web UI を設計する際の考慮事項とベスト・プラクティスを詳しく探ります。実装に関しての詳細はほとんど説明しませんが、記事では折に触れて HTML5 と Dojo Toolkit モバイル UI コンポーネントについて言及します。必要に応じてネイティブ・モバイル・アプリケーションの設計に関する問題も説明しますが、主にクロスプラットフォームの設計に焦点を当てます。また、市場で占めるシェアの大きさから、特に iOS、Android、および Blackberry のユーザーが期待する内容に重点を置きます。

上に戻る

ディスプレイ・サイズ

小型であることは、機器をどこででも使えるようにする一方、ユーザビリティーの多くの側面にとってはマイナスに作用します。小さな画面では、読みやすく明瞭に表示できる情報の量が限られます。設計時には、この制限された画面スペースがテキストと画像によって瞬く間に埋め尽くされると、コンテンツとユーザー操作との間のトレードオフが生じることになります。

スマートフォンは小さく、タブレットにはネットブックからラップトップまでの大きさがあります。多くのベンダーはこの両タイプの機器をさまざまなディスプレイ・サイズで提供しています (図 1 を参照)。モバイル Web アプリケーションの設計は、この広範なディスプレイに対応して、ローエンドの端末で文字が読みにくくなることも、ハイエンドの端末で引き伸ばされて見えたりすることもなく、拡大縮小するようでなければなりません。

上に戻る

入力

よく使われているモバイル機器の多くは、タッチおよびジェスチャーによる入力を使用しています。タッチ入力は直観的なものの、正確さに欠けます。従来のインストール型アプリケーションや Web アプリケーションでのマウスとポインター形式の入力と比べ、ボタンなどのタッチ・ターゲットはかなり大きくし、ターゲット間の間隔を広く取らなければなりません。

電話の場合、画面サイズが制限されている上に、操作ターゲットのサイズが大きいことから、パネルごとのコントロール数は絞られます。また、指および手による画面上での UI 操作は、マウス・ポインター・アイコンには程遠いほど曖昧です。

モバイル Web アプリケーションは本質的に特定のプラットフォームには依存しないため、各種機器の入力特性についても考慮しなければなりません。モバイル機器のなかには、物理的なキーボードを備えているものもあれば、仮想キーボードしかないものもあります。さらには、この両方を使用するモバイル機器もあります。一部の Blackberry 機器では、タッチパッドでポイント、選択、およびドラッグ操作を行えるようになっています。また、Blackberry 機器と Android 機器はどちらも各種のナビゲーション・アクション専用の物理ボタンを搭載していますが、その配列は異なります。

上に戻る

オペレーティング・システムの多様性

オペレーティング・システムによって左右される UI 設計の違いのうち、最も重要な違いはナビゲーションの設計、コントロールの実装、そしてビジュアル・スタイルの 3 つです。

ナビゲーション

iOS ではジェスチャーとウィジェットを使用して、ユーザーを画面間で移動させます。また、アプリケーションを閉じたり、フォルダーの外にナビゲートしたりするために、ベゼル上のホーム・ボタンも使用します。Android で使用しているのはジェスチャー、ウィジェット、ハードウェア・ボタン (ホーム、戻る、メニュー、検索) です。Blackberry ではジェスチャー、ウィジェット、ハードウェア・ボタン (メニューとエスケープ) を使用します。さらに複雑なことに、入力方式は、機器のモデルによっても、サービス・プロバイダーによっても異なります。この点は、Android 機器では重大な問題となります。仮想キーボード・レイアウト、およびベゼル上のボタンの左から右への並び順がサービス・プロバイダーおよび機器の製造業者によって異なるからです。

コントロールの実装

iOS は、ソフトウェアによる UI コントロール機能 (仮想ボタンなど) をふんだんに使用しています。アプリケーションまたはフォルダーの終了を唯一の例外として、ユーザーはウィジェットとの対話をタッチ操作によって行います。それとは対照的に、Android 機器と Blackberry 機器では、前の画面に戻る操作、そしてオプション・メニューを開く操作に物理ボタンを使用します。iOS 機器の場合、これらのアクションは画面上のボタンを使って呼び出します。

iOS アプリケーションでは、戻るアクションとコンテキスト・メニューのアクションをタブ行のボタンに割り当てることがよくあります。慣例により、iPhone および iPod Touch アプリケーションでは、ユーザーが親指で簡単に操作できるように、タブ・ボタンを画面の下部に配置します。別の理由から、Android スタイルの慣例ではタブ・ボタンを画面の上端近くに配置します。ボタンが画面の一番下に配置されていると、不注意に押してしまう可能性があるからです。

ビジュアル・スタイル

それぞれのプラットフォームが、カラー・テーマ、アイコン・スタイル、メタファー、ウィジェット・レンダリングによって固有のビジュアル・スタイルを定義しています。プラットフォームがビジュアル・テーマを使用するのは、美的理由だけではありません。プラットフォームのテーマを利用すると、アプリケーションのユーザー操作はプラットフォームの決まりに従うはずであるとユーザーが想定することができるからです。

上に戻る

パフォーマンス

JavaScript のパフォーマンスは良くはなってきているものの、モバイル機器に関しては依然としてパフォーマンスの問題があります。モバイル機器が使用するプロセッサーの処理能力はあまり高くなく、またラップトップ・システムやデスクトップ・システムよりも狭いネットワーク帯域幅に対処しなければなりません。

上に戻る

複数の機器の使用

ほとんどのスマートフォンのユーザーは、スマートフォンしか使用しないと言ってもよいでしょう。その一方、同じアプリケーションを何種類かの機器で使用する人々は大勢います。例えば、1 人のユーザーが iPod Touch、Blackberry フォン、Android タブレット、そして Microsoft Windows を実行しているラップトップなどから同じアプリケーションにアクセスすることも考えられます。基本的には、同じコンテンツが機器の種類によって異なる形でユーザーに対して表示されます。

マルチプラットフォームのマルチデバイス設計を複雑にしているのは、機器の種類による違いです。スマートフォンは、いつでもどこででも、簡単な操作で特定の目的を果たすのに適している一方、パーソナル・コンピューターは、どちらかというと特定の場所で、複雑な操作によってタスク間を切り替えながら複雑な情報を処理するのに適しています。タブレットの操作は、スマートフォンとラップトップの中間あたりに分類されます。

複数の機器を対象とした設計には、以下の要件についての慎重な考慮、そして競合する要件の間での妥協が必要になります。

• 各機器の機能を適切に利用すること
• 各機器の制約に賢く対処すること
• すべての機器で同じようなユーザー・エクスペリエンスを提供すること

優れたユーザー・エクスペリエンスを提供するためには、スマートフォンでの Web アプリケーションが、デスクトップ・バージョンとは異なる機能をサポートしなければならないことは珍しくありません。スマートフォンでアプリケーションを表示する場合、デスクトップでは意味のある機能を削除したり、モバイルのコンテキストでは当然の機能を追加したりする必要が出てくるはずです。けれども、モバイルにはその機能がなくても、複雑な Web アプリケーションをレンダリングする上で大きな支障にならない機能を予測するのは難しい場合があります。

こうした問題に対する魔法のような解決方法はありません。アプリケーションが使用されることになりそうな機器のコンテキストで、機能の使用ケースを理解して検証し、機器の能力と照らし合わせてみなければなりません。表 1 に、モバイル機器とデスクトップ機器でのユーザー・エクスペリエンスの違いを概説します。

複数の機器を使用するというシナリオで設計する際に何よりも重要なことは、ユーザーがアプリケーションにアクセスするために使用するすべての機器で、ユーザー・データを共有できるようにすることです。機器のタイプごとのアプリケーションのインスタンスは、同じコンテンツの調整した「ビュー」を提供することであると考えてください。

上に戻る

モバイル Web UI のベスト・プラクティス

ここまでは、モバイル Web のユーザビリティーに関する課題を検討し、マルチプラットフォーム・アプリケーションで考慮しなければならない事項をいくつか紹介しました。記事の残りでは、モバイル Web UI を設定する上でのベスト・プラクティスを探ります。

上に戻る

ツールキットの使用

開発という観点だけで言うと、ライブラリー、ツールキット、そしてフレームワークはいずれも作業を楽にしてくれます。標準的な UI コンポーネント・ライブラリーを使用すれば、開発およびテストの際に、下位レベルの設計、コーディング、ブラウザーの違いに対処するための処理、テスト、デバッグ、保守にかかる時間を大幅に節約することができます。質の高い UI コンポーネント・ライブラリーは、一般的に使用されるコントロールが一般に予想されるような外観と振る舞いを持つことを確実にすることによって、使い勝手を向上させます。

Dojo Toolkit は、バージョン 1.5 で基本的なモバイル UI 機能を導入しました。バージョン 1.6 とバージョン1.7 のベータ版では、ネイティブ・アプリケーションで通常見られるような UI コントロールの機能および対話動作をカバーしています。WebSphere Application Server Feature Pack for Web 2.0 and Mobile には、Dojo Toolkit バージョン 1.7 の他、いくつかの有用なアプリケーション・サービスおよび Diagrammer 可視化機能が統合されています。

上に戻る

機器のサイズに合わせたレスポンシブな設計

モバイル Web アプリケーションで筆頭に挙げられる設計上の課題は、有益なユーザー・エクスペリエンスをどのように作り出すかです。モバイル Web アプリケーションは、わずか数インチ四方の画面で表示されることも、タブレットやラップトップ、さらには大型ディスプレイを使用した機器で表示されることもあります。「レスポンシブ Web」とは、この問題に対処することを目的とした設計理念および一連の手法です。

レスポンシブ Web を設計する際の目標は、それぞれの Web サイトまたは Web アプリケーションが、それが表示される特定の機器およびブラウザー専用に設計されているかのように見せることです。レスポンシブ Web は、「よりレスポンシブな Web」と呼ばれるべきかもしれません。Web はこれまで常に、最大表示されていないブラウザーやさまざまなサイズと解像度のモニターでコンテンツを表示するという問題に対処してきたからです。モバイル機器のさらに小さいサイズ、そして多様性は、要求水準を今まで以上に引き上げただけに過ぎません。

レスポンシブ Web の実装では、コンテンツの表示を機器に適応させるために、CSS、メディア・クエリー、JavaScript を利用します。CSS3 のサブ仕様である Media Queries では、各種のスタイルシートを異なるメディア特性またはディスプレイ特性と関連付けることができます。例えば、機器の画面の高さ、幅、アスペクト比、そして解像度に応じてスタイルシートを選択することが可能です。

レスポンシブな設計の実装方法に関しては、この記事では詳細な説明をしません。そのいくつかの手法については、「Responsive Web Design: What It Is and How To Use It」およびレスポンシブな設計に関する A List Apart の投稿で説明しています。このセクションの残りでは、一般的な設計手法をいくつか抜粋して概説します。

レスポンシブなレイアウト

複雑なレイアウトが大きなディスプレイで効果を発揮することはよくありますが、スマートフォンでは使い物になりません。逆に、使用できる表示面積が十二分にある場合には、極端に単純なコンテンツ・レイアウトだと、興味を引かなかったり、読んでナビゲートするにはあまりにも退屈だったりします。多くの携帯型機器は、向きが変わるとそれを検知します。適切に設計されたレスポンシブなコンテンツは、自動的にそのレイアウトを機器のサイズと向きに合わせて調整します。

機器の画面のサイズがあまりにも小さくなり、解像度もがあまりにも低くなって、複数の列をサポートできない場合には、複数の列からなるレイアウトを 1 つの列だけからなるレイアウトに再フォーマットするという手段があります。図 2 と図 3 の例を見てください。

iPad アプリケーションでは、左ペインにナビゲーションを表示し、右ペインにコンテンツを表示するというお馴染みのパターンを用いることがあります。これは、大きなフォーマットの画面では効果がありますが、小さな電話サイズの機器に合わせて縮小することはできません。

この場合、モバイル Web アプリケーションでは、左側のナビゲーション・リストを画面全体に表示し、コンテンツは 2 番目の画面に表示するように設計することができます。この手法を実装するには、Dojo Toolkit のモバイル・ウィジェットである FixedSplitter と FixedSplitterPane を使用することができます。

タブ行も、レスポンシブな設計では懸念事項になります。前述したように、iOS 機器はタブ行を画面の一番下に配置する一方、Android 機器は画面の一番上に配置します。Safari モバイル Web ブラウザーは iOS の慣例に従って、ブラウザー・ナビゲーション・コントロールを画面の下端に配置します (図 4 の左側の図)。この配置は、タブを画面の下端に配置するという慣例に従う Web アプリケーションでは問題になることがあります。なぜなら、ブラウザーのタブ行とアプリケーションのタブ行が上下に積み重ねられることになるからです。この問題は、モバイル Web アプリケーションの HTML ヘッダーにmeta タグ <meta name="apple-mobile-web-app-capable" content="yes" /> を組み込むことで、簡単に解決することができます。こうすれば、ユーザーがホーム画面にアプリケーション・リンクを追加した場合、ブラウザー成果物が抑止されるからです (図 4 の b)。

Android アプリケーションで上記と同じような問題を回避するとともに、適切な Android アプリケーションのガイドラインに従うには、Web アプリケーションでメディア・クエリーを使用して Android 機器を検出し、画面のヘッダーの下にタブ行を配置してください (図 4 の d)。

レスポンシブなウィジェット

機器によって、搭載されている物理コントロールは異なります。そのため、Android 機器や Blackberry 機器で Web アプリケーションを表示するときには、機器の物理ボタンと重複するソフトウェア・ボタンを非表示にする必要があります。

ウィジェットのサイズについても考慮しなければなりません。ディスプレイの解像度 (インチあたりのピクセル数) はそれぞれに異なることから、モバイル UI の設計ガイドラインでは、物理サイズの単位で表現されることがよくあります。タッチ・ターゲットの最小サイズとしては、7 mm 平方から 10 mm 平方が推奨されています (これらのサイズは、iPad 2 では 36 から 52 ピクセル平方に相当し、iPhone Retina ディスプレイでは 90 から 128 ピクセル平方に相当します)。ターゲット間の間隔は、少なくとも約 1 mm から 2 mm にしてください。

レスポンシブなコンテンツ

場合によっては、ページ上のコンテンツを再編成するだけでは、広範なディスプレイ・サイズに対処しきれません。あらゆるアプリケーションを 2 × 3 インチ四方に押し込めて、それでもユーザビリティーを維持できるとは思わないでください。小型の機器と大型の機器の間では、使用パターンが異なることはよくあります。小型の機器は限られた簡単な操作をするのに最も適していますが、大型の機器は時間をかけて行う複雑な操作に向いています。例えば、モバイル上の気象情報アプリケーションで、現在のジオロケーションを取得して、現在および今後の気象情報を提供するとします。その場合、このアプリケーションのデスクトップ Web バージョンでは、この場所とその他の場所での気象履歴、気象事象に関するニュース記事や動画など、さらに多くのコンテンツを提供する可能性があります。

テキスト・コンテンツを縮小するには、最も重要な要素だけを選択的に表示するか、あるいは従属するセクションを別のページにリンクして移動させるという方法があります。

画像にしても、大型の機器と小型の機器に応じてサイズを調整することができます。それには、さまざまな手法があります。最も単純な方法は、画像を自動的に適切なサイズにすることですが、この方法にはパフォーマンスとの密接な関係があります。大きな画像を縮小すると、ユーザーに重要な詳細が見えにくくなる可能性があります。そこで代わりとなる手法は、モバイル機器にはサムネール画像を表示して、タッチ操作でズームインできるようにする一方、デスクトップ・ブラウザーでは画像をフルサイズで表示することです。また、場合によっては、重要な特徴のみが表示されるようにトリミングした複数の画像を作成し、ターゲット機器の解像度に応じて、選択的に画像を表示するほうが理にかなっていることもあります。

ネイティブな外観

主要な機器のプラットフォームの外観には、カラー・パレット、アイコン・スタイル、タイポグラフィーによって定義された、それぞれに固有の特徴があります。そのため、ある機器用に設計されたアプリケーションが、別のプロバイダーの機器では、とんでもなく場違いのように表示されることもあります。機器で一貫したエクスペリエンスを想定するユーザーの期待に応えるためには、アプリケーションを、それを表示する機器でのビジュアル・スタイルおよびインターフェースに合うように適応させることが極めて有効です。

図 5 に、dojox.mobile.deviceTheme (Dojo バージョン 1.7 ベータ版) モジュールでサポートされているプラットフォーム・テーマを示します。このモジュールを使用することで、自動的に機器のタイプを検出し、ターゲット機器に適したテーマを設定することができます。

ネイティブな対話インターフェース

レスポンシブな設計に必要なのは、ディスプレイの違いに対処することだけではありません。レスポンシブな設計では、ターゲット機器が該当する機能に物理ボタン (戻る、ホーム、オプションなどのボタンなど) で対応するかどうかに応じて、仮想ボタンを表示または非表示にすることについても考慮する必要があります。機器間でのその他の対話インターフェースの違いには、機器のブラウザーが対処します。

上に戻る

設計の再利用によるエクスペリエンスの改善

UI 設計パターンを利用すると使いやすさが向上する理由には、以下の 2 つがあります。

• 当然のことながら、パターンとは、よくある設計上の問題に対する実証済みのソリューションです。パターンのなかには、正式なユーザビリティーのテストによって証明されたものもあれば、設計の「自然淘汰」によって選ばれたものもあります。時間が経つにつれ、使用に適さない設計は使われなくなり、優れた設計が模倣されていくものです。
• パターンは一般的な設計のプラクティスであるため、ユーザーにとって親しみがあります。パターンをベースとした UI であれば、ユーザーが改めて学ぶ必要が一般に少なくなります。

Web 上にはモバイル UI パターンのサイトがいくつかあります。そのうち、pttrns および Mary Sheibley 氏の Mobile-Patterns は最も包括的なサイトです。この 2 つのサイトには、いずれも一般的な設計イディオムの例が提供されています。これらのパターン・ライブラリーでは設計のガイダンスを提供していませんが、他のアプリケーションでのユーザー・エクスペリエンスを利用した UI を設計する際には、設計のヒントとして役立つはずです。

上に戻る

ユーザーに選ばせること

可搬性の程度の他に、モバイル機器と従来のコンピューター機器との間には 2 つの大きな違いがあります。それは、ポイント操作の精度と入力の容易さです。いずれの点でも、従来のコンピューター・インターフェースのほうがモバイル機器のインターフェースよりも勝っています。タッチ式入力インターフェースは触覚反応に劣っていて、正確ではありません。小型の物理キーボードや仮想キーボードが採用されているかどうかに関わらず、モバイル機器での入力の速度と精度は、フルサイズのコンピューター・キーボードに比べると劣っています。機器が仮想キーボードを採用している場合には、入力操作が表示の妨げになります。仮想キーボードがポップアップ表示され、画面の大半を見えなくしてしまうからです。

推奨事項:

• 可能な場合には、ユーザーにテキストの入力を求めるのではなく、選択肢から選択できるようにしてください。
• タッチ操作での対話インターフェースには、ユーザーに適切なサイズのターゲットを表示します (例えば、10 mm 平方にするなど)。
• 選択肢の数が多く、キーボードで入力するしかない場合には、自動補完機能、または入力に従って選択リストをフィルタリングする機能を提供して、入力の必要を最小限に抑えます。
• HTML5 のリッチな入力タイプ別機能を使用して入力する内容 (テキスト、数値、電話番号、日付、時刻、URL など) に最適な仮想キーボードを提供し、あまり頻繁には使用しない文字を使用するためにユーザーが手動でキーボード画面を切り替える必要をなくしてください。

上に戻る

ホームのそばから離れないこと

ディスプレイが小さく、人間の指が大きいということは、モバイル機器の画面上で使える場所をナビゲーション要素とコンテンツが奪い合うことを意味します。そのため、コンテンツとナビゲーションをそれぞれ別の画面に表示しなければならないことも珍しくありません。けれども階層の深いナビゲーションにはうんざりする上にユーザー・メモリーも使用することになります。

モバイル機器設計のほとんどの側面と同じく、ナビゲーションはシンプルでなければなりません。可能であれば、ナビゲーションは 2 レベルか 3 レベルに抑えてください。ナビゲーションが 2 レベルを超える場合には、アプリケーションのホーム画面に簡単に戻れる方法が用意されていなければなりません。iOS 機器の場合、その方法としては、一部の画面に仮想のホーム・ボタンと戻るボタンを提供することが考えられます。一方、Android 機器でアクセスする場合には、物理ボタンとして戻るボタンとホーム・ボタンが提供されているので、これらのボタンを表示する必要はありません。

上に戻る

ユーザーに方法を示すこと

モバイル機器インターフェースが小さな画面サイズに対処する方法の 1 つは、ジェスチャー操作をサポートすることです。例えば、スクロール・バーというコントロール機能をドラッグする代わりに、ユーザーはページ上の任意の場所を指でスワイプして、縦方向または横方向にスクロールすることができます。これにより、上/下ボタンやスクロール・バーの「つまみ」などのビジュアル・コントロール・グラフィックは必要なくなるので、スクロール・バー・コントロールを最小サイズに縮小することも、一時的にポジション・インジケーターとして表示することもできます。コントロール機能を表示してスペースを占拠することなく、同じ 1 つの画面で複数のジャスチャー操作をさまざまな操作として使用することができます (例えば、ズームにはピンチ・アウト、ピンチ・イン、画面の移動には左右のスワイプ、スクロールには上下のスワイプ、クローズにはタップを使用することができます)。

ジェスチャー操作は画面の表示面積を節約しますが、これには犠牲も伴います。ただ単にジェスチャー操作を使用できるようにするだけでは、ユーザーは使用可能なアクションを知る術がありません。これに対する改善策は、アフォーダンスと呼ばれる視覚的なヒントによって、ユーザーに画面の操作方法を示唆することです。ビジュアル・アフォーダンスは、多少の表示面積を使うものの、通常その面積は、タッチ・ターゲットとして機能するコントロールよりも大幅に小さいものです。

ビジュアル・アフォーダンスの極めて単純な例は、リスト項目でタップ操作によって画面を変更できることを示す「>」記号です。その他多くのアフォーダンスは、実際の物を描写したレンダリングをベースとしています。例えば、Apple の iBook は実際の本の象徴を使ってページのフリップ・ジェスチャーを示しています。スピナー・ウィジェットは、そのグラフィック表示によって、ビジュアル・アフォーダンスを提供します。この場合、タンブラーまたはローラー・コントロールのビジュアル・メタファーが、上下にドラッグすることによって値を変更する操作を示します。

上に戻る

グラフィックにすること

モバイル UI は通常、グラフィカルに作られています。魅力的なグラフィック・デザインを使用しているアプリケーションは、テキストばかりのアプリケーションよりも好まれます。これは単に、見た目が理由になっているのかもしれませんが、適切に設計されていて非常にグラフィカルな UI は一般に、実用的な多くのメリットももたらします。優れたグラフィック・デザインは、操作の容易さを伝え、ユーザーを引き込むものです。前のセクションで説明したように、充実したビジュアル・コントロール・アフォーダンスは、ユーザーに機器の操作方法を効果的に「伝達」することができます。統計に関する視覚化は、通常、言葉や表形式でデータを説明するよりも容易に理解できる情報を豊富に提供します。

図 6 に示すように、Dojo Toolkit のバージョン 1.7 ではモバイル Web アプリケーション用に最適化された数多くの充実したグラフィカル・ウィジェットと視覚化ウィジェットを提供しています。

上に戻る

モバイル Web UI 設計の落とし穴を避けること

モバイル Web UI を設計するときには、以下のよくある落とし穴を避けてください。

何もしないこと

モバイル Web ブラウザーは、多くの Web アプリケーションを修正しないでそのまま表示します。修正されていない Web アプリケーションをスマートフォンで使おうとしたことがあれば、これがじれったく、非常に苛立たしいことであるとわかるはずです。複雑な Web アプリケーションは、小さなディスプレイ、不正確なタッチ操作、そして狭いネットワーク帯域幅には適していません。

パフォーマンスを無視すること

お粗末なパフォーマンスは、絶対とは言えないまでも、ユーザーには我慢できないものです。それは、代わりの手段が使えないとしたら尚更のことです。

ネイティブ・モバイル・アプリケーションをシンプルにしておくための一般的なアドバイスは、モバイル Web アプリケーションには特に当てはまります。大きな画像やページ・ロード、そしてその他のサーバーからの取得操作はパフォーマンスに影響を及ぼし、ユーザーが応答の遅れに気付くようになります。

ヘルプに頼ること

前述のとおり、モバイル・アプリケーションは、何かの合間に、目的がはっきりとした簡単な操作で使用される傾向があります。ユーザーは、モバイル・アプリケーションに対してこのような関わり方をするため、機器の操作方法を学ばなければならないとしたら、その必要性を受け入れ難いはずです。

アプリケーションは、ヘルプが必要にならないほど直観的に使用できるようでなければなりません。すべての UI に当てはまることですが、ユーザーにとってヘルプ・コンテンツの操作は、その目標達成に邪魔な追加のタスクとして受け取られるものです。モバイル Web アプリケーションがヘルプ UI も、ヘルプ・コンテンツも必要ないほど直観的であれば、機器にダウンロードするコードやコンテンツは少なくなります。

創造性を誤用すること

革新的な対話手法、独特なアイコン、そしてビジュアル処理をモバイル・アプリケーション設計に取り込む際には注意してください。ユーザーは、自分が使用している他のアプリケーションと同じような外観と振る舞いを持つアプリケーションであれば、その使い方を理解します。必要以上に創造性に富んだ操作やスタイルは、ユーザーが何らかの支援を必要とする可能性を高くします。

ブラウザーのインターフェースを無視すること

本質的に、モバイル Web アプリケーションはモバイル Web ブラウザーで動作します。デスクトップ Web の場合と同じく、ブラウザーは Web アプリケーションをラップする追加のユーザー・インターフェース層となります。そして、これもまたデスクトップ Web の場合と同じく、ユーザーがアプリケーション内部でナビゲーション・コントロールにアクセスすると、ブラウザー内での場合と同様にナビゲーションの問題が発生します。可能であれば、アプリケーションをキオスク・モードで実行して、必要なすべてのナビゲーションをアプリケーション内で行えるようにしてください。

上に戻る

まとめ

複数の機器のプラットフォームにネイティブなアプリケーションを開発する際に伴う多くの問題は、モバイル Web 技術を開発で使用してデプロイすることによって避けることができます。けれども、モバイル・アプリケーションとモバイル Web アプリケーションを使いやすいものにするためには、この両方のアプリケーションに特有の設計上の問題に対処しなければなりません。

モバイル Web アプリケーションの設計時に特に注意しなければならないのは、小型の機器のフォーム・ファクター、そしてタブレットを考慮に入れた広範にわたる機器のサイズです。モバイル機器プラットフォームのベンダーおよび通信業者によって UI は異なることから、設計では、各プラットフォームに固有の特性に適応しなければなりません。標準化されたコントロール、Dojo 1.7 Toolkit で提供されているネイティブ機器のテーマが、モバイル Web アプリケーションの設計および開発の両方を楽にしてくれるはずです。

参考文献

学ぶために

• FourSquare の主任デザイナー、Mary Sheibely 氏が、モバイル UI パターンのコレクションを提供しています。
  
  
• Android UI 設計のパターンについて詳細を学んでください。
  
  
• Pttrns もモバイル UI パターンの情報源となります。
  
  
• 「5 tips for converting iOS UI to Android」を読んで、iOS と Android のスタイルの違いについて学んでください。
  
  
• Apple Inc. の iOS ヒューマン・インターフェース・ガイドラインの詳細を学んでください。
  
  
• 「Blackberry Smartphones UI Guidelines」は、BlackBerry Java Development Environment 6.0 でサポートされる BlackBerry 機器を対象としたアプリケーションの設計決定に役立ちます。
  
  
• 「Android Design Guidelines - Version 1」(Adam Beckley 著、Mutual Mobile、2011年2月) を読んでください (Android では、正式なヒューマン・インターフェース・ガイドラインをまだ提供していません)。
  
  
• W3C の Media Queries 仕様を読んでください。
  
  
• 「Mobile Usability」では、ユーザー・テストにおいて、特にモバイル用に設計されていない「完全な」サイトにアクセスした場合、モバイル機器での Web サイトのスコアが非常に低い理由を探っています。
  
  
• 「iPhone Apps need low starting hurdles」を読んでください。
  
  
• Dojo Mobile 機能のすべてを学んでください。
  
  
• Dojo Toolkit のモバイル・ウィジェット、FixedSplitter と FixedSplitterPane を使用してください。
  
  
• WebSphere Application Server Feature Pack for Web 2.0 and Mobile V. 1.1 には、Dojo 1.7 をはじめ、リッチ・インターネット・アプリケーションとモバイル・アプリケーションを開発するための豊富な機能が含まれています。
  
  
• ブログ「Touch Target Sizes」では、最低限推奨されるタッチ・ターゲット・サイズを要約しています。
  
  
• 「Responsive Web Design: What It Is and How To Use It」では、設計および開発で、ユーザーの振る舞いや、機器の画面サイズ、プラットフォーム、向きに基づく環境に対応しなければならない理由を説明しています。
  
  
• 「Responsive Web Design」では、先進的な設計手法について説明しています。
  
  
• developerWorks Web Development ゾーンでは、多種多様な Web ベースのソリューションを取り上げた記事を専門に揃えています。
  
  

製品や技術を入手するために

• WebSphere Application Server Feature Pack for Web 2.0 and Mobile V1.1.0 をダウンロードしてください。
  
  
• Dojo を入手してください。
  
  
• IBM のソフトウェアを無料で試してみてください。試用版をダウンロードすることも、オンライン評価版にログインすることも、Sandbox 環境で製品を操作することも、クラウドを介して IBM 製品にアクセスすることもできます。100 を超える IBM 製品の評価版のなかから選ぶことができます。
  
  

議論するために

• 今すぐ developerWorks で自分のプロフィールを作って、モバイル Web の UI 設計に関するウォッチ・リストをセットアップしてください。developerWorks コミュニティーとずっとつながっていられます。
  
  
• Web 開発に興味を持つ他の developerWorks メンバーを見つけてください。
  
  
• Web のトピックを専門とする developerWorks グループに参加して、知識を共有してください。
  
  
• Roland Barcia 氏が彼のブログで Web 2.0 とミドルウェアについて語っています。
  
  
• developerWorks のメンバーが共有する Web 関連のブックマークをフォローしてください。
  
  

著者について

Jim Lentz は、WebSphere Application Server のユーザー・エクスペリエンス・アーキテクトです。彼はアリゾナ大学で実験心理学の博士号を取得しました。テキサス州オースチンに住む彼は、Web 2.0 およびモバイル技術のユーザビリティーに取り組んでいます。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ディスプレイ・サイズ
• 入力
• オペレーティング・システムの多様性
• パフォーマンス
• 複数の機器の使用
• Best practices
• ツールキットの使用
• 機器のサイズに合わせたレスポンシブな設計
• Recycle designs
• ユーザーに選ばせること
• ホームのそばから離れないこと
• ユーザーに方法を示すこと
• グラフィックにすること
• Avoid pitfalls
• まとめ
• 参考文献
• 著者について
• コメント