繰延べ式ハイパーテキスト：
先送りの満足感

ユーザは通常、リンクをクリックしたらすぐに反応が返ってくることを期待するが、このシナリオがうまくいかない場合もある。現在いくつかのシステムでは、その場でページビューが発生しないハイパーテキストリンクを利用している。結果の表示が、後回しにされるのだ。

繰延べ式のハイパーテキストの方が好ましい場合が、いくつか考えられる。

• ユーザインターフェイスのできが悪いと、ユーザは十分な操作ができない。繰延べ式ハイパーテキストなら、ユーザは簡単なリクエストをかけるだけで、ひとつにまとまった明確な情報ユニットを手にすることができる。複雑な画面やフォームを操作する必要はない。
• 画面表示がよくないと、じっくり読むのは苦痛になる。このシナリオでは、繰延べ式ハイパーテキストを利用することによって、ユーザは後ほど、もっと優れた画面で完全なテキストを読むことができる。

現状の繰延べ式ハイパーテキストシステムは、モバイル機器の非力なブラウジングインターフェイスを補うために電子メールを利用する形で機能していることが多い。だが、非力な画面表示と、読む時間がない場合に対応するため、こういったサービスは増加していくと思われる。

例えば、モバイル機器でブラウジングしている読者なら、記事やウェブサイトにマークをつけておいて、後ほどオフィスや家庭のフルスクリーンの画面でそれが表示されるようになっていれば、非常に役に立つだろう。もうひとつ、ユーザからある記事の繰延べ式リクエストがかかったら、それを自動的にオフィスのコンピュータにプリントアウトするようにしておくという応用方法も考えられる。オフィスに到着したらすぐ読めるというわけだ。ここにあげたアイデアはほんの一例であり、ローエンドのモバイルコンピューティングと固定式コンピュータ機器を結びつけるニーズは他にもたくさんある。

SMSのソリューション

現状、繰延べ式ハイパーテキストは、ヨーロッパの携帯電話ユーザの間で非常に人気がある。対話的に情報を探索すると言う点でWAP画面のナビゲートのしにくさを考えれば、大部分のユーザはSMSメッセージを送信して、回答は折り返しのメッセージで受け取る方を選ぶだろう。（SMSとは、携帯電話で送受信する短い電子メールのこと）

例えば、今チューリッヒにいて、ジュネーブ行きの列車の出発時間が知りたくなったとしよう。SMSを使って、列車情報サービスあてに「ジュネーブ」という言葉の入ったメッセージを送信する。同サービスからは、折り返し、この都市行きの次の列車数本分の出発時間が返信されてくる。このシステムでは、入力の負担を軽減するためにいくつかの条件を仮定している。出発時間は、数件あれば十分なこと。それも直近の列車の分だけがわかればよいこと。チューリッヒ発の時間だけわかればいいこと（私が利用したのはチューリッヒのサービスだけだが、他の大都市でも同様のサービスがあると思う）。

Blackberryでも同様のサービスを提供している。その多くは、複雑な企業データベースや、セールスオートメーションシステムを操作できるようにするというものである。

ユーザビリティ問題

SMSによる情報取得には、現代的な意味でのユーザインターフェイスがない。ユーザに許された行動は、コマンドを入力して、それを送信することだけだからだ。もちろん、コマンド言語には、それなりのユーザインターフェイスが存在する。SMSでの操作は、パンチカードのコマンドを利用する1950年代のバッチ処理コンピュータによく似ている。

SMSや、その他の電子メール方式のコマンドに関しては、基本的なユーザビリティガイドラインが4つある。

• コマンド認識には最大限の柔軟性を持たせること。バッチ処理システムにおいては、「コマンドがわかりません」という反応ほど頭にくることはない。人間とコンピュータの間のやり取りに時間がかかるからだ。柔軟性を持たせるには、以下に配慮すること。
  • すべてのコマンドが、「名詞－動詞」シンタックスと「動詞－名詞」シンタックスの両方に対応していること
  • できる限り多くの類義語を許容すること
  • 打ち間違いはスペルチェッカーで修正すること
• 省略形と同様に完全形のコマンドもサポートすること。Unixにはバカげた点がいくつかあるが、lsと入力しなければならないというのもそのひとつだ。listと入力してもダメなのである（こちらの方が覚えやすいのに）。
• 必要とあれば当て推量もしてやること。ユーザのコマンドを間違って解釈してもマイナスがないのなら、多少の当たり外れがあっても、打ち間違いの修正や、短縮形の読み取りについて当て推量をしてやるのがよい。例えば、ユーザが「シガコ」（Chigaco）の天気予報を聞いてきたら、シカゴ（Chicago）の天気を送ってやればよい。しかし、データベースにない株式略称で1万株の買い注文が来たからといって、一番似た名前の株券を買ってやるのはあまりいい考えではない。
• 必要な場合は複数の回答を返すこと。いくつかの解釈が成り立つ場合、あらためてユーザにどれか特定してもらうよりは、すべての可能性について回答した方がいい場合もある。回答があまりにも大量になって送信が大変だとか、読みきれないといった問題が生じるなら、もっとも可能性の高い回答とともに、次点の推量をいくつかメニューにして送信し、ユーザが選択できるようにしておく。

貧相な電話のキーパッドでユーザが間違って入力する可能性のあるコマンドすべてに対応するというのは、あまりにも難しい注文のように思える。だが、バリエーションの98％に対応するくらいなら、実現の可能性はかなり高い。問題をめぐって頭をひねるだけで、間違いの可能性の多くは予想できる。簡単なユーザテストをすれば、もっとたくさん見つかるだろう。例えば、そのサービスに問合せをかける時にどう入力するか、10人の人に書いてみてもらえばいい。最後に、現実世界のユーザ入力を知るために、継続的にログファイルを点検すること。私の経験では、実地に観察されたバリエーションを加えていくうちに、短期間でかなり高い認識パフォーマンスを発揮できるようになる。

繰延べか、半死か？

1995年に書いたウェブの背景理論に関する本で、私は「半死ハイパーテキスト」という言葉を使った。繰延べ式リンクが、生きリンクとも死にリンク（不活性の参照）とも違うことを指していった言葉である。半死リンクでは、ユーザの手仕事が必要になる。例えば、先にあげた私の著書が、タイトルだけ書いてあってリンクがなかったとしよう。ユーザは書店サイトか、もよりの図書館に行って調べるしかない。何の参照もない場合に比べればタイトルだけでも書いてあるだけまだましだが、半死リンクではコンピュータからの生き生きとした瞬時の反応は期待できない。「半死」と呼んだのはそういうわけだ。

この言葉がまったく広まらなくても、生 vs. 死のメタファーにはいくつかの利点がある。だが、今では私は「半死ハイパーテキスト」よりも「繰延べ式ハイパーテキスト」という言い方のほうが気に入っている。この新しい言葉から、重要な疑問が生まれてくる。すなわち：繰延べって、どれくらい待たされるの？

繰延べ式ハイパーテキストは生き生きしたインタラクションではないが、反応までの遅延の長さがそのサービスの有用性を左右する。あまり遅すぎると、ユーザはリクエストを出したことすら忘れてしまう。回答の中でそのコンテクストを再構築できなければ、回答自体が無意味になってしまう。こうなると、その情報は、繰延べというよりは死に情報に近くなるだろう。

2001年9月30日