Infoperience Home Site map Contact us

Column
2000.08.27

ナビゲーションの落とし穴

前回の「ウェブに関する基本的なメンタルモデル」でも書いたとおり、ウェブブラウザの「戻る」「進む」のボタンは、ウェブの閲覧という行動に地理的な移動概念を強く持ち込んでしまった。そのためユーザは、膨大な情報の中をページからページへ渡り歩いているような感覚でウェブサイトを利用している。ウェブサイトを作る側も、ユーザが最初に目にする画面を「ホーム」あるいは「トップページ」などと呼んで、そこから如何にしてユーザの求める情報まで導くのかということを第一義にインターフェイスをデザインすることになる。ユーザをうまく導くためには、そのウェブサイト全体の情報構造を目に見えるような形であらわしたり、その構造の中で今ユーザがどの部分を見ているのか(どこにいるのか)が分かるようなサインをどこかに埋め込んだりしなければならない。

ウェブページ上でこういった役割を持つインターフェイス要素を一般的に「ナビゲーション」と呼ぶ。ウェブのデザインをはじめたころはよく、「ブラウザのボタンを使わなくてもサイト内を自由に移動できるようにナビゲーション機能を随所に挿入するべきだ」といったことを聞かされた。だが本当にそうだろうか?様々なサイトを渡り歩くユーザにとっては、そのサイト独自の方法でデザインされたナビゲーションをいちいち学習するのは大変である。またサイト内での視覚的なフィードバックが統一されていないなど「マズいデザイン」が多いため、ユーザにとってはブラウザの「戻る」「進む」のボタンの方がよっぽど信頼のおける機能なのである。

GUI の基本として、操作の対象および利用可能な機能をすべて目に見えるような形にしておくことが重要とされている。つまり、基盤となる固定された世界(Mac OS でいえばデスクトップ)と、ユーザのアクションによって変化する部分とのコントラストによって、今おきている現象を直観的に把握できるようにし、またそれらフィードバックの起こり方に一貫性を持たせることによって、他の機能の働きをユーザが推測できるようにしている。

しかしウェブのように、一人の人間が把握できる量を遙かに超えた情報を扱わなければならないメディアにおいては、この手法は多くの問題を孕んでいる。ユーザの選択可能な機能(ノード)をすべて目に見えるように表現することは不可能である。逆に、今ユーザに何を見せるのかということや、ユーザが今必要とする機能は何かということを分析し、提供していく目的指向のインターフェイスが注目されている。しかしこれにもまた問題があり、それはあらゆるエージェントプログラムが抱える問題と同様である。必要なのは、サイトの構造をできるだけシンプルにして、ユーザが理解したり推測したりしなければならない特有の約束事を極力減らすことである。そのためにある情報にたどり着くまでのクリック数が1回増えたとしても、ユーザがそのサイトを利用している時間の中で経験するストレスが少なければ、最終的な満足度を上げることができるのである。構造自体が複雑で、ユーザに求める行動がそれに伴って難しいものであれば、初心者はもちろん、うまく使いこなすことができる上級者にとっても、エラーを起こさないように努力ためストレスが多く、長期的には有益ではない。

ナビゲーションエリアでノードをあらわす

ナビゲーションエリアのデザイン(機能も含む)によってサイト内の情報構造をあらわすということはよくあることである。一般的なものは、サイトを構成する最も大きな情報カテゴリーの分類名をラベルにして全ページに共通するエリアに水平方向(ヘッダエリア)か垂直(ページ左端)に並べるというもので、それらのラベルをクリックすると、ツリー型の階層構造に配置された各カテゴリー(サブサイトと呼ばれることもある)のインデックスページにジャンプするというものである。

情報の分類の仕方は様々であり、本来はユーザのニーズを的確に把握して、更にユーザビリティを十分に検査した上でのラベリングと階層構造を設計するべきである。これは各情報の重要度やユーザのコンテクストをよく理解していなければできないことであり、はじめてそのサイトを見るユーザにも、繰り返し利用するユーザにも、ウェブの利用に慣れていない初心者にも、あるいは上級者にも、すべてのユーザがそのサイトの全体像や情報構造のコンセプトを理解できるように、なるべく客観的で論理的な分類と、それを的確に表現したナビゲーションエリアの平面構成(レイアウト)、そしてユーザがそのナビゲーションを利用した時の一貫した(コンセプトに違反しないような)フィードバックが求められることになる。

