「インタラクション2000」平成12年2月

自由ストロークに基づく電子白板システムのためのソフトウェアアーキテクチャ
五十嵐健夫†，WKeithEdwards‡，AnthonyLaMarca‡，ElizabethD．Mynatt‡
5: Xerox PARC

†東京大学情報工学専攻，3333CoyoteHillRd．PaloAlto，CA94304，USA

東京都文京区本郷7−3−1＋1650−812−4405

03−5841−7413
ねkeo＠mtl．t．u−tOkvo．ac．jp

kedwards，1amarca，mynatt＠parc．xerox．com
な違いは、従来のシステムが文書生成といった

1．はじめにアウトプットを志向した活動の支援を目的としホワイトボードはオフィスにおいて最も重要ているのに対し、我々のシステムはアイデアの書き留めといった、より創造的な活動を支援すな役割を果たしている道具の一つである。メモを書き付けたり、スケッチを描いて考えを整理したり、文章を練る際に要点を書き留めたり、ることを目的としている点である。

同僚との議論の際に使用したりと様々な目的に使用される。デスクトップコンピュータが分析や清書といったアウトプットに近い作業に使われるのに対し、一般的にホワイトボードはより思考に近いレベルでの創造的な活動に使用されていると考えることができる［16】。

我々は、このような観察に基づき、計算機によって機能を強化された電子的なホワイトボー

ド（電子白板，通称Flatland）の研究開発を行っている。本研究の目的は、「手書きの線を書き付

図1：Flatlandシステムの画面例

けるだけ」という本来のホワイトボードの簡便より詳細には、本システムは以下のような3さを失うことなく、情報の保存や計算・図の整つの大きな特徴を持っている。まず第一に、創造的活動を支援するために、入力はできるだけ形といった計算機によって可能となる拡張能力を付加していく手法を確立することである。こ簡単なもの、出力はできるだけインフォーマルのような電子白板は、現在使われているデスクな形のものを採用している。具体的には、従来のGUIでは、ユーザの入力はマウスによるGUI

トップコンピュータでは困難な、柔軟な知的活動の支援が可能になると期待できる。
本稿では、【17】で紹介されたFlatlandの機能

部品の操作あるいはキーボードによるものであったが、本システムではより 軽い 入力方法を実現しているソフトウェアアーキテクチャー

である手書きストロークのみを入力とする。同様に、従来のGUIにおいて表示されるものはについて詳しく説明する。
本稿で提案するソフトウェアアーキテクチャ

整形されたテキストや詳細にデザインされた部

は、デスクトップコンピュータで使用されてい品であったが、本システムでは柔軟な発想を妨るマウスとキーボード入力に基づいたGUIシ

げないようユーザの入力からシステムの出力まステムの、ペン入力版と見ることができる。通ですべて自由ストロークの形で表現される。す常のGUIシステムと同様に、我々の紹介する

なわち、本システムでは、入力から内部表現、出力まで一貫して「自由ストローク」を基本単位として処理されている。

システムも画面全体をいくつかの領域に分けて使用する機構や、それぞれの領域内で特定の計算機能を付与する機構を提供している。基本的An Ink−Oriented Software Framework for
Personal Electronic Whiteboards， Takeo

Igarashi（UnivlOf Tbkyo），W，Keith Edwards，AnthonyLaMarca，Elizabeth D．Mynatt伍erox

第二に、形のはっきり定まっていない創造段

階での情報操作を支援するために、操作対象の情報とそれらの持つ内部構造の間の関係が非常に柔軟になっている。具体的には、通常のGUIシステムにおいて静的な関係であったウインド

PARC）

−213−

ウとアプリケーションに対し、本システムにおるのに対し、我々の研究はmamerらの研究といては情報素（自由ストローク）の集合関係（作業領域の区切り）は必要に応じて変更可能であ同様にペンを利用した多様なアプリケーションを動かすための基本的なフレームワークを対象としている点を特徴とする。

り、また個々の作業領域に割り当てられたアプ

従来のGUIの枠組みにかわるインタフェース

リケーションは取り外しや付け替えが可能となっている。

のためのソフトウェアフレームワークに関する

