resume.dvi

CHI'99

ハイパーテキストブラウズ関連 論文調査

担当

:

志築 文太郎

([email protected]) 1999

年

6

月

1

日

はじめに

WWWページを閲覧する際に、以下のようなことに悩まされているように思う。  検索エンジンが出力するリンク集を閲覧する際、思ったようなページが取れてこずbackボタン を押すことが多い。  複数ページのデータを並列取得するために複数のブラウザウィンドウを開き、デスクトップをぐ ちゃぐちゃにしたりする。 この問題をシンプルに解決できないかと考えている。

この発表では、CHI'99の予稿集に掲載されている論文(technicalpap ers、demonstration)のうち、

上のようなハイパーテキストの閲覧問題をトピックとして扱っている以下の3つのシステムを紹介する。

 MITMediaLab.のWexelblat、MaesのFo otprints[6]

 XeroxParcのZellweger、Chang、MackinlayのFluidLinks[8]  AT&TResearchのAmentoらのTopicShop[1]

1 Footprints

MITMediaLab.のAlanWexelblat、PattieMaesの研究。

1.1

システムの目標

Fo otprints[6,5]はinteractionhistoryを利用したサポートシステムである。このシステムの主目的

は、digitalな世界におけるinteractionhistoryの有用性を検証することにある。

Interactionhistory

interactionhistoryとは、オブジェクトに人間が働きかけた結果生じる痕跡のことである。現実世界で

は、人間がオブジェクトに働きかけると、オブジェクトに何らかの痕跡が残る。本でいえば、dogear(ペー

ジの隅の折れ)、付箋、メモ、下線、開きやすくなったページなどが相当する。一方、digitalな世界で

たとか、どのWWWページからどう辿ったとか、といった情報はあまり利用することができず、それ

ぞれのユーザが独自に一から作業するに等しい。

Fo otprintsは複数人がWWW空間をブラウズした結果のinteractionhistoryを残せるようなシス

テムで、かつそれを利用したブラウズ支援ツールを提供するシステムである。 1.2 UI

構成要素

 SiteMap  PathMap  Annotations  Signp osts(道標、手掛かり) それぞれの構成要素はstaticではなくactive。協調して動作する。例えばひとつのツールでページを 選択すると、他のツール上で対応する部分がハイライトされる。SiteMap内のフォーカスもそれに合 わせて変わる。 1.2.1 SiteMap WWWサイト間のtraÆcをグラフ表現する。ノードはWWWページに対応する。リンクは、ペー ジ間のハイパーリンクに対応する。 ノードは人々(このシステムに接続している全ユーザ)が実際に訪れたことがあるページのみ。ハイ パーリンクを辿る、URLを直接入力する、ブックマークを選択する、等により閲覧したWWWペー ジを追跡する。結果として、WWWページに埋め込まれたハイパーリンクのうち、ユーザによって実 際に辿られたものをグラフのリンクとして表現する。さらに、WWW ページのp opularityをグラフ ノードの濃淡により示す。最もhotなWWWページは赤で示し、度合いに応じてピンク、そして白で 示す。現在WWWブラウザ内に表示中のWWWページに対応するノードは黒で表示する。 (あれ、WWWページリンクを辿ることなく、直接URL入力されたページで、WWWページから のハイパーリンクに含まれているリンク先ページにもなっているページはどう表示する? グラフが connectedでない場合にはどのように表示する。この論文のgureにそのような例はないようだ。)

グラフが巨大になってもブラウズ可能にするため、Hyp erb olic Browser[2 , 3]を用いてグラフ表示

を行う1 。 1.2.2 PathMap ユーザが、かつて、  あるWWWページにどう至ったのか  あるWWWページからどこに行ったのか というpathを表示するためのツール。全ユーザの全pathは膨大な数に上るので、あるひとつのWWW ページに関連するpathのみを表示する。開始ページを同じくするpathをマージすることによって、 1 以下のページにて、ぐりぐり動く の バージョンが体験できる。

木構造にする。線の太さを変えることにより、リンクが辿られる頻度を示す。太ければ太いほど、よ く辿られたリンクである。 1.2.3 Annotations WWWページ内に存在するハイパーリンクのアンカー部分に挿入された数字。そのリンクを辿った ユーザをパーセントで示す(そのページの参照数を分母とし、各リンクの参照数を分子にする??)。イ メージマップやapplet内のリンクにannotationを付けることはできない。 1.2.4 Signp osts コメント。

