Webアプリ開発事始 第24回

WebサイトとWebアプリのデザインを考える(2) 長谷川裕行
有限会社 手國堂

情報の分類

Webサイト全体の構成について考えてみましょう。まず、ユーザーに提示したい情報を項目別に分類します。様々な情報がありますが、それをどのようにカテゴリー別に分けるかが大切です。


- 分類には手作業の柔軟性を -

Webサイト内でユーザーに提示したい情報をすべて列挙し、それらを適切に分類しなければなりません。手作業では、カードに書き出してテーブルに並べ、同じ仲間と思えるカード同士をまとめていく――といった手法がよく用いられます。コンピュータを使うことも、もちろんできます。例えばWordでは、情報の概要を入力したテキストボックスを作成し、それらを画面上でドラッグしてまとめていく――という方法が考えられます。

ここで大切なことは、Accessなどのデータベースでテーブルを作り、それをクエリやマクロで処理して……などと、本格的な自動化を考えないことです。雑多な情報を分類する作業には、「あっちの仲間かと思ったら、こっちにも仲間がいた」とか「あっちにもこっちにも、どちらの分類にも入ってしまいそう」といった曖昧さが付きまといます。コンピュータでこの曖昧さを処理させるのは非常に難しいことです。また、機械には真似のできない人間の「勘」の効用も無視できません。

手作業が一番確実です。仮にコンピュータを使う場合でも、先述したWordのテキストボックスのように、分類の本質では手作業に最も近い形態を採るのがよいでしょう。




- 分類は試行錯誤の連続 -

例えば、商品の基本的な使い方を説明する情報の場合、その商品の特徴を取り上げる必要が出てきたとします。商品の特徴は、「商品紹介」の仲間に分類されています。一方、目的の情報は「よくある質問」の仲間に分類されていいます。

こういうとき手作業なら、「商品の基本的な使い方」の情報を「商品紹介」と「よくある質問」の両方の仲間に分類することも可能です。もちろんデータベースでも、1つの項目を複数のグループに所属させることは可能ですが、最初にそのような事態を想定し、柔軟に対応できるシステムを設計しなければなりません。また、手作業では複数の情報を「群」としてざっと眺めることが可能ですが、データベースを使った場合、これは非常に厄介な仕組みとなります。

情報の分類は非常に難しい作業です。全体を見渡し、試行錯誤を繰り返さなければならないので、手書き&手作業が最も確実――と、いうことになります。もちろん人工知能を利用すれば、もっと簡単に手早く分類できるのでしょうが……。

業務アプリケーションを開発している人は、この階層構造の設計がアプリケーションの処理メニューと同じ感覚で扱えることにお気付きでしょう。Webサイトの構造も業務処理の構造も、基本は変わりません。


- 階層構造と戻り先の問題 -

情報の分類では、「仲間の中の仲間」――要するに階層構造の検討も必要になります。項目数が多い場合は、まず全体をいくつかのカテゴリに分類してカードの山を作り、次に個々のカードの山ごとにさらに分類して……という形で、段階的に分類して階層構造を作ります。

但し、前回述べたように、どんなときでも階層構造が有効であるとは限りません。特にコンピュータにあまり慣れていないユーザーを対象としたサイトで、項目数がそう多くない場合には、1階層にすべての項目を並べるだけでも構いません。

ここで難しいのは、先述した「複数のカテゴリにまたがる項目」の扱いです。「商品の基本的な使い方」が、「商品紹介」と「よくある質問」の両方のページから参照できるようにした場合、「商品の基本的な使い方」のページの「戻る」リンク先をどちらにするべきかが問題となります。

「商品紹介」のページに戻るよう作ってしまえば、「よくある質問」のページからやってきた人は戸惑います。Webの仕組みを知っているユーザーなら驚くことはないでしょう。しかし、誰もがWebの仕組みを知っている訳ではありません。

こういった設計段階に入ると、手作業は大変です。ワープロなどを使って図を描き、端的に構造を把握できるようにしましょう。




- JavaScriptで対処する -

上記のような「どちらからもリンクされるページ」の戻り先に対するひとつの解決方法は、先に紹介したJavaScriptを使うことです。もう一つの解決方法は、このような複数のページからアクセスされるページは、同じブラウザ内ではなく新しいウィンドウを開いて表示させることです。

  <A href="basic.html" target="_blank">基本的な使い方</A>

のようにしておけば、リンク元のウィンドウの内容を残したまま、リンク先が別のウィンドウでオープンされます。


