情報アーキテクチャ、インタラクションデザイン記述のためのビジュアルボキャブラリーversion 1.1b-j (29 June, 2002) based on version 1.1b (6 March 2002)
目次
サマリーダイアグラムはウェブ開発チーム内で情報アーキテクチャやインタラクションデザインについて話をする際に必須のツールである。 このドキュメントでは、それらのダイアグラム生成の理由について議論を行い、情報アーキテクチャやインタラクションデザインコンセプト作図のための基本的記号体系、そしてそれらの要素を使うためのガイドラインについて述べる。 バージョン履歴
はじめに一般に、ビジュアルボキャブラリーはなにかを(通常はシステムや構造や過程を)記述するための記号のセットである。 ここで定義されているこのボキャブラリーは、インフォメーションアーキテクトあるいはインタラクションデザイナーが、ウェブサイトにおけるストラクチャーあるいはユーザー経験のフロー、またはその両方を抽象度の高いレベルで記述するためのものだ。 この記述、あるいはダイアグラム、は5種類の人を対象にしている。
これらの対象者はみんな(スポンサーを除いて)、彼らの仕事を実行するために莫大な量の詳細情報を必要としている。 やっかいなのは、それぞれのそれぞれの役割の人々がそれぞれが必要としている詳細情報が、それぞれ他の種類の人に必要な情報と非常に異なっていて、そして大部分は他の種類の人にとっては見当違いな情報であるということだ。 すべての対象者に対してダイアグラムを有用に使ってもらうための正当なアプローチは、ダイアグラムの詳細を制限することだ。そうすることで、このダイアグラムはそれぞれの対象者の必要に特化したより詳細のドキュメントを作る際の基準して機能する。 情報アーキテクチャやインタラクションデザインのためのビジュアルボキャブラリーとして要求される他のポイント事項は以下の通り、
基本概念情報アーキテクチャとインタラクションデザインはコインの表裏のようなものであるといってよい(ここで用いられている用語の定義は“ユーザーエクスペリエンスの要素”を参照のこと(訳注:原著))。 現代のウェブサイトのダイアグラムはいうまでもなく両面を持っている。 しかし、これらのに対して、ダイアグラムの目的は微妙に異なっている。 どちらのケースおいても、ダイアグラムはいわゆるマクロストラクチャ(全体像)とよばれるものに焦点を定め、チームメンバーにその全体像を十分に提供する。 アーキテクトの仕事はこの目的にかなった、しかるべきレベルの詳細を決定することである。 さらなる個別のページレベルの詳細、またはマイクロストラクチャは、このアーキテクトが主に開発の責任を負うもの以外のドキュメントで定義される。 情報アーキテクチャを記述する際、ダイアグラムは概念的な構造とコンテンツの組織を強調しなければならない。 ここでいう概念的な構造とは、ナビゲーション構造とは異なる。 情報アーキテクチャのダイアグラムの目的は、完璧なナビゲーションの仕様を提供することではない。 これらのレベルの詳細仕様は、混乱をさけるため別のドキュメントに残しておくべきだ。 インタラクションデザインを記述する際は、ダイアグラムはユーザーが定められたタスクをどのようにたどっていくのか、またそれらのタスクがどのようにタスク分割されているのかをを強調しなければならない。 ナビゲーションなどのインターフェースの詳細はダイアグラムにあらわれてはならないーもしもあなたがボタンやフィールドまでを書き込んでしまっているとしたら、それはたぶんダイアグラムに過剰に情報を詰め込み過ぎだということだ。 このボキャブラリーはインタラクションデザインと情報アーキテクチャの両方を網羅するシンプルな概念モデルに基づいている:
基本要素:ページ、ファイル、そしてそれらの集まりウェブにおける基本的なユーザーエキスペリエンスのユニットとは、いうまでもなく単純な四角形であらわされるページである。 ページはプレゼンテーションのユニットであり、必ずしも実装のユニットで(ある必要)はない。 ダイアグラムの1ページは、(一つのフレームセットインターフェースに入った)複数のHTMLファイルや(サーバーサイドインクルードやデータベース型実装などの)複数のコードのユニットと対応している。 ページに加えて、ナビゲートされない特性を持った固まりとして、ファイルというものがある。 ファイルはウェブブラウザーの外の環境で使うものとしてユーザーに提供される(たとえばオーディオやビデオファイル、またPDFや実行ファイルなどのスタンドアローンドキュメントなど)。 これらには古くからの親しみ深いページの隅が折れているアイコンを使って表すことにしよう。
サイトの全体像にあまり重要ではなく、ナビゲーショナルな属性のある機能的に同質のページ郡を表現するために、ページの集まりを使う。 同様に、ファイルの集まりは独立した処理を受けるファイルグループとして表現され、一つの単体として分類できる(例えば、ダウンロード可能なゲームや、PDFの説明書など)。 ページとファイルの確認にはラベルを使う。 これらは、HTMLの<title>エレメントやファイルネームなどの実際の指示と完全に相関関係がある必要はないが、ダイアグラム内での各々のページやファイルのためにユニークでなければならない。 ユニークな数値の識別子とタイプの記号表示は、ダイアグラム内で全てのページとファイルを把握する良い方法である。 関係性の記述:コネクターと矢印エレメント郡の関係は、簡単な線かコネクターで表される。 これらの概念的な関係は、必ずナビゲーションの関係へと変換される。 しかし、全てのナビゲーションの関係がダイアグラムに表記されるわけではない。 情報アーキテクチャの場合、これらの関係性は一般にツリー型のページのヒエラルキー組織を反映したものとなる。 しかしながら、これは必須というわけではなく、(場合によっては)おすすめできない。
インタラクションデザインを図式化する際には、コネクターはどのようにユーザーがシステム内を動き、ある仕事の到達点に達するのか方向を示なければならない。 コネクターを矢印に変えることで、うまく事が運ぶ。 要素の位置の、この前進の動きに対応して、ダウンストリーム、アップストリームという言葉を使うことにしよう。 これらの矢印は、一方通行を表しているのではなく、むしろショッピングモールの食品売り場の進行方向を表している。 ユーザーは反対方向へいくことを禁止されているわけではない: 矢印は単にユーザーがもっとも行きそうな方向を示しているだけである。
なんらかの理由でアップストリームへの動きを禁止したいのなら(たとえば記録の削除などの取り消しできないアクションが行われた場合など)、そのことを示すために矢印の反対側の付け根のところに(短い線の)クロスバーを表記する。 ときにはより複雑なアーキテクチャのなかで流れの方向を明確にするために、アップストリームページ付近にもう一つ矢印を付け加える必要があるだろう。 (実践ノート:多くのダイアグラム記述のためのアプリケーションは、このように矢印を一緒に並べて描くことができない。 こうするためには、“グルードット”エレメントを含んだシェイプライブラリーや、単体の接点からなる見えないエレメントなどを使い、矢印をつなぎあわせる。) コネクターと矢印にもラベルをつけることができる。 しかしこれらの使用は、ユーザーのアクションを具体的に明示したい場合のみに制限しなければいけない。 もしラベルが長くなったり、重くなったり、またダイアグラムを乱したりするようであれば、読者に対して脚注や付録への指示を示そう。 このドキュメントで使われている例では、脚注または付録への参照は括弧でくくられた数字とアルファベット文字のコンビネーションとして示される。 数字はリファレンスのあるダイアグラムのページを、文字は特定の記述を表す。 たとえば、ダイアグラムのページ3の最初の記述は(3a)として、次は(3b)という風に表記される。
すべてを一度に:並列セット並列セット(半円で表す)は、一人のユーザーのアクションが複合的であったり、同時に起こる結果を引き起こす場合などに使われる。 これは、例えばポップアップウインドウが表示されると同時にメインウインドウにページがロードされたり、またはファイルがダウンロードされているときにページがあらわれたりすることをいう。
矢印のように、並列セットは方向がある。 アップストリーム要素は円の曲線につなげられ、ダウンストリーム要素は平面側につなげられる。 一時中断:連続ポイント情報アーキテクトたちは、いつも自分たちの仕事をダイアグラム化することのできる広大な用紙を熱望している。 しかしプロッタなどの大規模の作図デバイスが普及したとしても、いくつかのアーキテクチャは複雑すぎるために、一つの網羅的なダイアグラムでは表現できない。 ダイアグラムを簡単に消化できる部分に分けるために、連続ポイント(四角のカッコ)を用いて、ページ同士の接続する。
一つの連続ポイントには必要に応じて一つもしくはそれ以上の起点や目的地がリストアップされる。 括弧の方向(平行か垂直か)は、特に意味はなくアーキテクトの美的判断に依存する。 共通要素:エリアと反復エリアエリア要素(丸みのある長方形)は、一つもしくはそれ以上の共通の属性を持ったページグループを表している(たとえば同じポップアップウインドウに表示されたり、なんらかのユニークなデザイン処理が施されている、など)。 これらの属性を識別するためラベル表記を行うか、(コネクターと同様に)言わなければならないことが多くあるのなら、ドキュメント中の他の記述を参照する。
多くのアーキテクチャは、いくつかの機能的な情報要素によって構成される、同じ基本ストラクチャの繰り返しを含んでいる。 たとえば、それぞれの商品が複数のページを含んでいるような、商品カタログがあるとしよう。 それぞれの商品についてこの構造の例を描く事は可能であるが、時間の無駄ではないだろうか? その代わり、反復エリアー丸みのある長方形の集まりーを使えばよい。
コネクターと矢印は、エリアに対しては用いられない。 エリア要素はページを囲むだけである。 エリアは、注意深く用いなければならない。 どのページがどのサーバにホスティングされている、といったようなユーザー体験と無関係な事項も含めて、すべての種類の要素をエリア要素として囲ってしまうことは簡単だが、こうするとマクロストラクチャを伝えるというダイアグラムのそもそもの目的を妨げることになってしまう。 再利用可能な要素:フローエリアと参照いくつかのインタラクションデザインにおいて、そのデザイン全体を通して異なった文脈において繰り返し現れる一連のステップというものが存在する(たとえばログイン手順など)。 通常これらのシーケンスは、一つあるいはそれより大きなユーザーが達成しようとしているタスクの単なる構成要素にすぎない。 これはコンピュータプログラミングにおけるサブルーチンの概念と似ている。 このような再利用可能なシーケンスはフローとよばれ、2つの要素によってダイアグラムに表現される。 その2つの要素とは、繰り返される流れそのものを囲うフローエリアと、もとの文脈のなかで繰り返しのフローを示すためのフロー参照である。 どちらの要素も角を削がれた長方形(好みに応じて歪んだ8角形でもよい)で基本的に同じ形をしている。
フローエリアはまた、2つの特別な連続ポイントが必要となる。 それはエントリーポイントと、エグジットポイントである。 これらは、複数のダイアグラムによって示されるフローをフローエリアで囲っている外側に配置される。 フロー参照自体は、連続ポイントとよく似たような機能を果たす。 これら2つの要素のタイプの目的は同じであり、それはアーキテクトにページをこえてダイアグラムを分割できるようにすることだ。 両者の違いは、フロー参照は一つのポイントで“~へ”と“~から”の両方を表現することができることである。 もし、この両方の役割が必要ないようであれば、そのときはフローが必要ないときであろう。 条件要素の基本概念情報アーキテクチャやインタラクションデザインがユーザーのサイトの上での動きに応じてシステムによって動的に生成されることが多くなってきている。 この生成は条件ロジックによって実現されており、またこのボキャブラリーの残りの要素は条件ロジック構造について触れることにしよう。 ここでは、条件要素の応用のための基本概念モデルを示そう。
静的なアーキテクチャにおいては、すべてのパスはすべてのユーザーにすべての環境において提示される。 そして、それぞれのパスは常に同じ結果を導き出す。 動的なアーキテクチャにおいては、一つかそれ以上のコンディションの評価に基づいてシステムはどのパスをユーザーに提示するか決定する。 ダイアグラムの複雑さを最小限にするために、これらのコンディションは主として脚注や付録として示すことにしよう。 選択せよ:意志決定点もしも一回のユーザーアクションがいくつかの結果のうち、一つを生成するのなら、システムはどの結果を提示するのかを決定しなければならない。 (たぶんもっとも一般的な例は、フォーム申し込みにおけるエラー処理だろう。) これらを、意志決定点とよび、従来のフローチャートのようにダイアモンドとして表そう。
意志決定点に関連づけられた要素がアップストリームなのかダウンストリームなのかを明確にするために、意志決定点とともに矢印が用いられなければならない。 先駆者(Pathfinding):条件的なコネクターと矢印条件的なコネクター(点線で表記)は、一つもしくはいくつかの条件に応じてパスがユーザーに与えられたりられなかったりするようなときに用いられる。
例えば、会社の社員のみがアクセスできるような微妙な情報を含むページがありえる。 この場合のコンディションはユーザータイプ(社員)となるであろう。 ここでコンディションが条件を満たすときパスは現れ、そうでなければパスは現れない。 (訳注:英語ではpathfindingは先駆者、パイオニアなどの意味を持つ。path(パス)とfind(見つける)とをかけた言葉遊び。) 複数の選択:条件的な分岐システムがユーザーに提示する相互排他的なオプションのなかから一つのパスを選択するとき、条件的な分岐(三角形)を使おう。 アップストリーム要素は三角形の一つの点につなげられ、ダウンストリーム要素はその反対側につなげられる。
図12に示されている例は、図10の意志決定点の例に多くの点で似ている。 しかし、ここで表されている動きは全く違うものである。 意志決定点の例では、一つのパス(もしくはナビゲーション要素)しかユーザーに提示されない。 このため、ユーザーがたどるパスはいくつかのコンディションに依存していることになる。 図12では、システムは似たような意志決定を行うが、これはユーザーのアクションの前に決められる。 この条件的な分岐はシステムがどのパスをユーザーに提示するかを示している。 ページAからページB、C、Dへのパスは相互排他的となる。 つまり、もしページBへのパスが存在するのなら、ページC、Dへのパスは存在しないということになる。 条件的なコネクターと矢印と同様に、ある条件的な分岐がユーザーにまったくパスを提示しないことがありうる(空の結果)。 ここでの違いは、条件的な分岐においては空の結果は全く許されない。 もし許されるとしたら、その空の結果が3つあるいはもっと多くの可能性のある結果のうちの一つのときということになる。 この分岐が空の結果を許可するかどうかは脚注か付録に示しておこう。 一つか複数か:条件的な選択肢条件的な選択肢要素は(台形で表す)、条件的な分岐と似たように機能する。 重要な違いは、選択肢からのダウンストリームパスは相互排他的ではないということである。 条件を満たすパスであれば、ユーザーにいくつでもパスが提供される。
条件的な選択肢の一般的な応用例はサーチエンジンによる結果だろう。 この場合、検索結果のページは選択肢のアップストリームに現れ、コンディションはユーザーに入力されたキーワード、ダウンストリームパスはサーチエンジンによってインデクシングされたコンテンツページへとつながれる。 条件的な分岐と同様に、条件的な選択肢は空の結果を生成しうる。 実際、これはこれは分岐よりも選択肢の方が一般的にである。 一つの決定、複数のパス:クラスターいくつかの条件構造では、ある条件に基づいて一つ以上のパスをシステムが提示する必要がある。 これらのパスを構造内でクラスター(円で表示)によって関連づける。 クラスターは、条件的な分岐と条件的な選択肢のどちらダウンストリームにも現れる。
図14で表されている構造は、標準の条件的な分岐とよく似ている。 しかしここでは一つの条件に対して、一つ以上のパスがユーザー提示されている。 属性の値がXであったなら、ユーザにはページBへのパスが提示される。 しかし、もし値がYであったなら、ユーザーはページCとDへの両方のパスを見ることになる。 制約条件あり:条件的なエリア一つもしくはそれ以上の条件がページのグループに適応されるとき、それらのページは条件的なエリアとして囲まれる。 これは標準エリアと似た丸い角の長方形、しかし条件的なコネクターと同じ点線で表現される。
条件的なエリアは、ログインやSSLによる暗号化が必要となるようなアクセス許可が必要となるような状況で用いられる。 他のエリアと異なり、条件的なエリアは、1つあるいは複数の条件が満たされていないようなイベントの結果と関連している。 結論どのように全システムが機能しているか御覧になりたいのなら、こちらにMetaFillerのインタラクションデザインと情報アーキテクトのダイアグラムの例があります(私自身このサイトの設計には加わっていません。このダイアグラムは、このサイトから単純に再考したものです)。 Scott Larsonは簡単に様々な要素を参照できるこのハンディカンニングチャートを製作しました。 これ以上のもっと多くのボキャブラリーを使って、自分自身のライブラリを形作っていきたい方のためにPDFがここにあります(Ross Olson、提案ありがとう)。 このボキャブラリーは初めのステップを示したにすぎません。 ウェブの情報アーキテクチャとインタラクションデザインが進化すれば、状況は否応なく変化し、このボキャブラリーは対応しえなくなるでしょう。 あなたのフィードバックとアドバイスが、次のバージョンに大きく役に立つこととなるでしょう。 (訳注:これらのドキュメント(PDF)は和訳されていません。) ダウンロード可能なパーツライブラリOmniGraffle2.0がビジュアルボキャブラリをとりいれた最初のアプリケーションです。 OmniGraffleは最近ではパワーマック、パワーブックにあらかじめインストールされている。 またOmniのサイトから直接ダウンロードも可能である。 (訳注:現在のバージョンのMacOS Xには同梱されていないようです。また、日本ではOmniGraffleはAct2から購入可能です。) 他のシェイプライブラリはこちらから(訳注:英語版です):
(C) 2000-2002 Jesse James Garrett |