ナビゲーションエリアがサイト全体の構造を縮小して表現するのと同時に、そこではユーザが選択可能なノードを GUI 的に表現していることになる。企業のウェブサイトではよく、「ニュース」「製品情報」「サポート」「ソリューション」「会社概要」といった項目がナビゲーションエリアに並んでいるが、それらはサイトを構成する大きな情報分類をあらわすと同時に、その中の希望の項目をクリックすることによって、例えば「ニュース」セクションのインデックスページにジャンプできることをあらわしている。つまり、そのノードが目に見えるということは、それが選択可能であるという意味である。

サブサイトの構造を企業内の部署体制と混同したり、ナビゲーションエリアのレイアウトを「最も人気のあるページ順」などにすると、サイト全体の情報構造は表現されない。このようなナビゲーションの切り口は、そのサイトを理解しているユーザや特定の用途に制限されたユーザには有益であるが、サイトナビゲーションの主要な機能として実装するには、目的指向の、より高度な機能設計が必要となってしまう。どちらかといえばこれはナビゲーションではなく、いわゆる「リンク集」的な機能として用いた方が自然なので、ナビゲーションエリアとは別に扱う方がよい。

また、ページの一番下に「戻る」といったラベルでそのカテゴリーのインデックスページにリンクしているような場合がよくあるが、ユーザは制作側の意図した順序でページを閲覧しているとは限らず、どこか別のサイトからたまたまそのページにダイレクトにジャンプしてきているような場合もあるので、「戻る」といったコンテクスト依存型の表現をするべきではない。この場合は、リンク先の具体的なページタイトルを使って「製品情報インデックス」などとするラベルの方がよいが、ユーザは自分が一つ前に見ていたページのタイトルを正確に覚えているとも思えないので、「製品情報インデックスに戻る」とするのが理想である。これならば、別のルートからそのページにたどり着いたユーザも、そのページが「製品情報」のカテゴリーに分類されている情報であり、普通はそのインデックスページからリンクされてくるのが意図された順序なのだということが理解できる。

ナビゲーションエリアでモードをあらわす

GUI の視覚効果を使って、ナビゲーションエリアで現在見ているサイトの状況(モード)を表現することがある。例えば、現在見ているセクションに対応するナビゲーションエリアのボタンなどをハイライトするといった方法である。ここで注意しなければならないのは、「ハイライトされている」ということが「現在見ているセクション」をあらわしているのだということをどうやってユーザに理解させるのかということである。

Macintosh のインターフェイスガイドラインでは、現在選択できないメニュー項目は、メニューから消してしまうのではなく「グレイアウト」して、それが今選択できない状態なのだということを相対的に表現するように指示している。これはすべてのノードを視覚化し、更に現在のモードにおける機能の制限をうまく表現する方法である。ユーザのアクションによって変化する状態を相対的なコントラストに落とし込むことによって、コンピュータとのインタラクションに現実感を与えるのである。こういった仮想世界の物理法則を期待してウェブサイトのインターフェイスに接すると、おかしなことに気づく。

よくあるのは、ボタンのようにベベルのかかった画像がクリックできることをあらわしているのにもかかわらず、クリックしてもそのボタンは「へこまない」。へこまないのであれば、Macintosh や Windows のインターフェイス要素である「へこむボタン」を外見だけ真似するのは安易すぎる選択だ。

また、マウスオーバーによって画像が光ったり色がかわったりして、その部分がクリック可能であることをあらわすのも問題である。それはユーザがポインタをその場所まで持っていかなければリンク可能であるかどうかを判断できないという意味であり、本来は、なんらかの視覚効果によって一目でその部分がクリック可能かどうかが分からなければならないはずだ。

