モバイルサイトのヘルプページが使いづらい理由を考える

mixiでミクコレ(背景のデザイン)を選んでいたのですが、やっぱり初期設定のデザインに戻したくなりました。

が、戻し方がさっぱりわかりません。初期設定に戻すためのリンクがなかなか見つからないのです。

そこでヘルプページに飛んだのですが、ここでさらに困りました。ヘルプのトップページから、該当するヘルプ項目がどこにあるのかすぐに見つからないのです。

そもそもなんでミクコレページで「ヘルプ」をクリックしたのに、遷移先がmixi全体のヘルプのトップページなのかもわかりません。

ということでちょっと腹が立った勢いで、モバイルサイトのヘルプページについて考えてみました。


モバイルサイトのヘルプページはどこも使いづらい


超個人的な印象ですが、mixiに限らずヤフーもGREEも、モバイル用のヘルプはPC用のそれと比べ、どこもハードの特性以上に使いづらい印象を受けます。

その理由から考えてみます。


モバイルのヘルプページが使いづらい理由を考える


PCの場合、ユーザーがサイト上のどのページにいても、サイト内の位置を把握できるのサイトが優れたナビゲーションのサイトだ、と言われています。
図1・PCサイトの一般的なサイト構造

が、モバイルサイトの場合、サイト全体の階層を意識して利用しているユーザーはあまりいないような気がします。
ユーザーは階層を意識することなく、その場その場の判断でリンクをクリックしている印象です。
図2・モバイルサイトではユーザーはあまり階層構造を意識しない

そうなると困るのがヘルプページです。

多くのモバイルサイトでは、ヘルプページは「ヘルプページのトップ」にまず遷移し、そこからユーザーに対して「該当のヘルプページを自分で探して遷移してね」という作りになっています。

が、モバイルサイトでは前述のようにユーザーはサイトの階層を意識していません。

そのため、ヘルプが階層通りに並んでいても、目的のヘルプにたどり着くのは大変なのではないでしょうか。
図3・PCとモバイルでヘルプへの遷移を比較する

また、ヘルプのトップに遷移するというのは別の問題もあります。

目的のヘルプにたどり着くために、ヘルプページの階層をたどるという行為は、途中で見る必要もないページをブラウザ上で表示している、ということです。イコール、「いま作業したい本来のページ」からどんどん離れている、とも言えます
サイト構造が把握しづらいモバイルサイトでは、ユーザーは本来いたいと思っている場所から離れれば離れるほど不安になるものです。(どこまでブラウザの「戻る」機能が有効がわかりませんし)

ヘルプページは「読み終えたら元のページに戻りたい」というのが前提だと思います。
「戻る」機能が命綱(?)のケータイでは、なるべく間に余計なページ遷移を挟むべきではないと思います。


モバイルのヘルプページを使いやすくする案を考える


モバイルサイトのヘルプページを使いやすくする案を書いてみます。

しつこいようですが、「個人的にそう思っている」というだけで、正解なのかどうかはわかりません。


1.そもそもモバイルで「ヘルプを見ないと使えない機能」は、UIを改善するか、その機能自体を削るかを検討する


たぶんこれが絶対の正解だと思います。

しかしこれで終わってしまうのも寂しいので、もうちょっと考えてみましょう。


2.ヘルプに飛んだら「そのページに関するヘルプ」をまず表示させる


だれでも思いつく案ですが、そのページに関するヘルプをダイレクトで表示させてあげればいいのだと思います。

ミクコレのページでヘルプをクリックした人のほとんどは、ミクコレのヘルプを読みたいのだと予想できます。だったらそのヘルプをすぐに見せてあげましょう。

実現方法はいろいろ考えられますが、簡単な仕組みとしてはヘルプリンクを
http://ヘルプページのURL?keyword=今見てるページのtitle

のようなタグにしておき、クエリーを受け取るヘルプ側でどうにかしてあげる、などがあります。

3.ヘルプに検索機能をつける


仕組み的に2のようなことができないのであれば、せめてヘルプに検索機能をつけて欲しいです。

モバイル用サイトのUIを考えるとき、「なるべくユーザーに文字入力をさせてはいけない」という不文律があるような気がします。

