『情報アーキテクチャ 第4版』学習メモ（作成中）
はじめに
- information_architecture: 情報の供給過剰によって，探しているものを見つけたり，見つけたとしてもその意味を理解するのが，非常に難しくなっている．この問題の軽減を手助けする実践分野
- 情報への双方向アクセスが重要になっている
- 意味構造を告げる設計原則が，Webを越えて幅広く適用できる
- デジタル製品とサービスに，場所や時間に関係なく，一貫性と統一性，そして分かりやすさをもたらすのに，どんな状況でも利用できるようにするための原則
Part 1 information_architecture入門
- ありとあらゆる場所に膨大な情報 → 見つけるためのノイズはねのけ難しい，見つけても理解が難しい
- information_architecture: 情報を見つけやすく，理解しやすくすることにフォーカスしたデザイン規律
- 2つの重要な視点
- 情報製品とサービスは，情報でできた場所として捉えられている
- 情報環境は見つけやすく，理解しやすいように組織化できる
Ch01 information_architectureが取り組む課題
- points
- 情報を入れものから自由にする方法
- 情報オーバーロードとコンテキスト拡散の課題
- これらの課題をinformation_architectureで解決するには
- 歴史の大部分でやり取りしてきた情報
- 入れものと1対1の関係
- 整理する正しい方法を決める必要
- → 非物質化
- Rip, Mix, Burn
- hello, iTunes
- information_architectureが取り組む課題
- 情報オーバーロード
- トフラー，情報生産の速度と変化の度合up
- → 情報のS/N(Signal/Noise)比が小さくなり対処が必要
- internet → 大量の情報が世界のだれとでも共有可能に
- internet，とくにwwwは概念化された双方向のinteractive media
- Webでの公開は速く，安く，効率的
- 情報技術の進歩 → 入手可能な情報量が増える → 過剰な情報が，情報を整理・発見・よりよく利用するための新たな技術を生んでいる
- → 初期のWebの成功がオンラインでの情報発見を支えるために創業された企業のものとなった
- トフラー，情報生産の速度と変化の度合up
- 情報にアクセスするより多くの方法
- 電子機器の小型化 ＋ ワイヤレス通信
- → 情報をやり取りする方法を変える
- ユーザのアクセス方法の増加
- ユーザの利用に関する情報を収集して，このメタデータにもどついた追加機能を提供
- 情報の脱物質化の次の論理的ステップ
- 周囲へと浸透させ，世界との個人的なやり取りに絶えず存在する機能とすること
- モノのinternet
- 物質と情報のスペースをあいまいにする
- かつてないほど多くの情報処理必要＋多様な物理的，心理的コンテキストのなかで情報処理を行っている
- ユーザにどのように情報にアクセスしてもらうかを考える必要
- ↑ 各コンテキストで期待するものが違う
- ユーザが情報にどこでどのようにアクセスするかにかかわらず，一貫した分かりやすい体験を求めている
- : 多様なコンテキストにおいて多岐にわたる複数のデバイスで，情報を見つける必要がある
- 製品やサービスをデザインした人々の助けが必要
- information_architecture入門
- 混乱の理由の1つ: applicationのほとんどが特定の問題を解決するためにデザインされているが，時が経つにつれ当初の問題解決の枠からはみ出し，より多くの機能を持つようになる傾向
- → 明確さと単純さが失われる
- ツールからエコシステムに代わる
- 必要なのは，情報が簡単に見つかる，分かりやすい構成を作るための，体系化された包括的で全体的なアプローチ
- ユーザが情報へのアクセスに用いるコンテキスト，チャンネル，メディアにとらわれないもの
- 製品開発の溝から抜け出し，広い視点からものごとを見て，情報をより簡単に見つけ，理解できるようにするには，すべてをどう結び付ければいいのか理解する必要
- information_architectureは，チームや個人がこの視点を得るためのレンズとして使える
- 情報で作られた場所
- 製品やサービスのやり取りに，言葉を利用していることを認識するのが大切
- ラベル，メニュー，説明，ビジュアル要素，コンテンツ，それぞれの相互関係が体験を差別化し，理解を促進する環境を作り出す
- 言葉の違いが，特定のタスクを満たすために訪れるべき場所の発見に役立つ
- 言葉は伝える情報の枠組みを作り，既知のコンセプトとのつながりを理解させてくれる
- 特定の言葉やイメージを選んで，その環境で何ができ何ができないかを判断する
- 製品やサービスのやり取りに，言葉を利用していることを認識するのが大切
- チャンネルを超えた首尾一貫性
- information_architectureは異なるチャンネルのニーズによっていくつもの方法で説明できる意味構造を定義するように求める
- 普及するinformation_architectureの重要な要素: 整合性
- 複数チャンネルとコンテキストにおいて，体験は一貫しているべき
- 各チャンネルの機能や制限は異なるが，各チャンネルで用いられる意味構造は，なじみのある首尾一貫したものであるべき
- 実際の実装から抽出
- system_thinking
- まとめ
- 情報は歴史的に非物質化される性質を持ち，入れものとの1対1の関係から，入れものから完全に切り離された状態になっている
- このことから，情報がかつてないほど豊富になり，その情報とやり取りする方法がかつてないほど多くなっている
- information_architectureは，情報を見つけやすく，分かりやすいものにすることに焦点を絞っている
- 製品とサービスは情報でできた場所として認識され，そのエコシステムとしての機能は，最大効果を得られるようデザインされる
- 抽象レベル＋各レベルで定義
Ch02 information_architectureの定義
- 定義
- 定義
- 現れる言葉と実際の意味との関係には注意が必要
- 定義は不完全で制限されたもの
- 情報
- データや知識の管理とinformation_architectureとを区別するために，情報という用語を使う
- データ: 事実と数字が関わる
- 情報: ありとあらゆる形や大きさ
- データや知識の管理とinformation_architectureとを区別するために，情報という用語を使う
- 構造化，組織化，ラベリング
- 構造化: 製品やサービス内の情報「アトム（原子）」に対して適切な粒度レベルを決定し，それぞれをどのように関連付けるかを決定することが必要
- 組織化: これらの要素を意味があってほかと区別できるカテゴリーにグルーピングし，ユーザが現在いる環境とそこで見ているものを理解できる正しいコンテキストを創造すること
- ラベリング: そのカテゴリーおよびそのカテゴリーへのナビゲーション構造要素をなんと呼ぶかの答えを見出すこと
- 見つけることと管理すること
- findabilityは，ユーザビリティ全体の成功要因として欠かせない
- 閲覧，検索，質問を組み合わせてもユーザのほしいものを見つけられなければ，そのシステムは失敗
- ユーザ指向のデザインだけでは十分でない
- 情報を管理する組織と人も重要
- information_architectureはユーザのニーズとビジネス目標とのバランスを取る必要
- 効果的なcontents_management，明確なポリシーと手順が必須
- findabilityは，ユーザビリティ全体の成功要因として欠かせない
- アートとサイエンス
- 見えないからと言って存在しないわけではない
- チェスの情報構造について
- ものすごくいいinformation_architectureへの道
- 効果的なinformation_architectureの設計を実践するためのモデルの基盤
- ユーザ，コンテンツ，コンテキスト
- モデルの根底: 孤立してしまっては役に立つinformation_architectureを作り上げることはできないという認識
- 情報環境は，存在している情報システムやより広い環境の力により，動的で生体のような性質を持つ
- 情報の豊かな流れ，煩雑さ，間違い，試行錯誤，適者生存
- 情報エコロジーの概念: ユーザ，コンテンツ，コンテキストから成る
- 情報環境に存在する複雑な依存関係を扱うために使われる
- ベン図で3つの相互依存性を表す
- → プロジェクトの背後にあるビジネスゴール，そして設計と実装に有効な情報源の理解が必要
- 今日存在しているコンテンツの性質と量を認識し，この先1年でそれがどう変化するかも認識する必要
- 主な顧客のニーズと情報探索行動についても学ぶ必要
- 3つの分野すべてから情報を得て，3つの分野すべてを標的にする
- ユーザの考え方，デモグラフィック，心理，タスクと情報ニーズ，情報探索行動などには，かなりのばらつきがある
- コンテンツも，質，流通，権限，人気，戦略価値，コストなどによってさまざま
- 組織的コンテキストも，使命，ビジョン，目標，組織的政策，組織的文化，集中化や自主性の程度によって異なる
- 3つの円は難しい問題の解決にも役立つ
- problems
- 知っておくべき調査方法や評価方法とは何か
- information_architectureをデザインするチームに加えるべきなのはどのような人々か
- その分野と実践方法に遅れを取らないようにするには，どんな本やブログを読むべきか
- 新たな可能性を提案するinformation_architecture戦略を始めるべきなのは何か
- これらの問題への回答は，ユーザ，コンテンツ，コンテキストの3つのエリアとのバランスを取るところから始まる
- problems
- 情報エコロジーはすべて独特なもの
- 特定のプロジェクトにおいてそれに独自のニーズやチャンスが何かを学ぶ際には，このモデルが非常に役立つツールとなる
- 完全に独自性を持つ情報エコロジーを発生させる
- コンテキスト
- 理解と団結が重要
- コンテンツ
- 人々がシステム上で使用したり見つけたりするもの，技術用語でいう材料
- 所有権
- フォーマット
- 構造
- メタデータ
- ボリューム
- ダイナミズム
- ユーザ
- 何を求めているか
- 効果的なinformation_architectureの設計を実践するためのモデルの基盤
- まとめ
- information_architectureを定義する方法は1つ以上あっても問題ない
- information_architectureは簡単には説明できないもの
- かなり抽象的で，製品やサービスの表面化，意味構造の深い部分にあるが，それも問題ない
- 効果的なinformation_architecture設計を実践するためのモデルには，ユーザ，コンテキスト，コンテンツの3つがある
- 変化するもののミックスは，情報環境ごとに異なるだけでなく，同じ環境において時間とともに変化する
Ch03 見つけやすさのデザイン
- 内容
- 情報を探すためのさまざまなモデル
- 人々の情報探索行動
- こうした行動について学ぶ方法
- information_architectureは，人々がサイトを訪問したり，アプリを使用する理由から始まっている
- ニーズの違いが異なる情報探索行動へとつながる
- ユーザの優先度が高い行動がどれかを決める
- アーキテクチャ設計の上で，どこに努力とリソースを注ぎ込めばよいのか決定しやすくなる
- 「シンプル過ぎる」情報モデル
- ユーザ自身が何を求めているのか知っているときは〇
- それ以外では×
- 情報ニーズ
- ユーザが本来求めているのは，決断を下すための知識や手助けとなる考え
- 魚採りの比喩
- 既知情報探索
- 探求探索
- 全数探索
- 再探索
- 情報探索行動
- 情報ニーズと情報探索行動について学ぶ
- 検索アナリティクス
- 検索パフォーマンス，メタデータ，ナビゲーション，コンテンツでの問題を診断するうえで，自分のサイト上で最も一般的な検索クエリをレビューすること
- ユーザが何を求めているかが分かる
- contextual_inquiry
- 検索アナリティクスを補完
- ユーザが自然な状態で情報どのように相互作用するかを観察し，その文脈において，ユーザがなぜそのような行動をとっているかを質問できる
- 情報アーキテクトとしても目標: 最善を尽くしてユーザの主要情報ニーズと情報探索行動の典型を知ること
- ユーザがシステムに何を求めているかの理解が，どのアーキテクチャ要素を構築すべきかを決定，優先順位をつけるのに役立ち，ひいては作業を大幅に単純化する結果へとつながる
- 良質のユーザデータから，設計にしばしば影響を与える要素間のバランスを取るのにも役立つ
- 検索アナリティクス
- まとめ
- information_architectureは製品やサービスを利用するユーザと，利用する理由から始まる
- ユーザには情報ニーズがある
- ユーザが情報を求めるとき，何が起こるかというモデルがいくつかある
- シンプルすぎるモデルには問題がある
- ユーザに情報ニーズがあるとき，実際にはシンプルにことが運ばない
- 情報ニーズは魚釣りに似ている
- ユーザが自分で求めているものを明確に知っている場合もあるが，ほとんどの場合は流し網を使っている
- ユーザはさまざまな情報探索行動によって情報ニーズを満たす
- こうした行動を学ぶのにさまざまな調査方法がある
- information_architectureは製品やサービスを利用するユーザと，利用する理由から始まる
Ch04 理解のためのデザイン
- 内容
- ユーザは自分がいる場所とそこで何ができるかをどのように感じ取るのか
- 物理的な世界における場の創造と情報環境における場の創造
- 情報環境をより理解しやすくするための基本的な組織化原理
- 物事の理解: 何かほかのものとの関係性による
- information_architectureを設計するとき，「情報の受け取り方と理解の仕方を変える」という，新たなタイプの場の創造に取り組んでいる
- 建物の建築士と同じように，情報アーキテクトも人が理解でき，利用できる環境を創造し，その環境が時間の経過に伴って成長し，ユーザや組織のニーズに合致していくようにしたいと考える
- 情報を受け取る文脈を整え，構造によって原則が理解しやすくなる方法を見る
- 場所の感覚
- 場所の認識，プレイスメイキング衝動を，情報環境でも用いる
- 現実世界のアーキテクチャ
- 利用可能で，ほかのタイプの建物とは異なっているという共通点を持つ必要
- 情報から成り立つ場所
- UIの要素から，銀行のWebサイトと病院のWebサイトの違いが分かる
- 建築は社会的な機能を効率よく果たし，伝えるための物理的な環境を生み出すことを目的としている
- information_architectureもまた，情報環境において同じことを目的としている
- 現実の建築では物質の定義を行うのに対し，information_architectureではナビゲーションラベル，セクションの見出し，キーワードなどの語義を定義し，設計の指針，ゴール，ガイドラインなど，未来の場所の感覚を把握するためのものを定める
- 静謐な人里離れた場所なのか，それとも楽しい交流するためのスペースなのかなど
- 組織化の指針
- 情報環境は多種多様な方法で表現できる
- information_architectureが作り出す意味的構造は，ほかの設計分野の製品よりも抽象的
- architectureの異なるインスタンスに統一性を持たせるには，同じ言語を使用し，構成する言語要素間の特定の関係や秩序を作る
- 構造と秩序
- information_architectureの階層と要素の秩序は，完成したWebサイトに場所の意味と感覚を注入する
- 同じ業界のほかのサイトやサービスとの差別化となる重要な部分
- information_architectureの意味構造にも，サイト全体の中の個々の要素の相対的な重要性を示す階層がある
- 秩序が概念的な境界線を定義し，サイトの形式を認識するうえで大きな役割を果たす
- rhythm, pattern
- ユーザの情報の受け取り方が変わる
- information_architectureの階層と要素の秩序は，完成したWebサイトに場所の意味と感覚を注入する
- 類型学
- 建築における~~式
- どのような性質のビジネスがWebサイトを運営しているかのヒントになる
- ユーザが環境を理解し，ナビゲートしやすい
- 標準的な構造を持つことこそが，競合他社のWebサイトとの差別化を容易にする
- モジュール性と拡張性
- 基礎部分の情報構造は比較的同じ状態を維持する
- 時間変化の速度が異なる層で構成
- 意味構造は比較的安定
- information_architectureは比較的寿命の長い，意味構造の定義に主に焦点を当てている
- デジタル情報環境のダイナミズムを考えると，情報環境アーキテクチャの適応性と拡張性は，実際の建物の場合よりも重要
- 柔軟すぎてもあいまいさにつながり，communicationが不明確になりがち
- 柔軟ともろさの中間あたりが理想的
- 変化に対応しつつも，目的やアフォーダンス（身の回りに存在している意味ある情報）は明確にはっきりしているといえる
- 変化の速度が異なる部分を見つけ出し，それらを全体に関連付けながらここに切り離すのも，バランスを取るための1つの方法
- e.g. Google
- 地球上で一番幸せな場所
- ユーザ，組織，社会間でバランスが取れると，Webサイトから物理的な環境のthe wayfinding systemsにいたる，組織全体の製品とサービスに一貫性が生まれ，理解しやすくなる
- 入念に設計された組織化構造は，ユーザが新しい見慣れない環境を理解するのに役立つ
- 意味構造が場所そのもののコンテキストの設定だけでなく，ユーザにまで広げられるケース
- 買い手/売り手など
- information_architectureは各チャンネルの現在のユーザの特定の情報ニーズに応える必要
- チャンネル間の一貫性の上に来る
- まとめ
- 情報環境の構造はものをどのように見つけるかよりも大きな影響を与える．理解の仕方も変える
- 取引，学習，そしてほかの人々とつながるなど，さまざまな活動においてユーザは情報環境を場所として体験している
- 情報環境を設計する際，物理的な環境の設計から学べる
- 組織化原理の中には，物理的な環境から情報環境に取り入れられたものがある
- 構造と秩序，rhythm，類型学，モジュール性と拡張性など
- 情報環境を収める背景を理解することは，情報環境にある情報をどのように見つけるかに影響を与える
- その逆も然り
- 環境の組織化構造は，そこで何ができるかを人々に理解させるうえで重要な要因となる
- かつ，人々がその環境に加わった時に見つけたい，生み出したいと願う情報にも影響を与える
Part 2 information_architectureの基本原則
- information_architectureの構成要素を見る
- 組織化システム，ラベリングシステム，ナビゲーションシステム，検索システム
- 目に見えないシステムが情報環境の形成を背後で手助け
Ch05 information_architectureの解剖学
- 内容
- information_architectureの視覚化
- 抽象的な領域なので，実際に見るか経験しないと本当に理解はできない
- information_architectureの組織化
- 組織化システムは，サイトの情報をさまざまな方法で表示する
- ナビゲーションシステムは，メインのナビゲーションバーがある場合のドロップダウンメニューでそれぞれの組織へ進めるようにするなど，コンテンツ内をユーザが動き回れるようにする
- 検索システムは，ユーザがコンテンツを検索できるようにする
- ラベリングシステムは，カテゴリやオプション，リンクを，ユーザが理解できる言葉で（できれば）説明する
- トップダウン型information_architecture
- ボトムアップ型information_architecture
- 見えないinformation_architecture
- 検索システムを人間が背後で操作している
- information_architectureの構成要素
- 組織化システム
- いかに情報を分類するか
- ラベリングシステム
- いかに情報を表現するか
- ナビゲーションシステム
- いかにブラウズしたり情報間を移動したりするか
- 検索システム
- いかに情報を検索するか
- ラベリングシステムと組織化システムの区別は困難
- 以下は，もう1つの分類方法
- ブラウジングサポート手段
- あらかじめ決めた道筋をユーザに提供し，ユーザが情報環境をナビゲートする手助けをする
- 組織化システム
- 分類，階層
- general_navigation_system
- 第一次的ナビゲーションシステム
- ユーザが自分は情報環境内のどこにいるのか，どこへ行けるのかを理解するのに役立つ
- local_navigation_system
- 第一次的ナビゲーションシステム
- ユーザが自分は部分的情報環境内のどこにいるのか，どこへ行けるのかを理解するのに役立つ
- サイトマップ/目次
- 主要なコンテンツの領域と，サイト内に存在するサブサイトへのリンクと全体像の要約
- たいていアウトラインの形をとる
- インデックス
- 環境のコンテンツへのリンクをアルファベット順に一覧にしたもの
- ガイド
- 専門的に補う
- ウォークスルーとウィザード
- 段階を追ってユーザを導く，補足的なナビゲーションシステム
- コンテキスト的ナビゲーションシステム
- 一貫してコンテンツに関連したリンクを示す
- テキスト内に埋め込まれていることが多い
- 一般的には，情報環境内の非常に専門的なコンテンツへとつながっている
- 検索サポート手段
- ユーザ定義クエリを入力できるようにし，そのクエリにマッチする結果をカスタマイズしたものを自動的にユーザに提示する
- 動的に自動化
- search_interface
- query_language
- query_builder
- search_algorithm
- search_zone
- search_result
- コンテンツとタスク
- 目に見えない要素
- ほかの要素にフィードしていることが多い
- 検索クエリを強化するために使われるシソーラス
- 制限語彙
- 特定の範囲を指す優先用語をあらかじめ決めたもの
- 変形用語を含む
- search_algorithm
- 関連性によってランク付け
- 一番のおすすめ(Best bets)
- 検索クエリと手作業で組み合わされた，おすすめの検索結果
- ほかの要素にフィードしていることが多い
- 組織化システム
- まとめ
Ch06 組織化システム
- 内容
- 情報の組織化を難しくしている，主観性や政治およびそのほかの理由について
- 厳密であいまいな組織化スキーム
- 階層，hypertext，relational_database構造
- タグ付けとソーシャル分類
- 情報の組織化
- ものごとを理解する基礎である，分類システムが表れる
- 理解を助け，説明および管理をしやすくする
- 分類システムは，社会的，政治的な考え方や目的を反映している
- どのように情報を組織化し，ラベル付け，関連付けるかによって，人々がどう受け取るかが変わる
- 情報アーキテクトは，人々が求めている正しい答えを提供し，その答えを分かりやすくするために，情報を組織化する
- カジュアルブラウジングや直接検索の手段の提供も必要
- ユーザが理解しやすいように情報を組織化してラベリングする
- デジタルメディアによって，情報アーキテクトは非常に柔軟性の高い環境を組織化できるようになった
- 情報の組織化の課題
- 今や誰もがライブラリアンとなっている
- internetがユーザに情報発信の自由を提供
- コンテンツは指数関数的な勢いで成長し，コンテンツの組織構造の革新が必要となっている
- あいまいさ
- 不均一性
- 無関係なパーツまたは異なるパーツから構成されたオブジェクト，またはオブジェクトの集合を指す
- ありとあらゆる情報を広範かつ詳細にカタログ分類する必要
- コンテンツに単一の構造化された組織化システムを使用するのは困難
- 粒度や形式が異なるコンテンツは，それぞれ異なる方法で処理するべき
- 考え方の違い
- ラベリングシステムや組織化システムは作成者の考え方を大きく反映している
- 使いやすい組織化システムを設計するには，自分のメンタルモデルでコンテンツのラベリングや組織化をすべきではない
- さまざまなユーザ調査や分析手法を使い，現実を洞察する
- ユーザリサーチやユーザテストを通じて対象ユーザ層を理解しようと努め，ナビゲーションの通り道を複数用意することにより，先行きの見通しの重要性を認識できるようになる
- 社内の政治的関係
- 避けられないが制御は必要
- 今や誰もがライブラリアンとなっている
- 情報環境の組織化
- 組織化システムは，組織体系と組織構造から構成
- 組織体系
- コンテンツ項目が共有する特性とこれらの項目の論理的なグループ化を定義する
- 組織構造
- コンテンツ項目とグループの関係を定義する
- 組織体系
- 組織化は，ナビゲーション，ラベル，インデクシングとも深くかかわっている
- 密接に関連しているが，組織化システムの設計を分離することは可能であり有用
- ↑ ナビゲーションやラベリングシステムの基礎として活用できる
- 情報の分類だけを目標にすれば，実装上の詳細を気にせずに（ナビゲーションユーザインタフェースの設計など）よりよい製品の設計ができる
- 組織化システムは，組織体系と組織構造から構成
- 情報の組織体系
- 正確(客観的)な組織体系
- 情報を細かく定義された排他的なセクションに分ける
- 既知項目探索
- 設計と保守が比較的簡単
- 使いやすくもある
- アルファベット順
- ほかの組織体系の傘の役割
- 時系列
- ほかの組織体系の補完も必要
- 地理的
- 場所が情報の重要な特性となるとき
- 天気やニュースなど
- あいまい(主観的)な組織体系
- 設計や保守が困難
- 使うのも難しい
- 実際にはこの種の組織体系の方が重要であり，便利なことが多い
- 自分が何を探しているのか，探している本人が分からないことが多いため
- 情報検索には反復が多く，対話式に行われることが多い
- 検索の最初に何を見るかによって，何を検索するのか，あるいは最終的に何を検出するのかが変わってくる
- 連合学習が情報検索プロセスに関わる
- 連想のネットワークに対して検索を繰り返しながら意味空間を形成
- 優れた設計のシステムでは，ユーザは検索の過程で学習する
- → 項目を知的効果のある方法で分類することで，偶然性による情報検索をサポート
- ユーザ以外の誰かの知的判断にもとづいて，項目のグループ化
- 関連する項目のグループ化は，連合学習のプロセスをサポートし，ユーザは新しい関連付けを行って，よりよい結果を得ることができる
- → 高い価値をユーザに提供
- 成功の鍵
- 体系の質
- 体系内の個別項目の配置
- → 厳密なユーザテストが必要
- 新規項目を分類したり，産業界の変化を反映して組織体系を変更したりする必要がある
- トピック組織体系
- 情報を主題やトピックごとに組織化
- 最も有効で，非常に厄介
- 文化的構造 → 時の経過によって変化する
- 範囲を幅広く定義することが重要
- ユーザがシステムの範囲内で見つけようと期待しているコンテンツの全体を設計する
- タスク
- プロセス，機能，またはタスクの集合でコンテンツとアプリケーションがまとめられる
- ユーザが実行しようとしている優先度の高いタスクが少数しかない場合には適している
- Webにおいては，顧客とのinteractionが中心であるWebサイトで最もよく見られる
- 顧客
- 製品やサービスのユーザ層が複数存在することがはっきりしている場合
- 各ユーザ層別にコンテンツをカスタマイズする必要がある場合に〇
- personalization関連のあらゆる期待や危険がもたらされる
- 求めているものとユーザの特性がマッチしない場合もある
- メタファー
- ユーザの理解を促す
- ユーザはコンテンツ処理と模索を直感的に理解できる
- メタファー駆動型の情報の組織体系をどう処理するか模索する過程で，Webサイトの設計，組織化，機能について斬新なアイデアが浮かぶことがある
- ユーザになじみのあるものである必要
- 重荷となったり制限となることもある
- 一貫性に合わないケース
- ハイブリッド
- ナビゲーションの表層において有用
- 多くのWebサイトは，メインページ上とグローバルナビゲーション内でトピックとタスクをうまく組み合わせている
- ↑ 組織構造もユーザも，コンテンツの発見とキータスクの遂行が優先順位の1番上にあると認識しているという現実を反映
- 浅いハイブリッド型の組織体系は〇，深いのは×
- 深いハイブリッドを避けるために，複数の体系を1ページで提供するときは，各体系の整合性を維持するよう，設計者に呼びかける
- 同一ページ上でも体系ごとに提示されていれば，ユーザのメンタルモデルをサポートする機能を失わずに済む
- ナビゲーションの表層において有用
- 正確(客観的)な組織体系
- 組織構造
- 情報環境を設計するうえで非常に重要な役割
- 情報構造は，ユーザがナビゲーションするための主な方法を定義する
- 以下の3つの方を総合的に使用するのが〇
- 階層型: トップダウン型のアプローチ
- 優れた設計の階層構造は，多くの場合，優れたinformation_architectureの基礎となっている
- 階層構造は後半に用いられるので，ユーザは階層的な組織化モデルを使用しているWebサイトを容易にかつ瞬時に理解できる
- → 情報環境の構造を感覚的に理解し，構造内の現在位置の認識ができる
- → ユーザが使いやすいコンテキストを提供できる
- information_architectureの出発点として非常に適している
- トップダウン型のアプローチを利用することで，詳細なコンテンツのインベントリ化プロセス（データの一覧化を行うこと）を回避でき，即座に情報環境の全体を把握できる
- 主なコンテンツエリアを識別子，そのコンテンツへのアクセスを提供する組織体系を検討できる
- 階層の設計
- Webの階層を設計するときのいくつかの基本ルール
- 階層カテゴリは相互排他的にする
- とらわれすぎる必要はない
- 1つの組織体系では，排他性と包含性のバランスをとるようにする @あいまいな情報の組織体系のみ
- あいまいな項目は複数のカテゴリに含める
- クロスリストされている項目が多すぎると，階層そのものの価値が失われる
- 階層の幅と深さのバランス
- 幅: 階層の各レベルのオプション数
- 深さ: 階層内のレベル数
- 広さについて考えるとき，人が目でざっと見られる能力と認識の限度にも配慮する
- おすすめ
- 過剰なオプションはユーザを圧倒してしまう危険性があると認識する
- ページレベルで情報をグループ分けし，構造化する
- ページ内でアイテムをグループ分け
- ユーザテストを実施して設計を厳密に調査する
- 広さと幅の中庸が〇
- 深さについては，2か3レベル以上クリックが必要だと，ユーザは諦めて去ってしまう可能性がある
- 今後拡張が予想される新しい情報環境では，「狭く深く」ではなく，「広く浅く」を考慮すべき
- コンテンツの追加に大幅な再構築は不要
- 項目の追加はメインページに対して行うよりも，2番目のレベルの階層に対して行う方が若干容易
- メインページまたはスクリーンが，ユーザにとって最も明白で重要なナビゲーションインタフェースであり，システムにおいて何ができるかを理解する助けとなる
- メインページは最も目につくうえに重要 → 企業はメインページのグラフィックデザインとレイアウトに時間とコストを費やす傾向
- 階層カテゴリは相互排他的にする
- 組織体系を設計する際は，階層モデルの罠にはまらないことも大切
- 特定のコンテンツエリアでは，DBやハイパーテキストを使ったアプローチも可能
- 手始めとしては階層構造は適しているが，組織体系のほんの一部に過ぎない
- Webの階層を設計するときのいくつかの基本ルール
- データベース型モデル: ボトムアップアプローチ
- DB: 検索と情報収集の簡便化とスピードアップを目的としてアレンジしたデータの集合体
- メタデータが，information_architectureとDBスキーマとを結ぶ主要なキーとなる
- メタデータのエレメンツ間の関係は非常に複雑になる可能性がある
- 情報アーキテクトが理解しておくべきこと: メタデータや制限語彙，DB構造は，以下の事項を可能にするためにどう利用できるか
- 自動生成されるアルファベット順のインデックス
- 関連する「参照（see also）リンク」を動的に表現すること
- フィールド検索
- 検索結果の高度フィルタリングとソーティング
- 比較的均質なサブサイトに適用すると，特に効果的
- 製品カタログや社員住所録など
- ハイパーテキスト型
- 社会的分類
- 結合力のある組織化システムの作成
- 「データを情報へと変化させる第一歩は，その組織構造を調査すること」
- コンテンツのかたまりを小さな領域に集約すると，高度な機能を提供する組織化システムの可能性を追求できる
- 全体像を見落とさないようにすることも重要
- どの組織体系を適用するか検討する際，正確な情報の組織体系とあいまいな情報の組織体系の違いを考える
- できる限り両方の体系を利用する
- Web上で情報を組織化する難しさ
- 同じ情報にアクセスする方法を複数提供して対処する
- 大規模なシステムでは一般に複数の構造が必要
- いくつもの組織構造を組み合わせることで，結合力のある組織化システムが作成できる
- まとめ
- 世界をどう理解するのかは，世界をどう分類するかによって決まる
- 分類は簡単ではない．あいまい，不均一，考え方の相違，政治的な圧力などの問題に対処しなければならない
- 正確な組織体系またはあいまいな組織体系を使って組織化できる
- 正確な組織体系にはアルファベット順，時系列，地理的分類がある
- あいまいな組織体系にはトピック，タスク，顧客，メタファー，ハイブリッド型がある
- 組織体系の構造はまた，情報環境の設計においても重要な役割を果たす
- 社会的分類は，共有デジタル環境における情報の組織化のための重要なツールとして浮上してきた
Ch07 ラベリングシステム
- 内容
- ラベリングシステムとは何か，重要な理由
- よくあるラベルのタイプ
- ラベルを開発するためのガイドライン
- ラベリングシステムを作成するためのヒント
- ラベリング: 表現形態の1つ
- ラベルを使って情報環境内の情報のまとまりを表せる
- 情報をあれこれ目立つようにに表示する代わりにラベルを使えば，ユーザはすんなりと理解でき，何ができるかどうするか決められる
- ラベルの目的: 情報を効果的に伝えること
- → ページの物理的スペースもユーザの認識領域も無駄遣いすることなく，情報を伝える
- ラベルは，複数のシステムとコンテキストにまたがる組織とナビゲーションシステムを最も明確にユーザに示す方法
- なぜラベリングに注意を払う必要があるのか
- 多くの場合，情報環境は，システムの所有者と作者のメッセージをユーザにゆっくり翻訳して伝え，また元に戻す仲介メディア
- → メッセージがあいまいになるため，ラベルが必要
- 相手と直接向き合えないという欠点を最小限に抑えるために，ラベルを作る
- 新しい概念についてユーザに教えるのは，ラベルの役割
- うまくいったラベルは邪魔にならない（失敗したラベルは目立つ）
- 予測でき紛らわしくないラベルが〇
- ラベルのチェック
- 内容を描写していないうえにほかとの区別がつかないラベル
- 内容が不明，脈絡がない
- ラベルに専門用語が使われており，ユーザ中心のラベルになっていない
- ラベルのせいでお金が無駄になる
- ラベルのせいで悪印象を与えている
- 貧弱なラベルは×
- 内容を描写していないうえにほかとの区別がつかないラベル
- ラベルはほかの要素と同じくらい重要な要素
- 多くの場合，情報環境は，システムの所有者と作者のメッセージをユーザにゆっくり翻訳して伝え，また元に戻す仲介メディア
- さまざまなラベル
- テキストによるラベル
- コンテキストリンク，ヘッダ，ナビゲーションシステム選択，インデックス用語
- アイコンによるラベル
- コンテキストリンクとしてのラベル
- ドキュメントまたは情報チャンクの本文内にあるハイパーリンクテキストを説明しているラベル
- 周囲のテキストという説明的なコンテキスト内に生じる
- 作成が簡単で，Webの成功を促すエキサイティングな相互連結性の基礎
- 簡単に作成できるからこそ問題も起きる
- ハイパーテキストでのつながりは，個人的でそれぞれ異なる種類
- → コンテキストをうまく作り上げることで，ラベルの意味が周囲のテキストから引き出される
- ラベルの持つ多様性は，より多くのラベルの組み合わせやラベリングシステムからコンテキストを引き出し，ひいては意味を引き出している
- しかし，リンクラベルではシステム的な一貫性は期待できない
- コンテキストリンクを作成しラベリングする前に，「ユーザはどのような情報につながると予測しているだろうか」と問いかけることで，情報アーキテクトはコンテキストリンクラベルの具象性を確認できる
- ほとんどの場合，コンテキストリンクは情報アーキテクトの力が及ばないことも知る
- テキストによるラベル
- ヘッダとしてのラベル
- ヘッダ: それに続く情報チャンクを描写
- コンテンツ内の階層を築くために使われる
- サイトのサブサイトを決めたり，カテゴリとサブカテゴリとを区別する役目を持つ
- 親子関係や兄弟関係といったヘッダ間の階層関係は，視覚的要素の組み合わせを一貫して使うことで築ける
- 階層関係を目立たせることにあまり厳密にならないようにする
- 読まなくても視覚的に区別できればヘッダは不要
- ラベリングをプロセスに入れる際には一貫性の維持が特に重要
- ヘッダラベルははっきり目に見えていて，先へ進む順序を伝える必要がある
- → 番号を使うのが一般的
- 一貫性を持った行動としてラベルを述べる，つまり動詞を使用するという方法も先へ進む手順をまとめるときに役立つ
- ラベルは「どこから始まるか」「次はどこへ行くのか」「先へ進むときに各ステップでどんな行動を取ることになるのか」を伝える必要
- ヘッダラベルははっきり目に見えていて，先へ進む順序を伝える必要がある
- ヘッダラベルは階層的，順番的，または複合的かもしれないが，コンテキストリンクラベルよりもシステム的に設計されるべきもの
- ヘッダ: それに続く情報チャンクを描写
- ナビゲーションシステム中のラベル
- オプション数の少ないナビゲーションシステムラベルは，ほかのどのタイプのラベルよりも一貫して適用されることが要求される
- ナビゲーションシステムはサイトに繰り返し登場 → ナビゲーションラベリングの問題は拡大される
- ページ配置と見た目が一貫した場所で「合理的に」振る舞うために，ユーザはナビゲーションシステムに頼る
- ラベルは常に同じである必要
- ↑ 親近感を養うためには，ラベルを効果的に適用することが欠かせない → ページごとにラベルが違っては困る
- 色も配置も一貫していればさらに効果的
- 基準はないが，多くの場合ナビゲーションシステム用に共通する用語がある
- 各カテゴリに対して1つの用語を選択し，それを一貫して適用するのが〇
- メイン，メインページ，ホームのなかから1つ選ぶなど
- 各カテゴリに対して1つの用語を選択し，それを一貫して適用するのが〇
- インデックス用語としてのラベル
- キーワード，タグ，説明を含んだメタデータ，用語体系，制限語彙，シソーラスなどと呼ばれ，あらゆる形式のコンテンツを記述するために用いられるもの
- コンテンツの意味を描写することで，単にコンテンツの全テキストを検索するよりも精密な検索が可能になる
- 人がコンテンツの意味を確認して表現したもの → 単純に検索エンジンで全テキストからクエリと合うものを探すより，インデックス用語を検索した方が効果的
- ブラウジングも容易になる
- サイト本来の組織化システムの代替物となり，ユーザにとって非常に便利
- 組織化システムからもインデックス用語からもアクセスできる
- サイトインデックスやリストの形を取ったインデックス用語は，組織のサイロ間にある縦の境界線を横断する手段として有効
- インデックス用語がまったく見えない場合もある
- 各ページを目立たせようとするのはかなり困難な作業
- 制限語彙やシソーラスからインデックス用語を選んで利用するなど，よりシステム的なアプローチでラベリングする方が効果的
- → 目的: より詳細な範囲を一貫性のある予測可能な方法で記述すること
- アイコンラベリング
- アイコンはナビゲーションシステムのラベルとして使われることが最も多い
- 特にモバイルアプリのように，画面のスペースに制限がある場合など
- 問題: テキストラベルよりも言葉が限られている点
- → 小規模な組織のシステムラベルやナビゲーションシステムなど，オプションが少ない用途がほとんど
- 情報環境に優美さが生まれるので，システムのユーザビリティを阻害しないのなら，使わない手はない
- 繰り返し利用してもらえるなら，アイコンによる言語がユーザの心に確立される
- → アイコン言語は具体的かつ視覚的にも認識しやすい伝達システムとして非常に有効
- ユーザが繰り返し使ってくれる場合以外は，選択肢が限られたシステムにおいてのみアイコンラベルを使い，機能を説明する前に使用しないことが推奨
- アイコンはナビゲーションシステムのラベルとして使われることが最も多い
- ラベルの設計
- 効果的なラベルの設計はinformation_architecture最大の難関
- 言語自体があいまいなので，完璧なラベルという自身は持てない
- 類義語や同音異義語についても考えなければならないし，コンテキストが違えば用語の意味の理解にも影響する
- 多言語対応
- ラベリングは科学よりアート
- 一般的なガイドライン
- ユーザ，コンテンツ，コンテキストの変化のしやすさが，ラベルをあいまいな世界に導く
- 可能な限り視野は狭くする
- 全サイトをカバーしているグローバルナビゲーションシステム以外は，全システムのコンテンツを扱うラベルは使わないようにする
- 一貫性のあるラベルではなく，一貫性のあるラベリングシステムを発展させる
- 一貫性は予測可能であることを意味し，予測可能なシステムは覚えるのが容易 → 一貫性が重要
- 一貫性に影響を及ぼす問題
- スタイル
- 表示
- 構文法
- 粒度
- 総合性
- 顧客
- ラベリングシステムの情報源
- 新しいラベリングシステムの作成
- 最も重要な情報源: コンテンツ（と，その作者の可能性もあり）とシステムのユーザ
- コンテンツ分析
- 時間のかかるつらい作業
- 既に存在している「コンテンツの見本」に集中してスピードアップが必要
- コンテンツの見本: タイトル，要約，抄録
- 自動抽出ツールを使えば，作業の8割までは完了する
- 高額で学習コストもかかる
- コンテンツ著作者
- 著作者に提案を依頼する
- 再集計ではない
- ユーザの代表者とテーマ内容の専門家
- ライブラリアンと想定ユーザを決めて作業
- ユーザがシステムに何を求めているか
- まず少数のグループ化から初めて，それをもとにしてサイト全体のインデックスをサポートするラベル作りに発展させた例
- ライブラリアンと想定ユーザを決めて作業
- ユーザ（直接的）
- 入手しづらいが得られれば最も有用
- カードソート
- オープンカードソート
- 既存のコンテンツに対するラベルを被験者に与える
- 被験者はそれを群和気氏，独自のカテゴリとする
- クローズドカードソート
- 被験者に既存のカテゴリを与えて，そのカテゴリ内にコンテンツを並べ替えてもらう
- ナビゲーションのラベルなど，少数のラベルにより適している
- カードソートは非常に有益だが，被験者は実際の製品のコンテキストに即してラベルを提示しているわけではないことを認識必要
- オープンカードソート
- フリーリスティング
- カードソートよりさらに低コスト
- 1つの項目を選び，被験者にその項目を説明する言葉について意見を出し合ってもらう
- どんな人に何人に頼むのか，被験者について考える必要
- コンテンツのサブセットの選択
- 利用パターンと頻度を見る
- 個々のアイテムにどのようにラベルをつけるかの間を与えてくれると同時に，ユーザが用いる言語についても示してくれる
- ラベリングシステムを開発するうえで，どのような傾向，スタイルにすればよいかのヒントを与えてくれる
- ユーザ（間接的）
- 検索クエリやタグの分析
- → ユーザのニーズに関するデータという価値ある情報を生み出している
- 検索ログ分析
- 微調整
- まずリストをアルファベット順にソートする
- 重複を削除
- 用語の用法，句読点，大文字小文字の用法などの観点から，リストをチェックする
- 一貫性のなさを解決し，句読点やスタイルのルールを確立するよいタイミング
- どの用語をラベリングシステムに含めるのかは，システムがどれだけ幅広いのか，どれだけの規模かという状況のもとに決断する必要
- まずラベリングシステムに明らかなギャップがあるかどうか判断
- 最終的に要素として入れる必要のありそうなラベルが網羅されているか
- 将来サイトでカバーされると予想できるトピックについても考える
- 仮のラベルがラベリングシステムに及ぼす影響は驚くほど大きい
- サイト独自のコンテンツと特定のユーザのニーズを満たすには，ターゲットを絞り，範囲を限定し，手元にあるビジネス目標に狙いを定めたうえで，正しく定めた範囲内で包括的なものになるようにすべき
- バランスの問題
- 取り掛かろうとしているラベリングシステムは，その後すぐに調整と改善の必要性が生じる
- ラベルは，ユーザとコンテンツという，2つの絶え間なく変化し続ける対象の関係を描写しているため
- → ユーザテストを実施する容易を司，検索ログを定期的に分析し，必要に応じてラベリングシステムを調整するようにする
- 効果的なラベルの設計はinformation_architecture最大の難関
- まとめ
- 我々は常にラベリングしている
- ラベリングは，複数のシステムとコンテキストにまたがる組織のスキームを最も明確にユーザに示す方法
- システムのユーザと同じ言語を用いるラベルを設計しつつ，コンテンツを反映するようにしなければならない
- テキストラベルは仕事中に目にする最も一般的なラベルのタイプ
- コンテキストリンク，ヘッダ，ナビゲーションシステムオプション，インデックス用語がこれに含まれる
- アイコンラベルはそれほど一般的ではないが，スクリーン面積が小さい端末では広く採用されている．多くの情報環境において，こうした端末が重要になっている
- ラベルの設計は，information_architectureにおける最も難しい一面
- 既存の情報環境や検索ログ分析などさまざまな情報源があり，ラベリングを選択するうえで役立つ
Ch08 ナビゲーションシステム
- 内容
- コンテキストを提供し，より柔軟性を高めようとする場合は，お互いを補足し合うようなナビゲーションツールが必要になる
- 「構造化と組織化」は部屋を建築士，「ナビゲーション設計」はドアや窓を取り付けるようなもの
- 構造化，組織化，ブラウジング，検索システムのすべてが，効果的なナビゲーションに貢献している
- ナビゲーションの表層，つまりユーザが操作を行う部分が，非常に速く変化している
- さまざまな計上の端末の拡散により，設計者や開発者はバラバラ場スクリーンサイズや操作のメカニズムに対応するため，多様な戦略を考案せざるを得ない状況になっている
- 「レスポンシブWebデザイン」戦略はそれだけで大きなテーマなので扱っていない
- さまざまな計上の端末の拡散により，設計者や開発者はバラバラ場スクリーンサイズや操作のメカニズムに対応するため，多様な戦略を考案せざるを得ない状況になっている
- ナビゲーションシステムのタイプ
- ナビゲーションシステムはいくつかの基本的な要素，またはサブシステムで形成されている
- まずグローバルナビゲーションシステム，ローカルナビゲーションシステム，コンテキストナビゲーションシステムがあり，これらはサイトのページやアプリのスクリーン内に統合されている
- ユーザが「どこにいるのか」「どこへ行けるのか」を理解できるようにしている
- 図8-1: グローバル，ローカル，コンテキストの埋め込み型ナビゲーションシステムのレイアウト
- これだけでは不十分
- 図8-2: 補足型ナビゲーションシステム
- サイトマップ，インデックス，ガイド
- 同じ情報に対して異なるアクセス方法を提供する点で検索に似ている
- ナビゲーションシステムはいくつかの基本的な要素，またはサブシステムで形成されている
- あいまいな問題
- ナビゲーションシステムは，分野横断的なあいまいな領域に深く踏み込む
- エクスペリエンスデザインという傘の下に分類されるもの
- さまざまな分野が互いに協力するのが理想
- ナビゲーションシステムは，分野横断的なあいまいな領域に深く踏み込む
- ブラウザナビゲーション機能
- ナビゲーションシステムを設計する際は，システム環境について考慮が重要
- ナビゲーションはユーザがサイトとインタラクションするさいに重要
- 新しいナビゲーションスキームは検討要
- 場所を明確にする
- ここが何のサイトであり，何を見つけ，何ができるのかなど，コンテキストを明確にすることで，情報はより理解しやすくなる
- 言葉で存在位置を明確にし，サイトを見て回るはっきりした道筋を示すのは，ナビゲーションシステムが果たす大切な役割の1つ
- どのナビゲーションシステムでも，次にどこへ進むか決めるには現在地を知る必要がある
- 全体像から見た情報提供が特に重要
- 一見しただけでその内容を大まかに把握できるようなサイトを作るための，基本的な経験則
- 自分がどこのサイトまたはアプリにいるのか常に知らせる
- 組織名やロゴ，画像でのidentityをサイトの全ページに拡張すれば簡単に達成できる
- 自分がどこのサイトまたはアプリにいるのか常に知らせる
- 情報の階層構造を明確に，一貫性を持って示す，かつユーザの現在地を示す
- 組織体系のメンタルモデルを作りやすくなる
- ナビゲーションストレステスト
- 1.トップページを無視して直接サイトの中に進む
- 2.適当に入ったそれぞれのページに対して，自分がどこにいるか，サイトのほかの部分との関係を把握できるか，今いる主なセクションはどこか，親となるページはどこか
- 3.今いるページが次にどこへつながるのか予測できるか，リンクは何についてのリンクか十分に説明しているか，やりたいことがあるときに，似ているためにどれを選んでいいか分からないリンクがないか
- ここが何のサイトであり，何を見つけ，何ができるのかなど，コンテキストを明確にすることで，情報はより理解しやすくなる
- 柔軟性の向上
- ナビゲーションの観点では，階層化には制約がある
- → ハイパーテキスト機能はこの制約を取り除いた
- → 柔軟性という利点と混乱というリスクのバランスを取る
- 水平および垂直方向のナビゲーションサポートが必要
- サポートが多すぎると，階層構造が分かりにくくなってユーザを困らせる
- 階層構造を補強するのに十分なコンテキストと柔軟性を提供することが大切
- 埋め込み型ナビゲーションシステム
- 図8-1の3つの主要な埋め込みナビゲーションシステムの性質と，それらが一体になったときにコンテキストと柔軟性をどう提供できるかの理解が，成功するWebサイトの設計には欠かせない
- グローバルナビゲーションシステム
- サイトの全ページに表示される
- ユーザがサイト階層内のどこにいても，重要な領域や機能に直接アクセスできる
- 組織のロゴでホームページにリンク
- 検索機能へのリンク
- サイトの構造を強化し，コンテキスト的なヒントを提供することもある
- 絶えず発展している
- メガメニュー
- 従来のドロップダウンメニューの用に表示される，大きなメニュー画面
- ファットフッタ
- 要約されたサイトマップ
- サイトにおいて唯一の首尾一貫したナビゲーション要素であることが多いため，利便性という点で大きな影響力を持っている
- → ユーザ中心の設計となるよう，徹底して繰り返しテスト要
- ローカルナビゲーションシステム
- グローバルナビゲーションシステムが複数または1つのローカルナビゲーションシステムによって補足され，ユーザが現在いる領域を探索できるようにしている
- ローカルナビゲーションシステムとそこからアクセスできるコンテンツは大幅に異なることが多い → ローカルエリアはサブサイト（サイト内のサイト）と呼ばれる
- サブサイトが存在する理由
- 特定の領域のコンテンツと機能が，ユニークなナビゲーションを持つメリットがある場合
- 大規模な組織は分散化が進んでおり，コンテンツの領域が異なればその責任者のグループも異なるため，各グループが違ったやり方でナビゲーションを扱うことに決めている場合
- 単に設計チームが複数いて同じ方向性が選べなかっただけというのは望ましくないがよく見られるケース
- コンテキストナビゲーション
- グローバルナビゲーション，ローカルナビゲーションという構造化されたカテゴリが適さない関係のとき
- See alsoなど
- 関連学習をサポート
- 項目間に定めた関係を発掘することでユーザが学習していく
- ユーザと組織のためになる網の目のような組織を作れる
- アーキテクチャ側というよりも編集側のものと定義される
- このようなコンテキストリンクがコンテンツにとって非常に重要な場合は問題がある
- ユーザがページをすばやく読むため，隠れたリンクは見落とされたり無視される傾向にある
- → ページのどこか特定の位置にコンテキストナビゲーションリンクの欄を設けたり，見てわかるようにまとめられるシステムを設計する
- 適度な使用が〇
- 若干の柔軟性と補足的な役割を果たすようにする
- コンテキストリンクの性質と重要度により，各ページにこの方法を使うべきかが決まる
- コンテキストナビゲーションシステムを設計するときは，サイトのすべてのページがメインページ，または独自の目的を持ったポータルであると考える
- ユーザがいったん特定の製品やドキュメントを認識すると，サイトのほかの部分は背景に溶け込んでしまう
- このページがインタフェースとなる
- ユーザがいったん特定の製品やドキュメントを認識すると，サイトのほかの部分は背景に溶け込んでしまう
- コンテキストナビゲーションはクロスセルやアップセル，ブランド構築のチャンスであり，顧客に価値を提供する
- グローバルナビゲーション，ローカルナビゲーションという構造化されたカテゴリが適さない関係のとき
- 埋め込み型ナビゲーションの実装
- 柔軟に動ける性質と過剰なオプション機能でユーザを圧倒してしまう危険性とのバランスを取る
- 成功の鍵: 「ほとんどのWebサイトではグローバル，ローカル，コンテキストのナビゲーション要素が共存していて，コンテンツによるアプリも共存している」と認識すること
- これらの要素を効果的に統合すれば，お互いを補完できる
- 単独で設計は×
- 画面上のかなりのスペースが占領されてしまうため
- ナビゲーションバーによってグローバル，ローカル，コンテキストのナビゲーションをサポート
- 実装方法は，インタラクションデザインやテクニカルパフォーマンスの分野が決定を下す
- 画像/テキスト
- デスクトップブラウザが対象なら明確で実装しやすくアクセスしやすいテキストが〇
- モバイルアプリなどスペースが限定ならナビゲーションオプションをアイコンで示す方が〇
- ナビゲーションバーがページのどこに属するか
- → 図8-15
- デスクトップブラウザが対象なら，グローバルナビゲーションをページの一番上のどこかに配置し，ローカルナビゲーションバーをメインコンテンツと並べて配置
- モバイルWebページでは，ナビゲーションバーをコンテンツの左側か右側に見えないように隠しておくことが多い
- メニューボタンで表示
- 親指が簡単に届く，スクリーン株にナビゲーションバーを配置
- 設計するメディアのルールと制限の認識が必要
- 標準から外れるときはリリース前にユーザテスト
- 補足型ナビゲーションシステム
- サイトマップ，インデックス，ガイド
- 基本的なWebサイト階層外にあり，コンテンツの発見とタスクの遂行を補足する
- 検索も補足型ナビゲーションに属する
- 大規模なWebサイトでユーザビリティとファインダビリティを保証するために欠かせない要素
- 重要性に見合うだけの注目や扱いを受けていない
- ユーザの非常時に支援できる
- サイトマップ
- 上層における2~3番目までの情報階層が提示
- → システム内のコンテンツを一望し，セグメント化されたコンテンツにランダムにアクセスできる
- 画像またはテキストのリンクを利用して，ユーザが直接サイト内のページにアクセスできるようにしている
- 本来サイトマップは階層化構造の大規模なサイトで利用される
- アーキテクチャがそれほどしっかりとした階層になっていない場合は，インデックスやその他の視覚的な表現の方が〇
- 採用するかどうか決定するときは，Webサイトの規模を考慮する
- サイトマップの設計はユーザビリティに強く影響する
- 原則
- 情報階層を強化し，コンテンツの構造にユーザが徐々になじめるようにする
- 自分のほしいものが分かっているユーザがサイトのコンテンツにすばやく，直接アクセスできるようにする
- 過剰な情報でユーザを圧倒しないようにする．目標はユーザを助けることであり怖がらせることではない
- SEOの観点からも有用
- → マップは検索エンジンに配置して，Webサイト全体から重要なページへと直接アクセスできるようにしている
- サイトインデックス
- 階層はなく比較的平坦
- 探し物の名前がすでに分かっている人に対して上手く働く
- 大規模で複雑なWebサイトでは，多くの場合サイトマップとサイトインデックス（とそのための検索能力）の両方が要求される
- サイトマップは階層を強化し，探求を促進
- サイトインデックスは階層を無視して既知項目の発見を容易にする
- どの程度詳細なインデックスを作成するかという問題
- Webページ/ページの各段落や概念/複数のWebページをまとめてインデックスをつけるかなど
- まずユーザがどのような用語を探そうとするのかを把握する
- 検索ログを分析し，ユーザ調査を行う
- 2つの作成方法
- 小規模なWebサイトでは，コンテンツについての知識を利用してどのリンクを含めるのか決め，単純に手作業でインデックスを作成する
- 1ステップ
- 2ステップで用語のローテーションと参照(see also)という特徴のもの
- 最適の結果をアルファベット順のリストで表示
- コンテンツ管理が分散している大規模なサイトでは，ドキュメントレベルで制限語彙インデクシングを利用し，サイトインデックスを自動的に作成するのが〇
- 制限語彙用語は複数のドキュメントに適用できるものが多いため，2段階のプロセスが必要
- まずユーザがインデックスから用語を選択し，次にその用語を用いてインデックス化されたドキュメントの一覧から選択する
- 制限語彙用語は複数のドキュメントに適用できるものが多いため，2段階のプロセスが必要
- 小規模なWebサイトでは，コンテンツについての知識を利用してどのリンクを含めるのか決め，単純に手作業でインデックスを作成する
- 用語のローテーション
- 順列
- 用語を入れ替えたインデックスでは，語句内の言葉の位置がローテーション表示され，そのフレーズをアルファベット順のインデックスの2つの場所からひけるようになっている
- 単語の順番を入れ替えた用語によって，様々な方法で情報を検索できるようになる
- 順番を入れ替えるべき用語はきちんと選ぶ必要
- ガイド
- コンフィギュレータ
- 製品を構成したり，別途注意が必要な複雑な決定木をナビゲートする際に役立つ
- 洗練されたコンフィギュレータでは，ユーザの複雑な意思決定プロセスを詳しく考察できる
- 直線的にプロセスを進んだり，ステップを飛び越えたり戻ったりできる
- サイトのグローバルナビゲーションが常に表示されているので，次に進むべきステップが分かる
- 選択が構成プロセスにどれほど影響を与えるかをはっきり理解してもらうために，さまざまなオプションがあると理解させるヒントを提供する
- 検索
- 補足型ナビゲーションの中心
- 自分の入れたキーワードで情報を探せるという理由から，ユーザに好まれる
- かなり詳細なレベルで結果を得られる
- 言葉の性質があいまいなため，たいていの検索体験には大きな問題が発生している
- 同じものを指していても，ユーザ，著者，情報アーキテクトと，それぞれが使う単語が異なる
- → Ch09
- 高度なナビゲーションアプローチ
- パーソナリゼーションとカスタマイゼーション
- パーソナリゼーションは提供側がユーザの望みを推測し、カスタマイゼーションはユーザが望みを提供側に伝える
- あくまでも既存のナビゲーションシステムの改善または補足に過ぎない
- 現実的な役割
- 一般的に重要ではあるが限られた役目を果たす
- 構造化と組織化の基盤がしっかりしている必要がある
- うまく生かすのは非常に困難
- 計量した数値を収集しユーザ行動を分析するのがさらに困難になる
- 効果的なパーソナリゼーションに必要な情報をユーザは提供しない
- Amazonで持っている本が表示される例
- 全ユーザの経験の操作は×
- カスタマイゼーションの問題
- 大部分の人々はカスタマイズに時間を費やしたくないと考えていて、本当に重要な数少ないサイトでしかそういう作業をしない
- ユーザ自身でさえ、明日自分が何をしたいのか分からないこともある
- 視覚化
- メタファーとして物理的な場を表示したり、ページ間の関係を示したりするのはそれほど有用ではなかった
- 選択が必要な要素の結果がどのように見えるかをユーザが知っている場合は、視覚化が最も有効
- ソーシャルナビゲーション
- 巨大なソーシャルネットワークの興隆により、ソーシャルナビゲーションは情報を構築するための重要な手段となっている
- ほかのユーザの行動を観察することで、ユーザは利益を得ることができるという前提にもとづいて築き上げられたもの
- 例
- トラフィックの量やユーザ主導の投票システムの実装によって、人気のあるコンテンツを見つける手助けをする
- ネットワークでつながった人々や端末が増えるのに従って、生成されるソーシャルナビゲーションシステムは劇的に複雑になり、洗練され、そして便利になる
- 組織は個々のユーザのニーズに合った情報環境のナビゲーション構造を構築する新たな方法を見つける
- 特定のユーザのソーシャルグループの好みにあまりにもぴったり一致したシステムは、ほかのものの見方を軽視しがち
- プレイスメイキングにおいては、グローバルナビゲーション構造が重要な役割を果たす
- Webサイトを訪れるとき、ユーザは共通する、変化のない構造をある程度共有する必要がある
- → バランスが重要
- パーソナリゼーションとカスタマイゼーション
- まとめ
- 進路を定め、現在地を把握し、帰り道を見つけるためにナビゲーションシステムを使う。
- ナビゲーションは前後の感覚を提供し、新しい場所も安心して探検できるようにしてくれる
- ナビゲーションの表層、つまりユーザが操作を行う部分は、非常に速く変化している
- ナビゲーションシステムにはさまざまなタイプがある
- グローバルナビゲーションシステム、ローカルナビゲーションシステム、コンテキストナビゲーションシステムの3つが一般的
- ブラウザなどの情報環境を探検するためのツールは、独自のナビゲーションメカニズムを提供する
- ユーザがシステム内で現在位置の把握を可能にするコンテキストの構築は、ナビゲーションシステムの重要な機能
- グローバルナビゲーションシステムは、情報環境においてすべてのページまたはスクリーンに表示されるもの
- ローカルナビゲーションシステムはグローバルナビゲーションシステムを補足するもので、これによってユーザは現在いるところを探検できる
- コンテキストナビゲーションシステムは環境内で表示されるコンテンツのコンテキスト内にある
- 項目間に定めた関係を発掘することで、ユーザの関連学習をサポートする
- サイトマップ、インデックス、ガイドなど、利用できる補足型ナビゲーションシステムにもさまざまな種類がある
- 進路を定め、現在地を把握し、帰り道を見つけるためにナビゲーションシステムを使う。
Ch09 検索システム
- 内容
- サイトに検索システムが必要かどうか判断する
- 検索システムの基本解剖学
- 検索しやすくするものとは
- 検索アルゴリズムの基本的理解
- 検索結果を表示するには
- 検索interface設計
- もっと学ぶには
- サイトに検索は必要なのか
- サイトにはコンテンツが十分にあるか
- ユーザがサイトにどんな情報を求めてやってくるのかが重要
- 求める情報がはっきりしているほど、検索機能の価値も上がる
- ユーザがサイトにどんな情報を求めてやってくるのかが重要
- より有益なナビゲーションシステムに集中しているか
- サイトの検索システムを最適化する時間とノウハウはあるか
- 検索よりもよい代替案があるか
- 技術的な制約がある場合など
- ユーザは検索を嫌がらないか
- 以上が注意や脅威、以下が実装のタイミング
- 情報が多すぎてブラウズしきれないとき、検索が役に立つ
- 大きな書店のようなイメージ
- 検索は断片化したサイトの役に立つ
- 最優先にすべきことは、組織横断的なコンテンツに対して、可能な限り全文テキストによるインデックス化を行う検索エンジンを設定すること
- 検索は学習ツールである
- ユーザが望むから検索はそこにある
- 探したいものが分かっておらず、ブラウジングで十分かもしれない場合も、とにかく検索してみるユーザ
- あって当然という期待
- 検索はダイナミズムを制御する
- 動的なコンテンツ → 検索システムを構築
- 検索エンジンが自動的にコンテンツにインデックスをつける
- サイトにはコンテンツが十分にあるか
- 検索システムの解剖学
- 何をインデックスするかを選ぶ
- 検索領域を作り、きちんと比較できるものが表示されるようにする
- ドキュメントやレコードの構造における要素の選択
- ふさわしいものを最初に検索し、そこで役立つ結果が得られない場合に、サイト全体を検索できるようにする
- まずは製品を検索し、見つからなければサイト全体を検索するなど
- 検索領域の決定
- ニーズに合わないコンテンツを除外
- サイトの組織化体系を選択する際に下した決断が、検索領域の選択の際にも役立つ(Ch06で開設した項目)
- コンテンツの種類
- 顧客
- 役割
- 主題/topic
- 地理
- 時系列
- 著者
- 部門/business unit
- ブラウジングシステムと同じく、検索領域も大きなコンテンツを細かくし、ユーザにサイトとコンテンツの見方を複数提供する
- 一方で、検索領域によって設定がさらに複雑になり、検索領域を使ってもらえないこともある
- ナビゲーション vs 目的ページ
- サイトを検索する際、ユーザは目的ページを探している
- 検索結果を得るプロセスの途上にナビゲーションページがあると煩雑になり、検索結果が分かりづらくなる
- ナビゲーション vs 目的ページというアプローチの問題点
- 本質的に厳密な組織構造の体系であり、ページの役割をナビゲーションか目的かに限定してしまう点
- 特定のユーザ層のためのインデクシング
- サイトのアーキテクチャにユーザ中心の組織構造の体系を採用しようと決めているなら、ユーザ層ごとに分けた検索領域の作成が〇
- インデックス動詞の重複が少なければ検索のパフォーマンス〇
- 主題によるインデクシング
- 最近のコンテンツをインデクシング
- インデックスをつけつコンテンツの要素を選択する
- ドキュメントの構造を開発・利用する
- コンテンツ要素がより正確な検索を可能にする
- コンテンツ要素が検索結果のフォーマットにも意味を持たせる
- → 検索結果をさらに柔軟に設計できるようになる
- パラドックス
- 最初の検索で高性能な検索機能を求めることはほとんどない
- ユーザが価値があると思っているほかの検索interfaceを研究し、それと同様の機能を提供するかどうか決めるのが〇
- ドキュメントの構造を開発・利用する
- 検索アルゴリズム
- information retrievalに関する標準テキストで詳細は求められる
- 本質的にはツールであり、特定のアルゴリズムが特定の問題解決に役立つ
- 全ユーザの情報ニーズを満たせる検索アルゴリズムは1つとしてない
- 検索エンジンの心臓部
- パターンマッチアルゴリズム
- 再現率と適合率
- 再現率 = 検索された適切なドキュメント数/適切なドキュメントの総数
- 高めると、良い結果とともに不適切な結果も大量についてきてしまう
- 適合率 = 検索された適切なドキュメント数/検索で表示されたドキュメントの総数
- 十分な検索結果が得られればほかの関連情報は要らない場合
- 精度の高さが望まれる
- 反比例の関係
- バランスが大事
- ユーザのニーズによる
- バランスが大事
- ステミング機能
- 同じ語幹を持つ単語を含めて検索
- 再現率が高まる
- 適合率は低くなる
- コンテンツがどれだけ構造化されているのかの考慮
- 構造の一部のみ見れば良い場合の方が精度〇
- 再現率 = 検索された適切なドキュメント数/適切なドキュメントの総数
- 再現率と適合率
- ほかのアプローチ
- クエリビルダ
- 検索結果の表示
- どのコンテンツ要素を表示するか
- 探し物が分かっている人には少なく情報を表示
- 象徴的コンテンツ要素、つまりタイトルや著作者などのみを表示して、求める結果を素早く区別できるようにする
- 何を探したいか分かっていない人にはより多く情報を表示する
- 記述的コンテンツ要素、つまりページの要約やキーワードなどを表示すれば役に立つ
- 何を表示するかユーザに選んでもらう方法もある
- ほとんどのユーザが見るのは結果のうち最初の画面だけ
- 検索結果についてどのコンテンツを表示するかは、各ドキュメントでどのコンテンツ要素が使えるか（どのように構造化されているかなど）にも、またコンテンツがどのように使われるかにも依存する
- 特に引き出すような構造がない場合や、検索エンジンが全テキスト検索をする場合は、ドキュメントのテキストからコンテキストの一部をそのまま表示するのも〇
- 検索用語を太字で強調など
- 探し物が分かっている人には少なく情報を表示
- どのコンテンツ要素を表示するか
- ドキュメントをいくつ表示するか
- ユーザのニーズに合わせて選べるようにさまざまな設定方法を提供する一方で、少ない結果を示すことで単純化し使い勝手を調整していくと、信頼できる検索結果となる
- ドキュメント1つ1つに対して少量の情報なら、得られる結果が多いほうがよいこともある
- 検索で得られたドキュメントの総数は必ずユーザに知らせる
- 検索ナビゲーションシステムの提供も考慮
- 検索ボックスでクエリを繰り返せるようにする
- 検索結果を一覧表示する
- どのような順番でユーザは情報がほしいのか、検索結果をどう使いたいかによって、並べ方が変わる
- 並び替え
- タスクを遂行する際に役立つコンテンツ要素で並び替えが現実的
- ランク付け
- 情報の理解や何かを学ぶ必要がある場合はランク付けの方が役だつ
- 一般的には、ドキュメントの関連性を高いものから順に示すために使われる
- 関連性は相対的なもので、ランク付けするアプローチも厳選が必要
- アルファベット順の並び替え
- 一般的な目的、とくに名前の並び替えには〇
- 時系列の並び替え
- 時間が問題、歴史的なデータを提示する場合に役立つ
- 関連性でのランキング
- 条件
- 獲得したドキュメント内に何回クエリ用語が出てくるか
- そのドキュメントにどれだけの頻度でクエリ用語が出てくるか
- クエリ用語がどれだけ接近して出てくるか
- どこにクエリ用語が出てくるか
- タイトルにある方が本文より〇など
- クエリ用語が出てくるドキュメントの人気度
- ドキュメントの内容が雑多なほど、関連性のランキングには注意が必要
- 人によるインデクシングでも関連性を確立できる
- キーワードと説明文の領域で検索して、日との判断した価値を利用
- 専門技術と時間とにかなりの投資が必要なので、best betのアプローチは実装コストが高くつく
- → サイトの全ユーザクエリの開発には適さない
- recomendationは、最も一般的なクエリに使われるのが一般的で、自動的に出てくる検索結果との組み合わせによって使われるのがほとんど
- 条件
- 人気度によるランキング
- ユーザまたは専門家の評価によるランキング
- ドキュメントとともにユーザ評価を表示すると役立つ
- 広告型検索サービス(Pay For Placement)によるランキング
- 結果のグルーピング
- 一覧にする方法はどれも完ぺきではない
- → 混合させるアプローチの方が上手くいくが、高度なレベルでツールに関わると、検索エンジンを制作する作業が必要になる
- 代わりに、得られた結果を何らかの一般的な観点によってクラスタリングする方法がうまく機能する
- 検索結果がカテゴリ別にクラスタリングされていると、一覧を評価の順番で並べたサイト同様にパフォーマンスが向上するという結果
- トピックやユーザ、言語、製品群などのメタデータを使って手作業で分類するのが効果的
- ただし手作業はコストがかなりかかる
- 図9-21: クエリをコンテキスト化
- 興味にあうカテゴリを選択 → 結果が大きく減る
- 検索の進行中に検索領域を作り出しているようなもの
- 検索結果を出力する
- コンテキスト分析とタスク分析のテクニックえ、ユーザが検索結果で何をしたいのか分かる
- 行動喚起（Call To Action）
- 個々の検索結果にCall To Actionボタンやリンクを含めるのが〇
- 例: アプリのインストール
- 結果のサブセットを選択する
- ショッピングカート機能など
- 検索の保存
- 定期的に動的に生成されるコンテンツのクロールなどには非常に便利
- 検索interfaceの設計
- ユーザと検索テクノロジの機能には幅広いバリエーション → 検索interfaceを設計する「正しい方法」は出てこない
- バリエーションの例
- ユーザの検索経験のレベルと動機付け
- ユーザの求める情報のタイプ
- 検索される情報のタイプ
- 検索される情報の量
- ユーザのニーズの推測が重要
- 検索がうまくいくかどうかは、主に検索エンジンとそのinterface、コンテンツがどのようにタグされ、インデックス化されているかにかかってくる
- → 検索interfaceはできるだけシンプルが〇
- シンプルな検索ボックスと「検索(Search)」というボタンだけユーザに提示する
- ボックス
- 検索システムを設計する際はテストを行うのが〇 ← ユーザは動作を仮定して考えるため
- ユーザが検索をやり直す必要を感じたときに、方法を伝えるようにする
- 本当に複数のフィールドが必要なとき以外は、検索ボックスは1つにしておくのが〇
- 複数必要な場合は分かりやすいラベルが必要
- 無味乾燥な小さい検索ボックスの背景には、数多くの仮定がある
- 設計においては、ユーザの持つ仮定を判断して、そのうえでデフォルト設定を決めるようにする
- オートコンプリートとオートサジェスト
- ユーザが最初に入力したいくつかの文字に遭いそうな結果の一覧が、検索ボックスのそばに表示される
- 検索インデックス、制限語彙、手作業で作成された一致リスト、またはこれらのすべてから選り抜かれたもの
- 表示はシンプルで直接的なテキストの一覧から、高度にカスタマイズされたレイアウトのポップオーバーまでさまざま
- 非常に有効なテクニック
- 一部、または不完全な情報をもとに、ユーザが合っているかもしれない情報を見つける手助けになるため
- ユーザは検索ボックスからシステムを探っていけるので、検索をより賢くしていける
- ユーザが最初に入力したいくつかの文字に遭いそうな結果の一覧が、検索ボックスのそばに表示される
- 高度な検索
- 探している情報の構造を理解しているユーザには、柔軟性とパワーを与える
- ほとんどのユーザが高度検索ページを訪れる必要がないよう、検索システムを設計するという目標を持つ方がよい
- 検索のやり直しのサポート
- ユーザがつまづいてしまったとき
- もっと知るためには
- 書籍
- Searchtool.com
- Search Engine Watch
- まとめ
Ch10 シソーラス・制限語彙・メタデータ
- 内容
- Webサイトのようなインタラクティブな情報環境は、システムが複雑に依存しながらつながりあった集合体
- ページ上の1つのリンクはサイトの構造の一部であり、組織化、ラベリング、ナビゲーション、検索システムの一部でもある
- これらがどのように関わり合っているかを考える必要がある
- システム間のネットワーク関係を見る際に、メタデータと制限語彙はすばらしいレンズを提供する
- さらに、シソーラスのデザインを行うことは、過去と現在との間に存在する溝を乗り越える助けとなる
- メタデータ
- Wikipediaからの引用
- 例
- データの作成方法
- データの目的
- データ作成の日次
- データのクリエイタまたは作者
- データが作成されたコンピュータネットワークのロケーション
- 使用された標準
- 例
- メタデータタグが使われるのは、ほかのコンテンツオブジェクトを描写するため
- コンテンツのナビゲーションと検索を向上させる目的
- 例
- HTMLのmetaタグにおけるkeywords属性
- 例
- 今日では、多くの企業はもっと洗練されたやり方でメタデータを使っている
- メタデータで動く動的なサイトは、分散型オーサリングとパワフルなナビゲーションをサポートするが、こうしたサイトの作成の手段としてコンテンツマネジメントソフトウェアと制限語彙が使われる
- メタデータ駆動型モデルを見ると、Webサイトの作られ方と管理のされ方が大きく変化したことがわかる
- 「分類学のどこにこのドキュメントを入れるか？」から、「このドキュメントをどう表現するか？」と質問できるようになった
- あとはソフトウェアと語彙システムが面倒を見てくれる
- 「分類学のどこにこのドキュメントを入れるか？」から、「このドキュメントをどう表現するか？」と質問できるようになった
- Wikipediaからの引用
- 制限語彙
- 語彙の制限は形も大きさも様々
- 最もあいまいなところでは、制限語彙は自然言語の中で定義された部分集合
- 簡単に言うと、制限語彙は同義語の輪の中にある適当な言葉のリスト
- 典拠ファイルのフォーム内の同意義用語のリスト
- 用語と用語の間に階層的な関係を定義すれば分類体系ができあがる
- 概念間の関連関係(see also, see related など)を規範にすればシソーラスに取り組み始めることになる
- 制限語彙のタイプ: 図10-1
- ↓ 単純→複雑
- 同義語の輪→典拠ファイル→分類体系→シソーラス
- 同義語の輪
- 検索を目的としたときに、同義の言葉であると定義された単語をつなげて1つのセットにする
- 適合率と再現率の問題
- 同義語の輪は再現率を劇的に高める
- 一方で適合率は下がる
- → interfaceデザインをよくし、ユーザの目標をうまく理解すれば、2つのバランスを取ることができる
- 検索結果の1番上には正確にキーワードとマッチした結果を並べる
- 一番最初の検索では同義語の輪を無視し、結果がほとんど不足しているときに、「関連する単語を含めて検索してください」と表示するオプションを加えるなど
- 制限語彙の単純かつ便利な形式
- 今日の多くの巨大な情報環境において、欠かせない基本的な機能
- 典拠ファイル
- 厳密な定義としては、優先語、すなわち条件に合う価値を一覧にしたもの
- バリエーションや同義語は含まれない
- 図書館や政府機関で広く使用され、制限範囲内のエンティティに適切な名前をつけることを目的としている
- 言い換えると、典拠ファイルは好ましいと定義された、または条件に合った価値がある用語を含んでいる同義語の輪
- オンライン環境で典拠ファイルを使うことと、その価値に関する問題
- バックエンドでの理由として、典拠ファイルがあれば、コンテンツの著作者とインデックス供給者は承認された用語を効率的かつ一貫性を持って使える
- 制限語彙管理の点から見れば、優先語があるおかげで類義語の追加、削除、変形を効率よく行え、同義語の中からどれを使えば良いか判定できる
- ユーザにとっては、教育的な面で役立つ
- スペルミス、業界用語の説明、ブランド名の認識など
- コンテキストが非常に異なる場合に、このような「レッスン」が役立つ
- クライアントが使った言葉を理解して、それを企業や業界で使われている用語に翻訳してクライアントに返す
- ユーザが検索からブラウジングに移る際にも優先語は重要
- 分類体系、ナビゲーションバー、インデックスの設計において、優先語を使える
- バックエンドでの理由として、典拠ファイルがあれば、コンテンツの著作者とインデックス供給者は承認された用語を効率的かつ一貫性を持って使える
- ポインタの使用: 用語のローテーション
- 調査と判断の上で、有効なインデックスのみ作成する
- 厳密な定義としては、優先語、すなわち条件に合う価値を一覧にしたもの
- 分類体系
- シソーラス
- 辞書の定義: 類義語と関連する概念の言葉のグループを一覧にした本
- ナビゲーションや検索を改善するために情報環境の中で統合化されたもの
- 語義に関する概念のネットワーク
- 単語とその類義語、同音異義語、反意語、意味が広い用語や狭い用語、関連用語などと結びついている
- オンラインDBの形となっていて、デジタル製品やサービスのUIと緊密に結合している
- 類義語を管理して、言葉のあいまいさを減らし、ほしいものを見つけられるようにする
- 定義
- 検索向上のために同義性、階層性、関連性を明らかにした制限語彙のこと
- これら3つの語義関係を基本にしながら、単純な制限語彙の構造物の上に成り立っている
- 技術専門用語
- 優先語(PT: Preferred Term)
- 変形語(VT: Variant Term)
- a.k.a. entry terms, non-preferred term
- 優先語に相当する言葉、または漠然とした意味での同義語と定義されている
- 広義語(BT: Broader Term)
- 優先語の親
- 狭義語(NT: Narrower Term)
- 優先語の子
- 同義語(RT: Related Term)
- 結合関係で優先語につながる
- See also
- 使用(U: Use)
- 変形語 Use 優先語
- 変形語 See 優先語 と同じ
- 優先関係(UF: Used For)
- 優先語 UF 変形語 の相互関係を示す
- 優先語に対する変化形の全リストの表示のために使われる
- スコープノート(SN: Scope Note)
- 本来、優先語を定義する種類のものではない
- できる限り言葉のあいまいさを除外して限定した意味を伝えることを目的として用いられる
- 優先語が語義の世界の中心
- 作動中のシソーラス
- シソーラスのタイプ
- 古典的シソーラス
- インデクシングシソーラス
- 検索シソーラス
- シソーラス標準
- 語義の関係
- 等価
- 優先語と変形語をつなぐ
- 類義語よりも幅広い用語
- 目標: 検索目的の等価として、用語をグループ分け
- ユーザに見つけてほしいと思うコンテンツに導く漏斗役となる収録語意を作り上げる
- 階層性
- 連想
- 同意義または階層関係内では捉えられない語義のつながりを強くほのめかすもの
- かなり主観的なプロセス
- sub type
- 研究領域と研究主題
- プロセスとその手段
- 概念とその構成要素
- 行動と行動結果
- 因果的依存につながる概念
- オンラインコマースでは、顧客と関連商品・サービスを結ぶよい手段となる
- クロスセル
- UEとビジネス目標の両方の向上につながる
- 等価
- 優先語
- terminology(用語学)は欠かせない
- 用語形
- 基本は標準に従う
- 標準がカバーしている問題
- 文法的語形
- 標準では名詞の使用が奨励されているが、動詞や形容詞を使った方が良い理由も多く存在する
- スペル
- 一貫性が重要
- 単数形と複数形
- 加算名詞は複数形の使用が〇
- 一貫性が重要
- 略語と頭字語
- 一般的な用法がデフォルト
- 文法的語形
- 用語選択
- 文語的な正当さとユーザにとっての正当さのバランスを解決するのに必要なのは、目標がなんであるかと、Webサイトにシソーラスがどう組み込まれているかを再確認すること
- 業界用語をユーザに教えるために優先語を使いたいか、入力語彙として優先語を頼りにしているか
- 用語の定義
- 挿入用語限定子(Parenthetical term qualifier)は同綴異義語を管理する方法を提供している
- e.g. Cell
- スコープノートも、意味をより限定するほかの方法を提供している
- 1つの概念に限定した意味を伝えるためのもの
- インデクサーが適切な優先語を選択するのに役立つ
- 検索の手段か結果として表示されて、ユーザの役に立つこともある
- 挿入用語限定子(Parenthetical term qualifier)は同綴異義語を管理する方法を提供している
- 用語の限定性
- コンテンツのボリュームが増すにしたがって、精度の高い複合語を使う必要性が増す
- 平行階層
- 大規模になれば避けられない
- 精度を高めるためのpre-coordination(複合用語を使って予め調整すること)を高レベルで行う必要が生じる
- クロスリスト
- e.g. Wikipedia
- ファセット分類
- ドキュメントとオブジェクトには多面性がある、つまりファセットがあるという概念の元にシステムを構築
- 旧式のモデルの問い: 「これはどこへ置けばいいか」
- ファセットアプローチの問い: 「どうこれを記述できるか」
- ランガナータンのファセット
- Personality, Matter, Energy, Space, Time
- ビジネスで一般的なファセット
- Topic, Product, Document type, Audience, Geography, Price
- フィールドを持つDBの構造を、Web上でより同質のドキュメントとアプリケーションの混合物に適用すること
- フリーサイズ型アプローチよりも、コンテンツの異なる面に注目した複数の分類学の概念に取り組んでいる
- e.g. Wine.com
- interface内でいつどのようにファセットを手段とするかについて決定
- merit: すばらしい能力と柔軟性
- 基礎をなす記述的なメタデータと適切な構造のおかげで、ナビゲーションの選択肢を何百通りも試せる
- ガイド付きナビゲーション: 発見しやすさと利益性が明確に直結している通販サイトですぐに採用された
- 展望
- まとめ
- シソーラス、制限語彙、メタデータは、フロントエンドのエクスペリエンスをシームレスでかつ満足できるものにするため、情報環境のバックエンドで運用される
- メタデータタグは、ドキュメント、ページ、画像、ソフトウェア、ビデオ、オーディオの各ファイル、またその他のコンテンツオブジェクトを説明し、効率よくナビゲーション、検索できるようにするために用いられる
- 制限語彙は自然言語のサブセットであり、同義語の輪、典拠ファイル、分類体系、シソーラスが含まれる
- これらのシステムによって言語を構造化、マップ化できるため、利用者はより簡単に情報が探せるようになる
- ファセット分類と平行階層によって情報を複数の方法で提示できるので、利用者は自分が探しているものを自分の方法で見つけられる
Part 3 information_architectureの仕上げ
- information_architectureを作り上げるためのプロセスとメソッドを追求していく
Ch11 調査
- 内容
- information_architectureの開発プロセスへの統合
- 人、コンテキスト、コンテンツを学ぶ方法と理由
- ステークホルダーへのインタビュー、実践的評価、ユーザテスト、カードソーティングを含む調査方法
- 開発プロセス: 調査→戦略→設計→実装→保守
- 調査
- 現在ある背景の情報をよく検討し、戦略チームとミーティングを行うことから
- 目的: 目標とビジネス上のコンテキスト、既存のinformation_architecture、コンテンツ、対象としている顧客をよく理解すること
- その後、情報の生態環境を探求するために、様々な手法を用いて一連の調査、検討を行っていく
- 戦略
- 設計
- 実装
- 保守
- サイトのinformation_architectureを継続的に評価し、改善する
- 新しいドキュメントに対するタグ付けや古いドキュメントの削除といった日常的タスク
- サイトの利用状況やユーザからのフィードバックのモニタリング
- 調整を通じてサイトを改善する機会を明らかにする
- 調査フレームワーク
- 適切な質問を選ぶための幅広い環境の概念的なフレームワークが必要
- コンテキスト、コンテンツ、ユーザのベン図でバランスを取る
- 適切な質問を選ぶための幅広い環境の概念的なフレームワークが必要
- コンテキスト
- ビジネスのコンテキストを調査することから始めるのが〇
- プロジェクトは、目標を明確に理解し、政治的環境を正しく認識するところから始めるべき
- 必要なものの入手
- プロジェクトにサポートを受けるためのプレゼンテーションと説得
- 背景調査
- 適切な人に適切な聞き方で適切なタイミングで質問する
- サイトの使命、ビジョン、目標、期待される顧客、コンテンツに関するものならどんなドキュメントでもよいので手を付ける
- マネジメント構造と企業文化の鳥瞰図を得られるようなドキュメントも見つける
- 特に組織図は、組織に対するユーザのメンタルモデルがどうなっているかという重要な要素を表している
- インタビューやテストを行う際に、どの出資者、ユーザグループに依頼すればよいかを決めるのに役立つ
- NOTE: ビジョンと実際のサイトとの比較の意義
- 導入のプレゼンテーション
- 調査ミーティング
- 戦略チームミーティング
- 難しいけれど必要な質問を質問しやすいと感じられるのは、顔をあわせた実際の会話の中でのみ
- 小規模で、自由な雰囲気で行うことが大切
- 議題
- システムの目標
- 期待されている顧客
- 計画しているコンテンツと機能
- アクセスのためのチャンネル
- 誰が作業にかかわるか
- いつ結果が必要か
- 予期している障害は何か
- コンテンツマネジメントミーティング
- 情報技術ミーティング
- 戦略チームミーティング
- ビジネスのコンテキストを調査することから始めるのが〇