最後に、ホワイトボード上での長期的な活動を効率的に支援するために、自動的な情報の保存、およびコンテクスト情報による検索機能をいったものが挙げられる。

提供している。従来のデスクトップシステムで3．エーザインタフエース

ものとしては他にPad＋＋［1】やMagicLens，【2】と本節では、ユーザからの視点でシステムの動は、ユーザは明示的に文書をファイルシステム

作を概説する。細かい動作およびデザイン上のから取り出し、編集し、また保存するといった作業が必要であった。しかし、このような操作は、「手書きでメモを取る」といった処理が主体

議論については【17］を参照のこと。

の電子自板においては手間がかかりすぎる。本3．1． 基本操作システムでは、あらゆる時点におけるすべての本システムは基本的には従来のホワイトボー

画面上のストロークが自動的に時間や色といっ

ドと同様に動作する。すなわち、ペンでボード上に自由に線を措くことで入力を行う。措かれた付加情報とともに記録されており、明示的な保存操作をすることなく、後から取り出すことた線は空間的な近接関係に基づき自動的にグループ化される（図2a，b）。グループ化されたストロークはセグメントと呼ばれる作業領域を構成すが可能となっている。
以下、関連研究について述べた後、システム

る。セグメントをまたぐ線を引くと、それらのの動作について簡単に説明し、ついでアーキテ

セグメントを融合することができる（図2c）。一方、
ペン上のボタンを押しながら線を引く（具体的なクチャについて各特徴毎に詳細な説明を行う。
最後に実装について触れ、結論を記す。

機構はハードウェアによる。マウスにおける右2．関連研究ボタンに相当）ことで制御ジェスチャが入力され本研究に非常に関連の深いものにKramerの［10］および【11】がある。これらは、従来一対一であった画面上の表現（ここではストローク）と計る。制御ジェスチャでぐちゃぐちゃした線を措
くとその下にある線の消去が消去される。またセグメントを横切る線を引くことでセグメント

算機内部での解釈とのつながりを一対多にして、同一の表現の柔軟な構造化【10】、および多様な計の分割が実現される（図2d）。

算処理の適用を可能にする枠組みを示したもの

御車轡

で【11］、本研究の出発点となるものである。本研a）Joiningtoanexistingsegment

究では、先行研究の発展として、具体的なアプ

衛妄鷲i中漸b）Assigninganewsegment

リケーションの例を数多く示す他、、画面領域の￠も皇＿ qlらoqd）segmentspLitting

管理方法ヤアプリケーションの動作など具体的な問題についてより詳細な検討および提案を行C）segmentjoiningう。

図2：ストロークのグループ化処理

ペン入力を用いた計算機システムの関する研究は数多く存在している。すでに商業化されてセグメントの囲いの上から制御ジェスチャを開始することで、移動が実現される（ドラッグ操いる文字認識に関するものの他に、ペンによるテキストの高速入力【18】やジェスチャ入力【9】に作）。領域同士の重なり合いを防ぐため、他の領関するものがある。システムとしては、創造的域にぶつかった場合にはその領域を押しのけ、さらに場所がなくなるとその領域は押し潰されて小さくなる（図3）。小さくなった領域は、そのな活動を支援することを目的としたものが様々な応用分野で提案されている他【14，6，23，13］、会議での利用を想定した電子白板システムが多く上で作業を開始すると、もとの大きさに戻る。
その他、カーテンを引くようにして隣のパネル開発されている【8，19，15】。これらの研究が主に

特定の入力手法を提案するものであったり、特に移動するといったことも可能となっている定の作業のためにデザインされたシステムであー214−地図描画：線を引くと、自動的に2本の線からなる道路が措かれる。交差点や消去操作等も適切に処理される（図6）。

辿っ堅車≠a）standragging b）pushingaway c）squashing
図3：領域の移動と押し潰しa）Addinganew streetb）Erasingastreet

図6：地図描画
制御ジェスチャによるタッビング操作により

図4のようなパイメニュー【22】が表示され、undo
やredo，アプリケーションの付与といった操作

幾何図形描画：手書きの自由ストロークを自動を行うことができる。これはマーキングメニュ

