結果画面に於ける再絞り込みの要否としてヒアリングを行っていた、辞書引き機能のversio 2.0.2での改版内容ですが、早々に仕舞いにしました。ユーザの方からメールをいただいてようやく気付いたのですが、検索結果画面に於いて見出し語インクリメンタル検索という絞り込みを省略することは、ブラウザの履歴を「進む」「戻る」した場合に対応出来ないことを意味していました。
改版内容のおさらい
versio 2.1.1 (37-a publikigo, en 2008/02/08)
- 【仕様変更】JavaScriptが有効な環境下では、いかなる場合でも見出し語インクリメンタル検索（絞り込み）を実行するように戻しました。versio 2.0.2での仕様変更を見直し、元通りにしたものです。
- 【表示変更】見出し語インクリメンタル検索時、検索中の場合に表示する「通信中」という文面が、通信毎に重畳してしまう問題を是正しました。
後者は「通信中」の文面自体にID属性を与え、当該オブジェクトの存否を判断して「通信中」の追記要否を決めるようにしたものです。
問題は前者で、何ともお恥ずかしい改版内容です。
実装方法の割り切りが裏目に
検索結果画面というのは、当然のことながら或る検索語・一致条件で検索をした結果が表示されているわけで、わざわざ見出し語インクリメンタル検索で絞り込むのは無駄な処理だという考えは変わりません。検索語に文字列が入っていれば見出し語を常に絞り込める、という状態でなくなるので、先の記事の通りにアフォーダンス喪失の懸念があることも変わりません。
ところが、その実装がまずかったです。検索結果画面であるという条件を、何も考えずに「ドキュメント（HTML）が読み込まれた時点で検索語が入力されていること」としてお気楽に規定していました。ところが、ウェブブラウザの機能で履歴を「進む」「戻る」した場合には、フォームの内容はブラウザが復活させてくれることもあります。すると、例えば結果画面でなくてもドキュメント読み込み時に検索語が入った状態が成立しています。また、結果画面であっても、或る検索条件α（検索語・一致条件）の結果画面で、検索条件を変えて条件βとした場合には検索結果画面の検索条件と違うので、見出し語を絞り込むべきですが、これも同様に「進む」「戻る」をした場合に対応出来ません。
もししっかりと規定するならば、title辺りの文字列を解析し、検索語と一致条件を取得し、onload時の検索語・一致条件と同じであるならば絞り込まないという処理を講じる必要があります。
しかしどうでしょう、KISS原則: Keep It Simple, Stupidという標語もあります。「簡単にしときなさいよっ、ばかっ」（ツンデレ風味意訳）という金言ですが、そもそもアフォーダンスの観点で疑義がある処理にそこまで対処するのも考え物です。
こうして、見出し語インクリメンタル検索の一部省略という発想は、わずか8日間で命脈を絶たれたのでした。いやはや、もう少しテストケースの在り方を考えた方が良いなと恥じ入っています。
記事の配信