Path Map内のリンク内、およびノード内に表示されている円。lled circleはハイパーリンクや WWWページにコメントが付いていることを示す。op encircleには存在しない。他のシステムと異な

るのは、リンクにもコメントが付けられる点。この仕組みによって、分岐点の説明を付けることがで きる(と主張している。ページにのみコメントが付けられるようなケースでも可能だと思うのだが、ま

あ、よりstraightforwardなので良いか。)。ユーザテストでは、\Gothiswayforsoftwareagents;go thatwayforarticiallife"というコメントを付けていた。円がクリックされるとそのコメントを表示

するためのウィンドウを作成する。「AddComment」ボタンによって、ユーザはコメントを(追加)作

成することが可能。複数のコメントが付いている場合には、コメントは入力された日付によってソー トされ、最新のコメントを一番上に表示する。コメントは削除することができない(!!)。小さなコミュ

ニティではこの仕組みが機能するが、大きなコミュニティではさらに調査する必要がある。

1.3

システム構成

システムはfrontend、backendのふたつの部分に分けて作られている。

frontend UIを制御。proxyserverとして実現されている。

back end ずっと動き続けている。frontendでユーザがページ間を移動すると、その情報を受け取り、

データベースに蓄積する。全ユーザのブラウズデータをデータベースにマージする。マージする 際にはあるURLに対応するWWWページが有効かどうかチェックを行う(存在しない場合には どうするのか、よく分からない)。現時点では、プライバシーを保護するためfrontendから受け 取るデータを匿名化する。ユーザは他の個々のユーザがたどったパスを見ることはできない。 1.4

実験

実験結果の結論としては以下のふたつを導いている。  同じ程度の量・質のページ群を発見するのにあまり余計なページを見ずに済む。  経験豊かな被験者は、他の被験者によって作成されたデータをうまく利用して、楽にナビゲー ションを行うことができる。 タスク 20000$の予算があるとし、購買すべき乗用車をWWW上で探す(詳細は不明。適切な車のペー ジをブックマークに登録するのだと思われる)。時間は20分間。

被験者 参加費をもらう。被験者はNetscap e Navigatorに慣れている。被験者を2グループに分ける。

第1グループ(20人)は、通常のWWWブラウザのみを用いて探す。第2グループ(20人)は、 5分間のFo otprints使用訓練を受けた後に、Fo otprintsを用いて探す。その際のFo otprints用