や次の描画操作の予測等も行う［12】（図7）。

的に整形して提示する。複数の候補の自動生成ーとしても動作するので、慣れたユーザは短い＜少侭△′申脱線を制御ジェスチャにより各方向に向けて引くだけでコマンド操作を起動できる。
Remove application
Changeco10r
Undo

図7：幾何図形描画

Redo

Time sliderb）Predictiona）Beautific由tion

Deletesegment

3次元描画：入力された2次元図形が3次元物体が生成される。手書きストロークによる切断や−Tbkesnapshot

突起生成といった編集も可能【13】（図8）。

Attachapp［ication
図4：パイメニュー

ひ○ゆ0㊥〔少83．2． アプリケーション
Flatlandは、上記のように単に手書きストロb）Cuttinga）Creation
図8：3次元描画

ークを書き付ける機能に加えて、さまざまなア
プリケーションを走らせることができるようにって明示的にセグメントに対して付加される。

計算機：手書きの数式を入力として計算を行う（図9）。長い横線が措かれると、その上にある数

通常のウインドウシステムと異なり、このアプ式を認識して計算する。手書き文字認識を利用なっている。アプリケーションは、ユーザによしている。計算結果は辛が気風に表示される。

リケーションは随時取り外しおよび付け替えが／之000．

可能である。また、アプリケーション毎にボタ㊥十もも00 望

ンやメニューが表示されるのでなく、通常の描画操作に対して各アプリケーションが適切な処理を行なう。以下に現在実装されているものを列挙する。

a）userjnputa）Addinganewitem／ぎも00b）systemoutput

Flatlandにおけるユーザの操作はすべてシス□UfST ロUIST ロUIST ロCHl
ロ▼3．3． 履歴管理

ャで順番を変更したり、項目を削除したりすることができる（図5）。

島cHl少□UISTロ■ ￣＝＿＿：￣ ▼ ▼図9：計算機

リスト管理：縦に並んだ手書きの項目の列を管理する？小さい四角を起点とする操作ジェスチ

口C…．中ロCHl／之000

テムによってコンテクスト情報と共に自動的に記録され、後から取り出すことができるようになっている。
一つの方法は、スライダーによって領域や画ロ

面の状態を任意の時点に逆戻しするものでありb）reorderingitems【21】（図10左）、もう一つは時間や位置、色などのコンテクスト情報を元に検索するものである。

図5：リスト管理−215−

を設定すると、検索結果が縮小表示される（図10

画面上のストロークはグループ化されて、セグメントとして管理される。セグメントは移動や押し潰しなどの領域管理の基本となる他、ア
プリケーションの付与や検索の際の単位となる。
セグメントは、互いに重ならない、自由に分割

右）。

されたり統合されたりするいった点で通常のウ

これにより、作業の度に明示的に保存振作を行うことなく、「先週、右の隅に措いた地図」といった情報を取り出すことができる。現在の実装
では、表示されるボタン類を操作して検索条件

インドウと異なっている。

セグメントには任意の処理モジュールを付与することができる。処理モジュールは特定のサービスを提供するもので、セグメントでおきたイベントを監視し、適切な処理を行う。一つの．耶一望翫庇

セグメントに対しては、常に一つのアプリケー■㌻Hl

ションレベル処理モジュールと、複数の基礎処
理モジュールが付与されている。アプリケーシ

ョン処理モジュールは、ユーザが直接選択する
ことのできるアプリケーションに相当するもの

図10：時間およびコンテクスト情報による検索である。基礎処理モジュールは、入力中のストロークを画面に表示したり、セグメントの枠を表示するといった基礎的なサービスを提供する。

4．アーキテクチャ

本節ではアーキテクチャの全体像を示し、以GUIシステムにおけるウインドウとアプリケー

下の節で各特徴について詳しく述べる。

ションの関係が固定的なのに対し、セグメント⊂：：：コdApplicationbeha血rと処理モジュールはセグメントから動的に取り⊂＝コiEmbedd∝柏融avior

除いたり付加したりすることができる。
入力されたストロークは、まずルートセグメ
ントによって対応するセグメントに分配され、ついでそのセグメントに付与されている処理モ
ジュールに分配される。処理モジュールは必要に応じてセグメントによって管理されているス