しかし最近では、ケータイをメインで利用しているユーザーは、最短距離で目的が達成できるのであれば4文字くらいの検索キーワード入力に抵抗を感じていないのではないかと考えられます。(これを裏付けるリサーチ資料があったのですが見失ってしまった…)

ですので文字入力をあまり怖がらず、確実に調べたいヘルプがヒットするのであればヘルプに検索機能をつけてもいいのではないでしょうか。

「確実に調べたいヘルプがヒット」を実現するためにはたとえば、サイト中で使う単語はケータイの予測変換機能ですぐ出てくるものを選ぶようにしたり、ページとヘルプで使われている文言のズレをなくしたり、などが考えられると思います。

個人的に、今後モバイルサイトの文言を考える際は、ケータイの予測変換機能の存在を無視して考えてはいけないのではと思います。(モバイルサイトのSEOとかでは当然のように考慮されてるのでしょうね)


まとめ、「でもなんで」


上記2も3も、ヤフーやmixiのPC版では実現できていることです。ですのでモバイル版でやらない理由は、技術的な問題ではない、と考えられます。

おそらくUI的に、今のほうがいいと判断されているのだと思います。
その判断理由をご存じの方がいらっしゃいましたら、教えていただけるとうれしいです。
Web > UI / design | comments (0) | trackbacks (0)

『NAVITIME』に見るケータイサイトのページ分割基準

ルート検索サイトって便利ですね。
わたしは出かけるとき出発がギリギリの時間になってしまうことが多いので、しょっちゅう最短ルート検索機能を利用しています。
(余裕のある時間に出かければいいじゃないかという正当な意見は却下)


NAVITIME』ではPCとケータイが連動しており、あらかじめ出発地や目的地、ルートをPCで設定してけば、あとから簡単にケータイで呼び出せるようになっています。
画面1・『NAVITIME』のPC版で検索地点やルートを登録する


なっているはずなのですが、実際にケータイから使ってみると、
画面2・登録した地点やルートを呼び出すにはリンクをたどらなければならない
登録済みの地点やルートは、リンクをたどらないと呼び出せないようになっています。
これではあらかじめ地点やルートを登録したメリットがない…。


「ページ遷移が1回増えたぐらいで」と思われるかもしれませんが、わたしは自宅最寄り駅が地下にあるので、電車移動中のアクセスはタイミングが限られるのです。
そのため、ページ遷移が1回増えただけでも、使い勝手にかなり影響してくるのです。

実際NAVITIMEの場合、電車に乗ってからサイトにアクセスすると、登録済みルートにたどり着くまでに3駅ぐらい過ぎてしまいます。
「すぐに検索できること」がルート検索サイトの重要な要素であるはずなのに。


ケータイは容量や通信速度、画面の広さに制限があります。そのため、1ページあたりのコンテンツ量を(PCと比べて)絞る必要があります。

しかし一方で、それらの制限があるがゆえに、利用したい機能にたどり着くまでの距離が長くなるだけで、機能を利用する意味がなくなってしまうこともありえます。


ですから1ページにどの要素を含めるか、どこでページ分割するかは単純にページ容量だけで判断せず、その機能がどのようなシチュエーションで呼び出されるかを考慮の上で決めるべきだと思います。

そしてそうなるとUIを考える上でますます、リサーチやペルソナ、シナリオが重要になってくるような気がします。

Web > UI / design | comments (2) | trackbacks (0)

他力本願でモバイル版『へたれwebディレクターの覚え書き』を設置する

このブログでは『Serene Bach』というブログシステムを利用しています。

Serene Bachは標準でモバイル版の表示に対応しているのですが、やたらページを分割してしまったり、専用のテンプレートがイマイチだったりと、デフォルトテンプレートのデザインに不満がありました。
時間ができたら自分でモバイル用のテンプレートを作ろうと思っていたのですが、仕事が忙しくじっくりカスタマイズする時間がなかなかとれず。

そんなわけで今回は、他力本願でモバイル版『へたれwebディレクターの覚え書き』を簡単に設置する方法、です。
以下の作業で10分でモバイル用ページを作ります。

  1. 『Google Mobile Gateway』を利用してモバイル用ページを作る
    mod_rewriteを利用して、モバイルからPC用ページにアクセスされたらモバイル用ページにリダイレクトさせる
  2. Mobile Link Discoveryを設定して、検索エンジンにモバイル用ページURLを明示する