データベースのデータは、第1グループがタスクを行うことによって生成された結果のデータを 用いる(かなり実験条件がずるいような気がする。他人のタスクと自分のタスクが全く同じであ るケースは現実的に考えられない。現実的には、他のユーザが「汚した」データベースを用いる ことになるはず)。なお、練習の際のデータベースのデータとしてはMedia Lab.で作成したも のを用いた。 1.4.1 評価 以下の4種類の評価を行った。  2種類の客観的評価 { 発見した車のモデル数 { 発見するのに要したページ数  2種類の主観的評価 { 結果に対する満足度 { タスクをこなす困難度、容易さ 客観的に評価に関しては、モデル数には特に差異が見られなかった。発見するのに要したページ数 は24.8から18.75に減少した。 主観的な評価に関しては、両モデル間に顕著な差異は認められなかった。しかし、同じモデル内で、 以前に同じ様なタスクを自分でこなしたことがあるユーザとそうでないユーザとを比較した場合、経 験者はインタフェースに高い満足度を示した。すなわち、他の人がブラウズすることによって構築さ れたデータベースの生成地図をうまく利用して、快適にブラウズすることができた。以前に車を探し たことのないユーザは、地図情報をどう利用していいのか、ということを把握するのに苦労している ようだ。 1.5

その他

JAVAで実装。どこでも動く。 ホームページはhttp://footprints.media.mit.edu/。このページにはデモも置いてある。しか し、私が試してみた限り、動作しない。 2 Fluid Links

XeroxParc(PaloAltoResearchCenter)にてPolleT.Zellweger、Bay-WeiChang、Jo ckD. Mackin-layが行った研究。

2.1

システムの目標

ハイパーリンクを選択する際に、リンク先のデータが自分の求めるものかどうか判別する材料が不 足し、辿ってみてから初めてページ内容が分かることが多い。この問題に対してFluidLinks[8,7]は、 リンクを辿るべきかどうか判断するための材料を、元ページの内容を読む妨げにならないように提供 することを目標とする。 2.2 UI

構成要素

gloss リンクを辿るべきかどうか判断して貰うために、行間に埋め込む簡潔な説明(文)。具体的には、 以下のようなものが考えられる。  リンク先ページの説明文(ページデザイン上の問題のような気がするが…)  リンク先とリンク元との関係の説明文(ページデザイン上の問題のような気がするが…)  リンク先内容(文、絵もありだと思う)の引用  リンク元に誰かが付けたannotation  リンク先ページの作者、作成日時、リンクのp opularity(どの程度の人がリンクを辿ったか)、 recommendationdata(??)などのメタ情報

uidlink ハイパーテキスト内に埋め込まれたリンクに対して定義されたglossを、もとのテキスト

文章を読むのに妨げにならないよう、表示するためのいろいろな技術。表示前と表示後の関係を 把握しやすいよう滑らかにアニメーション表示する。glossを表示するために用いる手法として は以下を用いる。  interline expansion  graphicalvariations { margincallout { textualoverlay { high-resolutionannotation なお、 uid linksの最初の形状は通常のハイパーリンクと同じ。すなわち、リンクの存在を示すた めにアンカーを何らかの形式(色を変える、ボールド、アンダーライン等)で強調する。クリックされ ると、現在表示中のハイパーテキストページを、リンク先のハイパーテキストパージに置き換える。 2.2.1 glossを表示する技術 interlineexpansion 操作数が少なく、視線をあまり動かすことなく、他の文書内容を覆い隠すこと なく、リンクの重要度を判別するための手段を提供する。具体的には、マウスポインタがハイ パーリンク上に来ている間、行間にスペースを空け、そのスペースにそのハイパーリンクに定 義されたglossを表示する。さらに、行間を空け、そこに情報を挿入するという表示はアニメー ションによって滑らかに行う。この表示技法をinterlineexpansionと呼ぶ。

margincallout 近隣の余白にglossを表示する。アンカーから、表示位置に指示線を延ばすことに

textualoverlay 行間を空ける代わりに、glossをページの内容に上書きする。その際には、glossを

濃く、ページ内容を薄くすることにより、それぞれの視認性をある程度保持できる。

high-resolutionannotation 解像度の高いディスプレイを用いる場合、小さなフォントでgloss自

体をアンカー部分に表示してしまうことも可能である。アンカー部分を示す機能自体も果たし、 かつglossが存在することも示せる。解像度の低いディスプレイを用いた場合でも、なんとなく 点線のように見えないこともない。 (いくつかの表示技術を併用するケースについては論じられていないように見える。) 2.2.2 glossに対する操作法 glossに関しては以下の基本操作が可能となっている。  展開したglossはクリック対象となっており、クリックされた場合には、ハイパーリンクがクリッ クされるのと同様に、現在表示中のページをハイパーリンク先のページに置き換えて表示する。  アンカーやglossからマウスポインタが外れたら、表示を元に戻す。  gloss表示中に、ユーザは別のボタンを押すことによって、glossを表示しっぱなし状態にしてお くともできる。  現在ページに定義されている全てのglossを表示する。 2.2.3 glossの内容 glossの内容としては主に以下のようなものが考えられる。 linkrelationship アンカー、およびリンクが存在するコンテキストのみでは、リンク先のページが 何を説明するものか判断できないことが多い。glossに各リンクの意図、リンク先ページの内容 の説明を含めることにより、ユーザが判断するための材料を提供する。 meta-information リンク先のページの作者、作成日時、リンク先ページの大きさ、リンクのp op-ularity(人気度、辿った人数)など。

completedestination リンク先のページ内容が短い場合には、その全てをglossとして表示するこ

とも考えられる。 (その他のglossとしては(複数人で作成した)annotation、辞書を検索した結果、関連WWWペー ジリストなどもありうるだろう。) glossの内容はリンク元のページの作者が作成する方法と、自動的に作成する方法が考えられる。自 動作成は、glossをup-to-dateに保てるというメリットがある。リンク先ページの内容変更を、リンク 元ページの作者の知らなくても大丈夫。ただし、上に挙げたリンク間の関係を自動作成することは難 しい。

またglossの作り方として、glossに更にハイパーリンクを定義することも考えられる。これを multi-waylinksと呼ぶ。そのハイパーリンクに更に uidlinkを定義し、階層的な uidlinkを作成すること

2.3

評価実験

なし。

(CHIにはビデオsubmission。ペーパーは2ページ。Hyp ertext'98の論文にもユーザテストらしき

ものの記述はなし。)

2.4

その他

ふたつの実装がある。

 UNIX上でPAD++とPythonを組わせ  Windows上でのC++

3 TopicShop

AT&T所属のBrianAmento、WillHill、LorenTerveen、PeterJuとVirginiaTech所属のDeb orah Hixが行った研究。

3.1

システムの目的

TopicShopはtopicmanagementを支援するシステムである。[1]はこのシステムの構成を示し、そ

の評価を行う。ここで、topicmanagementとはあるtopicに関して、情報を収集し、個々の情報を評

価し有用なものを選択し、分類することとする。

3.2

システム構成

ユーザがfrontendにseed siteを与えると、frontendがそれらをweb crawlerに送り、web crawler

は関連するWWWページを収集し、関連度の高いものをsiteとしてまとめる。収集が終了すると、そ

れぞれのsite のプロファイルを格納したMSWindowsのファイルを各site毎に生成する。そして最

後に全てのファイルをひとつのアーカイブファイルにまとめてユーザの使用しているマシンに送る(ど

うやって??)。

なお、web crawlerは収集経過を逐次frontendに送る。ユーザは収集途中でも、発見したsiteをす

ぐに参照することが可能。

3.2.1 web crawler

ユーザが指定したseed site群に関連するWWWsiteを発見し、ユーザが各サイトを評価するのに

役立つサイトのプロファイルを生成する。web crawlerはseedから張られているリンクのうちtopicに

関連しそうなリンクのみを辿る。seed site群と取得したsite群の中から、関連度の高いものをグルー

プ化する。各サイトのプロファイルも生成する。

(用語に注意。siteの定義が非常に分かりにくい。単独のページであることもあるし、いわゆる複数

のページの集合の場合もあるようだ。また、アルゴリズムはだいたい同じであっても、[4]とCHI99

的としていたが、こちらは既知のsiteのプロファイルデータを収集することを目的としている。した

がって、アルゴリズムの基本構造は同じであっても、パラメータや細部は大分いじっているように思 われる。)

seed site seedsiteとはそのtopicを扱っているWWW site群(例えば、Yaho oに登録されている

特定のtopicを扱ったページ群)。

アルゴリズム概要 [4]

queue := seed sites

while (there is a queue element with a score above threshold) do get the highest scored site from the queue

expand the site

merge new sites and links from the expands site into the queue re-organize and re-score the sites on the queue

end

(停止が保証されていないように思う…)

スコア 数多くのseedsiteからたどり着けるsiteがより有用なsiteであるとする。具体的には、site S

のスコアを以下のように定義する。

seed siteからリンクを1回か2回辿ることによってSにたどり着けるseed siteの数 merge& expand あるtopicに関連するページ群をひとまとめにしたい。以下のルールを基本とし

て、「同じsiteに属する」ページ群をひとつのsiteとする

URLAがあるページからリンクされており、かつURLA/Bがあるページからリン

クされている場合、Aをsiteのro otとし、A/Bはその内部ページとする。

具体的には、http://a/b/page1.htmlへのリンクを発見し、かつhttp://a/b/index.htmlがある

既知のsiteである場合には、発見したリンク先ページはその既知のsiteの一部とみなし、merge

する。

なお、http://x/yを解析中にここから http://a/b/index.htmlが属するsiteにリンクが存在す

る場合、site間のリンクを記録する。

その他の制約 expand時に、1つのsiteから取得するページ数はP(default=25)に制限する(この制

限は今回のシステムでは取り外されていると思われる。それにしても、元のシステムでは、制限 を入れることにより停止するのだろうか??)。

補助ルール www.geo cities.com内に作成したあるtopicに関連するページ群と、www.geo cities.comが

自分のサイトの案内用に持っているページ群とが一つのsiteとして認識されてしまうのを防ぐ

ために、以下のルールを適用する(きちんと実装されていないように思われる。)。

siteのトップページにしては、あまりにも多くのページからリンクが張られていると

(やっぱり怪しい。論文には[4]と同じアルゴリズムを使ったと書いてあるが、実際にはこの「古い」 アルゴリズムを改造し、パラメータをかなりいじっているように思われる。恐らく、新しいsiteを発 見しても辿らないようにし、かつ、一つのsiteの中はURLのパスを深くする方向にいくらでも深く 探索を進めて行くようにしてあると思われる。) プロファイル site毎のプロファイルとして以下の情報を記録する。  siteのro otページのタイトル  siteのro otページのサムネイル  他のsiteへのリンク  ページのHTML数  イメージ、音声、動画ファイルの数 3.2.2 frontend

ユーザがweb crawlerにseed群を与えるためのインタフェース。

3.2.3 TopicShopExplorer

各サイトのサムネイル、および各サイトのプロファイルを閲覧し、分類するためのインタフェース。

MSWindowsのExplo ereをカスタマイズしたもので、detailsview、およびiconsviewというふたつ

のビューを提供する。 目標は以下の3つ。

Make relevantbut invisibleinformationvisible. ページタイトルやアンカーに書かれたテキス

ト程度のみの情報ではそのsiteを参照すべきか否か、判断するのは困難である。数多く他siteか ら参照されている、ある特定のコンテンツを多く含む(イメージ、音声データ)、といった情報が あると判断しやすい。また、以前参照したことのあるページであれば、サムネイルが役立つ(タ イトルも役立つだろう)。 これを実現するために、detailsviewにプロファイル情報を表示し、さらに両ビューにおいてサ ムネイルを表示する。

Make itsimpleforusersto explore andorganizeresources. siteを様々な性質によって分類

し参照すべきサイトを選定する、という作業を支援する。

details viewではMSWindowsのExploreのインタフェースを用いて、prop ertyに基づいてサ

イトを並べ替えることが可能になっている。適当な位置で右クリックすると、そのデータがどの ようにして得られたのか、詳細なデータを表示することができるようになっている。例えば、あ るsiteのInLinksの部分で右クリックが発生すると、そのsiteを参照しているsiteのリストを

表示する。あるsiteがダブルクリックされると、WWWブラウザにそのsiteを表示する。

分類は、iconsviewに置いてサムネイルを配置すること、およびフォルダーを両方のビューにお

適切な分類を認識している場合には、フォルダーを作成し、siteを適切なフォルダーに仕分けす

ればよい。しかし、その分類が分かっていない初期段階では、分類自体を発見するためにicons viewにおいて並べてみると良いだろう。

Integratetopicmanagementintoa user's normalcomputingandcommunicationenvironment.

なるべく既存の慣れ親しんだインタフェースに近づけることにより、学習に要する時間を短縮 し、既存のインタフェースで培った技術を応用できるようにする。さらに、既存のデータ共有方 法も利用できるようにする。

TopicShopは、MS WindowsのExploreと同じインタフェースとして実現している。さらに、 Windowsのファイル、フォルダーをそのまま用いることによって、複数人でデータの共有が可

能となるようにしてある。

3.3

実験

Yaho o/b o okmarks併用、およびTopicShopとの比較を行う。被験者があるtopicに有用なsiteを

集めるのに要した労力、および集めたsiteの有用性を判定する。

タスク ある決められたtopicを扱ったsiteのうち、\b est"なものを15選択し、ランクづけする。こ

こで\b est"なsiteとは、\sitesthatcollectivelyprovidesausefulandcomprehensiveoverview forsomeone wantingto learn ab outthetopic"としている。制限時間は45分間。45分以内に

満足する結果が得られたらそこでやめてOK。WWWの使用目的の多くはホビー関連であるた

め、以下のふたつをtopicを選択する。

 Homebrewing(ビールの自家醸造)

 Buy theVampireSlayer(ホラーテレビ番組、実写、oÆcialsiteあり 2 ) それぞれにはYaho oのカテゴリーが既に存在し、それぞれに約60のリンクが定義されている 3 。 被験者 16人のボランティア。研究所のメンバー。TopicShopは使ったことがない。4人ずつ4グルー プに分ける。各グループは、1つのtopicを割り当てら1つのインタフェースを用いて探索する。 (4人は少ないだろう。ひとりでも特異な結果を出すと全体に影響が及ぶ…。) 3.3.1 評価 被験者が選択したsiteの質は、専門家(!!)が選択したsiteとの合致度とする。まず、それぞれの topicの専門家にその約60のsiteから良いものを20選択して貰う。その結果、それぞれのtopicで共

通して選択されたsiteは12つづあった。この12のsiteと被験者が選択したsiteとを比較する。 TopicShopの方が、余計なサイトを参照することなく、クオリティの高いサイトを見つけ出すこと

ができた(表1)。

被験者が実際に辿ったsiteの平均数 あまり差はないが、TopicShopの方が一応小さい。

被験者が選択した15site中、専門家が選択したものに一致した数 TopicShopが高い数値を示した。

ランダムに選択した場合、Averageover Topicの期待値は3である。Yaho oを用いた場合には

ほとんど良くなくて、TopicShopを用いた場合には良好だと言える。 2

被験者が実際に辿ったsiteの平均数 46 36 被験者が選択した15site中、専門家が選択したものに一致した数 4.6 8.4 被験者が共通して選択したsite数 2.5 9.5 表 1: 選択結果 in-link 3.00 title 2.75 pages 2.00 out-link 5より大 image 5より大 audio 5より大 表2: 各prop ertyの有用度 各被験者に共通して選択されたsite数 TopicShopは良好。 3.3.2 被験者の取った戦略

実験後のインタビュー時、TopicShopを用いた被験者に、各prop ertyの有用度をランクづけして

貰った。被験者は各prop ertyに1(mostuseful)から7(lessuseful)までの数値を与える(表2)。

このうち、titleはsiteの有用度を判定するのに役立つのではなく、siteを覚えておくのに役立てて

いた。したがって、in-linkの数、およびpagesの値がsiteの有用度判定に有効だった。

観察の結果、Yaho oとTopicShopでは、以下のような戦略の差が見られた。

Yaho o 被験者は大抵は順々にsiteを見て行く。annotationを読んで戦略をたてる被験者も数人いた

が、annotationがあまり役だたないと判断し、結局順番に見てゆくという作業を繰り返すよう

になっていた4

。

TopicShop 被験者は有用そうなprop ertyに対して、siteをソートしては上位に来たsiteをいくつか

調べ、別の有用そうなprop ertyについて同様に調べる、という作業を繰り返していた。

3.4

その他

frontendはJAVAのAppletとして実装。TopicShopExplorerはMS WindowsのExplo ereをカ

スタマイズしたもの。

4

テレビ番組の方では、annotationなしのものが多かったり、書いてあっても\screenshots,sounds,p olls,pictures,and more."とか\BuytheVampireSlayerbulletinb oard."ばかり。Homebrewingの方は、\comprehensivesiteofbrewing resources."とか\b eerrecip es,chat,etc. "。

参考文献

[1] BrianAmento,WillHill,LorenTerveen,Deb orahHix,andPeter Ju. Anempiricalevaluationof user interfaces fortopic managementofWeb sites. InProceedings on ACMCHI'99Conference on HumanFactorsinComputing Systems,pp.552{559,May1999.

[2] JohnLampingand RamanaRao. Laying OutandVisualizing LargeTrees Using aHyp erb olic Space. InProc.ofthe ACMSymposiumonUserInterfaceSoftwareand Technology,pp.13{14, 1994.

[3] JohnLamping,RamanaRao,and Peter Pirolli. A Fo cus+ContextTechniqueBased onHyp er-b olic Geometryfor VisualizingLarge Hierarchies. InProceedings on ACM CHI'95Conference on HumanFactorsinComputing Systems,1995.

[4] Loren Terveen and WillHill. Findingandvisualizing inter-site clangraphs. In Proceedings on ACM CHI'98Conferenceon Human Factors in Computing Systems, pp.448{455,April 18{23 1998.

[5] Alan Wexelblat. History-based to ols for navigation. In IEEE's 32nd Hawai'i International Conferenceon SystemSciences (HICSS'99),1999.

[6] Alan Wexelblat and Pattie Maes. Fo otprints: history-rich to ols for information foraging. In Proceedings on ACM CHI'99 Conference on Human Factors in Computing Systems, pp. 552{ 559,May1999.

[7] Polle T. Zellweger, Bay-Wei Chang, and Jo ck D. Mackinlay. Fluid Links for Informed and IncrementalLinkTransitions. Inhypertext98,pp.20{24,June1998.

[8] Polle T. Zellweger, Bay-Wei Chang, and Jo ck D. Mackinlay. Fluid Links for Informed and IncrementalHyp ertextBrowsing.InExtendedAbstractsonACMCHI'99ConferenceonHuman FactorsinComputingSystems, pp.7{8,May1999.