トロークの集合に変更を加える。
5．ストロークを基本単位とした入出力
Flatlandはストロークを中心とした設計となっている。ユーザの入力はすべて自由ストロー
Eventsクによって行われ、システムのフィードバック（処理結果の提示など）はすべてストロークの集合として表示される。これによって、システム

図11：アーキテクチャの概要

内部の処理はすべてストロークを対象とした計全体像を図11に示す。ルートセグメントが複数のセグメントを管理し、セグメントは各種の算処理として記述することが可能となる。さらに、システムが処理結果として生成したストロ処理モジュール（Bebavior）とストロークの集合

ークをさらに後の処理への入力として使用するを管理する構造になっている。

といったことも自然に実現される。

システム全体を通してストローク（具体的には
点列で表現される折れ線）を基本的な情報の単位として取り扱う。ユーザの入力、画面表示、内部での表現がすべてストロークを基本として表

5．1． 入力ストロークの処理
ユーザがストロークを措き終えると、まずルートセグメントがそのストロークの送り先とな現され、計算処理はストロークの集合に対する編集操作として記述される。これは、アプリケ
ーション固有の内部表現を基本とし、画面表示

るセグメントを検出する。もし入力ストロークが単一のセグメント内に含まれている、あるいは十分に近接している場合には、そのセグメン

やユーザ入力とはまた別の表現を用いている通常のGUIシステムと対照的である。

トが送り先になる。近くにセグメントがない場−216−

を行うことが可能となる。

合には、新しいセグメントを生成してそこを送り先とする。もし2つ以上のセグメントにまた
6．取り外し可能な処理モジュール

がっている場合には、それらのセグメントを融合し、できあがったセグメントを送り先とする。

Flatlandにおける処理モジュールは、ウイン入力ストロークを受け取ったセグメントは、

ドウシステムにおけるアプリケーションに近いが、いくつかの重要な違いがある。

それをそのままセグメントの管理するストロー

まず、通常のウインドウとアプリケーション

ク集合に加えるのではなく、セグメントに含まれているアプリケーションレベル処理モジューの関係は静的で、システム動作中に関係が変化

ルに処理を委託する（具体的には、することはないが、処理モジュールは動的に取addInputStrokeメソッドが呼ばれる）。アプリ

り外しおよび付け替えが可能である。次に、ウケーションレベル処理モジュールは、必要に応インドウに対応するアプリケーションは通常1

じて、セグメントに表示ストロークを加えたりつであるが、セグメントは複数の処理モジュー

変更したりする。このような構成とすることで、ルを持つことができる。最後に、ウインドウの低レベルでの動作を気にすることなく、基本的

視覚的な表現はアプリケーション固有の描画ルにはaddInputStrokeメソッドを記述するだけ

ーチンで生成されるが、セグメントではストロでアプリケーション処理モジュールを設計することができるようになる（図12）。

ークの集合として統一された方法で管理される

6．1． イベント処理
各種の異なる処理モジュールに対して、イベントを知らせるために、Javaにおけるイベント
リスナーによる実装を採用している。
SurfaceListenerはセグメントの移動や分割統合といったイベントを受け取る。ほとんどの基

礎処理モジュールはSurfaceListener を実装している。StrokeListenerはユーザによって措かれたストロークを処理するためのもので、アプ
リケーション処理モジュールに必ず実装されている。MetaStrokeListenerは制御ジェスチャー
を処理するためのものである。

図12：入力ストロークの処理

6．2． 基礎処理モジュール

説2． 処理結果のストロークによる表現

基礎処理モジュールは、セグメントに関わるシステムにおける情報の提示はすべてストロ

各種の基本的な計算処理を提供するもので、ユーザによる指示ではな一く自動的に付与される。

ークとして表示される。これは主に、手書きによるホワイトボードの外観を保持し、インフォ

このような計算処理は、処理モジュールとしてーマルなインタラクションを促進するといった独立させるのでなく、セグメント自体の機能として実装する方法もありうるが、独立させるこ