- 自分の居場所が分からない -

深い階層構造は、コンピュータの操作に慣れたユーザーでも迷ってしまう場合があります。WindowsなどGUIを駆使した現在のOSでは、エクスプローラのようなグラフィカルなシェルがフォルダの階層構造を画像として提示してくれるので、5階層でも10階層でも、どこまで潜っていってもユーザーは自分の居場所(現在操作しているフォルダ)が「全体の中のどのあたりなのか」を視覚的・感覚的に認識できます。

ところがWebページでは、ユーザーが今参照しているページがサイト全体の何番目の階層なのか、どのカテゴリに属しているか……といったことは、ページの作成者がそのための仕組みを用意していない限り分かりません。仮に各ページごとに階層を明示するようHTMLをデザインしたとしても、作者が階層の記述を間違えればそれまでです。

昔のMS-DOSやUNIX系OSのコンソールモードを経験したことのある人なら、この「深すぎる階層」がどれだけ厄介かはすぐに理解できるでしょう。UNIX系OSでは、一般ユーザーには見られたくないシステム関係のファイルを、わざと深い階層の奥に保存したりします。


- ワープを使いすぎない -

深い階層構造の持つ欠点の1つに、簡単に他の項目に移動できない――ということが挙げられます。他のカテゴリに移動するための入り口に戻るまで、何度も「戻る」ボタンをクリックしなければなりません。

この手間を軽減するために、深い階層のあるページから別のカテゴリのページへと一足飛びに移動できるリンク――いわゆる「ワープ」を作ってしまうと、便利なようでさらに厄介な問題にユーザーを巻き込んでしまいます。「ここはどこ?」という問題です。

ユーザーはカテゴリの内容に従って順番に階層をたどり、あるページまでたどり着きました。このときユーザーの頭の中には、「大分類→中分類→小分類……」と進んできた経路が記憶されています。そこから一気にまったく別のカテゴリに属するページに飛んでしまうと、それまで頭の中にあった「大→中→小」の道順が一気に吹っ飛んでしまいます。嫌、吹っ飛ぶというより「ごちゃごちゃにもつれてしまう」と言うべきでしょう。

ワープは親切なようで、ユーザーの自然な思考の流れを壊す厄介な仕組みです。HTMLでは簡単に作れてしまうので、注意すべきです。もちろん、画面の上や横にサイトの階層構造を示し、ユーザーがそれを見て異なるページにワープできる――というスタイルなら、問題はありません。要は、ユーザーの「何をしたいのか」「何について知りたいのか」「どこへ行きたいのか」という要求に正しく応えられるインターフェイスを作ることです。親切心が裏目に出て、ユーザーを迷子にさせてはいけません。

シンプルな別ウィンドウを開く

ブラウザの別ウィンドウを開く際に、開いた別ウィンドウにメニューバーやアドレスバーなどを表示させないようにして、シンプルな画面にしたいことがあります。これを実現するには、JavaScriptでwindowオブジェクトのopenメソッドを操作します。

リスト1のようなファンクションを作り、HTMLから以下のようにして呼び出すだけです。openメソッドでは、ウィンドウの幅と高さも指定できます。リスト2を参照してください。

  <A href="JavaScript:ShowWindow('basic.html');">基本的な使い方</A>

リスト1:メニューやツールバーのない別ウィンドウを開く
リスト2:サイズを固定した別ウィンドウを開く

このようにメニューやツールバーのないウィンドウでは、それを閉じるための機能をウィンドウ内に用意しなければなりません。これは

  window.close();

のようにwindowオブジェクトのcloseメソッドを呼び出すだけです。まずリスト3のようなファンクションを作ります。これを画像やテキストなどのonclickイベントで呼び出すだけです。

例えば、close.gifという画像ファイルをクリックしたらウィンドウを閉じる――とするのであれば、以下のようなHTMLを記述します。

  <IMG src="close.gif" border="0" onclick="CloseWindow();">

あるいはもっと単純に、<A>タグに以下のように記述しても構いません。   

リスト3:ウィンドウを閉じる


トップページ
Webアプリはサイトの一部
どこに「戻ればいい」のか?
ユーザーを把握する
情報の分類
分類には手作業の柔軟性を
分類は試行錯誤の連続
階層構造と戻り先の問題
JavaScriptで対処する
自分の居場所が分からない
ワープを使いすぎない
その他の注意点
あとがき

Copyright © MESCIUS inc. All rights reserved.