4章 デザインパターン(前半)

 4章では,検索においてこれまで良く使用されている10個のパターンについてと,そのパターン相互の関係性について具体的に解説しています.この記事では,4章前半部分のオートコンプリート・ベストファースト・横断検索・ファセット型ナビゲーション・詳細検索・パーソナライズ機能を扱います.

抜き書き

  • オートコンプリート(Autocomplete)
    • (オートコンプリートが解決する問題は)第一に,文字入力には時間がかかること.第二に,ユーザーがスペルを間違えやすいこと.第三に,入力するキーワードが思いつかない場合が多いこと.(p.89)
    • 注目すべきなのは,オートコンプリートとオートサジェストは概念上は別物なのに,ほとんどのアプリケーションが省スペース目的でそれらを合体させていることだ.(p.90)
    • 視覚的なオートコンプリート(p.90)
  • ベストファースト(Best Frist)
    • (ベストファーストが重要な理由)第一に,結果の制度が高ければ,ごく単純な検索ならざっと眺めただけで目的を満たせる.
    • 第二に,上位数件の結果は,クエリーの再構成に多大な影響を及ぼす.
    • ユーザは,関連度も人気度も高く,しかもタイムリーな結果をほしがるのが普通である.(p.95)
    • ただ一つの基準でソートするのは,選択肢としてはあっても良いがデフォルト設定には向いていない.(p.95)
    • ベストファーストこそ検索においてもっとも普遍的かつ重要なデザインパターンなのだ.(p.98)
  • 横断検索
    • 婦談検索は,データモデルが異なる複数の情報源から集めた動的なコンテンツを扱う場合に必要となるだろうが,そこには課題が生じる.まず何よりも,パフォーマンスがとんでもなく悪化するおそれがある.(p.99)
    • 横断検索の実現によって,ファセット型ナビゲーションなどの高度なアプローチが難しくなる恐れもある.(p.99)
    • すべてのコンテンツを一つの統合されたインデックスにまとめて,断片化を解消してもいい.(p.99)
    • 横断検索が重要となる理由は,ユーザーがどこを探せばよいかしらないことにある.(p.100)
  • ファセット型ナビゲーション(Faceted Navigation)
    • キーワード検索に始まり結果一覧に目を通すまでの従来の流れの中で,統合的かつ漸進的検索とブラウジング体験を生むところにある.(p.102)
    • コンテンツとその体系についての深い理解をもたらし,次に役立つさまざまなステップを示すカスタマイズされたマップ(通常は結果一覧の左側に表示される)の役目も果たす.
    • ユーザーの行動とボックスが出会うところには,検索結果を絞りたいというニーズが必ず生じるからだ.(p.107)
  • 詳細検索(Advanced Search)
    • 詳細検索は往々にして,めったに使われない邪魔者でしかなく,エンジニアやデザイナーの手抜きを招く原因となる.(p.109)
    • 詳細検索は横断検索と同様に,僕らがさらなるアイデアを探し求めるきっかけとなり,さまざまな実験や探索をおおらかに認めてくれる活動の場として役立つのだ.(p.112)
  • パーソナライズ機能(Personalization)
    • パーソナライズ機能はカスタマイズ機能と混同されがちだ.(p.113)
    • ほとんどのアプリケーションでは大部分のユーザーがカスタマイズなどしていない.(p.113)
    • 過去に欲しかったアイテムに基づいて現在または未来の興味関心や購入意欲を予測しても,失敗に終わることが多いというのが一番の問題なのだ.(p.114)
    • 限られた状況でしか,過去の実績から未来の望ましい結果は予測できないだろう.(P.118)

 ここであげられているパターンは,全てが等価ではありません.横断検索や詳細検索は,パターン自体よりも,それが生み出す可能性のあるもの,インデックスの統合や革新的な検索方法(鼻歌による音楽検索・手書き画像検索・色検索),への期待から取り上げられています.また,パーソナライズ機能もオートコンプリートやベストベットのパターンとの相性の良さを説明しつつも,動的かつ明示的に検索結果を調整できるファセット型ナビゲーションのパターンが有用であるケースが多いと指摘されています.そして,オートコンプリート・ベストベットは普遍性の高い重要なパターンとされています.この特に重視されている2つのパターンの大学図書館蔵書OPACへの適用を考えてみます.

  • オートコンプリート

 現状,国内の大学図書館システムベンダー大手4社(NEC・リコー・富士通NTTデータ九州)でオートコンプリートの機能を有する蔵書OPACはありません.(3月1日追記.NECの図書館システム E-Cats Library にはオートサジェストの機能が含まれてました.サジェストの候補は数年間分の所蔵図書の書名・著者名のフィールドのデータを利用しているそうです.大谷の確認不足により失礼しました.)ただし,OPAC検索ログを使ったキーワード補完計画 - マイタンwiki で,近いことは試みられています.マイ探で試みられているように,蔵書OPACの検索ログを活用して,オートコンプリートは近いうちに実装されるかもしれません.この場合は検索語とその後にクリックした書誌の対応を調べることで,オートサジェストの機能も実現も考えられます.また,蔵書OPACをりようするということは,探しているコンテンツが図書・雑誌・論文といったものに限定されていると思われるので,タイトルフィールドのデータを利用してオートコンプリートの候補として活用できるのではないでしょうか?オートコンプリートというより,インクリメンタルサーチ - Wikipedia になりそうですが.

  • ベストベット

 先にあげた4社の蔵書OPACでは,タイトル・出版年・著者名・書誌IDなどいずれかの基準でソートした結果を表示させるようになっています.これをよりユーザーに最適な候補を上位に表示するにはなんらかのカスタマイズが必要です.一例として考えると,新しい情報を上位に表示するというのは,ユーザーにとって意味があることですので,これをベースにします.次に重み付けにつかえそうなデータは貸出回数です.ただ,単純に貸出回数を利用すると,古くから所蔵されている本が有利になります.同じ貸出回数でも,より最近借りられている本を重要と見なすなどの調整が必要となります.このほかに,大学ならではの教員のシラバス指定図書に重み付けをすることも考えられますし,パーソナライズが可能であるならば,ユーザーの所属する学部情報の活用や協調フィルタリングの手法をもとにユーザーに応じて表示順をカスタマイズできるはずです.

  • 所感

 OPAC同士の機能比較をするのは一部の研究者と図書館員だけです,ユーザーは比較するとしたら自分が普段利用しているGoogleなりAmazonとの比較のもとに,OPACを評価するはずです.この章のデザインパターンの様に,検索技術の世界で得られた知見をもとにきちんと取り込んでいく必要があると考えます.また,図書館のOPACについて考えるとき,ユーザーの労力を減らし,利便性を高めることは重要ですが,単館の所蔵目録の中から最適解とおぼしきものを提供するだけでなく,背後には単館の所蔵目録を越えた広範なコンテンツの世界があることをユーザに伝えることができるような検索サービスを提供したいと改めて思いました.