美術デザイン上の理由からであるが、同時にシステム全体の実装をわかりやすくするといったとでセグメントの実装をストロークの保持と処効果もある。

理モジュールヘのイベントの配布という単純な

アプリケーショ ン処理モジュールは、addPaintedStroke や removePaintedStroke ものとすることができる。現在の実装では、画面の描画要求に応じてストロークを画面に描画といったメソッドを呼び出すことで、親セグメ

するPaintStroke処理モジュール、枠をつかん

ントが管理している表示ストロークの集合に変で移動する制御ジュスすヤーを処理する

更を加える。これは、通常のアプリケーション

DragBorder処理モジュール、セグメントの分割

プログラムがdrawTbxtやdrawLineといった直接描画操作を呼び出すのと比較して間接的な方や統合を管理するSegmenting処理モジュールなどが実装されている。

法である。これによってアプリケーション処理
モジュールの側で特に表示に関して特別な処理

6．3． アプリケーション処理モジュール

ルーチンを書くことなく、セグメントの移動やアプリケーション処理モジュールは、通常の押し潰し、表示内容に基づく検索といった動作ー217−アプリケーションプログラムに相当するものである。Flatland はアプリケーションプログラマ

地図描画：このアプリケーション処理モジューが、システムの低レベル処理を意識することな
く新しいアプリケーション処理モジュールを記

ルは、道路と交差点からなるネットワーク構造
を内部表現として管理する。各道路は画面に表述できるようなAPIを提供している。

示される2本のストロークへのボインタをもち、各交差点はそこへつながる道路へのボインタを

アプリケーション処理モジュールの基本的な動作は、ユーザによる入力ストロークを受け取持つ。新しいストロークが入ってきたり、消去って、それを処理してセグメントによって管理

ジェスチャが措かれた場合には、ネットワーク

されているストロークの集合へ加えたり、すで構造を適切に変更し、同時にセグメント内の対応するストロークを変更する。

にあるストロークに変更を加えたりするというものである。また、消去ジェスチャーを受け取って、対応するストロークをセグメントから取り除くといった処理も行う。

幾何図形描画：整形エンジン【12】が入力ストロークとセグメントに含まれるストロークの集合を受け取り、整形結果の候補を返す。整形結果

アプリケーション処理モジュールは、ストローク自体を管理することはないが、ストロークの候補は、ピンク色のストロークとしてセグメ同士の関係や構造といった付加的な情報を管理

ントに加えられる。短いストロークが措かれるする（図13）。例えば、リスト管理アプリケーシと（タップ操作に相当）、ピンクの候補が削除され、対応する候補が黒い確定したストロークとしてセグメントに加えられる。

ョンは複数のストロークをまとめて⊥っの項目とするグループ構造を持つ。また地図描画アプ
リケーションでは道を表す内部表現と画面に表示されるストロークとの関係を表す内部表現を3次元描画：ポリゴンメッシュが内部表現として持つ。この付加的な構造情報は、アプリケーシ
ョンが取り外された時に消滅し、再付与された時点で再構成される。

管理される。形状変形や回転などによって見えかたが変る度に、すべてのストロークがセグメ

ントから削除され、新しい見えかたに対応するストロークが追加される。

計算機：長い横線が引かれた時点で、すでに措かれているストロークの集合を文字認識エンジンに渡して数字に直し計算を実行する。計算結果
は、手書き風のストロークに変形されセグメン
トにつけ加えられる。これらのシステムによって生成された数字も手書きで措かれた数字と同

図13：アプリケーション固有の内部構造

以下に各アプリケーション処理モジュールの様に認識できるため、さらに後の計算で利用す実装について具体的に説明する。

ることもできる。

手書き描画：このアプリケーション処理モジュ6．4． アプリケーション処理モジュールの再ールは、ユーザが明示的にアプリケーションを指定していない時に、デフォルトとして自動的に付与されるものである。動作は、入力ストロ

付与

すでに述べたように、付加的な構造情報は、ークをそのままセグメントに加え、また消去ジ

アプリケーションが取り外された時に消滅し、

ェスチャーに対しては最寄りのストロークをセ再付与された時点で再構成される。この節では、グメントから取り除くといった単純なものであ

