近年、計算機の能力は飛躍的に増大し、処理能力の多くをユーザインタフェース(UI)を充実させるために使うことが出来るようになってきている。パーソナルユースの計算機でもグラフィカルユーザインタフェース(GUI)を備えることはごく普通となり、画像情報、音声情報を比較的自由に取り扱えるようになった。それらの様々なモダリティを利用したアプリケーションプログラム(AP)は、テキストデータのみを頼りとしていた時代のAPに比べ、操作性・作業効率・学習のしやすさ等の面で格段に優れている。しかし一方では、身体的障害や計算機の使用環境によってモダリティの一部でも使えないユーザは、APそのものを使えなくなってしまうという事態が生じてきた。例えば全盲の視覚障害者はグラフィカルに提示された情報をそのまま利用することができないし、聴覚障害者は警告音に気づくことができない。また、障害者でなくとも、小さな移動端末を携帯している人は精細なGUIよりもむしろ旧式のコマンドラインインタフェースを望むかもしれない。 身体障害への対応を念頭においた従来の研究では、標準的な入出力(主としてGUI出力)をデバイスに近いレベルでフックし、他のモダリティにマッピングするという方法がとられてきた。この方法は既存のAPがほぼそのまま使えるという利点があるが、UIの表面的な情報だけを扱うため、本来のインタフェースのセマンティクスをうまく表現できないという欠点がある。特にGUIからの出力であるビットマップ情報や図形の位置情報からUIのセマンティクスを再現するには、2次元の空間配置を解析する必要があり、困難である。 我々は、現在のUIの多くがインタラクションの「部品」を提供するツールキットを用いて作成されている点に注目した。このようなツールキットで提供されるオブジェクトは、外見を管理する機能とインタラクションを管理する機能の両方を担っている。本研究では、これら二つの機能を個別に実装できるようにすることで、ツールキットそのものにモダリティの動的な選択機構を導入することができ、柔軟なインタフェースが構築できることを示した。 まず、分散オブジェクト空間linked spaceを定義する。linked spaceは複数のプロセス間で情報の共有ができるオブジェクトのプールである。最初にlinked spaceを生成したプロセスはmasterと呼ばれ、他のプロセスはmasterに接続することでlinked spaceのイメージを共有する事が出来る(slaveとなる)。Linked spaceにはmasterが許可すればいつでも参加・離脱することができる。linked spaceの参加者の一人がspace内にオブジェクトlinked objectを作成すると、そのオブジェクトは他の参加者のspace内にも見えるようになる。 プロセス間の通信にはlinked methodと呼ばれるメソッドが用いられる。linked methodは、参加者の一人がlinked objectにそれを適用するとあたかも他の参加者全てが自分のlinked objectにそのメソッドを適用したかのような効果を生むメソッドである。例えばオブジェクトのスロットの値の更新はlinked methodとして定義され、スロットの値の更新は常にspaceの参加者全員に見えるものとなる。単なる共有オブジェクトと異なる点は、メソッドのディスパッチと実行が各プロセス内で個別に行なわれる点である。したがって、一つのlinked objectのクラスに対して別々のメソッドを各プロセス内で定義することにより、メソッドの適用が各プロセスで違う効果を持つようにできる。 次に、インタラクションのセマンティクスを表すオブジェクトである、abstract widgetを導入する。通常、GUIはwidgetと呼ばれる部品を組み合わせることで構成されるが、abstract widgetはwidgetのテンプレートとなるものである。例えばアプリケーションに対して動作のきっかけを与えるabstract widgetや、いくつかの選択肢からユーザが望みのものを選ぶabstract widgetなどが考えられる。GUIならば前者はボタンで、後者はスクロール可能なリストで表現されるかもしれない。コマンドライン指向のインタフェースでは前者は特定の単語の投入、後者は選択肢が表示された後に番号を選ぶといった形に表現されるかもしれない。 Abstract widgetを用いれば、アプリケーション側からはインタフェースのモダリティに依存しない記述ができる。しかし実装上、様々なインタフェースの形態に対応するために、ツールキットに考え得るすべての表現に対するコードを埋め込んでおくというのは、新たなインタフェースの表現を追加するのが非常に困難であるという点で非現実的である。Abstract widgetをlinked objectの一形態として定義することにより、この問題を解決し同時にインタフェースを動的に切替える機能を持たせることができる。 すなわち、インタラクションのセマンティクスに関わる部分だけをアプリケーションとインタフェースで共有する定義としておき、インタフェースモジュールの方では望ましいモダリティへの表現をするlinked methodを個別に定義するのである(図1)。このようにabstract widgetに具体的な定義を与えることをexternalizationと呼ぶ。特に、基本的なインタフェースモジュールとアプリケーションモジュールはexternalizeしたウィジェットセットをあらかじめ作っておくことができるので、アプリケーションプログラマは通常のGUIを作るのと同じ工数でモダリティ独立なアプリケーションを作成することができる。例として、アプリケーションに動作のきっかけを与えるCommandと呼ばれるabstract widgetについての定義を図2に示す。  図1:Development of applications and user interface modules:Abstract widgets are like template of ordinary widgets.Interface developers can’externalize’them by adding interface specific features.Application programmers construct interface using application-side externalized widgets as interaction objects,without concerning interface details.Instantiation of application side widgets automatically propagates to interface modules and creates corresponding interface-side widgets. 図2:Example of externalization of command abstract widget この原理に基づいて、インタフェースツールキットFRUITをUNIX上に実装した。linked spaceを始めとするオブジェクトシステムは主としてSchemeで実装されているが、ベースとなるwidgetの階層は、GUIのツールキットとして広く使われるようになったTkと互換性を持たせてある。 実行時のアーキテクチャは、図3(b)のようになっている。ユーザの手元にはinteraction shellと呼ばれるプロセスが走り、abstract widgetの表現を担当する。アプリケーションは、通常のツールキットライブラリを使う代わりにabstract widgetのツールキットを使うことにより、容易にFruitの持つ柔軟性を得ることができる。ユーザは自分の環境に合わせたinteraction shellを立ち上げて望ましいモダリティでアプリケーションを使用でき、またアプリケーションの動作中にも別のinteraction shellを立ち上げることによりモダリティを動的に変更することが可能である。標準ではGUI、line-oriented interface及びカーソル制御可能な文字端末を用いたインタフェースに対するinteraction shellが提供される。特に、文字端末やline-oriented interfaceを用いたインタフェースは既存の文字から音声への変換システムを用いることにより音声出力として情報を取り出すことができ、視覚障害者へのインタフェースとして有効である。立ち上げられたアプリケーションはsession managerというプロセスで管理され、アプリケーションを一時停止させ、interaction shellをシャットダウンし、別の場所に移ってinteraction shellを立ち上げ、再びアプリケーションと接続して仕事の続きを行なうといったユーザの環境変動にも対応できる。  図3:Runtime structure of ordinary application and FRUIT application |