さらに、一目でボタンのように見えているのにもかかわらずマウスオーバーによる画像の変化がおきると、ユーザのメンタルモデルでは、「ボタンのように見えて、さらにマウスオーバーで画像が変化するものがクリックできるエリアである」という法則が形成されるので、その他のすべてのリンク箇所(テキストによるリンク部分も含む)にも同じ動きを持たせなければならなくなってしまう。

こういったフィードバックの一貫性を保っているウェブインターフェイスは希である。このような一貫性の欠如は、WWW というものに対する信頼感を随分と下げている。だがこれらを統一するガイドラインを制定したり、あるいはそのガイドラインを守るよう制作者に強要することは不可能である。

機能を表現する vs 状態を表現する

マウスオーバーでボタンがハイライトするというフィードバックはいたるところで見かける。また、(ユーザにとって、あるいは制作側にとって)重要な情報へのリンクを大きなボタンであらわしたり、相対的に目立つように配置するグラフィックデザイン的な手法も、あらゆる場所で見ることができる。更に前述のとおり、現在見ているセクションをあらわすナビゲーション上のボタンをハイライトして目立たせるというやり方も多く利用されている。これらは似たような効果を狙ってはいるのだが、明らかに混乱の原因である。こういったフィードバックは、以下のようにきちんと整理して、混在しないように注意しなければならない。

ナビゲーションは誰のもの?

ナビゲーションエリアは、ユーザにサイトの基本的な機能を提供するインターフェイスである。しかしそのエリアのデザインを間違えれば、ユーザの操作を不本意に制限してしまうという全く逆の役割を果たしてしまう。

極論から言えば、そもそもコンテンツとナビゲーションを一枚の HTML の中に記述するということ自体が間違っているようにも思えるのである。素のドキュメントとしての価値が下がり、せっかく論理的にマークアップされた文書が、加工・再利用されにくくなってしまう。

また、本来ユーザはサイトの情報構造などというものに興味はない。ユーザは必要な情報を早く見つけたいだけなのであって、すばらしく計算されたサイトの設計などはどうでもよい。ただ便宜上、サイトの構造を理解していれば自分の判断で必要な情報にたどり着けるので、仕方なく全体を把握しようとするだけである。

それと同時に、制作側がどのような順番で情報を見せたいかということもユーザには関係がない。とにかくシンプルな構造にしてさえくれれば、ユーザは好きなようにそれを利用できるのだ。そのためには、ドキュメントは様々なコンテクストや利用方法に耐えられるように、ナビゲーションと内容物を分離するべきである。そして、サイトによって異なる方法で情報構造を示すのではなく、そういった機能は「ブラウザが提供すべき」なのではないだろうか。

ブラウザは、「戻る」「進む」というだけの貧弱なナビゲーションではなく、もっと効率的で一貫性のある方法でユーザにサイトの情報アーキテクチャと現在の状況を視覚化して提供するべきである。例えば、ブラウザはサイト制作者が提供する情報構造マップ(ファイル構造マップではない)を元にリアルタイムにサイトマップを生成したり、ウェブサーバと連係してユーザのリンク履歴からコンテクストを推測し、それをサイトマップとシンクロさせて各ユーザにカスタマイズされた形でナビゲーションエージェントになることができるだろう。また、他のユーザの行動をトラックして客観的に分析したサイトの利用法をサイトマップに連動させて新しいピリオディカルな情報コミュニティを形成できれば楽しいだろう。

そのためには制作側が現在の CSS ファイルのような外部ファイルの形で、サイトの情報構造を記述したファイルを用意する必要がある。そのサイト構造記述ファイルの作り方と、ブラウザ側のマップ生成のインターフェイスデザインが、サイトのユーザビリティを決定する主要な要素になれば、ブラウザベンダーの競争も正常なものになるし、ドキュメントもクリーンで余計な情報を含まなくなるので、多くのプラットフォームでの閲覧とその他の高度な再利用が可能になるはずである。


Column
2000.08.27
Copyright (C) 2000 Infoperience Laboratory. All rights reserved.
Infoperience Home Site map Contact us