このようなアプリケーション固有の構造情報のる。また実装上、他のアプリケーション処理モ

再構成について説明する。当初の実装では、こジュールのプロトタイプとして使用される。

れらの内部構造は、処理モジュールが取り外された時点でセグメントに埋め込む方針であった

リスト管理：ストロークの集合である項目の列をが、その後でのセグメント分割統合処理が複雑

内部表現として管理する。また各項目の左端にあるチェックボックスは、このモジュールによ化するため、最終的には、内部構造を個々のストロークに断片を「埋め込む」方針を取った。

って生成されセグメントに追加されたストロー

これによって、アプリケーションが取り除かれクである。

た後でのストロークの消去やセグメントの分割−218−

統合の際には、アプリケーション固有の内部構

コマンドオブジェクトは通常、ユーザの操作

造に関して一切触れなくて住む。当該アプリケ ーつに対して一つ割り当てられる。しかし、そ−ションが再付与されると、そのセグメントに のような方法では、コマンドオブジェクト内の含まれているストロークに埋め込まれている内 コマンドを実行するたびに、すべてのイベント
部構造の断片を集めて一貫して内部構造が再構 処理を再現しなければならず、オーバーヘッド成される。ただし、この埋め込みと再構成に関 が大きい。本システムでは、ユーザの操作をそしては、各アプリケーションごとに注意深く設 のまま記録するのでなく、その結果としてアブ計する必要があり、実装の手間が大きくなる点 リケーション処理モジュールがセグメントに対が問題となる。
して起こした処理をコマンドとして記録する。

図14に、リスト管理アプリケーションにおけ この結果、セグメントの外見だけを再生したい
る再付与の例を示す。3）の時点での画面表示は大 場合には、アプリケーション処理モジュールをきく崩れているが、個々のストロークにグルー 意識することなく、このセグメントに対する操プ構造が埋め込まれているため、4）で再付与され 作だけを再生していくだけで十分となる。このると正しいリスト構造が復元される。
セグメントに対する操作に加えて、アプリケー
ション処理モジュール内部にある内部データ構

造の対する変更も同様にして記録され、外見だ
けでなく内部構造をすべて復元することも可能になっている。
C

3法㌶i。．．よ．

かし、実際にユーザがUndo偲edoを行ったり、時系列をたどる場合には、ユーザの操作毎にま図15は、地図描画の場合の例である。同様に、 とめておく必要がある。そのため、ユーザの操
図14‥リスト管理アプリケーションの再付与．

3）で大きく崩れた画面表示が、4）で再構成されて 作開始・終了毎に、履歴内にトランザクションいる様子が分かる。
の開始および終了マークを挿入している（図16）。
1210penTransaction
122 BehaviorSpecificCommand（Map′ addstreet，Street＃12a）＄i

123 AddPaintedStrokeCommand（StrOke♯23al）
124 AddPaintedStrokeCornmand（StrOke＃23a2）

s・r・

125C10SeTransaction

図16：トランザクションの例

図15：地図描画アプリケーションの再付与

7．2． 局所的履歴と全体的履歴

て動的に再

7・

作、。

ht＃1）
＿…

＝−

とで任意の時点でのセグメントの状態を復元す

図17：局所的な履歴と全体的な履歴ることができる【4，5】。スライダーによる時間操
作はこの機構を直接利用したものである。

7．3．コンテクスト情報による検索−219−

履歴の永続性を保存し、コンテクスト情報による検索を実現するために、本システムではPrestoデータベース【3】を利用している。Presto

6・Forsberg，A・，Dieterich，M・，Zeleznik，R■C，The

MusicNotepad，UIST98
7．Gamma，E．，Helm，R．，Johnson，R．，Vlissides，Design PatternS：Elements of Reusable

はあらゆるJavaオブジェクトをタグづけして保存、検索できる機能を持つ。システムは、定期的にセグメントの状態をそのセグメントが生成

Object−Oriented Software，Addison−Wesley
Publishing，1995．Reading，Mass・

8．Geissler，）．，Shuffle，throw or takeit！Working

されてからの履歴としてコンテクスト情報と共