1・Google Mobile Gatewayを利用する


Googleが用意している、PC用ページをモバイル用に変換するエンジンである『Google Mobile Gateway』を利用すると、あっさりとモバイル用ページを生成してくれます。

そのページをmod_rewriteを利用して、PC用アドレスにケータイからアクセスがあったらケータイ用アドレスにリダイレクトしてあげれば、あっという間にモバイル用ブログの完成。

やり方は、『Yoichi Kawasaki's Weblog』さんの「Google Mobile Gatewayで3分モバイル対応」を参考に(というか完全にパクって)、.htaccessに以下を記述しただけです。簡単です。

RewriteCond %{HTTP_HOST} ^studio-no9.com/sb
RewriteCond %{HTTP_USER_AGENT} ^DoCoMo [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^KDDI [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^UP.Browser [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^J-PHONE [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^vodafone [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^MOT-.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SoftBank [NC]
RewriteRule ^(.*)$ http://www.google.co.jp/gwt/n?u=http%3A%2F%2Fstudio-no9.com%2Fsb [NE,L]

mod_rewriteはhttp.confに設定した方がサーバーに負荷がかからないと聞いたことがあるのですが、初心者な僕にhttp.confの設定難しいので、.htaccessに設定することでいいことにしてしまいます。


mod_rewriteは使いでのある魔法のようなモジュールですが、レンタルサーバーでは標準設定のままでは使えないことが多いです。その場合は1行目に
RewriteEngine On

と記述すると動く場合があります。それでも動かない場合はレンタルサーバー会社がmod_rewriteモジュールの動作を禁止にしているのであきらめましょう。


2・Mobile Link Discoveryを設定する


ついでにMobile Link Discoveryも設定してみることにします。

Mobile Link Discovery(MLD)とは、XHTMLのメタ情報に「モバイル用ページのURLはここだよ」と明示するフォーマットです。このメタ情報を記述しておくと、Yahoo!やGoogleのロボットがPC用ページとモバイル用のそれとを間違えることなく検索インデックスに登録してくれたりします。

またGoogleモバイルの検索結果からPC用ページにアクセスするとき、普通は強制的にGoogle Mobile Gatewayを経由した画面を表示しますが、MLDを設定していれば、ちゃんとモバイル用ページにアクセスしてくれるようになります。

簡単に言うと、この仕組みが普及したら、モバイル利用者が「このアドレス、PC用?それともモバイル用? PC用だとしたらモバイル専用URLはあるの?」とか迷わなくて済むようになるのですね。素晴らしいです。

設定はこちらも簡単、こちらのページを参考に

<link rel="alternate" media="handheld" type="application/xhtml+xml" href="モバイル用のURL" />

を記述するだけです。


最後に


Google Mobile Gatewayでの表示ですが、一部のJSをソースで表示してしまったりと不満もありますが、ちゃんとモバイル用テンプレートを作るまでのつなぎとしては十分だと思います。

MLDはいいですね。
理想としてはモバイルのブラウザがこの仕様に対応してくれて、たとえばPCのアドレスにアクセスしたときにMLDのメタ情報がhtmlに記載されていたら「モバイル専用URLに移動しますか?」とか聞いてくれるようになったらさらにうれしいです。

それと逆の仕組みも一般的になって欲しい。わたしは仕事以外のwebアクセスはほとんどケータイなのですが、たまに「このページはあとでゆっくりPCから見てみよう」と思うことがあるわけです。モバイルのURLにアクセスしたときに、「PC用のURLが別にあるよ」と教えてくれる仕組みができたらうれしいです。
きっとわたしのような「普段はモバイル、たまにPC」という人はこれからどんどん増えていくと思いますし。

MLDは日本人が中心になって仕様を決めたようで、そういう意味でもぜひ普及して欲しいです。
携帯 | comments (0) | trackbacks (0)

携帯から投稿テスト

携帯から投稿テストです。

mobile photo
携帯 | comments (2) | trackbacks (0)

BANANAサーバー