「PC 向けサイト」であってもタッチ操作が当たり前に
今や取り立てて言うほどのことではありませんが、Apple の iPad の登場を機に「タブレット」と呼ばれるタッチインターフェース型デバイスの普及が進んでいます。2014年にはタブレットの出荷台数が従来型の PC に並ぶ、という予想もあります。(参照 : 「調査リポート：世界でのタブレット出荷、2014年にPCと横並びに ─ Canalys予測 (ITmedia Mobile)」)
また、Microsoft Surface のように、PC とタブレットの「あいのこ」とでも言えそうなデバイスが出てきたり、従来型の PC にタッチインターフェースを備えたモデルも各社から出始めています。
こうして考えると、PC で閲覧されることを想定した Web サイトであっても、マウスの代わりに (あるいはマウスに加えて) タッチ操作で使用される...というのは、今後当たり前になってくると予想されます。そうなった場合、いわゆる「PC 向けサイト」には、どのようなことが求められるのでしょうか。
ここで言う「PC 向けサイト」とは、「レスポンシブ Web デザイン」で作られたもの、PC 専用に作られたもの、の両方を含みます。クリッカブルな箇所は (指でタップもできるように) 十分な大きさにする。
「PC 向けサイト」もタッチ操作で使用される...となると、何はともあれ、クリッカブルな箇所 (リンク、フォーム要素、各種ボタン、など) は、指でタップもできるように十分な大きさにすることが求められます。英語圏では「 "fat finger" problem」と呼ばれていますが、指先は「太っちょ」で、マウスポインターほど精緻なポインティングができず、誤操作につながりやすいからです。
タップ可能なターゲットの大きさについては、様々なガイドラインがあります。「iOS ヒューマンインターフェースガイドライン (PDF)」が定める「44×44ポイント」が有名ですが、Luke Wroblewski 氏の2010年の記事「Touch Target Sizes (LukeW)」を読んでみると、総じて (物理的な実寸で) 8ミリメートルから10ミリメートルくらいが目安、と言えそうです。必ずしもタップ対象物 (目に見えるボタンなど) がその大きさでなくても、 対象物＋余白によってタップ可能な領域が構成されていて、その領域が十分な大きさを持っていればよいでしょう。また、別のタップ対象物と隣接しすぎていないことも大切です。
このようにして、クリッカブルな箇所を指でタップもできるようにしておくことで、マウスを使用するユーザーにとっても、より使いやすいものになります。高齢や手指の怪我などで精緻にマウス操作ができない人はもちろんのこと、「フィッツの法則」の観点で見ても (クリック可能なターゲットが大きくなり、マウスポインターの移動距離も短くなるので) 多くの人にとってユーザビリティが向上すると言えます。
また、副次的な効果として、テキストリンクを含むコンテンツの場合、その文字サイズ (行送り) も併せて大きくなることが期待できます。高齢者に限らず多くの人にとって、テキストの読みやすさが格段に向上すると言えるでしょう。
「ホバー (hover)」を前提にした UI は採用しない。
マウスを使用して Web サイトを閲覧する場合、マウスオーバーによってコンテンツを表示させることができますが、タッチインターフェースの場合、このような「ホバー (hover)」操作は基本的に不可能です。このため、クリック/タップしないとオブジェクト (対象物) を実行できない、という前提でのユーザーインターフェース (UI) 設計が必要になります。
「ホバー (hover)」を前提にできないということは、重要な情報は隠さずユーザーにあらかじめ提示することにつながります。これによって、認知/理解がしやすいデザインになることが期待できます。
また、「ホバー (hover)」を使わない UI は、(障害や怪我などでマウスが使えず) キーボード操作をするユーザーのアクセシビリティという点でも、メリットがあります。マウスオーバー (hover) によって表示されるコンテンツは、キーボード操作では表示させる術がありませんが、クリック/タップしないとオブジェクトを実行できない、という UI であれば、そのオブジェクトに [Tab] キーでフォーカスを当てて [Enter] キーで実行すればよいので、より多くのユーザーに、コンテンツを提供することが可能になります。
画像拡大はピンチ＆ズームできるようにする。
Web サイトの閲覧中、商品の詳細 (質感や機能) を確認したい場合などに、画像を拡大して見たい、というユースケースがあると思います。マウス操作を前提としたサイトであれば、ページ上にレイヤーがポップアップする、いわゆる「Lightbox」を使って画像を開く (そのうえで、マウスで拡大ボタンをクリックするとズームができる)、というのが一般的だと思います。
タッチインターフェースの場合、拡大ボタンをタップするよりは、手指によるジェスチャ (ピンチ＆ズーム) で画像を広げるようにして拡大する、という操作のほうが自然かもしれません。しかし、世に出回っている「Lightbox」のライブラリーではそういった操作に対応しておらず、ピンチ＆ズームをしようとすると (レイヤーの背景側にあるページ全体もひっくるめて、一応その画像を拡大することができるとしても) 画像がジャギーになってしまい、肝心な情報を得ることができない、という結果になります。
中途半端なライブラリーを使うくらいなら、オリジナルの画像ファイル (高解像度のもの) を直接ブラウザウィンドウ上に開き、ユーザーが任意でピンチ＆ズームする、という単純な仕掛けのほうがかえってよいかもしれません。(または、タッチジェスチャに対応した「Lightbox」系ライブラリーの普及に期待したいところです。)
ページ内スクロールエリアで「はまらない」ようにする。
ページ内のどこを触れても、そこからスクロールできる (わざわざ画面の端にあるスクロールバーまでマウスポインターを移動させなくてもよい)、というのがタッチインターフェースの利点ですが、その際、思わぬ「罠」となるのが、インラインフレームなどで実装されるページ内スクロールエリアです。
ユーザーの指が偶然 (無意識的に)、ページ内スクロールエリアの上に置かれて、そこからスワイプ操作でスクロールする場面を想像してみましょう。ユーザーはページ全体がスクロールされることを期待していましたが、実際には、指が置かれていたページ内スクロールエリアの中身だけがスクロールする、という現象が生じます。自動車が雪や泥沼にはまってスタックしてしまうような感じで、ユーザーに余計なフラストレーションを与えます。
最近では、「ページ内スクロールエリアの是非」で例示したようなページ内スクロールエリアは減ってきている印象ですが、Google マップなど、<iframe> 要素を用いた埋め込みコードを提供しているサービスは多いので、注意が必要です。
ページレイアウトをタッチインターフェース機器向けに変更する必要はあるか？
タッチインターフェースの普及に伴って、スマートフォンやタブレット、タッチインターフェース搭載 PC が、どのように手で持たれているのか、画面上のどのエリアがタップされやすいのか、といった研究があります (参照 : 「Responsive Navigation: Optimizing for Touch Across Devices (LukeW)」)。また、英語圏では「gorilla arm」と呼ばれていますが、タッチインターフェース搭載 PC の場合、画面をタッチ操作している最中、腕を休ませる定位置が無く、ゴリラの腕のようにブラブラしてしまう (その結果、腕が疲れてしまう)、という懸念も一部で考察されています。
こうした研究や考察から、ページレイアウト (ナビゲーションメニューの位置など) を、タッチインターフェース機器向けに変更する必要があるのではないか？という議論がありますが、個人的には、(利用デバイスを特定できるアプリケーションならともかく) 一般的な Web サイトの場合、汎用的に、多種多様なデバイスで利用されることを考慮する必要もあるのでは、と考えています。そう考えると、ドラスティックに従来のマナーを変えて一部のデバイスへの最適化を試みるよりは、「重要な情報はページ上部に配置する」「ユーザーの目線移動 (Z字、F字) を意識する」といった従来のセオリーを踏襲しておくのがよいのかな、という気がしています (そもそも、メインのコンテンツに比べてナビゲーションメニューのほうが重要なのか？という気もしますし)。
このあたりは、ユーザーの Web 閲覧環境が今後さらにどう変化してゆくかを見定めつつ、引き続き考えてゆきたいと思います。
タッチインターフェース機器による「PC 向けサイト」の利用は、まだまだ歴史が浅く、上記以外にも留意すべき点はあるかもしれません。ぜひ一度、皆さんご自身が制作/運営されている「PC 向けサイト」に対して、タブレットを用いたユーザビリティテストを実施してみることを、おすすめしたいと思います (サイトのターゲットユーザーでなくても、ご家族やお友達など身近な方に少し触っていただく、という簡易的なものでも構いません)。サイトやページによって、独自のコンテキストによって生じる問題があったりなど、思わぬ気づきが得られるかもしれません。