efficientlywithaninteractivewa11，CmにPrestoへ保存する。検索時には、検索キーと98・9．Gross，M．D．，Do，E．Y．，Ambiguousintentions：apaper−1ikeinterfaceforcreativedesign，U［ST 96・
10．Kramer，A．，TranSlucent Patches−dissoIving

一致するコンテクスト情報を持つセグメントの履歴が取り出され、その履歴を実行することでセグメントの状態が再構成される。検索結果を表示するだけであれば、履歴のうちアプリケー

Windows，U搭T94．

11．Kramer，A．，Dynamic Interpretations in
TranSlucent Patches， Representation−Based

ション処理モジュール固有のデータ構造書き換えに関するものは無視して、セグメントのスト

Applications，AⅥr 96・

12．IgaraS軋T．，Matsuoka，S・，Kawachiya，S・，
Tanaka，H・，Pegasus：A Drawlng System fbr
Rapid Geometric Design，C〃J198 summary，ロ「ク書き換えに関するものだけを扱えばよいので、再生がアプリケーション処理モジュールを経由せず高速に行える。検索の結果見つかった過去のセグメントで作業を続けたい場合には、

pp．24−25・

13・IgaraShi，T・，Matsuoka，S・，Tanaka，H・，Teddy：A

内部構造書き換えも含めた完全な履歴の再実行

SketchingInterfacefor3D Freefbrm Design，が行われる。

∬GG尺AP〃タタ．

14・Landay，J・A・，Myers，B・A・，Interactivesketching
fbrtheearlystageofinterfacedesign，C〃J 95・
15．Moran，T．P．，Chu，P．，VanMelle，W．，Kurtenbach
G・，Implicit struCtureSfor pen−based systems
withinafreeforminteractionparadigm，Cf〃 95．
16・Mynatt，E・D・，The wrltlng On the wa11，

8．まとめ

手書きストロークに基づく電子白板システム、
およびその実装について紹介した。本システム
は、従来のデスクトップシステムを補い、より自由で創造的な活動を支援することを目的としている。今後の発展の一つとしては、本アーキ

INTERACT99．

17・Mynatt，E・D・，Igarashi，T・，Edwards，W・K・，
LaMarCa，A．，Flatland：New Dimensionsin

テクチャを他のペンベースのシステムに適応することなどが考えられる。

OfnceWhiteboards，C〃J

99．

18．Perlin，K．，Quikwriting：ContinuousStylus−based

参考文献
TextEntry，tHST98・
1．Bederson，B．B．，Hollan，J．F．，Pad＋＋：AZoomlng
19．Prderson，E．，McCall，K．，Moran，T．P．，Halasz，graphical interface for exploring alternate

Tivoli：An electronic whiteboard fbrinformalinterfacephysics，t〃Sr94・

workgroupmeetlngS，JⅣTERC〃J，93，Pp，39l−399・
2．Bier，E．A．，Stone，M．C．，Pier，K．，Buxton，W．，
20．Rekimoto，J．，A Multiple Device Approachfor
DeRose，T．，Toolglass and maglClenses：The
Supportlng Whiteboard−based Interactions，

See−throughinterface，S［GGRAPH 93・
C〃J′9β．
3．Dourish，P．，Edwards，W．K．，LaMarCa，A．，
21．Rekimoto，］．，Time−Machine Computlng：A
Salisbury，M．，Using Propertiesfor Unifbrm

Time−Centric Approach for theInformation

Interactionin the Presto Document System．

Enviroment，U［Sr99．

と〃∫r タタ．

22・Tapia，M・A・，Kurtenbach，G・，Some Design
4．Edwards，W．K．，Flexible ConflictDetectionand
Refinements and Principles on the AppearanceManagement in Collaborative Applications・and Behavior of Marking Menus，UIST 95，と〃∫r 夕7．

pp．189−195・

5．Edwards，W．K．，Mynatt，E．D．，Timewarp：

Techniques fbr Autonomous Collaboration・C〃J 夕7．

23．Zeleznik，R．C．，′Hemdon，K．P．，Hughes，J．F・
SKETCH：Aninterfaceforsketching3Dscenes．
ぶJGG尺Af）〃 タ∂．

ー220−