リアルワールドメタファを使った
ユーザーインターフェースの研究
H100078G
李 端明
目次：
第１章 はじめに...5 １.１ 研究背景... 5 １.２ 研究目的... 5 １.３ 論文の構成... 6 第２章 背景知識と関連研究のまとめ...7２.１ TANGIBLE BITS: TOWARDS SEAMLESS INTERFACES BETWEEN PEOPLE, BITS AND ATOMS 7 ２.１.１ イントロダクション... 7
２.１.２ 関連研究... 8
２.１.３ Tangible Bits のデザイン例：metaDesk と Tangible Geospace... 9
２.１.４ ambientROOM... 10
２.１.５ まとめ... 11
２.２ TRIANGLES: DESIGN OF A PHYSICAL/DIGITAL CONSTRUCTION KIT... 12
２.２.１ イントロダクション:トライアングル・システム ... 12
２.２.２ ITERATION AND BALANCE IN DESIGN： ... 13
２.２.３ コミュニケーション構造... 14
２.２.４ One Application Scenario... 15
２.２.５ まとめ... 15 ２.３ まとめとこれからの研究... 16 ２.４ メタファとアイコン... 16 ２.４.１ 視覚化する必要性... 16 ２.４.２ アイコンとメタファ... 17 ２.４.３ メタファとは？... 18 ２.４.４ リアルワールドメタファ... 18 第３章 システムの設計...20 ３.１ コンセプト... 22 ３.２ 基本設計：... 24 ３.２.１ 表現方法と基本設計... 24 ３.２.２ システム機能... 25 ３.２.３ システムの構想... 26 ３.２.４ 環境編集機能... 26 ３.３ ネットワークの基本設計... 27 ３.３.１ 接続方法：... 27
３.３.２ 接続を受け入れる：... 27 ３.３.３ ログオンする側の制約... 28 ３.４ クラス設計図... 29 第４章 システムの実装...31 ４.１ アーキテクチャ... 31 ４.１.１ マップマネージャークラス... 31 ４.１.２ クライアントクラス... 32 ４.１.３ セルクラス... 32 ４.１.４ スプライトクラス... 33 ４.２ システム構築上に必要なクラス... 34 ４.２.１ ビットマップクラス... 34 ４.２.２ アイテムダイアログクラス... 35 ４.２.３ メッセージクラス... 37 第５章 評価実験...38 ５.１ 実験方法... 38 ５.２ 実験結果... 38 第６章 まとめと今後の課題...40 ６.１ 今後の課題... 40 ６.２ 結論... 40
図目次
図 ２-1Tangible UI ... 7 図 ２-2 Augmented Reality... 9 図 ２-3 メタデスク ... 9 図 ２-4ＧＵＩとＴＵＩの要素の対応... 10 図 ２-5 立体的な接続... 13 図 ２-6 トライアングルの接続... 13 図 ２-7 トライアングル・ネットワーク ... 14 図 ２-8 シナリオの例... 15 図 ２-9 フォルダ... 17 図 ３-1 もっとも代表的なチャットソフト、ＩＲＣの画面。... 21 図 ３-2 プレイオンライン誌が実施したアンケート結果... 22 図 ３-3 コンセプト ... 25 図 ３-4 状況によって違うメニュー項目を表示する ... 27 図 ３-5 接続許可のメニュー項目 ... 28 図 ３-6 クラス設計図... 29 図 ４-1 接続の様式図... 32 図 ４-2 セルクラス用ビットマップの一例... 33 図 ４-3 キャラクターを表すビットマップ... 34 図 ４-4 右クリックメニュー... 35 図 ４-5 アイテム選択ダイアログ ... 36 図 ４-6 アイテム選択ダイアログに使用例... 36 図 ４-7 メッセージ表示... 37第１章 はじめに
１.１ 研究背景
現在のＰＣ・ＷＳ上では、デスクトップメタファが完全に主流の位置を占めてい る｡デスクトップメタファは、読んで字のごとく、机を模擬したユーザーインターフ ェースである。その自然な拡張として考えられるが、複数のワークスペースを用意 したルームメタファであり、今後グループウェアの応用が増えるのにしたがってそ の必然性が高まると考えられる｡ デスクトップメタファもルームメタファも、基本的には実世界の仕事や活動をそ のまま模擬したインターフェースにして、操作を推測しやすいようにデザインされ たものである。その考え方は、リアルワールドメタファと呼ばれることもある。 しかし、その利点である理解のし易さを得たのと同時に、それらが隠喩できる範 囲はそれらメタファが模擬している範囲の中に限られることになる｡具体的には、デ スクトップメタファに机の形をしたアイコンを置いても、それはなにを意味するか ユーザーには分かりにくいという、メタファの限界が存在する。 この中で、特定の環境や範囲ではなく、世界をそのまま模擬してユーザーインタ ーフェースにすれば、多少操作の利便性とスピードを犠牲することによって、もっ と広い範囲でユーザーのシステムへの理解を補助するのに有効ではないかと予測す る。そのようなメタファを指す言葉は特にないので、この論文では、“リアルワール ドメタファ”という単語を、実世界をそのまま模擬するメタファとしてとらえたい と思う。１.２ 研究目的
本研究の目的は、現存するＯＳにおけるデスクトップメタファとリアルワールド メタファの並存と融合を目指すことである｡リアルワールドメタファを使うことに よって損なわれた利便性と操作の単純さを、二つのメタファの共存によって相互補 完すると同時に、現存のシステムで新しいメタファを導入することを実現する。 また、リアルワールドメタファを使い、同じ画面と操作方法でＯＳの基本的機能 であるファイル操作、そしてコミュニケーションツールとしてよく使われているチ ャットをメインに、できるだけ多くの性能を追加させることによってデスクトップ メタファより優れた点を発展させていきたい｡ 個人でＯＳを完成させるのはかなり困難なので、現在あるシステムと共存するこ とを目的として研究を進めた。また、リアルワールドメタファには大量のビットマップを使っているので、それを活用しインターフェースのカスタマイズ性を高めて、 ユーザーに「飾る楽しさ」「見せる楽しさ」を与えることによって、パソコン初心者 や子供など現存ＯＳのビジュアルを敬遠していた人にも楽しく、そして使いやすく する。
１.３ 論文の構成
本研究では，以下のような構成で述べていく：
メタファについて メタファとはなにか、メタファの種類 背景になる研究−Tangible Bits: Towards Seamless Interfaces Between People, Bits and Atoms
−Triangles: Design of A Physical/Digital Construction Kit
システム設計 構想段階におけるシステムの設計 システム実装 実装段階の問題点、実装方法、そしてアーキテクチャの説明 評価実験 本研究で実装したアプリケーションをもとに，評価実験を行う まとめと考察 本研究についての考察と，今後の課題について述べる
第２章 背景知識と関連研究のまとめ
２.１ Tangible Bits: Towards Seamless Interfaces between People, Bits
and Atoms
２.１.１ イントロダクション
今日のＧＵＩ（Graphical User Interface）の基本概念は３０年以上前に生まれた。 ＧＵＩは情報をピクセルとしてスクリーンで視覚化する。このＧＵＩの次に来るＨ ＣＩ（Human Computer Interaction）として、著者たちは”Tangible Bits”の研究を 進めている。Tangible Bits とは、bits（デジタル情報）の世界から atoms（物理世 界）の世界への回帰と融合を目指すものである。本稿では次世代のインターフェー スの具体例を紹介する。そして、われわれの肉体が存在する建築空間そのものを、 人間とサイバースペースとのインターフェースに変えていくという新しい方向を提 案している。 図 ２-1Tangible UI 人間とサイバースペースとのインターフェースは今、コンピュータのＧＵＩに限 定されている。しかし、スクリーン、ウインドウ、マウス、キーボードに縛られた 現在のＧＵＩは、物理世界のインターフェースと大きくかけ離れている。直接物に 触れて操作するスキルや、周辺感覚（peripheral sense）による情報の獲得などはま ったく活かされていない。 Tangible Bits プロジェクトの目的は、現実の物理世界とサイバースペースに存在 するデジタル情報を有機的に結合することで、デジタル情報を直接アクセスできる ようにすることであり、以下のコンセプトで研究を進めている： １、Interactive Surfaces:（インタラクティブな表面）: 机、壁、天井などの建築空間の表面を、物理世界とデジタル世界とのインター フェースに変える。
２、Coupling of Bits and Atoms: 手につかみ操作できる物理世界のオブジェクトをデジタル情報とリンクする。 ３、Ambient Media: （周囲の、環境のメディア） 建築空間の中の音、光、影などのambient media をサイバースペースとのバッ クラグウンド・インターフェースとして利用する。 デジタル情報をgraspable object（つかめるオブジェクト）と結合することによっ て、フォアグランド（認知の焦点）でビットを直接操作ができるようにすることと、 ambient media を用いることにより、認知の周縁（バッググラウンド）において情 報の気配を感知することができることを目指している。ＧＵＩは注目されることを 前提に、フォアグラウンドを中心にデザインされている。しかし、人間は無意識的 にバッググラウンドから多様な情報を受け取っているので、いかにフォアグラウン ドとバッググラウンドの間のスムーズな情報提供を可能にするかが研究テーマであ る。 ２.１.２ 関連研究 この研究は、数種類の研究の強い影響を受けている。ここではそれらの先行研究の 概念と、この研究との関連をいくつか簡単に述べる： （１）Ubiquitous Computing：（いたるところに存在するコンピューティング） Mark Weiser は将来、多様なデバイスによってコンピューティングサービスが提 供されることによって、コンピュータが「透明化」になると予測した。彼が提唱し た「コンピュータを遍在化させる」ことに対して、ＴＵＩ研究の焦点は物や建築の 表面にデジタル情報を提供させることにある。 （２）Augmented Reality：（増大するリアリティ） 略してＡＲ。それはVirtual Reality とは逆に、実際存在するオブジェクトにデジ タル情報を供給することによってその機能を増大させる実験。ＴＵＩの研究では、 ものを直接つかみ操作することに焦点を置いている｡ （３）ClearBoard ClearBoard は、分散した２点の物理空間を仮想の２次元共同作業空間によって結 合する、CSCW(Computer-Supported Cooperative Work)のためのシステムである。 本プロジェクトによって、建築空間の壁、天井などあらゆる表面を情報が流れるア クティブ・インタフェースに変えると言う構想を得た｡
Bricks は、小さな物理オブジェクトでこれをスクリーン上に置くことによって仮 想オブジェクトを直接操作する。つまり、デジタル情報を直接両手で操作すること が可能になる｡これによってTangible bits のキーコンセプト「graspable media」（ク ラスパブルメディア）が生まれた。
図 ２-2 Augmented Reality
２.１.３ Tangible Bits のデザイン例：metaDesk と Tangible Geospace
現行のOS で良く使われているデスクトップメタファとは逆に、metaDesk はＧＵ Ｉ世界で確立された基本要素に物理的な実体を持たせることで、新しいインターフ ェースの可能性を模索するプロジェクトである。 metaDESK は、水平に近いバックプロジェクション型の大型スクリーンと、スクリ ーン上のオブジェクトを検出するビジョン・システム、アームに接続されたＬＣＤ からなるactiveLENS、ファイバーを埋め込んだ枠からなる passive-LENs、そして ファイコン(phicon)と呼ばれる物理的なアイコンから構成される（図２−３）。ファ イコンはアイコンの物理的バージョンで、LENS はウインドウの物理的バージョン である。 図 ２-3 メタデスク
metaDESK のプロトタイプアプリケーションである“Tangible Geospace”の例 でいうと、例えば図６で示されるファイコンは、ＭＩＴのシンボルをモデル化した もので、このファイコンをmetaDESK のディスプレーの上に置くと（つまり机の上
におく）ビジョン・センサーがそのファイコンの種類と位置を確認し、その場所に ＭＩＴの２次元マップ情報を表示する。ユーザーから見るとまるでファイコンから 絵が漏れ出したかのようにその場所から机の上全域に広がったかのようにみせる。 つまり、ダブルクリックする代わりに、ファイコンをつかんで置くことで、そのフ ァイコンが内蔵（意味的に）された情報にアクセスすることになる。 図 ２-4ＧＵＩとＴＵＩの要素の対応 activeLENS に３Ｄの情報が表示され、それを動かすことによって三次元情報の検 索ができる。passiveLENS は、それ自体はディスプレーではないが、システムがそ の位置を追跡することができるので、passiveLENS が置かれている場所に隠された 情報（例えば地図の衛星写真など）を表示させることができる｡ このＴＵＩの実験プロジェクトで分かった主な問題点は、ファイコン操作などの 自由度から生み出した命令解釈の曖昧さにあり、現在も都市計画、スライド・ソー ティングなどを通してＴＵＩの有効性と限界を検証中である。 ２.１.４ ambientROOM ambientROOM は、人間の知覚の周囲で情報を通信するために手段として周囲の メディア(ライト、影、音、気流)を使用することにより metaDESK のような集中的 な、認識のフォアグラウンドを補足する。その一種であるWater Lamp の例を上げ てみよう。 人間は、環境の中の微妙な光や空気の変化によって、周りの人の活動や環境の変 化に意識を集中することなく察知する能力をもっている。Water Lamp はその認知 特性を活かし、他のフォアグラウンドに集中しながらも、デジタル情報を“気配” のように感じるというコンセプトで設計された。 WaterLamp は天井に向けて強力なランプ、その上の水槽、そして水面に波紋を作 り出すための制御装置によって構成される。ネットから流れ込むビットが制御装置 によって波紋を作り出し、その波紋が光と陰になって天井に投射される仕組みであ る。 今開発しているアプリケーションのシナリオは、腕時計と組み合わせた”ghostly
telepresence”である。遠くに居る人が身につけた腕時計がその人の脈拍を拾い、そ れをインターネット経由で室内に設置したWaterLamp に情報を送ると、天井にその 情報にあわせた波紋が広がり、その人の気配が感じられるという。
２.１.５ まとめ
ambient media のデザインはどのソースをどの ambient media にマッピングする か、個人によるカスタマイズのためのインターフェースをどのようにデザインする かなどの問題について、現在も研究を進めている。
２.２ Triangles: Design of A Physical/Digital Construction Kit
この論文は、データと対話するために手段を提供と、デジタル情報を具体化する ために物理的なオブジェクトを使用するコンピューター・インターフェースの新し い設計を紹介している。 トライアングルは、全部同じ大きさで、プラスチックでて きている三角形の形をしている物理的なインターフェースである。 トライアングル はお互い磁気で導くコネクターで物理、デジタルの両方を接続する。互いに繋いだ ら、その特定の接続（組み合わせ）は特定のデジタルなイベントを起こすことがで きる。 ２.２.１ イントロダクション:トライアングル・システム トライアングル・プロジェクトは、1 つの「タンジブルインターフェースの」-デ ィジタル情報を具体化するおよび操作するための物理的なオブジェクトのシステム を構築することを目的とする。 プログラミング言語およびコンピューター・システ ムは、情報の管理と理解しやすいためのメタファとして「オブジェクト」および「キ ット」がよく使用される。 しかしこれらのシステムの操作は、より複雑な構造へ組み立てる時に、抽象的な イメージを使用することを要求する。このプロジェクトにおいての理想的なインタ ーフェースとして、もしその複雑な問題をレゴブロックなどおもちゃのように簡単 に組み上げることができたら、複雑な物理的な構造は容易に 2 つの手を使用して、 組み立てることができ、基礎的な要素を速く識別しソートすることができるように なる。また、ユーザーがもともと持っている能力：“特定のものを探し出す能力と複 雑な構造を感じ取る能力“により、典型的なコンピューター・ビジュアル化より多 くの情報を受け取ることができる。 トライアングルのパーツは、平面上、あるいは三次元的に接続（構築）すること ができる。 三角形は、磁気で、電気的に導くコネクターを用いて物理的にデジタル での両方接続する。 データ関係は即時で、簡単に作れる上、取消すことも簡単であ る。 パーツが接続する場合、それらの同一性に関する情報は交換される。 また、メッセージはコンピュータ(図 1)に伝わることによって、アプリケーション は接続している部分のすべての関係をいつでも決定することができる。また、特定 の接続は特定のデジタルイベントを起こすことができる。 トライアングルにアイコンまたは画像を描くことによって、作る人は各ピースおよ びその各々の辺にユニークな意味を与えることができる(図 2−６)。 ユーザーはアプリケーションの詳細を調査して、「適切な」2 つ以上の三角形を接続することができ る。 ユーザーはさらに３次元の「データ構造」を作成することができる (図２−５)。 三角形は、それそれらのイメージおよび対応するソフトウェアイベントの変更によ り異なるアプリケーションのために再使用することができる。 図 ２-5 立体的な接続 図 ２-6 トライアングルの接続
２.２.２ ITERATION AND BALANCE IN DESIGN：
トライアングルの設計は模型、プロトタイピングおよび実験の反復するプロセスで だった。 問題は 3 つのレベルで発生し続けた: オブジェクトの物理的な設計 三角形間のメッセージを渡すことに関するエレクトロニクス、および ホストコンピュータが扱うソフトウェア。 設計のこれら 3 つのエリア、同時に設計されるために、それらはしばしば深く影響 し合う。 設計段階ではいろんな形のピースが考慮されました。理想的には、それの個々の パーツは平面で、同じ大きさで、そしてその側面でお互い接続できなければならな い。これらの基準は、等辺三角形によって満たされた。 さらに三角形は、コンピュ ータ情報中の分岐する構造及び複雑な関係や構造を表現するのに必要最小限の辺を 持っている。 トライアングルを六角形へピースを張ることでループおよび再帰的な 状況を作成できるかもしれない。三角形のピースは、さらに三次元的に構成するこ とによって複雑な関係を表すのに適している。 トライアングルの最大な特徴は、接続されたら、それらの位置および方向情報は 即座に通信することである。著者たちは最初、特定の机とビジョン・センサーによ ってそれをキャッチすることを計画した。しかし、これらは特定の環境を要求する ので、システムはポータブルではなくなる。 また、三次元の構造も任意のオブジェ クトを確認することを妨害する恐れがある。また、IR および誘導のカップリング技 術は離れて作動するので、物理的接続と同時にデジタルの接続を保証することがで きません。このことによって、センサーの内蔵が要求されるだろうことは明らかに
なった。 ２.２.３ コミュニケーション構造 このシステムを実現するには、各三角形がそのとなりのピースとの関連と、それ がどの面だったかの情報を中継できる、メッセージを伝導するシステムを設計する 必要があった。 プロジェクトは最初にethernet に似た方法で通信する方法を検討した。しかし、 そのようなシステムでは各三角形は簡単に自分を識別できるが、その隣のピースと の関係などを識別するのにローカルのコミュニケーションを要求するので、コネク ター上に余分の回路類、プログラミング及び多くのピンが必要になるだろう｡それは 設計上好ましくないことなので、代わりにシステムが各トライアングル間のメッセ ージをホストコネクタにメッセージを送るだけの構造を使用すると決定した｡ 図 ２-7 トライアングル・ネットワーク 最終的にインプリメントしたメッセージ伝達アルゴリズムは、一番低い場所をホスト コンピュータとして、新しいピースが加われると共に、個々の新しいタイルの高さを僅 かに増大することによって確立される(図 5)。 トライアングル・ネットワークは、どのピ ースもメッセージを生成するか受け取る場合、それは単に次の高さの低い隣人を探し、 低い方にメッセージをどんどん渡していく｡このシステムは、各メッセージがホストコン ピュータに最短距離で伝達できることを保証すると共に、各ピースが地形情報を格納す ることを回避した。 地形上の情報を得て中継するこの方法は、メモリーと機能性では各マイクロプロセッ サーに関する要求を最小限にする。 各チップは、5 つのアイテムを格納できればよい： それ自身のユニークなID 接続している３つのピースのＩＤ 自分より「高さ」が低いピース その結果、互いとローカルに通信することに加えて、いかなるトライアングルもメッ
セージを直接ホストコンピュータあるいは他のトライアングルへ渡すことができました。 これは、システムの速度を非常に改善し、ソフトウェア設計を単純化しました。
２.２.４ One Application Scenario
初期のトライアングルの開発では、著者たちはパソコンに接続された 4 つの三角形を 使用して、次のシナリオを考案しました。 シナリオはオーディオ、視覚的、テキストに よってフクロウ、蛙およびトンボ(図２−８)を表現する。 図 ２-8 シナリオの例 ユーザーがベルのシンボルおよび蛙を完成させるために三角形を接続する場合、蛙の 音声が聞こえる: " Ribbit…ribbit…ribbit。 " その後、ユーザーはベルを分離し、「画像 フレーム」シンボルを完成される。 コンピュータは、蛙の写真を表示する。 そして、ユーザーがトンボを完成すると、急に、スクリーン上の蛙はトンボを食べる。 ユーザーがトンボを分離し、代わりに、フクロウを完成すれば、蛙を食べる。 もしユー ザーがいかなるポイントで本のシンボルを接続したときには、現在の特徴に関するテキ ストはより多くの詳細を提供して、現われていたである。 ユーザー相互作用のログの記録によって、ソフトウェア・システムは、そのイベント の発生順序によってイベントを起こすことが可能である｡例えば、もしトンボが現われる 前に、フクロウが蛙を食べたならば、トンボは生き残ったかもしれない。 ２.２.５ まとめ 物理とデジタル世界間のギャップを埋めることは重要である。コンピュータに人間の言 語(音声、身振り)および実世界についての理解を与えることを試みるのではなく、この論 文のアプローチは人々およびコンピュータの両方が理解することができる新しい言語を 提供する。 トライアングル部分が付けられたり、分離される時、コンピュータが知覚す ることができるデジタル接続を備えた彼らの手にユーザーが持っているものとの同期が 生じる。 この言語(接続する、分離する)は単純だが、多数の三角形の組み合わせによっ て可能になる表現力は、非常に豊富である。 トライアングル・システムは、広く様々 な分野での明確なインターフェースを調査するための基礎である。 このプロジェクトの
将来の研究は、明確なインターフェースを使用して、対話型のアプリケーションを開発 することに興味を持っている、他の研究者に完全なトライアングル・システムを供給す ることに注目するであろう。
２.３ まとめとこれからの研究
２回のTangible Bits プロジェクトの論文を読んで特に感じたのは、如何にしてユーザ ーがもともと持っている能力を目的のシステムで適用させることが、ＵＩシステム開発 上最大の課題でもあり、また使いやすさを判断する基準となることが分かった｡よりよい ユーザーインターフェースを作るという目的の手段として、論文の中で主に取り扱われ たのは現存するコンピュータの形やあり方を変えることに着目したが、それを今のパソ コンで実現させることが、本研究の動機となった｡ いま良く使われているほとんどのパーソナルコンピュータのＯＳは、デスクトップメ タファを使用されている。確かにテキストベースに比べれば理解しやすい表現法ではあ るが、学習の初期段階では馴染みづらい操作にユーザーが戸惑う例が多く、また表現の 限界もあり、抽象的なアイコンもよく用いられるようになった。そこで、メタファを変 える事によって、よりよい表現法と操作性を実現したい。２.４ メタファとアイコン
これからの研究において重要な概念、メタファとアイコン、そしてＧＵＩの基本 知識についての紹介である。 ２.４.１ 視覚化する必要性 認知工学の研究結果によると、人間は一度に処理できる情報力は限られており、 その単位を“チャンク”と呼ばれるが多い。チャンクとは、単語や句といったよう な、あるまとまりを持ったものであり、脳内の知識によって対象の変換を行うこと ができる。例えば、“日本”“ご飯”など使い慣れている単語は、脳内で１認知単位 に変換されるので、１チャンクとなる。逆に“mldtq”のような知らない単語、ある いは意味の無い単語の集まりになると文字数だけのチャンクを消費する。分かりや すく言えば、知っている単語は早く読めるが知らない単語は一文字一文字読んでい くので理解できるまで遅いということになる。そして、人間は一度に処理できる情 報量は約７チャンクで、視神経が一度に記憶できる量は７∼１７チャンク（７０∼２０００ｍｓ単位）である。 上記のデータで分かるように、単語で情報を表示する時は脳内の知識と照合して、 理解できる単語を１チャンクへと変換できるが、視神経が一度に取り込める量は７ ∼１７チャンクしかない。つまり、“デスクトップメタファ”と“インターフェース” のような長い単語を連続に読むと、視神経の処理能力を超え、結果的にはその分の 処理能力が無駄になる結果となる。それに対して、文字ではなく図形で表示すると、 一度記憶すればどのような図形も１チャンクとなり、また同時に記憶、処理できる 量が大幅に増大されるので大量の情報を楽に処理できる。それが現在使われている パソコンやワークステーションではＧＵＩ（グラフィックユーザーインターフェー ス）が主流を占めている最大の理由であり、また使い心地がいい理由でもある。そ のほかに、文字は言語によって発想やイメージが制限されることがしばしばあるが、 それに対して図形（アイコン）はそのような制限が無いので、ＧＵＩを採用するこ とでより表現力豊かなインターフェースを構築することができる。このように「視 覚情報を活用することによって文字文化の溝を埋めることができる」ことと、「コン ピュータ専門家と非専門家との溝を埋めることができる」ことができるのが、ＧＵ Ｉ研究する最大の理由である。 ２.４.２ アイコンとメタファ コンピュータ環境における視覚化技法としてもっとも一般的なのは、アイコンを 用いるものでしょう。これは、データであるとか、コマンド、あるいはプログラム など、コンピュータの世界で観察される要素を目に見える形に記号化したものであ る｡例えば図１，１のようなものはその例である。 図 ２-9 フォルダ 図 １−１の左側は実際のファイルフォルダで、右側はもっともよく見かけるフ ォルダのアイコンである。よく見るとアイコンの角が丸く、ラベルの部分ちゃんと 再現していて、理解しやすいように工夫したのが分かる。ところが、あのフォルダ のアイコンを最初はフォルダのメタファと認識できない人が多いようだ。メタファ のもとになった紙フォルダを使う習慣が一般には少ないせいかも知れない。例えば
オフィスにパソコンを導入する時、人によってはプリンタに見える例もある。これ は、メタファの限界による混乱と考えられる。 デスクトップに、「壁紙」を張ったり、「窓を開く」などはすでに隠喩であるデ スクトップメタファで、さらに“例える”ことであり、２重のメタファになるので なかなか理解されにくい。そのうえ、自分のコンピュータの中にあるデスクトップ にさらに「マイコンピュータ」があるなどは理解を超えている。 ２.４.３ メタファとは？ 直訳すると、暗喩、隠喩、暗に指す言葉などを意味する。ここでは「対象が目に 見えない場合、その表現法として現実に 存在する具体物やよく知っている事象を用 いる」ということになる。 今使われているメタファの種類は以下のとおり： デスクトップメタファ システムを机に例えるメタファであり、現在のパソコン／ワークステーション上で は完全に主流の位置を占めている。 ルームメタファ 作業環境を「部屋」と捉えるメタファである。実際にはデスクトップを複数持った だけの物も多いが、今後グループウェア応用が増えるに従って必然性が高まると考 えられる。 ブックメタファ 本の有する操作感を持たせたメタファで、ＰＤＡなどで採用される。 他に、モニターなどを通さず、デジタルの世界を実世界に投影することで実世界 と同一化する手法もある。それについては２章：背景知識と関連研究のまとめの 「Augmented Reality」や、「Ubiquitous Computing」として紹介される。
２.４.４ リアルワールドメタファ そのような「メタファの矛盾」をなくすことによって、より自然にシステムを表 現するには、リアルワールドメタファを使うことによってメタファの限界をなくす ことがかなり有効な手段である。リアルワールドメタファはすでに商品レベルでの 適用が開始しており、General Magic 社のＰＤＡ用ビジュアルインターフェースで ある MagicCap が恒例である。MagicCap のインターフェースは具体的作業をする ための部屋と、いろいろな部屋に行くための廊下、複数の部屋をまとめたビル、さ
らに様々なビルが立ち並ぶ街路といった複数の階層から構成される。ワープロで文 書を作りたければ自分の部屋のデスクトップに行って作業をする、医者のアポイン トメントを取りたければ外に出て病院のビルを探して受付の部屋に入って予約作業 をするといった調子である。リアルワールドメタファはビジュアルインターフェー スの発展の流れからみても自然であり、今後のパソコンやＰＤＡの主流になること も予想される。 本研究では、主に自分が持っている複数の部屋の実装である。上記の MagicCap の例で触れた「ビル」や「街路」などの要素を、ネットワークを用いて他人の部屋 へ接続することによって実現する。
第３章 システムの設計
第１章で述べたように、デスクトップメタファやコンソールなどの表現方法では、 どうしても抽象的なイメージを使わざるを得なくなる。例えばフォルダの中にまた 何層もフォルダが入るようなファイル構造、ショートカット、チャットにおけるチ ャンネルやユーザーリスト、ＯＳではユーザー権限や個人領域などがあげられる。 これらはシステムの構成上必要不可欠な要素ではあるが、ユーザーがそれを理解 するにはヘルプを熟読するか、時間かけて習得するしかなかった。それに対して、 複雑な機能はなるべく見えないところで処理して、ユーザーにより高レベルなイン ターフェースを提供するのが本研究の目的である。その手法としては冒頭で述べた ように、メタファを変えることによって実現したいと思う。 冒頭で述べたように、デスクトップメタファやルームメタファにはそのメタファ の限界が存在する。限定されたメタファでは、その範囲を越えることができないの で、そのメタファの範囲を拡大させることで表現力の拡大を狙い、より直感的に操 作できるようなインターフェースをデザインしていく。 また、本研究のもう一つの目標は、インターネットを通じてのコミュニケーショ ンをより楽しくすることである。いまあるチャットソフトの大半は、まだテキスト ベースのままである（図３−１）。テキストベースでも意識の疎通はできるが、下記 のような欠点がある： １、話題が把握にくい： 同じチャンネルに居る限り同じウインドウに表示されるので、同時に複数の話 題を展開することが難しい。また、チャンネルを別々にすると、今度は大人数 での会話ができなくなる。 ２、発言者を確認する手間がかかる： 前項と同じ理由で、会話の流れを会話の内容だけではなく、発言者を確認しな がら判断していかないといけない。図 ３-1 もっとも代表的なチャットソフト、ＩＲＣの画面。 それに対して、かなりのユーザーが不満を抱いているが、長い間、それを取って 代わるものが無かった。しかし、意外なところでチャットを楽しんでいる人もいる。 ネットワークゲームである。図３−２は、ネットワークゲームの専門誌、「プレイオ ンライン」が去年実施したアンケートである。読者にネットワークをする理由、ネ ットワークゲームでもっとも楽しみにしていることについてアンケートを実施して、 このような結果がでた。一目見て分かるように、ゲーム自身よりも、チャットを楽 しむ人が明らかに多い。とくに女性の約半数はそれを理由にネットワークゲームを するという驚くべき結果が出てる。このアンケートの結果で分かるように、ネット ワークゲームのようなインターフェースはコミュニケーションする上では優れたデ ザインと言える。 アンケートの詳細を見ると、テキストベースのチャットが気軽に楽しめない、知 らない人とチャットするのが難しい、共通の話題を用意できないなどなどの理由が ある。それに応えて、グラフィカルなインターフェースを用意することでより多く の人がチャットを楽しめる環境を作るのがシステムを設計する上での第二の目標で ある。
0
20
40
60
80
100
チャッ
トがで
きる
競争
相手
がいる
他人
と協力
できる
その
他
ネットワークゲームをする理由アンケートに対する
回答：
男性
女性
図 ３-2 プレイオンライン誌が実施したアンケート結果３.１ コンセプト
前章でも説明した通り、使いやすいインターフェースの構築は、いかにユーザー が実生活で身についた能力をいかに生かせるかが最大の課題である。デスクトップ メタファやコンソールなどの表現方法が直感的に理解できない理由には以下のよう なことが考えられる： ユーザーを表すオブジェクトが存在しない： 人は自分自身に対して他の存在との相互関係なら簡単に把握できるが、自分以外 の複数ある物体の相互関係を把握するには直感的に理解できず、時間や経験を要す る。 操作に対する反応は直感的でない： 操作に対してシステムの反応は主にテキストで応答することが多いので、慣れな いシステムや機能を使いこなすのにユーザーが対話に集中しなければならない。 システムとの会話ができない： 人と対話することと異なり、システムはあくまで客観的な決められたメッセージしか返せない。人は対話する能力に優れているが、フローチャートを描いて行動を 決めることは不慣れである。 それに対しての解決法はこれらの手法が考えられる： 表現方法の変更： リアルワールドメタファの使用、システムを実世界に投影、あるいは拡大する。（前 章で述べたmetaDesk、ClearBoard などがその例である） マルチメディア、マルチモーダルの使用： 現在使われているＯＳでも操作に対して音声や、文字以外の画面表示（オブジェ クトの一部を点滅されるなど）を取り入れていて、ユーザーの注意を喚起するには 十分有用であるが、それをさらに延長して、音声や光、あるいは特殊なデバイスに よってシステムの表現力を拡張する。 エージェントの使用： エージェントとは、「人間の機能特性を模擬した構成要素からシステムを構築しよ うとする設計手法」である。システムとユーザーとの間に仮想のアシスタントを設 けることによって、ユーザーの対話する能力を生かせる。マイクロソフトのオフィ スシリーズが搭載しているアシスタントはその一例である。 これらの解決法の中で、エージェントは対話によって生じる曖昧さがあるので、シ ステムレベルで搭載するには不向きで、特定な環境を対象にしか実装できず、汎用 的な手法とは言い難い。マルチモーダルは特殊なデバイスを必要とするので、個人 単位で研究を進めるのは困難である。 それに対してマルチメディアとリアルワールドメタファとマルチメディアを活用す れば全ての操作環境において有効で、そしてそれらの操作環境を統合する際有効で あると思うので、本研究では、主にリアルワールドメタファを使用してシステム、 ユーザー、ネットワーク環境においては他のユーザーとの間の相互関係をユーザー が一目でわかる様にインターフェースを改善することを基本コンセプトとした。
３.２ 基本設計：
３.２.１ 表現方法と基本設計 リアルワールドメタファには２D と３D、そして色々な視点（どの方向から世界を 捉える）があるが、３D は遠近感把握しやすいが操作が複雑になる上、同時に画面 内の収められるオブジェクトが減るので作業の利便性に致命的な障害をもたらすの で今回は採用しない。パフォーマンスを確保すると同時に操作のしやすさを重視す るため、２D の画面に、世界を俯瞰する視点を採用する。 ソフトの見た目は、一個のウインドウの中に３２×３２ピクセルのマスによって 構成されたマップの上に、ユーザーは自分自身を表すキャラクターをマウスやキー ボードで操作し、オブジェクトの間を移動する形になる。１マスを３２×３２ピク セルにした理由は、ウインドウズの標準アイコンは３２×３２ピクセルだからであ る。マップ全体のことを部屋、あるいは家としてとらえることができ、ユーザーは 自分の家を飾るような感覚でパーソナリティと機能性を両立させたデザインを自由 に設定できる。 ユーザーはデスクトップやほかのフォルダにあるプログラム、ファイル、フォル ダなどをメインウインドウにドラッグアンドドロップすることによって、そのアイ コンの絵をそのまま表示した、ショートカットの機能を持つオブジェクトを生成す る。このように、Windows にすでにある機能をうまく取り入れることによって、ほ かのアプリケーションとの連携がよりスムーズに行える。図 ３-3 コンセプト 一回登録したオブジェクトはあとで自由にカスタマイズでき、絵を差し替えるこ とによって部屋のデザインに合わせることや、より分かりやすい絵柄に変えるなど のニーズに応えることができる。 ３.２.２ システム機能 本研究の目的とするアプリケーションはリアルワールドメタファによるインター フェースを実装したもので、リアルワールドメタファの有用性を立証するために、 なるべく多くの機能をシステムに取り入れたい。そこで、パーソナルコンピュータ に搭載されているオペレーティングシステムで主に使われている機能、そしてネッ トワークコミュニケーションを取り入れる。 基本設計段階でシステムに取り入る予定の機能は以下のとおりである ファイル管理 アプリケーションの起動 ネットワークを使用して他のユーザーとコミュニケーション ネットワークを使用して他のユーザーとファイル交換 ユーザー同士の権限を制御する
それらを実現するためのシステムを維持するためには マップ／部屋の編集ツール ユーザー管理機能 ネットワーク通信時におけるサーバー機能 オブジェクトの配置によって部屋の有効範囲を計算する など内部機能が必要になると考えられる。 ３.２.３ システムの構想 ユーザーが使用する際、ローカル環境においてはファイル操作とアプリケーショ ンの起動のみなので、画面を占める割合は少ない方が望ましい。一方ネットワーク 環境においては複数のユーザーが同じ画面を使用する、そしてチャットによるコミ ュニケーションはより直感的に表現するためメイン画面で表示するので、より広い 作業領域が必要になる。そのニーズに応えて、作品はサイズ変更可能か、スクロー ル可能、あるいは両方の機能を備えなければならない。 一人のユーザーが複数の部屋を保有することによって、必要とされる環境を別々 に保持することが可能である。これはルームメタファから得たヒントの応用で、デ スクトップメタファ環境でたとえると、複数のデスクトップを保持できることにな る。これによって使用状況にあわせてすばやく対応できる。 ３.２.４ 環境編集機能 ユーザーの作業環境を整えることができるように、さまざまなツールを用意し なければならない。まず、ドラッグ＆ドロップの操作でファイルやフォルダを登録 することができる。操作の多くはより直感的に行えるようにするため、右クリック で出るポップアップダイアログで操作を行えるようにする。右クリックしたマスの 内容によってポップアップダイアログの内容が自動に更新され、行えない操作は最 初から実行できないようにする。その際、よりシステム全体を把握やすくため、表 示しないのではなく灰色表示にして選択できなくすることによって初心者の混乱を 避ける。
図 ３-4 状況によって違うメニュー項目を表示する 以上の基本設計に踏まえて、４章のシステム実装に移る。
３.３ ネットワークの基本設計
ネットワークへの接続は、他のユーザーの部屋に入るのと、自分の部屋を開放し て他人の訪問を許可するのと２種類がある。サーバー側（部屋を開放する側）が特 に制限をかけない限り、何人でも接続することができる。 接続したあとはお互いを表しているキャラクターが画面上に表示され、文字を入 力することによってチャットできる。入力された文字は、キャラクターの頭上に表 示されることによって、今誰と話しているか、お互いの位置関係、他人との位置関 係などがより把握しやすく、チャットがより楽しくすることができる。 ３.３.１ 接続方法： ユーザーは自分で配置した“出入り口”に乗るという操作でネットワークと接続 する。家から出てほかの人の家を訪ねるという自然な動作と重なり合わせることに よって、初心者でも簡単にサーバーと接続できる。 接続する操作にあわせて、画面上にダイアログを表示し、IP アドレスとポート番 号の入力を待つ。入力するとサーバー側から部屋のデータを受け取り、相手の了承 を得た後他人の部屋に入ることができる。その際、操作の利便性を図るためブック マークの機能も実装したい。 ３.３.２ 接続を受け入れる： メニューで“接続を許可する”という項目を選択すると、接続を受けいれること ができる。接続した後マップの変更やアイテムの追加、削除などの操作を許可する とログイン中のほかのユーザーにいろいろ影響を与える、また急に部屋を丸ごと変 更するとほかのユーザーは困惑するので、ネットワーク接続を受け入れる操作をし た後部屋の変更が一切できないようにする。接続中に変更できるのは、自分を代表 するキャラクターの名前と見た目だけとした。接続を受ける側は、部屋の状態をビットマップ形式で送信する。そうすることに よって、例え相手が持っているマップセットやオブジェクトのビットマップが違っ ても、自分でカスタマイズした部屋をそのまま見せることができる。 図 ３-5 接続許可のメニュー項目 ３.３.３ ログオンする側の制約 他人に部屋に入る側（クライアント）は様々な制約を受けることになる。それは、 サーバー側の安全性を保つためと、ネットワークはあくまでコミュニケーションの ために実装したもののため、リモートコントロールなどの操作を想定していないか らである。 まず、ファイルやフォルダなどは自由に操作することができない。ショートカッ トはサーバー側にインストールされているものなので安全性のために完全に禁止し、 フォルダはサーバー側が許可したもののみ内容を参照することができる。閲覧でき るだけではあまり意味ないので、できればそれをダウンロードできるように実装を 進めたい。
３.４ クラス設計図
メインクラス
Ｇ
Ｕ
Ｉ
ユーザー
操作
対話
スプライト
クラス
管理
他のユーザー
通信
管理
マップ
クラス
図 ３-6 クラス設計図 図３．６は、本章で設計したクラス間の相互関係を図に表したものである。図で示し たように、メインとなるクラスをＧＵＩから切り離すことによって、必要に応じて（こ の場合はオンラインとローカル環境）操作の受け付けをするクラスを差し替えることが できる。次章で説明するマップマネージャークラス、そしてクライアントクラスがそれ に当たる。最大の違いは、ローカル環境用のマップマネージャークラスはマップデータ を管理する必要があるが、ネットワーク用、つまり他人の部屋に訪問するユーザーはマ ップを管理しない点である。これによって、マップデータはサーバーとなるユーザーの マップマネージャークラスによって統一され、通信のミスやパケットロス、タイムラグ などの通信トラブルよってクライアントとサーバーのデータが一致しないような状況を 防ぐことができる。 スプライトクラスは、ユーザー本人のデータとログインしてきたユーザーの管理を行 う。中にはキャラクターを表示するための位置情報、ビットマップ、名前などが保持さ れている。また、他のユーザーと通信をするためのソケットクラスもこのクラスに実装 することによって、ユーザーに関連する操作をこのクラスで統一することができた。ＧＵＩはウインドウズプログラムでよく見かけるウィンドウクラスで、キーイベント、 マウスイベントやタイマーイベントなど本ソフトの中でのシステムと対話する部分を担 当する。いまのモードに合わせて適切なクラスを呼び出して操作の応答をする。 細かい機能を実現するにはいろんなクラスを実装しなければならないが、メインとな るクラスとその間のやり取りは図３−６で示すことが出来ているので、以上でクラスの 基本設計ほぼ完成したと言える。次章では、これらの設計に沿って実装を進めたいと思 う。
第４章 システムの実装
前章の設計を踏まえて、この章では，本研究の実装をどのように行っているのかと いうことを述べる。まずはじめに，アーキテクチャについて述べる。４.１ アーキテクチャ
４.１.１ マップマネージャークラス 本研究において最も多くデータを保持している、そしてメインとなるクラスであ る。マップマネージャークラスはマップを表すクラスと、本ソフトを制御するため の関数を保持している。マップ構造体は以下のデータを保持している： 1. そのマスに存在しているオブジェクトのタイプ 2. そのオブジェクトのポインタ 3. マップの地形データ ソフトが起動するとき、マップ上のマスの数だけマップクラスを生成し、二次元 配列のベクタークラスに格納し管理する。その後オブジェクトやキャラクターの生 成／移動／削除などの状況変更する際マップクラスを変更することによって、マッ プ上の全てのマス情報を管理する。 後述するセルクラス、スプライトクラスなどがユーザーの操作によって状況変更 するときも、このクラスのデータを参照して行う。 他に、サーバーモードやローカルで使用するときの全ての操作を管理しており、 マップのサイズが変更した時などはこのクラス経由でウインドウサイズの変更を行 う。また、スプライト、セル、を種類別に数個のリストに分けて保存して必要に応 じて追加・削除などの操作を行う。 画面を描画する際、まず一枚の画面分の大きさを持っているビットマップクラス を用意する。そして、セットしたタイマーがタイマーイベントを送ってきた時に、 保持している全てのセルクラスとスプライトクラスに描画命令を出し、それぞれが 自分自身を表示用のビッドマップに合成する。スプライトクラスは操作によって登 録されたアニメーションをタイマーに合わせて発動するので、マップ上でアニメー ションをしているように見せることができる。４.１.２ クライアントクラス 他人と接続する時に使うクラスである。ユーザーが他人の部屋に入るとき（クラ イアントモード）はこのクラスが表示／データの管理をする。機能的にはマップマ ネージャークラスとそれほど変わらないが、マップクラスを持たないのが最大な特 徴である。複数のユーザーがサーバーにログインしている時に、個々のユーザーが 各自のマップデータを持っていると、通信のタイムラグなどによってお互い重ねあ ったり、サーバー側のデータと矛盾して移動しようと思ってもサーバー側が許可し ないことが考えられる。それに解消法として、全てのデータ管理はサーバー側に任 せて、自分を表すキャラクター含めて全てがサーバー側からのメッセージで稼動す るようにした。このクラスは、サーバーに居る人数分だけのスプライトクラスのリ ストと、操作や表示に必要なメソッドしか持たない。 図 ４-1 接続の様式図 ４.１.３ セルクラス マップ上に配置されるオブジェクト（ショートカット、フォルダ、壁、家具など） を現すクラスである。数種類のオブジェクトを収納できるため、それらの必要なア トリビュートと種類を識別するための変数を持っている ショートカットとフォルダはそれのフルパスであらわす文字列を保持して、呼び 出されるときそれで実行できる。フォルダかショートカットかは登録した時点で判
別して、判別するための変数に格納する。またアイコンをそのまま表示できるよう に、登録された段階でそのファイルに関連付けされたアイコンを抽出して保持する。 壁、家具など特に動作が用意されてないオブジェクトはただの障害物や飾りなので それらの要素をもたない。 そしてそれらが共通に持っている要素は、セルを配置した位置、アイコンや家具、 壁などの絵柄を保持するビットマップクラスである。ユーザーが頻繁に登録・削除 や内容の変更を行うことも考えられるので、そのインスタンスはマップクラス内に リスト構造で保持する。図４−１は家具や壁などの絵を表しているビットマップフ ァイルの一例である｡たくさんの種類の障害物や家具などを用意して、ユーザーはそ の中から自由に選択して部屋を飾ることができる。ユーザーが家具や壁などを登録 した時、その中から３２×３２の分だけ切り取って、セルクラス内にコピーする。 図 ４-2 セルクラス用ビットマップの一例 ４.１.４ スプライトクラス ユーザーを表すキャラクターと、それと関連するデータを保持するクラスである。 このクラスは以下の要素を保持する： １、ユーザーの名前 ２、ユーザーが使用しているキャラクターのビッドマップ ３、現在位置 ４、動作中であるかどうかを示すフラグ ５、メッセージを保持・表示する機能を持っているメッセージクラス ６、アニメーションを記憶するアニメーションクラス
キャラクターを表示するビッドマップは、同じキャラクターを４つの方向から見た 画像を、方向ごとに３枚の画像（右足前に出す、左足を前に出す、普通に立ってい る）を持たせることによって、ユーザーの操作に応じて全方向のアニメーションを 実現することができる。 図 ４-3 キャラクターを表すビットマップ アニメーションする時はマスをまたがることがあるので、現在位置はマップの位置 ではなく、画面の座標である。後述する画面に表示するメソッドなどはこの値を参 照して、座標に合わせて表示する。 また、スプライトクラスは以下のメソッドを実装してある： １、現在位置に合わせて画像を表示するメソッド ２、必要に応じて移動アニメーションを登録するメソッド ３、移動のアニメーションがない時、その場で動くメソッド ４、タイマーによって登録されたアニメーションを使用して、表示位置を変更する メソッド アニメーションクラスは、単に方向と、移動する距離と移動の際に表示されるアニ メーションしか保持していない単純なクラスである。操作に応じて、例えば“右に 移動する”という命令を受けた時、あらかじめ目的地までの４枚のアニメーション （左足だす、両足そろう、右足出す、目的地に立っている）を登録する。そして、 事前にセットしたタイマーのタイマーイベントによってそれが発動していく仕組み である。
４.２ システム構築上に必要なクラス
４.２.１ ビットマップクラス 本研究でデザインしたシステムは、頻繁に合成やコピーを行うので、既存のライ ブラリを使わず独自のクラスを実装した。効率を確保するため、ＷＩＮ３２ＡＰＩ を通して操作するのではなく、メモリーを直接比較する。独自に実装する最大の理 由は、合成をするときに、抜き色（透明色）をコピーしないようにするためである。 透明色は普段使われることの無い極端的な色（真緑、真っ青など）であり、実装では、ピクセルのＲＧＢ値を比較して、３つの中に二つが０で、残った一つが最大値 の２５５の時はコピーや合成を行わない。こうすることによって、自由にビットマ ップを自然に、そして効率よく重ねることができる。メモリー上で編集すると画面 上に表示する動作を同じクラスで実現するため、DIBSECTION 形式のビットマップ を使用する。 また、作業の利便を図るため、ビットマップ関連のメソッドを多数実装してある。 １、ビットマップをファイルからロードメソッド ２、ビットマップをファイルにセーブメソッド ３、ビットマップをＤＣに描画するメソッド ４、ビットマップをビットマップにコピーするメソッド ５、ビットマップ同士を合成するメソッド などを実装した。これによって、全てのクラスが簡単にビットマップを扱うことが できる。 ４.２.２ アイテムダイアログクラス 特殊な使い方なので、既存のクラスでは使えず、ダイアログクラスも自分で実装 する必要があった。ユーザーにより簡単に部屋をカスタマイズできるために、より 直感的な操作ができるインターフェースを実装する必要があった。それが、このダ イアログクラスである。 図 ４-4 右クリックメニュー ユーザーは変更したい場所で右クリックして、変更したい項目を左クリックする と、特殊なダイアログクラスがその場で現われる。
図 ４-5 アイテム選択ダイアログ 表示されたダイアログはシステム標準の、あるいはユーザーが自分で用意したオ ブジェクトを集めたものである。キャラクターの右上の方で見える緑色の四角いカ ーソルで好きなオブジェクトを選ぶことで、その場所にオブジェクトを配置したり、 地形を変更することができる。 図 ４-6 アイテム選択ダイアログに使用例 このダイアログが特殊なところは、呼び出す際に引数として受け取るビットマップ クラスへのポインタとフラグによって、ビットマップに合わせて大きさを変えて表
示することである。そして、マウスポインタがさしている場所にカーソルを表示し ていまどのオブジェクトを選択しているかを分かりやすく表現する。そして、シン グルクリックでそのオブジェクトを選択した後、呼び出す際のフラグによってアイ テムの登録・削除・変更などを行う。また、操作に間違いがあるときなどダイアロ グをキャンセルしたい時は、他のところをクリックなどの操作でアイテムダイアロ グのフォーカスをはずすことによって消去できる。 ４.２.３ メッセージクラス ユーザーが入力したメッセージや、接続したほかのユーザーが入力したメッセー ジをそのキャラクターの頭上に表示することは前章に述べた通りで、それを実現す るためのクラスである。メッセージクラスはスプライトクラスの中に存在して、登 録や表示もスプライトクラスを経由して行う。これは、一つのキャラクター（スプ ライト）は同時に一つのメッセージしか出せないから、このように管理した方が合 理的である｡ このクラスはコンストラクタからメッセージを受け取り、それに合わせて入力さ れた文字を表示するビットマップを作成する。文字に吹きだしのような効果をつけ るため、直接画面に文字を描画するのではなく、メッセージの文字数に合わせて改 行や、長すぎるメッセージを削除して必要なサイズを算出し、それに合ったサイズ の背景を用意された背景ビットマップからコピーする。そしてその上にメッセージ を描画してから画面上に表示する。これによって漫画などでよく見られるような、 自然なメッセージ表示ができる。 図 ４-7 メッセージ表示
第５章 評価実験
本研究では、ＧＵＩ（グラフィカルユーザーインターフェース）の研究として、 リアルワールドメタファを使用したチャット、ランチャー機能を実装したソフトを 作成した。本章は、本研究で作成したソフトが当初予定されていたあるユーザーの 理解を手助けすることと、使いやすいインターフェースを構築するという二つの目 的が達成できたかどうかについて評価実験を行い、その実験方法及びその結果を記 録する。５.１ 実験方法
本研究が目標達成できたかどうかについて、知り合い数人に実際ソフトを使用し てもらって、評価実験を行った。本研究は主に初心者をターゲットとするため、ユ ーザーをパソコン歴や知識などでグループ分けして、グループごとに意見を聞くこ とにした。グループ分けは以下の通り： 上級者グループ：情報管理学科の学生、ネットワークでの知り合いなどパソコンを 使い慣れているグループ 初心者グループ：情報管理学科以外の学生、日常的にパソコンを使う習慣のない人 がメインとなるグループ 評価実験をする際、主に以下のポイントについて協力者の意見を求めることにした。 ローカル環境での操作性 理解の手助けになったかどうか チャットなどのネットワーク機能は使いやすかったのか ネットワーク環境とローカル環境の統合について５.２ 実験結果
協力者の意見をまとめた結果、上級者グループにはネットワーク環境とローカル 環境の統合、そしてグラフィカルなインターフェースについては評価だれたが、ロ ーカル環境の操作に自由度が足りない、無駄な操作がある、必要とされる機能が足 りないという意見が多い。チャットについては対話の相手を把握しやすいがログ機能を実装していないので、まだまだ改良する余地がたくさんある。 それに対して初心者グループはランチャー機能を使いこなせることができ、自分 の作業領域を構築して使うこともできた。チャットに関してもテキストベースのも のに比べて理解しやすいので使いやすいという意見が多かった。 協力者の意見をまとめた結果、上級者グループには理解を補助するようなソフト を必要としないので、見た目のかわいさ以外はそれほど評価されなかったが、初心 者グループは本ソフトの機能をよく使いこなせて、予定されていた理解を助ける目 的は達成できたと言える。機能を省いてもリアルワールドメタファを使用してなる べく分かりやすく実装する本研究のコンセプトとしては、予想通りの結果となった と言える。
第６章 まとめと今後の課題
６.１ 今後の課題
ネットワークとの共存はメイン目的でしたが、部屋を分けることでチャットのチ ャンネル機能を実装できなかった。マスにチャンネルに相当するデータを埋め込ん だが、それをユーザーの手でマスごとに入力してもらう形でしか変更できないので、 それを自動で行えるようにするのが今後の課題である｡ また、現在のバージョンでは主にウインドウズシステムとの共存を目的としてい るが、メタファの運用をより高いレベルで実現して、システム全体にリアルワール ドメタファを適用したいと思う。６.２ 結論
本研究では、様々なインターフェースの実験をしてきた。しかし、リアルワール ドメタファを使用しても大量の文字を使わなければならない箇所がある、また、ど うしてもリアルワールドメタファで統一することのできない機能もあった。しかし、 限定された機能とはいえ、パソコンの初心者の理解を助けることや限定された機能 でサービス提供したいときなどで役立てることが分かった。 また、ネットワークにおいてリアルワールドメタファの有用性も実証され、チャ ット環境としてはテキストベースに比べて理解のし易さや操作性などがかなり向上 できた。今後それをさらに拡張し、プリンタなどネットワークデバイスも使用でき るようにすることによってグループウェアの実現も可能である。しかし、現システ ムではデスクトップメタファのＯＳに依存している部分が多いので、今後は前節の 研究課題以外に、さらに有効なリアルワールドメタファの運用法の研究を進める必 要がある。参考文献：
（１）Ishii, H., "Tangible Bits: Feeling of Information, Awareness of Information IPSJ Magazine, Vol. 39, No. 8, August 1998
（２）Ishii, H. and Ullmer, B., Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms, in Proceedings of Conference on Human Factors in Computing Systems (CHI '97), (Atlanta, March 1997)
（３）Gorbet, M. and Orth, M. "Triangles: A Physical/Digital Construction Kit" In Proceedings of Designing Interactive Systems: Processes, Practices Methods and Techniques (ACM DIS '97), Amsterdam, ACM, August 1997
（４）Gorbet, M., Orth, M. and Ishii, H. "Triangles: Tangible Interface for Manipulation and Exploration of Digital Information Topography"Proceedings of ACM CHI '98, Los Angeles, ACM, April 1998.
（５）変わりゆくプログラミング / 市川忠男・平川正人 著 / 共立出版 / １９９５ （６） ｂｉｔ別冊 ビジュアルインターフェース―ホストＧＵＩを目指して / 平川正 人・安村通晃 著 / 共立出版 / １９９６
