JP2794339B2 - アプリケーションプログラムのユーザインターフェースを設計するプロセス - Google Patents

Description

【発明の詳細な説明】 発明の背景 1.発明の分野 一般に、この発明はコンピュータで動作するアプリケ
ーションプログラムに関し、より特定的に、この発明は
アプリケーションプログラムのためのユーザのインター
フェースを指定するためのプロセスに関する。

2.関連技術の説明 アプリケーション アプリケーション（またはプログラム）は人がコンピ
ュータを使用してタスクを行なうことを可能にするツー
ルである。たとえば、ワードプロセッサはコンピュータ
のユーザにレターを書き、ストアしかつプリントアウト
する方法を与える。作図プログラムはユーザがチャー
ト、図および組織図を作ることを可能にする。ユーザに
関する限り、アプリケーションは彼とコンピュータハー
ドウェアとの間のインターフェースである。しかしなが
ら、アプリケーションの見解から、もう１つの層があ
る。

オペレーティングシステム オペレーティングシステムはアプリケーションとコン
ピュータハードウェアとの間のインターフェースとして
作用するプログラムである。それはユーザがプログラム
を実行し得る環境を与える。オペレーティングシステム
はコンピュータシステムを使用するのに容易でかつ効率
的にするように試みる。コンピュータハードウェアと関
連するオペレーティングシステムはしばしば環境と呼ば
れる。これらの原理は、「オペレーティング・システム
・コンセプツ（Operating System Concepts）」でジェ
ームズ・ピーターソン（James Peterson）およびエイブ
ラハム・ツルバーシャッツ（Abraham Silberschatz）に
よって論じられる。

ユーザインターフェース ユーザインターフェース（UI）はそれによってコンピ
ュータシステムがそれを操作する人と意志を通じ合う１
組の規則および規約である。最初、オペレーティングシ
ステム（UNIXまたはMS−DOSのような）はテキストベー
スのコマンドラインインターフェースを特徴とした。ユ
ーザは「enscript−2Gr−Plw」のような複雑で忘れられ
やすいコマンドを使用しかつ覚えていることを求められ
た。異なったアプリケーションはすべて異なったユーザ
インターフェースを有した−−現在のドキュメントをプ
リントするためには、ユーザはワードプロセッサではフ
ァンクションキーF7を、データベースプログラムではキ
ーCtrl−Alt−Ｐを押さなければならないであろう。コ
ンピュータは学習するのが困難であり、使用が困難であ
り、かつ最も悪いことに一貫していなかった。「ユーザ
フレンドリネス」として知られるしばしば新造されるプ
ロパティを追求して、多くの作業がユーザインターフェ
ースを改良することに関して行なわれた。パーソナルコ
ンピュータ市場が全体として急速にかつ劇的に変化して
いるように、ユーザインターフェース標準もまた変化し
ている。

何年にもわたって、オペレーティングシステムはUNIX
またはMS−DOSのような複雑なテキストベースのコマン
ドラインインターフェースから、Apple Macintoshおよ
びMicrsoft Windowsのようなグラフィカルなウィンド
ゥインターフェースに発展してきた。これらの新しいグ
ラフィカルなユーザインターフェース（GUI）はマウス
によってアクセスされるメニュー、ボタンおよびウィン
ドゥを特徴とする。これらのインターフェースのグラフ
ィカルな直観的な性質は初期のオペレーティングシステ
ムに固有の問題の多くを解決した。GUIは典型的にウィ
ンドゥ、ボタンおよびメニューのようなユーザインター
フェース小道具の大きなツールキットを与える。アプリ
ケーションはこれらのUI項目を利用してそのユーザとの
対話を実現化する。一貫していないアプリケーションイ
ンターフェースにより混乱が生ずるのを回避するため
に、各企業はUI小道具を使用するための規則および規約
を開発している。スタイルガイドとして知られるドキュ
メントは、システムによって提供されたユーザインター
フェース小道具の適切な使用をアプリケーション設計者
に教えるために影響されている（より詳細な情報につい
ては付録Ｄ、「スタイルガイド」を参照）。かかるユー
ザインターフェース標準のいくつかの例はOSF/Motif、O
penLook、CUA、NewWaveおよびMacintoshである。これら
の標準の各々を特定ユーザインターフェースとしてここ
で参照する。

しかしながら、WindowsまたはMacintoshのような「ユ
ーザフレンドリな」環境のために開発されたアプリケー
ションでさえ使用が困難になり得る。アプリケーション
が強力になればなるほど、いくつかのアプリケーション
はまたますます使用するのが困難になった。これらの新
しいプログラムでユーザが行なうことができる非常に多
くの魅力的でかつ複雑なことがあるので、常に使用する
のが容易なユーザインターフェースを作ることは非常に
困難である。GUIコミュニティの新しいコンセプトはこ
の問題と折り合いをつけるように試みる。それはスケー
ル可能な（scalable）グラフィックユーザインターフェ
ースである。かかるGUIは同一のアプリケーションが様
々なレベルの機能でアクセスされることを可能にする。
これらのレベルはユーザが２、３のボタンを押すことの
みしか要求されないアプライアンスモードから、初心者
コンピュータインターフェース（タンディ（Tandy）の
登録商標デスクメイト（Deskmate）など）、登録商標Mo
tifインターフェースのような一人前のプロフェッショ
ナルなグラフィックユーザインターフェースまでにわた
る。ユーザはその技術および必要性が大きくなるにつれ
て、より強力な特徴にアクセスするためにインターフェ
ースレベルを単に切換えるだけでよい。そこで、もしユ
ーザが素早くレターまたは封筒をタイプしたいと思うだ
けであれば、ユーザはページからページに続くテキスト
の多数のカラム、およびドキュメント全体にわたってラ
ンダムに配置されるグラフィクスを含むニュースレター
を作成するために設計されたプログラムを苦労して操作
する必要はない。ユーザは単にアプライアンスモードで
ワードプロセッサを実行し、非常に多くのオプションを
設定することなく、かつ非常に多くの余分な特徴の中か
ら方法を選ぶことなく単純なレターを苦労せずにタイプ
することが可能である（スケール可能性（scalabilit
y）がどのようにスタイルガイドに関連するかについて
は、付録Ｄ、「スタイルガイド」参照）。

アプリケーション開発 アプリケーションは常に開発するのが困難でかつ時間
がかかった。しかしながら、コンピュータソフトウェア
産業の変化しやすくかつ多様な性質のために、異なった
特定ユーザインターフェース標準のもとで実行するアプ
リケーションを作ることは多大な努力を必要とした。過
去においては、アプリケーションのほとんどすべては様
々な標準に従うようにしばしば書き直され、各バージョ
ンはしばしば別々に販売用に提供された。

いくつかのアプリケーションはスケール可能なGUIコ
ンセプトをある程度実用化した。Microsoft Wordのよ
うなプログラムは「フルおよび簡易メニュー」モードを
有し、初心者はメインメニューから上級コマンドを単に
除去することによって上級機能を隠す「簡易メニュー」
を選択することができる。しかしユーザは依然としてだ
れにも頼らずに多数のウィンドゥおよびプルダウンメニ
ュー、十分困難なコンセプト、に取り組まなければなら
ない。しかしながら、ほとんどのプログラムはこの制限
されたスケール可能性さえ特徴としていない。通常、も
しユーザが単純なワードプロセッサと上級のワードプロ
セッサの双方をほしければ、ユーザは２つの別個のパッ
ケージを購入しなければならないであろう（実際いくつ
かのソフトウェア発行者はその製品ラインで様々な複雑
さのいくつかの類似のパッケージを提供している。

図面の簡単な説明 図１は従来のアプリケーション設計プロセスを例示す
る。

図２はこの発明に従うアプリケーション設計プロセス
を例示する。

図３はダイアログボックスを例示する。

図４はメニューである。

図５はスクリーン上の画素を例示する。

図６はスクロールバーを例示する。

図７はスクローリングリストを例示する。

図８はサブメニューを例示する。

図９はツリーデータ構造におけるオブジェクトの階層
化を例示する。

図10はウィンドゥを例示する。

図11はセールスマン例を例示する。

図12は包括的ユーザインターフェースオブジェクトの
GenTriggerクラスおよびそのクラスの２つのオブジェク
トを例示する。

図13はサンプル包括的ユーザインターフェースツリー
を例示する。

図14は図13のサンプルユーザインターフェースツリー
のオンスクリーン実現化例を例示する。

図15は先行技術のMacintoshアプリケーションのサン
プルユーザインターフェーススクリーンを例示する。

図16は先行技術のOS/2アプリケーションのサンプルユ
ーザインターフェーススクリーンを例示する。

図17は従来のユーザ対話を例示する。

図18はこの発明に従うユーザ対話を例示する。

図19はプリントダイアログボックスのためのよいレイ
アウトを例示する。

図20はプリントダイアログボックスのための好ましく
ないレイアウトを例示する。

図21はこの発明に従った要素を組込むコンピュータシ
ステムを例示する。

図22は先行技術のコンピュータシステムを例示する。

図23はドキュメントコントロールオブジェクトを例示
する。

図24は図23のドキュメントコントロールオブジェクト
の登録商標NewWave解釈を例示する。

図25は図23のドキュメントコントロールオブジェクト
の登録商標OpenLook解釈を例示する。

図26は図23のドキュメントコントロールオブジェクト
の登録商標Motif解釈を例示する。

図27はリストオブジェクトおよびそのオブジェクトの
ためのインスタンスデータとして使用することが可能な
いくつかの可能性のあるヒントを例示する。

図28は図27のリストオブジェクトの登録商標NewWave
解釈を例示する。

図29は図27のリストオブジェクトの登録商標OpenLook
解釈を例示する。

図30は図27のリストオブジェクトの登録商標Motif解
釈を例示する。

図31は３つの可能な小道具選択肢（Abbreviated Men
u Button、Exclusive SettingsおよびScrolling Lis
t）を与えるスタイルガイドインタープリタを、スクリ
ーン表示の例および各々のためのスタイルガイド解釈規
則とともに例示する。

図32は仮定上のユーザインターフェースのための２つ
の可能な小道具選択肢（Graphical Radio Buttonsお
よびScrolling List）を与えるスタイルガイドインタ
ープリタを、スクリーン表示の例および各々のためのス
タイルガイド解釈規則とともに例示する。

図33は包括的ユーザインターフェースオブジェクト、
および登録商標OpenLookユーザインターフェース、およ
び包括的オブジェクトの仮定上のユーザインターフェー
ス解釈を例示する。

図34はサンプル包括的ユーザインターフェース仕様を
例示する。

図35は登録商標Motifまたは登録商標OpenLookのもと
での図34の仕様を有するオブジェクトの解釈を例示す
る。

図36は仮定上のユーザインターフェーススタイルガイ
ドのもとでの図34の仕様を有するオブジェクトの解釈を
例示する。

図37は上級モードにおける将来の仮定上のユーザイン
ターフェースのもとでの図34の仕様を有するオブジェク
トの解釈を例示する。

図38は初心者モードにおける将来の仮定上のユーザイ
ンターフェースのもとでの図34の仕様を有するオブジェ
クトの解釈を例示する。

図39は手続貸プログラミング規則を使用するこの発明
の原理の実現化例を例示する。

図40は方法へのポインタを使用するオブジェクトを使
用するこの発明の原理の実現化例を例示する。

図41はクラス構造へのクラスポインタを有するオブジ
ェクトを使用するこの発明の原理の実現化例を例示す
る。

図42はコンピュータシステムのアクションを作るため
のアプリケーションでの先行技術のユーザ対話を例示す
る。

図43はコンピュータシステムのアクションを作るため
のこの発明に従うアプリケーションでのユーザ対話を例
示する。

図44は特定のユーザインターフェースのための特定ユ
ーザインターフェース仕様の先行技術の開発および用途
を例示する。

図45は多数の特定ユーザインターフェースインタープ
リタ（たとえば登録商標Motif、登録商標NewWaveおよび
登録商標OpenLook）のいずれかとともに使用するための
包括的ユーザインターフェース仕様の開発および用途を
例示し、かつかかる包括的ユーザインターフェースを使
用してかかる異なった特定ユーザインターフェースイン
タープリタを使用する異なったオンスクリーンディスプ
レイを作る方法を例示する。

好ましい実施例の詳細な説明 この発明における原理を説明する前に、一群の専門用
語を以下のように定義することは有用である。

小道具ツールキット ウィンドゥ、メニュー、ボタン、スクローリングリス
ト、ラジオボタン、スクロールバーなどのようなコンポ
ーネントのセット。各特定ユーザインターフェースのス
タイルガイドの一部はそれ自体これらのコンポーネント
の一覧、定義および用途に関連する 包括的UIオブジェクトクラス 同一の型のデータおよび方法を有する包括的UIオブジェ
クトの集まり 包括的UIオブジェクト アプリケーションの入力／出力要求を示すUIコンポー
ネント（スクローリングリストのような視覚に関する仕
様に対抗する。）例の中にはドキュメントコントロー
ル、排他的リスト選択および視野エリアが含まれる。

包括的UIオブジェクトライブラリ 任意の特定の小道具ツールキットに関係なくインター
フェースを特定するために利用可能な包括的UIオブジェ
クトおよびヒントのセット 包括的ユーザインターフェース仕様 オブジェクトおよびヒントの選択および編成を含む包
括的UIオブジェクトライブラリからのオブジェクトに基
づく特定のアプリケーションのために設計されたインタ
ーフェース 包括的から特定的へのUIインタープリタ（UI Intepret
er） 包括的UI仕様を解釈して特定UIのスタイルガイド要求
および勧告に合うような方法でアプリケーションのオン
スクリーン表示を作り出すソフトウェア ヒント デジタル的にストアされたアプリケーションのための
人間／コンピュータインターフェース規準の実施例。か
かる規準の例は以下のとおりである。

・「めったに使用されない特徴」 ・「先進的特徴」 ・「できるだけ大きくディスプレイするべきである」 特定ユーザインターフェース Motif、Open Look、WindowsまたはMacintoshのよう
なそのユーザインターフェースのスタイルガイドによっ
て示されるような特定のユーザインターフェース仕様の
ルックアンドフィールのみ（つまりAPIおよびソフトウ
ェアから分離されたユーザインターフェースのエンドユ
ーザの知覚） 特定ユーザインターフェース仕様 特定ユーザインターフェースの小道具ユーザキットか
ら小道具に基づいた特定のアプリケーションのために設
計されたインターフェース GEOSアプリケーション設計プロセス このプロセスは実行可能な同一のアプリケーションが
各々のためのスタイルガイド要求および忠告を満たしな
がら任意の数の特定ユーザインターフェースのルックア
ンドフィールを示すことを可能にする。図２の例示的な
図面はこの発明に従うアプリケーション開発プロセスを
示す。包括的オブジェクトおよびヒントフォーマアット
にストアされ得るアプリケーションのインターフェース
要求および主観的考察についての情報が多ければ多いほ
ど、異なったまたは新しい特定ユーザインターフェース
のためのUIインタープリタのもとで実行しているときに
アプリケーションのために作られ得るインターフェース
はよりよくなる。包括的モデルは本質的にアプリケーシ
ョンをそのユーザインターフェースから分離するので、
アプリケーションは特定ユーザインターフェースの変化
とは完全に関係がない。アプリケーションのユーザイン
ターフェースは特定のUI小道具の細目よりはむしろ共通
の意味的プロパティの点でもっぱら特定されるので、ア
プリケーションのユーザインターフェースは新しくかつ
異なった特定ユーザンインターフェースのもとで適切に
構成されかつ示されることが可能である。新しいスタイ
ルガイドのための新しいUIインタープリタは実行可能な
アプリケーションを作った後に書込まれることが可能で
あり、かつアプリケーションのユーザインターフェース
は新しいスタイルガイドに従って示されるであろう。こ
れが意味することは新しい改良されたユーザインターフ
ェースは、単にアプリケーションのUI要求についての機
能的であるとともに主観的な情報がアプリケーションと
ともにストアされるので、元のアプリケーション設計者
によって想像されたものをはるかに越える新規でかつ素
晴らしい能力を加え得るということである。同様に、熟
練の様々なレベルを有するユーザに向けられた特定ユー
ザインターフェースが規定され得るので、実行可能なま
さに同一のアプリケーションもまた初心者、平均的およ
び上級ユーザのどれにも適切に与えられ得る。

そこで問題はどのようにしてアプリケーション入力／
出力要求および主観的設計考察をデータの中で正しく示
すかということである。GECSプロセスは伝統的な小道具
ツールキットを包括的UIオブジェクトライブラリと取り
換え、主観的、記述的考察をヒントにデジタル的にスト
アする。

包括的UIライブラリvs.小道具ツールキット 前述のように、従来のオペレーティングシステムは開
発者に小道具ツールキットを提供する。これらのツール
キットは多数の単純であるとともに洗練されたユーザイ
ンターフェースコンポーネントを与えることを一般に試
みる。この考えは多量の低レベルの基本ブロックがあれ
ば、インターフェース設計者はサイズ、速度および複雑
さ問題のバランスを保つことができるような方法で、そ
れらを使用し組合わせかつ編成することが可能であると
いうことである。

残念ながら、ユーザインターフェースを規定するこの
方法は、アプリケーションの核心の基本的な入力／出力
要求または能力を記述しかつストアするタスクにはあま
り向いていない。そしてそれは利用可能な小道具から選
択しそれらをレイアウトするために設計者が考察した生
の主観的情報を全く何も示さない。

包括的UIオブジェクトライブラリはこれらの制限を克
服する。入力／出力要求は可能な最高レベルまで抽象化
される。機能的要求は認識され、包括的UIオブジェクト
クラスと呼ばれる別個のカテゴリに置かれる。以前はUI
設計者の心の中にのみ存在した記述的思考および考察
は、アプリケーションおよびそのユーザインターフェー
スの、ヒントとして知られる、特性としてストアされ
る。

以下の部分はどのようにして新しいモデルが実際的レ
ベルとともに概念的レベルで先行技術を実質的に改良し
ているかについて詳しく説明する。

スコープの抽象化 任意の数の異なった特定ユーザインターフェースで所
与のアプリケーションを適切に与えるために、アプリケ
ーションの多くのより高いレベルの機能要求を抽象化す
ることが必要である。さもなければ、他のスタイルガイ
ドの要求と食い違うインターフェースを、あるスタイル
ガイドのために定めてしまう危険がある。たとえば、２
つのスタイルガイドは「File」メニューにおいて何が現
われなければならないかについての要求において矛盾ん
するかもしれない。

仮定上の特定UI「Ａ」例 スタイルガイド「Ａ」は「File」メニューが以下のメ
ニュー項目を有することを必要とする。

New−−新しいドキュメントを作る Open…−−以前に作られたドキュメントを開く Close−−開かれたドキュメントを閉じる（ユーザは
変化を保存すべきかどうか選択する） Save−−変化を保存するがドキュメントを閉じない Save As…−−別名のもとで変化を保存し、元のドキ
ュメントはそのままにする Copy To…−−修正されたドキュメントを別のファイ
ル名に複写する Exit−−プログラムから抜ける（ユーザはドキュメン
トを保存すべきか閉じるべきかを選択する） 特定UI「Ｂ」 スタイルガイド「Ｂ」は「File」メニューが以下のメ
ニュー項目を有することを必要とする。

Create−−新しいドキュメントを作る Open…−−以前に作られたドキュメントを開く Close−−ドキュメントを閉じかつ保存する Quit−−プログラムを終了する（自動的にドキュメン
トを保存する） 「File」メニューに特定UI「Ｂ」のために必要とされ
る項目を与える特定UI仕様は、特定UI「Ａ」にとっては
認められていないインターフェースであろう、なぜなら
メニュー項目は異なって名前が付けられかつ異なって機
能するからである。この問題はアプリケーション内の
「ドキュメントコントロール」のための基本的な要求を
抽象化することによって解決される。大半のアプリケー
ションはドキュメントを管理しかつ操作する必要性を有
するので、包括的UIオブジェクトライブラリは単一のGe
nDocumentControlClassオブジェクトを与える。このオ
ブジェクトは、もしアプリケーションのインターフェー
スで使用するために選択されれば、アプリケーションが
ファイルに基づいてオペレーションを行なうという抽象
的コンセプトをストアし、かつゆえにユーザがファイル
を操作することを可能にするためにユーザインターフェ
ースを必要とする。上の特定UIの各々のための包括的UI
から特定UIへのインタープリタソフトウェアは、スタイ
ルガイドによって特定されるような、適切なファイルメ
ニューを作ることによってGenDocumentControlCuassオ
ブジェクトの存在を処理する。

対照的に、アプリケーション設計の従来の方法であれ
ば、開発者がＡおよびＢのスタイルガイドに従うように
２つの別個の実行可能なものを作ることを要求するであ
ろう。一方は１つのタイプのふるまいを有する適切なFi
leメニューを作るためのコードを含むであろう。他方は
別の異なったふるまいを有するより短いFileメニューを
作るための異なったコードを含むであろう。

機能の抽象化 アプリケーションの共通インターフェース要求は、ユ
ーザに多数の異なったオプションから選択させることで
ある。これを達成するために使用され得る異なった特定
UIで利用可能な小道具のいくつかは以下のとおりであ
る。

・項目のスクローリングリスト、そのうちの１つが強調
される ・ラジオボタン、そのうちの１つが選択され得る（ステ
レオ受信機のボタンのようにTuner、Tape、CDなどを選
択するために押される） ・項目のメニュー、そこで最後に選択されたものがチェ
ックされる ・ポップアップリスト、それによって現在の選択が示さ
れる。それをクリックすると可能な選択の残りを示すウ
ィンドゥが現われる。所望の項目の上にマウスをドラッ
グして解除するとそれを選択する。

大半の特定UIはこれらのオプションの１つ以上を提供
するが、基本的抽象的な入力／出力要求は同一である−
−ユーザは数個のリストから１つの項目を選択すること
ができる。包括的UIオブジェクトライブラリいは機能的
に同一であるとして上の小道具の各々を分類し、かつゆ
えにGenListClassオブジェクトのみを与える。特定の実
現化例の選択はUIインタープリタに任される。結果とし
て、アプリケーションは特定の小道具を使用することの
みに拘束されない。たとえば、伝統的なアプリケーショ
ンはスクローリングリストを使用することを選択しても
よい。ポップアップリストの方がより適切であったかも
しれないが、まだ発明されていなかったとしよう。スク
ローリングリストはコード中に書き込まれているので、
アプリケーションはスクローリングリストから離れられ
ない。新しいアプローチがあれば、アプリケーションは
利用可能な最新の技術を利用するであろう。逆に、GEOS
アプリケーションもまたスクローリングリストの使用を
禁止する特定ユーザインターフェースのもとでも適切に
動作するが、一方伝統的なアプリケーションであれば動
作しないであろう。

主観的設計考察の記憶 現存するかつ将来のUIインタープリタがUI小道具の選
択肢について知的決定を行なうために、適切な情報が利
用可能でなければならない。アプリケーションが必要と
するまたは期待する機能的ふるまい以上に、設計者は他
のあまり実体のない情報を知っている。たとえば、ユー
ザが多数の異なったオプションから選択するリストを実
現化する場合、設計者は以下の包括的特性のどれが適用
され得るかを知っている。

・この特徴は不明瞭である ・この特徴は共通に使用される ・この特徴は容易に理解される ・この特徴は先進的である 彼はおそらくより多くの特定の特性を知っているであ
ろう。

・選択する際にはこれらの項目のうちのできるだけ多く
を一度に見たい ・選択しながら一度に１つ各項目を検討してもよい ・常にすべてのオプション（選択されたおよび選択され
ていない）を見たい 情報のこれらの主観的部分は列挙され、適切な記述が
包括的UIオブジェクトとともに「ストアされる」ことが
可能である。この場合、GenListClassオブジェクトであ
れば上に挙げられた考察のすべてを組込むことができる
であろう。

ヒント ヒントはデジタル的にストアされた、アプリケーショ
ンのための人間／コンピュータインターフェース規準を
具体化したものである。以下の例はどのようにそれらが
使用されるかを示す。

まず、我々は３つの仮定上の特定ユーザインターフェ
ース、Ａ、ＢおよびＣを有すると仮定する。それらのス
タイルガイドは以下を特定する。

特定UI Ａ ・スクローリングリスト小道具 特定UI Ｂ ・「初心者」および「上級者」メニューコマンドを有す
る「オプション」メニューを必要とする。上級特徴は
「上級」メニュー項目が選択されたときのみ現われるよ
うになっている。

・スクローリングリスト小道具 ・ポップアップリスト選択小道具 特定UI Ｃ ・初心者ユーザに向けられる−−アプリケーションは基
本的なふるまいを与えるべきであって過度に複雑であっ
てはならない ・ラジオボタン小道具 例：サンプルUIコンポーネント 新旧のアプローチを使ってどのようにUIコンポーネン
トを記述するかについてみることとする。我々のアプリ
ケーションはユーザに50の状態のうちの１つを選択する
ことを要求すると仮定する。そのアプリケーションにと
って、状態選択項目はその機能にとって重要ではないし
かつ必要ではない。

伝統的に、設計者はUIコンポーネントおよび彼がそれ
を与えることのできる多くの異なった方法について考え
る。設計者はその項目が重要ではないという事実によっ
て課せられた考察の重要度を測る。もし彼が特定UI Ａ
に合わせて書いていれば、彼は50の状態を含むスクロー
リングリスト小道具を選択するであろう、なぜなら彼に
は他の選択肢がないからである。もし彼が特定UI Ｂに
合わせて書いていれば、彼はスクローリングリストとポ
ップアップリストとの間での選択肢を有するであろう。
かれは50の状態を含むポップアップリスト小道具を選択
するであろう、なぜならそれはスクローリングリストほ
どスペースをとらないからである。彼はまたユーザが
「初心者」モードを選択した場合にポップアップ小道具
を除去するのに必要な機能を実現するであろう。もし彼
が特定UI Ｃに合わせて書いていれば、彼はオプション
を全く含まないであろう、なぜならUIは初心者のために
設計されているからである。特定UIの各々のためのこれ
らの決定の各々は、アプリケーションの各異なったバー
ジョンにコード化されるであろう。アプリケーションの
任意の１つに合わせたUIの変化はプログラムが修正また
は書き直されることを要求するであろう。

ここで新しい設計プロセスをみてみよう。機能的に、
設計者はユーザが50のうちから１つの項目の選択肢を有
することを知っている。そこで、彼はGenListClassオブ
ジェクトを選択し、それはリストから選択する抽象機能
を包括する。彼はそれから選択するために50の状態のリ
ストを添える。次に、彼はオブジェクトに主観的考察を
割り当てて、以下のヒントを選択する。

・特徴は重要である ・特徴はアプリケーションの機能に不必要である ・特徴はスクリーンスペースのごくわずかしか占有すべ
きではない ・ユーザは同時にオプションのすべてを見る必要はない これだけ終了である。いかなるプログラムコードも書
込まれない。その後、アプリケーションが３つの特定ユ
ーザインターフェースの各々のもとで実行される場合、
関連するUIインタープリタがその記述に合うように小道
具を選択する。

特定UI Ａ解釈 コンポーネントはリストオブジェクトであるので、そ
れはスクローリングリスト小道具として実現化される
（他のいかなる小道具も利用可能ではない）。

特定UI Ｂ解釈 この特徴は「スクリーンスペースのごくわずかしか占
有すべきでないので、それはポップアップリスト小道具
として実現化される。さらに、それは重要でもなく必要
でもないので」、コンポーネントはユーザが初心者モー
ドを選択する場合には除去される。

特定UI Ｃ解釈 この特徴は「重要でなく」かつ「必要でない」ので、
アプリケーションのユーザインターフェースに含まれな
い。

そこで、包括的UIオブジェクトおよびヒントを使用し
てアプリケーションのユーザインターフェースを単に規
定することによって、実行可能な単一アプリケーション
は多くの異なった機能のレベルで、多くの異なった特定
ユーザインターフェースのもとで実行され得る。開発者
にとって、それはよりよい製品であり、時間およびリソ
ースが節約される。ユーザにとって、１つの価格で５つ
（以上）のプログラムということになる。

付加的なヒント例 広範囲のセットのヒント値の規定および組込みは、ユ
ーザインターフェース技術における将来の開発に対する
アプリケーションの適応性を大幅に増やす。

したがって、GEOSプロセスは多くの異なった型のヒン
トを提供する。上述の機能的ヒントに加えて（サイズ、
重要性など）、タスク関連ヒントがある。たとえば ・この特徴は履歴書を構成している人にアピールするで
あろう ・この特徴は期末テストを構成している人にアピールす
るであろう ・この特徴はレポートを構成している人にアピールする
であろう ・この特徴はスケジュールを構成している人にアピール
するであろう ・この特徴はポスタを構成している人にアピールするで
あろう これらのヒントはタスク指向の特定ユーザインターフ
ェースによって使用され得る。ヒントの他の型およびカ
テゴリを規定することが可能である。組込まれるこれら
のものが多ければ多いほど、将来のスタイルガイドのも
とでのアプリケーションのユーザインターフェースの実
現化はよりよくなる（たとえば3Dホログラフィックコン
ピュータディスプレイのために開発されたもの）。

この発明に従う実施例を説明する前に、用語集でいく
つかのさらなる従来の定義を列挙することは有用であ
る。

従来の用語集 アプリケーション 人がタスクを達成するためにコンピュータを使用する
ことを可能にするツール アプリケーションプログラムインターフェース（API） オペレーティングシステムがプログラムに利用する多
くのシステムサービスのパッケージ、および開発者がそ
れらを呼出すために使用する技術 ボタン コマンド、ディスプレイポップアップウィンドゥおよ
びディスプレイメニューを実行するような様々な方法で
使用されるコントロールエリアまたはメニューの１選択
エレメント チェックボックス セッティングを選択された場合正方形のボックスの中
にチェックマークを示す非排他的セッティング クラス 同一の型のデータおよびメソッドを有するオブジェク
トのグループ データ構造 構造的関係を含むデータのテーブル 宣言的言語 実行のオーダ、必要に応じて分岐およびルーピングが
明確に規定されているプログラミング言語、個々の機能
および手順が別個に規定されかつ保持されたデータに基
づいて動作する 開発ツール アプリケーション開発プロセスに本質的であるか、ま
たはプロセスをよく速くかつより便利なものにするツー
ル、一般的にソフトウェアプログラム ダイアログボックス ユーザから応答を引き出す、典型的に一度に数個の応
答を引き出すエレメントを含む矩形、図３の図面は例示
的なダイアログボックスを示す 環境 オペレーティングシステムと、それが使用される特定
のコンピュータとの組合わせ 実行可能ファイル アプリケーションコードを含むバイナリファイル、ユ
ーザによって実行され得る単一のファイル グラフィックユーザインターフェース テキストおよびコマンドよりはむしろピクチャおよび
オブジェクトに基づくユーザインターフェース 継承 クラスは階層においてそれより上のクラスと共通のイ
ンスタンスデータおよびメソッドを有する インスタンス ある型（クラス）のオブジェクトの特定の具体化 ライブラリ １つ以上のアプリケーションによって要求された場合
ダイナミックにメモリにロードされる実行可能なコード
のモジュール。ライブラリモジュールの１つのコピーの
みが一度にロードされ、すべての実行しているアプリケ
ーションによって共有される メニュー コントロールのグループを含む矩形（基本的に「マル
チプルチョイス」コントロール）。メインメニューエリ
アからのプルダウンメニューとして、またはスクリーン
上の任意の場所からのポップアップメニューとして通常
アクセスされる、図４の図面は例示的なメニューを示す メッセージ オブジェクトは他のオブジェクトにメッセージを送
り、それに特定のアクションを実行させる メソッド 特定のメッセージに応答するオブジェクトのプログラ
ムコード モーダル 「ダイアログボックス」と関連して通常使用される−
−ユーザは継続する前に応答しなければならないことを
意味し、ユーザは他に何もできない オブジェクト インスタンスデータおよびメソッドを含む自己充足し
たデータ構造 オブジェクト指向プログラミング メッセージをお互いに送って物事を行なう自己充足し
たオブジェクトに基づくプログラミング言語 オペレーティングシステム アプリケーションとコンピュータハードウェアとの間
のインターフェースとして作用するプログラム 画素 矩形のグリッドに配列されたスクリーン上の単一のド
ット、スクリーン上の映像はある色の多くの個々の画素
から構成される、図５の図面は個々の画素から形成され
る曲線を示す 手続型言語 その間手続がデータに基づいて実行されタスクを達成
する明確に規定された実行のフローを有するプログラミ
ング言語 リソース 実際のプログラムコードとは別の、リソースファイル
にストアされたデータまたはコード リソースファイル メニュー、フォントおよび／またはアイコンのような
アプリケーションによって使用されるデータを含むファ
イルまたはファイルの一部 スケール可能なユーザインターフェース 同一のアプリケーションが様々な機能および複雑さの
レベルでアクセスされることを可能にするユーザインタ
ーフェース スクロールバー 表示野内にディスプレイされるデータの視点を動かす
ために使用されるコントロール、図６の図面は代表的な
スクロールバーを示す スクローリングリスト テキストフィールドのリストを含む枠。リストはリー
ドオンリーであってもよいしまたは編集可能であっても
よい、図７の図面は代表的なスクローリングリストを示
す スタイルガイド 特定の環境で実行しているアプリケーションのセット
にわたって視覚上のおよび動作上の一致を課すように意
図されたドキュメント サブメニュー メニューのメニュー項目の下に、付加的に選択肢をデ
ィスプレイするメニュー、図８の図面は代表的なサブメ
ニューを例示する システムソフトウェア オペレーティングシステム参照 ツリー オブジェクトの階層化、図９の図面はツリー階層構造
の例を示す ユーザインターフェース（UI） それによってコンピュータシステムがそれを操作して
いる人と意志を通じ合う規則および規約のセット ユーザインターフェースコンポーネント ユーザインターフェース小道具参照 ユーザインターフェース小道具 ユーザがコンピュータと意志を通じ合うことを可能に
する際のいくつかの機能を有する項目、たとえばボタ
ン、メニュー、ウィンドゥ ユーザインターフェースツールキット アプリケーションにおいて使用するために、オペレー
ティングシステムによって提供されたユーザインターフ
ェース小道具の集合 ウィンドゥ アプリケーションエレメントを含む矩形、図10の図面
はサンプルウィンドゥを示す オブジェクト指向のプログラミング オブジェクト指向のプログラミングは、伝統的な手続
型プログラミングとは非常に異なるプログラミングへの
アプローチである。Ｃおよびパスカル（Pascal）のよう
なプログラミング言語はデータを操作する機能および手
続からなる。プログラムコードは明確に規定されたオー
ダで、ルーピングおよび分岐を必要な場合に実行する。
一方、オブジェクト指向のプログラミングはオブジェク
トとして知られる塊にデータおよび手続をグループ化す
る。実行の予言可能なフローはない。

オブジェクト指向のプログラミングの５つの主要なコ
ンセプトは、オブジェクト、メソッド、メッセージ、ク
ラス、および継承である。各々を以下に説明する。

オブジェクト オブジェクトはデータ（インスタンスデータと呼ぶ）
およびそれ自身のデータを修正するための手続（メソッ
ドと呼ぶ）を含む自己充足したユニット（データ構造）
である。オブジェクトはメッセージを送りかつ受信す
る。たとえば、犬がオブジェクトであると仮定する。犬
に与えるコマンドがメッセージである。犬はそれらのコ
マンドを学習し、犬が覚えている応答がそのメソッドで
ある。そこで、もし犬に「おすわり」を命じれば、犬に
「おすわり」メッセージを送っていることになる。犬は
「おすわり」メッセージを受信し、その「おすわり」メ
ソッドを開始し、その後地面に座る。

メッセージ メッセージはＣまたはパスカルにおける手続要求に大
まかに対応する。オブジェクトは他のオブジェクトにメ
ッセージを送り、それに特定のアクションを実行させ
る。これもまた他のオブジェクトのメソッドを引き出す
ものとして知られている。このタスクの達成方法は人間
の対話方法の自然な延長である。たとえば、図11を参照
して、巡回セールスマンが貴方の家に現われた場合、貴
方は「帰れ」と言い、彼は帰る。貴方はコマンドを与え
コマンドを受けたものがそれを処理することを期待す
る。このようにユーザはそのコンピュータと対話し、そ
のためにオブジェクト指向のプログラミングがユーザに
より操作されるシステムによく向いている。

メソッド メソッドは手続型言語における手続および機能に直接
対応する。メソッドは特定のメッセージに応答するオブ
ジェクトのプログラムコードである。上の例において、
セールスマンの「帰れ」メソッドは、誰かが「帰れ」と
言った場合に向きを変えて歩き去り、その名前を潜在的
な顧客のリストから外さなければならないという彼の知
識（彼のインスタンスデータ）であった。

クラス クラスは同一の型のデータおよびメソッドを有するオ
ブジェクトのグループである。あるクラスのオブジェク
トはあるメッセージへの応答の仕方に関するデータおよ
び知識の共通のセットを共有する。各オブジェクトはク
ラスの「インスタンス」と呼ばれる。たとえば、上のセ
ールスマンは「アクメ（Acme）社の百科事典セールスマ
ン」クラスのインスタンスであるとする。彼および「Ac
me」クラスの他の仲間のインスタンスは、すべてその上
司からのトレーニングのために「帰れ」メッセージへの
応答の仕方を知っている。

クラスは階層的構造で編成される。クラスはその上の
クラスからのふるまいを継承する。たとえば、クラス
「犬」は以下のように規定され得る。

犬 かわいい犬 プードル ドーベルマン 醜い犬 ピットブル（Pit Bull） サンプルクラス階層化 継承 犬のクラスはかわいい犬と醜い犬のサブクラスを有す
る。これらのサブクラスはそれ自体のサブクラスを有し
得る。継承のために、もし犬のクラスが「おすわり」メ
ソッドを含めば、すべてのサブクラス（かわいい犬、醜
い犬）もまたそのメソッドを理解する。ここで、もしプ
ードルのクラスのインスタンスが「おすわり」メッセー
ジを受ければ、それはそれ自身の「おすわり」メソッド
を有する必要はない。それは単にかわいい犬のクラスに
そのメッセージを送り、そのクラスは犬のクラスにメッ
セージを送る。

オブジェクト指向のプログラミングがなぜ自然か 我々が生活している世界はオブジェクトから構成され
る。そして前に見たように、我々は我々の世界の他のオ
ブジェクトにメッセージを送り、それらのメッセージに
反応することによってするべきことの大半を行なう。さ
らに、我々は他のオブジェクトにどのようにするかを詳
細に説明するよりはむしろ何をしてほしいかを言うこと
によって一般に物事を行なう。この「どのように」は手
続を記載するものであり手続型プログラミングモデルの
一部である。この「何を」はタスク、問題およびその解
決を記述的、または宣言的言葉で記載するものであり、
宣言的プログラミングモデルの一部であり、オブジェク
ト指向のプログラミングはこの主要な例である。貴方が
コンピュータにプリントメッセージを与える場合、貴方
はコンピュータに対して「さて私がちょうど作成し終え
たばかりのこのドキュメントを取込み、そのビットマッ
プ構造を分析してもらいたい。わかったか」とは言わな
い。貴方は単にプリントするように命じそれが行なわれ
ることを期待する。

同様に、もし貴方が部下に命令を与えるとすれば、貴
方は一般に「ジム、３時までに私の机に毎季の目標レポ
ートを持って来てほしい」という。貴方は「ジム、私は
君に机に座ってもらいたい。一枚の紙と鉛筆を取り出
せ。さて紙の１番上に…を書け」とは言わない。

しかしこれらの記述は、−−例示のために単純化され
ているが−手続型プログラミングとオブジェクト指向の
プログラミングとの間の差の上手な要約である。世界は
手続的に動いてはいない。結果として手続指向の環境に
おけるより、オブジェクト指向のプログラミング環境に
おいて、現実および知性をエミュレートまたはシミュレ
ートするように設計されたプログラムを書く方がずっと
容易である。ダン・シェーファー（Dan Shafer）の「ハ
イパー・トーク・プログラミング」（Hyper Talk Progr
amming）を見られたい。

いかにしてこれすべてが実現されるか オブジェクトは本来クラスに関連する。名前、住所お
よび電話番号のための印刷されたセクションを有するロ
ロデックス（rolodex:回転型電話番号簿）について考え
られたい。貴方が１つを書き込むたびに、オブジェクト
が作られる。ロロデックスカードのフォーマットはクラ
スである。そこで貴方がロロディックスカードを埋める
ためび、貴方はロロデックスカードクラスのインスタン
スを作っていることになる。ロロデックスカードのフォ
ーマットがオペレーティングシステムに与えられる方法
はデータ構造として既知である。オブジェクト（および
クラス）はデータ構造として実現化される。データ構造
は構造的っ関係を含むデータのテーブルである。そこで
その人名、属性およびヒントを有するUIオブジェクトは
そのクラスの形の単一データ構造である。

アプリケーション設計のGEOSプロセス 導入 オブジェクト指向のプログラミングは新しいコンセプ
トではない。ユーザインターフェースコンポーネントを
与えるためにオブジェクトを使用するアイデアも新しい
ものではない。何が新規であるかといえば、GEOSオペレ
ーティングシステムがそれらのコンポーネントが何をす
るように意図されているかを解釈できるように、UIコン
ポーネントとしてオブジェクトを使用する方法である。
GEOSは任意の数のスタイルガイドのよい解釈になるよう
に実際の、視覚上のかつふるまい的なアプリケーション
UIを作ることができる。

GEOSプロセスはアプリケーションのユーザインターフ
ェースを設計するプロセスを変える。ユーザインターフ
ェース設計者は、アプリケーション入力／出力要求に対
する人間／コンピュータ対話設計考察に重きを置き、包
括的ユーザインターフェース記述（属性およびヒントを
有するオブジェクトの形で）を作る。GEOSオペレーティ
ングシステムは、その特定ユーザインターフェースソフ
トウェアおよび自動化されたスタイルガイドインタープ
リタを使用して、包括的記述を読み、任意のある特定ユ
ーザインターフェーススタイルガイドに忠実なオンスク
リーン表示を作る。

GEOSシステムは２ステッププロセスによってこのタス
クを達成する。

まず、アプリケーション開発者は自分のアプリケーシ
ョンのユーザインターフェース要求を表わすことを可能
にする特別なプロパティを有するUIオブジェクトを使用
して、自分のプログラムのユーザインターフェースを規
定する。

次に、GEOSシステムはその記述を読み、それを解釈
し、特定のスタイルガイドの明示のおよび暗黙のガイド
ラインに視覚上およびふるまい的に従うプログラムユー
ザインターフェースの実現を作る。この解釈は実行時に
行なわれるので、ユーザはいつでも特定ユーザインター
フェースを切換えることが可能である（たとえばMotif
からOpenLookへ）。

自動化されたスタイルガイド GEOSプロセスはユーザインターフェースが特定のスタ
イルガイドに適合するように設計されるステップを除去
することによって、アプリケーション開発プロセスを短
縮しかつ簡略化する。GEOSシステムは本質的に自動スタ
イルガイドであるものを与える。付録Ｄはスタイルガイ
ドの役割を説明する。各特定ユーザインターフェースの
すべての詳細および微妙な差異はGEOSシステムによって
実現化される。アプリケーションは単に包括的モデルを
使用してユーザインターフェースを規定する。この包括
的モデルは、本質的に、そのユーザインターフェースか
らアプリケーションを分離する。アプリケーション開発
者は特定のユーザインターフェース小道具の細目よりは
むしろ、共通の意味的プロパティの点からアプリケーシ
ョンのユーザインターフェースを特定する。結果とし
て、このシステムはスケール可能な環境および同一のア
プリケーションコードを有するいくつかのGUI仕様をサ
ポートすることが可能である。包括的モデル下では、開
発者は特定ユーザインターフェース小道具よりはむし
ろ、抽象的（包括的）オブジェクト、共通意味的プロパ
ティおよび誘導ヒントの点からアプリケーションのユー
ザインターフェースを特定する。これらの包括的オブジ
ェクトはその相対的重要性および相互依存性を示すため
に階層に置かれる。

一旦アプリケーションのユーザインターフェースが包
括的な言葉で記述されれば、GEOSシステムはどの特定ユ
ーザインターフェースが選ばれるかに依存して、１つ以
上の特定UIオブジェクトに各包括的UIオブジェクトをマ
ッピングする。たとえば、アプリケーションのUIファイ
ルはオプションのリストがユーザに与えられることを特
定するかもしれない。包括的オブジェクトの属性および
「ヒント」に依存して、これはOpenLookのサブメニュー
として、または登録商標OSF/Motifのダイアログボック
スとして実現化され得る。包括的から特定的へのユーザ
インターフェースへの転換はアプリケーションにとって
はトランスペアレントである。GEOSシステムは任意の数
の特定ユーザインターフェースライブラリを収容するこ
とが可能である。

この態様において、GEOSシステムは特定ユーザインタ
ーフェース変換の最終的な結果がその対応するスタイル
ガイドに一致することを確実にする。これは重要なステ
ップである。前に説明されたように、スタイルガイドは
アプリケーション設計者がプログラムのユーザインター
フェースを設計する場合に従うべきガイドラインおよび
仕様を与える。特定のセットの人間対コンピュータの対
話要求が与えられたとすると、それはどの特定UIコンポ
ーネントを使用すべきかを規定する。ときとしてスタイ
ルガイドは非常に特定的であり、たとえばOpenLookはメ
インコントロールは一連のボタンメニューで編成される
べきであることを特定し、大半のスタイルガイドはもし
ユーザがオペレーションが実行される前により多くの情
報を要求される場合には、メニュー項目が省略符号
（…）で終わることを求める。ときとしてスタイルガイ
ドは非常に包括的であり、たとえばMotifはプロパティ
を設定するために使用されるダイアログボックスが与え
られたとすると、OK、Reset、Cancel、およびHelpのボ
タンを与えるべきか、またはApply、Reset、Closeおよ
びHelpボタンを与えるべきかについて明らかでない。そ
こで、アプリケーションのユーザインターフェースの細
目を設計するプロセスに固有な複雑さおよび微妙な差異
のために、開発者はその設計をかえるのに多くの時間お
よびリソースを費やすことを強いられる。GEOSシステム
があれば、このステップは自動化され相対的に困難でな
い。

ユーザインターフェースを実現化するこの方法は開発
者およびユーザに同様に利益を与える。ユーザは１つの
アプリケーション−−ワードプロセッサをたとえば購入
することができる。そこでこの個人的な好みに依存し
て、ユーザはMotif、OpenLookまたはNewWaveのユーザイ
ンターフェースでプログラムを実行することが可能であ
る。もしその息子が素早くレターをタイプしたいと思え
ば、初心者のために設計されたユーザインターフェース
に切換えることが可能である（GEOSシステムのApplianc
eモード）。

開発者はそのプログラムのためのユーザインターフェ
ースを設計し、それについて考えかつ再設計するのに費
やしたであろう莫大な時間およびリソースを節約する。
しかもたった１つの特定のスタイルガイドのためにであ
る。GEOSシステムがあれば、１つのアプリケーションは
異なったスタイルガイド（特定のスタイルガイドの実現
化例を「特定ユーザインターフェース」と呼ぶ）、およ
び様々なレベルの複雑さ（実際は単に他のスタイルガイ
ド）のもとで実行される。

アプリケーションのユーザインターフェースを規定する
こと アプリケーションは包括的UIクラスを使用してそのユ
ーザインターフェースを規定する。

包括的ユーザインターフェースクラス 包括的UIクラスはユーザインターフェースコンポーネ
ントの抽象的なタイプである。現存するかつ提案された
GUIを完全にリサーチしかつ分析することによって、ジ
オワークス（GeoWorks）は共通であるユーザインターフ
ェースコンポーネントの主要な種類を認識した。これら
のコンポーネントを抽象化すること−−それらをその機
能的本質にかえることは、10の包括的UIクラスを結果と
してもたらした。たとえば、すべての特定UIはアクショ
ンを開始するメソッド、ゆえに包括的トリガクラスを必
要とする。主要な包括的UIクラスのリストは以下のとお
りである。

・GenApplication、アプリケーションの様々なトップレ
ベルウィンドゥを管理する ・GenPrimary、アプリケーションにメインウィンドゥを
与え、アプリケーションのためのコントロールのすべ
て、および出力エリアをグループ化しかつ管理する ・GenTrigger、ユーザによってトリガされた場合に、あ
るアクションを開始するプッシュボタンを示す ・GenSummons、ユーザからの応答を、典型的に一度に数
個引き出す ・GenInteraction、包括的グループ化オブジェクトとし
て機能する（コントロール、非定型のダイアログボック
ス、メニューまたはサブメニューのグループ） ・GenRange、ユーザがディスクリートな範囲の値内で値
を対話型で設定することを可能にする ・GenList、多数の選択項目をグループ化する（オプシ
ョンを設定することなど） ・GenView、ドキュメントが示され得るスクリーンのエ
リアを与える ・GenDisplay、１つ以上の２次ウィンドゥをディスプレ
イしかつ管理する ・GenTextEditおよびGenTextDisplay、テキストフィー
ルドに異なってフォーマットされたテキスト、キーボー
ド操作ガイド、切り貼りおよび他の編集機能を与える 包括的ユーザインターフェースオブジェクト 包括的UIオブジェクトは包括的UIクラスのインスタン
ス−−特定の具体化−−である。図12はGenTriggerクラ
スの２つのインスタンス、オプショントリガおよびイネ
ーブルトリガを例示する。アプリケーションが特定のUI
コンポーネント（たとえばボタン）を必要とした場合、
それは適切な包括的クラス（GenTrigger）を選択し、GE
OSシステムにそのクラスのインスタンスを作るように要
求する。アプリケーションはそのユーザインターフェー
スの一部として結果として生じる包括的UIオブジェクト
を使用することが可能である。各個々のUIオブジェクト
はその範囲がUIクラスによって決定されるその独自のイ
ンスタンスデータを有する。２つの種類のインスタンス
データ、属性およびヒントがある。

ユーザインターフェースコンポーネント アプリケーションが特定のUIコンポーネント（たとえ
ばボタン）を必要とした場合、それは所望されたコンポ
ーネントの型に固有の機能を与える包括的UIオブジェク
トを規定する。GEOSシステムは望まれる機能の包括的カ
テゴリを決定する異なったタイプの包括的UIオブジェク
トを与える。そのオブジェクトの特別のプロパティは、
人間／コンピュータ対話設計考察およびアプリケーショ
ン入力／出力要求についてのより詳細であると同時に曖
昧な情報を伝えるように設定される。

基本的に、これらの包括的UIオブジェクトは２つの異
なった型のインスタンスデータ−属性およびヒントを有
するデータ構造である。

属性 属性は非常に特定的な態様でUIオブジェクトのふるま
いおよび／または外観を規定し、属性はオンまたはオフ
のいずれかであり、すべてのUIオブジェクトクラスに関
連する属性の明らかなセットがある。アプリケーション
が属性を設定する場合、GEOSシステムが選択する特定UI
コンポーネントが所望のふるまいを示すことは確実であ
り得る。

たとえば、ダイアログボックスのためのモーダル属性
を設定するとユーザが継続する前にそれに応答しなけれ
ばならないことを確実にする。トリガについて不能化と
いう属性を設定するとトリガのラベル（モニタと呼ばれ
る）の表示を薄くし、ユーザがそれを選択することを許
容しない。

モニカ モニカはすべてのUIオブジェクトが有する特別の属性
である。各UIオブジェクトはモニカ、または視覚表現を
与えられてもよいが、モニカはすべてのオブジェクトに
対して規定される必要はない。それはウィンドゥが最小
限にされた場合にディスプレイされるべきボタンの名前
またはアイコンであり得る。UIオブジェクトは単一のモ
ニカに制限されず、モニカのリストが規定されてもよ
い。状況および文脈に依存して、GEOSシステムはモニカ
のうちの１つを使用する。たとえば、アプリケーション
はその外観を最適化するためにCGA、EGAおよびVGAモニ
タに対して異なったアイコンを規定し得る。GEOSシステ
ムは特定のユーザのセットアップに対して正しいものを
ディスプレイする。いくつかのUIオブジェクトはいくつ
かのテキストおよび絵のモニカを有し得る。GEOSは適切
なモニカを選択する。

ヒント ヒントは問題になっているUIオブジェクトについての
付加的な情報を与える。アブリケーションの要求は必ず
しも絶対的なものではなく、異なった特定UIによって異
なって解釈（無視さえ）されてもよい。UIオブジェクト
のいくつかの視覚上およびふるまい的な局面はこのため
に属性として実現化されるべきではない。言い換えれ
ば、すべての特定UIに共通でないいくつかのUIコンポー
ネントまたは機能がある。これらの能力はすべての特定
UIがそれらをサポートするわけではないので属性にはな
れない。したがって、それらはヒントになる。開発者が
ヒントを特定のUIオブジェクトに割り当てた場合、彼は
ヒントがいずれの特定UIによっても実現化されることは
確信することができない。

ヒントには２つの型、すなわちコマンドおよび宣言型
がある。

コマンドヒント コマンドヒントはUIコンポーネントの特定実現化例の
ための直接要求である。開発者は心の中に特定UIコンポ
ーネントスタイルを持っている場合にはコマンドヒント
を使用することを選択するであろう。たとえば、アプリ
ケーションはスクローリングリスト（HINT_SCROLL_LIS
T）またはチェックボックス（HINT_CHECKBOXES）を明ら
かに要求するかもしれない。すべての特定UIがコマンド
ヒントに従う能力を提供するわけではない。たとえば、
いくつかの特定UIはユーザがメニューおよびダイアログ
ボックスを操作ガイドするためにキーボードを使用する
ことを可能にする。これをサポートするために、あるUI
オブジェクトはいくつかのHINT_NAVIGATION_IDおよびHI
NT_NAVIGATION_NEXT_IDヒントを含むであろう。Motifは
これを利用するであろう。OpenLookはスタイルガイドが
かかる操作ガイドを許容しないのでそれを無視するであ
ろう。GEOSシステムはそれをサポートする任意の特定ユ
ーザインターフェースにおいて特定のコマンドヒントを
実行する。

宣言的ヒント 宣言的ヒントにより曖昧であり、特定の実現化例を具
体的に参照せずに、それらは問題になっているUIオブジ
ェクトの機能の表示を与える。たとえば、可能なアクシ
ョンのリストを含む包括的UIオブジェクトはHINT_MENUA
BLEを有し、開発者がリストがメニュー形式で示される
ことを想定していることを示す。しかしながら、おそら
く初心者ユーザのために設計された特定UIにとってはメ
ニューがあまりに複雑であるだろう。そこでGEOSシステ
ムは単純な一連の大きな平面的に可視のボタンとしてア
クションのリストを実現する。または同様に、そのメニ
ューのオプションはそれが先進的でめったに使用されず
かつ潜在的に危険であることを述べるヒントを有し得
る。そこで初心者の特定UIはトリガを完全に除去するで
あろう。

再び、宣言的ヒントはある特定UIによって実現化され
るかもしれないしされないかもしれない。たとえば、CU
Aはメニューバーのサブメニューを許容しない。ヒントH
INT_MENUABLEを有する他のGenInteractionオブジェクト
の内側にあるヒントHINT_MUNUABLEを有するGenInteract
ionオブジェクトは、OpenLookまたはMotifのサブメニュ
ーとして実現化されるであろう。しかしながら、CUAに
おいては、それはメニューに付加され、セパレータによ
って分離されるであろう、なぜならサブメニューはスタ
イルガイドに従って認められないからである。

包括的UIオブジェクトを使用すること アプリケーションが必要とするUIコンポーネントを示
すために選択する包括的UIオブジェクトは、ツリーに配
列される。このツリーはUIオブジェクトの階層化であ
り、各オブジェクトの相対的重要性および相互依存性を
伝える。これはどのコンポーネントがはっきり見えるべ
きであり、かつどれが１つ以上の層深いところに隠され
得るかについての表示を与える。図13の例示的な図面は
かかる包括的なUIツリーの一例を示す。図13の包括的UI
ツリーの記述は付録Ａで与えられる。付録Ａ−Ｄはこの
引用によりここに援用される。

図13のもののような包括的ユーザインターフェース記
述が与えられたとすると、GEOSシステムは任意のある特
定ユーザインターフェースにおいてそれを実現化する。
それは自動的にメニュー、フィールドおよびボックスの
大きさを調整し、ボタン、スクロールバーおよびテキス
トを配置し、−−その間ずっと特定ユーザインターフェ
ーススタイルガイドに忠実である。図14の例示的図面は
どのようにこの特定の包括的UI仕様がMotifのためのGEO
Sによって実現化され得るかである。GenApplicationは
視覚上の表示を何も有さないことに注目されたい。

装飾 装飾は開発者は要求しないが、GEOSシステムが特定の
スタイルガイドのよう実現化を維持するために与える付
加的な特定ユーザインターフェースコンポーネントであ
る。たとえば、上のサンプルアプリケーションにおい
て、GEOSは上隅のボタン、リサイズ用ボーダ、およびメ
ニューの「ピン」オプションを加える。これらはある態
様で存在し、かつ機能すべきであるMotifスタイルガイ
ドが述べているすべての装飾である。開発者はそれらを
覚えているまたはそれらを要求することを心配する必要
はない、なぜならそれらはOpen LookまたはNew Wave
に対して異なってもよいからである。これはGEOSシステ
ムがプログラマからの明示の指示を必要とすることなく
どのようにスタイルガイドのよい解釈を確実にするかの
他の例である。

特定ユーザインターフェース 特定ユーザインターフェースはライブラリとして実現
化される。集団の学生が公立の図書館に行って百科事典
を共有できるのとほぼ同じように、プログラムはライブ
ラリモジュールを共有できることが可能である。ライブ
ラリは１つ以上のアプリケーションによって必要とされ
た場合メモリにダイナミックにロードされる実行可能な
コードのモジュールである。ライブラリモジュールの１
つのコピーだけが一度にロードされ、すべての実行して
いるアプリケーションによって共有される。特定UIライ
ブラリは包括的UI記述を解釈し、かつ実際のアプリケー
ションのユーザインターフェースを実現化する原因とな
る。

プログラミング例 上のコンセプトを根拠のあるものにするために、単純
なユーザインターフェースの設計を従来の方法とGEOSの
方法とで比較してみることにする。我々は基礎をなすア
プリケーション機能については心配していない。我々は
２つの異なった特定ユーザインターフェース（マッキン
トッシュおよびOS/2プリゼンテーション・マネージャ
（Presentation Manager）における単純なユーザイン
ターフェースを作る。我々は最終的に２つの別個の実行
可能なアプリケーションを作る。同じことをGEOSプロセ
スに従って行ない、結果として生じる単一の実行可能な
アプリケーションが任意の数の特定ユーザインターフェ
ースでどのようにディスプレイされ得るかを示す。

マッキントッシュ例 アップル・マッキントッシュで単純なユーザインター
フェース−−５つのコマンド、New、Open、Save、Save
AsおよびQuitを含むFileメニューを有する単一ウィン
ドゥを作ることにする。

マッキントッシュアプリケーションはリソースファイ
ルにストアされるメニュー、フォント、ダイアログボッ
クスおよびアイコンのような多くのリソースを利用す
る。たとえば、アイコンは32掛ける32ビット映像として
リソースファイルに存在し、フォントはフォントの文字
を含む大きなビット映像として存在する。いくつかの場
合において、リソースは記述的情報（たとえばメニュー
については、メニュータイトル、メニューの各コマンド
のテキスト、コマンドがチェックマークでチェックされ
ているかどうかなどのような）からなる。アプリケーシ
ョンによって使用されるリソースが作られ、アプリケー
ションコードから独立して変えられる。この分離はリソ
ースファイルを有することの主要な利点である。たとえ
ばメニューのタイトルの変化はコードの再コンパイルも
必要としなければ、他の言語への変換も必要としないで
あろう。この先行するおよび後続の記述およびコードフ
ラグメントは、「インサイド・マッキントッシュ」（In
side Macintosh）、第１巻からのものである。

そこでサンプルアプリケーションを作るために、プロ
グラマはマッキントッシュに基づくグラフィカルな対話
的開発ツールをまず利用して、メニューおよびその内容
を規定する。彼はまず新しいメニューリソースを作る。
そして彼はそのメニューにコマンドを加える（New、Ope
n、Save、Save AsおよびQuit）。最後に、彼はメニュ
ーの属性およびその選択肢を設定する（たとえばSave
AsとQuitとの間にはチェックマーク、セパレータがない
など）。以下は彼が規定するであろうすべてのリソース
の完全なリストである。

・Menu（リソースID＃128）−そのタイトルとしてアッ
プル記号を有するがその中にコマンドが何もないメニュ
ー ・Menu（リソースID＃129）−コマンドNew、Open…、Sa
ve、Save As…、およびQuitコマンドを有するファイル
メニュー ・ウィンドゥテンプレート（リソースID＃128）−−サ
イズボックスのないドキュメントウィンドゥ、座標面上
の（50、40）の左上隅、（300、450）の右下隅、タイト
ル「サンプル」、クローズボックスなし 各メニューリソースはまたユーザがそれからコマンド
を選択する場合にメニューを認識するために使用される
「メニューID」を含み、すべての３つのメニューに対し
てこのIDはリソースIDと同一である。

これらのリソースを初期化しかつディスプレイするた
めのコードの抜粋は付録Ｂで与えられる。

付録Ｂのコードおよびリソースファイルは結果として
図15に示されるオンスクリーン表示をもたらす。

この特定のオンスクリーン表示を作るために必要とさ
れるコードはマッキントッシュに非常に特定的であるこ
とに注目されたい。たとえば、もし貴方がアプリケーシ
ョンの外観およびふるまいをCUA（ソート・プリゼンテ
ーション・マネージャ（Sort Presentation Manage
r））スタイルガイドに一致させたいと思えば、すべて
を書き直さなければならないであろう。

OS/2プリゼンテーションマネージャ例 OS/2プリゼンテーションマネージャで同一のユーザイ
ンターフェースを作ることにする。OS/2のスタイルガイ
ド（CUA）およびオペレーティングシステムはアップル
のものとは非常に異なっており、それでユーザインター
フェース設計を変える必要があり、コードは完全に書き
直さなければならない。

OS/2プリゼンテーションマネージャでアプリケーショ
ンのユーザインターフェースを作るために、ユーザイン
ターフェースを記述するコードは、実際のプログラムコ
ードに部分的にはめ込まれる。単純なメニューを有する
標準ウィンドゥをディスプレイするために、設計者はそ
のメインプログラムファイルに付録Ｃで示されるライン
を含まなければならないであろう（たとえばSAMPLE.
C）。付録Ｃのコードフラグメントは、チャールズ・ペ
ッツオールド（Charles Petzold）による、「OS/2プリ
ゼンテーションマネージャのプログラミング」（Progra
mming the OS/2 Presentation Manager）からのもので
ある。

コードおよび付録Ｃのリソースファイルはコンパイル
され、アプリケーションの結果として生じるオンスクリ
ーン表示は図16の表示に類似に見えるであろう。

OS/2プリゼンテーションマネージャまたはアップルマ
ッキントッシュのいずれかで開発する際に、プログラマ
は特定の属性で特定ユーザインターフェースコンポーネ
ントを規定することに注目されたい。そしてプログラム
コードはそれらにアクセスし、オペレーティングシステ
ムはそれらをスクリーン上で作図する。これらの２つの
環境における実際のプログラミングおよび開発のメカニ
クスは非常に異なっている。

プリゼンテーションマネージャにおいて、メニューお
よびメニュー関連属性はテキストのリソールファイルに
規定される。ウィンドゥおよび他のUIコンポーネントの
属性はルーチンコールによって規定される。オプション
はパラメータとして渡される。

マッキントッシュでは、UIコンポーネントは別個のリ
ソースファイルに含まれる。このように、その属性はリ
ソースエディタアプリケーションを使って規定される。
このアプリケーションはプログラマがリソースを作りか
つ編集するために使用するグラフィカルテンプレートを
与える。たとえば、プログラマがエディタ内のダイアロ
グボックスのフォーマットを決め、手動でボーダをサイ
ズ決めし、テキストブロックを加え、テキストスタイル
を設定し、ボタンを押すなどである。

GEOS例 GEOSプロセスにおいて、プログラマは包括的UIオブジ
ェクトを使ってそのアプリケーションのユーザインター
フェース要求を規定する。これらのオブジェクトはOS/2
またはマッキントッシュオブジェクトがそうであるよう
に属性を有するが、これらの属性はすべての特定UIに共
通なスペースおよびふるまいの局面を示すものだけであ
る。異なった特定UI実現化例の特質なヒントの使用によ
って実現される。

ユーザ対話 おそらくコンピュータ使用の最も重要な局面はコンピ
ュータとのユーザ対話であり、ユーザがそれらをたやす
く利用できないとすれば何百もの特徴および明らかで完
結なユーザインターフェースは何のためにもならない。
大半のグラフィック指向のシステムはマウスと呼ばれる
デバイスを利用する。ユーザはそのデスク上で掌サイズ
の物体を滑らせ、スクリーン上のポインタはこれに従っ
て移動する。マウスは１つないし３つのボタンを有し得
る。スクリーン上でポインタを移動させながら、ユーザ
はボタンをクリックし、ウィンドゥをリサイズし、円を
作図することができる。しかしながら、すべての特定ユ
ーザインターフェースがシステムの視覚上のおよびふる
まい的な局面を記述するスタイルガイドを有するよう
に、すべての特定ユーザインターフェーススタイルガイ
ドはユーザ対話規約を規定する。もしかしたらユーザは
クリックしかつドラッグし、左ボタンをダブルクリック
し、右ボタンをトリプルクリックし…というように非常
に多くの方法があるので、これらの規約が必要とされ
る。

そこで再びジオワークスが問題を認識した。従来のア
プリケーションはそれ自体のユーザ対話を一般に扱う。
たとえば、図17を参照してもしユーザがある語の任意の
文字上でダブルクリックすれば、アプリケーションが全
体の語を選択する。なぜならそれがそのスタイルガイド
がするように言っていることであるからである。我々は
初期のジレンマなしに匹敵するものを有することに注目
されたい−−異なったスタイルガイドは異なったユーザ
入力処理方法を有する。もし異なった型のユーザ入力に
ついて心配しなければならないとすれば、どのようにア
プリケーションは真に特定ユーザインターフェースから
独立できるであろうか。この発明に従う答えは同様にユ
ーザ対話を抽象化することである。

図18を参照して、ユーザ対話がGEOSシステムにおいて
どのように作用するかを追ってみよう。まず、アプリケ
ーションはユーザ入力を受信する。たとえば、ユーザは
Motifのもとでワードプロセッサを使用しながらダブル
クリックする。そこでアプリケーションはユーザ入力の
文脈を判断する。たとえば、ユーザはワードプロセシン
グドキュメントの第２の語上でクリックした。次に、ア
プリケーションはこの情報、実際の入力および文脈を適
切な特定UIインタープリタに送る。最後に、UIインター
プリタは文脈および生の入力を考えて、アプリケーショ
ンに正確に何をすべきかを告げる。たとえば、それはワ
ードプロセッサにターゲットにされた語を選択するよう
に命令する。

従来の開発 従来のユーザインターフェース開発には２つの主要な
問題があり、それはかかわる時間と難しいアプリケーシ
ョンユーザインターフェースの可能性である。

時間 現在の最新のオペレーティングシステムは様々なツー
ルおよびユーティリティを提供し、開発者の生活をより
楽にしている。しかしながら、プログラムの環境がNeXT
コンピュータまたはPCのためのマイクロソフトウィンド
ウのいずれであっても、開発者は依然として手動はすべ
てのユーザインターフェースコンポーネントをレイアウ
トしなければならない。彼はウィンドウスタイルを選択
する。メニュー項目を設置する。ボタンおよびダイアロ
グボックスを加える。注意深くそれらのダイアログボッ
クスのオプションのリストおよびテキストフィールドを
設定し、恐らくは一度にそれらを１画素（スクリーン上
の単一の点）ごとに動かす。彼はすべてのユーザインタ
ーフェースコンポーネントの正確なサイズおよび場所を
規定する。そして彼は一歩下がって眺め、結果として生
じるインターフェースが依然として自分の環境のために
説明されたスタイルガイドに忠実であることを確実にす
る。彼は幾分設計を変え、一歩下がって眺め、またそれ
をもう少し変える。最後に、ユーザインターフェース設
計が最終的に完了した場合、プログラミングチームはプ
ログラムの残りを書く。一般に、開発時間の少なくとも
30パーセントがユーザインターフェースの設計および実
現化に費やされる。

他の環境のためのアプリケーションのユーザインター
フェース（完成するのに非常に長くかかった）を再設計
することは時間のかかるタスクである。幾つかの環境に
おいてそれは他のものより容易である。しかしそのすべ
てにおいて、設計者は絶えず結果を調整し、その結果を
スタイルガイドに一致させることを絶えず心配してい
る。そしてそれは多くの時間ときつい作業を要する。そ
れを他のスタイルガイドに忠実であるように修正するこ
とについては言うまでもない。

UI品質の差 直感的および論理的ユーザインターフェースを有する
多くの非常に良いアプリケーションがある。また直感的
には使用困難なユーザインターフェースを有する多くの
非常に強力なアプリケーションもある。開発者がそのア
プリケーションがスタイルガイドで述べられた目標およ
び目的に一致することを確実にすることに専ら責任を負
っている場合は、幾つかの奇妙な解釈に束縛される。積
み重なった木材および電力工具が与えられたとすると、
優れた大工なら美しくかつ非常に価値のある鳥小屋を作
ることができるであろう。それほど熟練していない職人
なら価値のないドア押えを作るかもしれない。同様に、
ユーザインターフェースを作るためのツールが与えられ
ると、プログラマは非常に簡単にそれほど品質の良くな
いインターフェースを作り得る。たとえば、ユーザがプ
リントコマンドを選択した場合に呼出されたダイアログ
ボックスの場合を検討されたい。アプリケーションがこ
の状況を処理できる非常に多くの方法がある。満足のい
くものがあれば、選れたものもあり、またそれほど良く
ないものもある。たとえば、図19はプリントダイアログ
ボックスの良いレイアウトである。

図19のダイアログボックス設計は幾つかの理由のため
に良い。まず、それはオプションをそれとわかるタイト
ル−−Printer OptionsおよびDocument Optionsを有
する論理グループに視覚上グループ化する。どのプリン
タが接続されるかのセッティングはユーザがしばしば変
えるようなものではない。したがって、これに関連する
オプションはこのダイアログボックスによってもアクセ
スされない。Change Options…をクリックすると別の
ダイアログボックスが現われる。Document Optionsは
記述的なはっきりした名前−−高、中、および低プリン
ト品質を有する。PrintおよびCancelはボタンが何を行
なうかについての良い表示を与える。付加的に、Print
の周りの余分のボックスはデフォールト動作を示し、そ
れは経験のあるユーザにとって、および次に何をすべき
かわからない初心者にとって同様に良い。

対照的に、図20のダイアログボックスはまずく設計さ
れている。オプションは明らかに論理的分割にグループ
化されていない。タイトルOther Optionsは曖昧であ
る。Configurationは専門用語である。Printer Config
uration optionsはしばしばはアクセスされないので、
ここにあるべきではない。クリックにより選択肢が順に
表示されることはタスクを達成するために直感的または
フレンドリな方法ではない−−それはユーザにすべての
可能性のある選択肢をはっきりと示さないし、かつもし
ユーザが適切なセッティングを行き過ぎれば、彼はそれ
に戻るためにクリックし続けなければならないであろ
う。Print Quality Optionsは漠然とした専門用語−
−NLQ、レギュラーおよびドラフトを使用する。それは
どういう意味か。レギュラーをNLQの後に置くべきなの
か。GoおよびStopボタンはその機能について不明瞭であ
る。デフォールト動作がない。

とりわけ、一旦開発者がそのアプリケーションのため
の良いインターフェースを作成し、それをするのに多く
の時間およびお金を費やしたとしても、開発者は依然と
して異なった特定UIのもとで異なった環境で実行するた
めには完全に新しい実行可能なプログラムを作らなけれ
ばならない。

スケール可能なユーザインターフェース スケール可能なユーザインターフェースは他のスタイ
ルガイドの１つにすぎないと考えられ得る。それはユー
ザのコンピュータ熟練度を非常に考慮して設計されたス
タイルガイドである。たとえば、初心者に対して、この
スタイルガイドはユーザはオプションのすべてをはっき
りと見ることができると述べる、したがって、隠された
メニュー（プルダウンまたはポップアップ）は許容され
ない。スクローリング視野もまたその複雑さのために望
ましくない。助けとなる目に見える方法は常に明らかで
なければならない。自動化されたスタイルガイドはその
通常のスタイルガイド（MotifまたはOpenlookのよう
な）でアプリケーションを実行可能であるか、または初
心者のために設計されたものに切換えることが可能であ
る。概念的にかつアプリケーション開発者にとって、そ
れはちょうど２つの非常によく似た「プロフェッショナ
ルな」特定ユーザインターフェース間で切換えることと
同一である。ユーザにとって、それは１つの価格で数個
のプログラムを手に入れることと同じである。

動作 図21を参照して、この発明の構成要素のダイナミック
な対話を例示する図が示される。図21の要素はすべてコ
ンピュータソフトウェアで実現化される。アプリケーシ
ョンソフトウェアはオペレーティングシステムソフトウ
ェアと対話する。オペレーティングシステムソフトウェ
アは包括的ユーザインターフェースオブジェクトライブ
ラリおよびコントローラ（GUIOLC）、多数特定UIインタ
ープリタ（SUII）（１つのみ図示）、および多数特定UI
ツールボックスおよびコントローラ（SUITC）（１つの
み図示）、ならびにそのそれぞれのドライバソフトウェ
アモジュール（１組のドライバソフトウェアモジュール
のみ図示）を含む。

アプリケーションデータはアプリケーションソフトウ
ェアに基づいて動作される。包括的UI仕様（GUI）は、
アプリケーションに関連し、GUIOLCに基づいて動作され
る。特定UIアプリケーションインターフェースデータは
SUITCに基づいて動作される。

複数のアプリケーションが同時に実行可能である。各
アプリケーションは特定のGUIに対応する。多数のGUI
S、つまり異なったアプリケーションのための異なったG
UISを有することが可能である。

GUIOLCおよびSUIIはアプリケーションの入力／出力
（I/O）要求をその下でアプリケーションがユーザに示
されることが可能なSUITCにマッピングする機能を果た
す。この実施例において、GUIOLCは一連の包括的UIオブ
ジェクトクラス（たとえば、GenApplication、GenPrima
ry、GenTrigger、など）を与える。これらの包括的UIク
ラスは、アプリケーションとそのアプリケーションのた
めの特定ユーザインターフェースの表示をコントロール
するオプレーティングシステムソフトウェアの部分との
間のインターフェースとして作用する。たとえば、アプ
リケーションがあるユーザアクションを開始するために
使用されるUIコンポーネントを示すことが必要な場合、
それはGenTrigger包括的ユーザインターフェースオブジ
ェクトを特定する。アプリケーションの見地から、ユー
ザ対話を開始するためのコンポーネントを示すために必
要とされるステップは、単にGenTriggerオブジェクトを
特定することを含むだけである。以下に説明されるよう
に、この発明に従うオペレーティングシステムソフトウ
ェアは、コンポーネントを示すために使用される小道具
を実際に選択する、配列するおよびそうでない場合は管
理する詳細を扱う。

一旦アプリケーションが特定の包括的ユーザインター
フェースオブジェクトを特定すれば、選択されたSUIIは
特定されたオブジェクトおよびそのオブジェクトのため
のインスタンスデータを使用して、特定されたオブジェ
クトが表示されることが可能な態様を解釈する。特に、
選択されたSUIIは対応するSUITCから小道具を選択し、
その小道具を特定されたオブジェクトのためのインスタ
ンスデータの属性およびヒントに従って配列する。

各アプリケーションはそれに関連する異なったGUISを
有することが可能である。したがって、２つのアプリケ
ーションは同一の包括的UIオブジェクトを特定し得る一
方で、異なったアプリケーションに関連する異なったGU
ISは同一の包括的UIオブジェクトに対して異なった表示
（視覚上またはふるまい上）という結果をもたらし得
る。これは異なったGUISは異なったインスタンスデータ
を有することが可能であるからである。

この発明において、アプリケーションよりはむしろオ
ペレーティングシステムソフトウェアがその下でアプリ
ケーションが実行される特定UIを示す。このように、た
とえば、もし４つの可能な特定UI（４つの対応するSUIS
および４つの対応するSUITCを有する）があれば、シス
テムソフトウェアは４つのうちのどれがアプリケーショ
ンによって使用されるべきか（および４つのSUIIおよび
SUITCのうちどれか）を決定する。しかしながら、アプ
リケーションそれ自体が４つの（またはそれ以上の）特
定UIのどれがアプリケーションによって使用されるべき
であるかを示すことは可能である。

図21、31および32を参照して、本願発明の実施例の動
作の例をいくつか説明する。図21を参照して、あるアプ
リケーションプログラムはそのユーザインタフェースの
要件を特定するためにある包括的オブジェクトクラスを
使用する。包括的ユーザインタフェース仕様（GUIS）
は、そのアプリケーションによって使用された個々の包
括的ユーザインタフェースオブジェクトのインスタンス
データを提供する。特定ユーザインタフェースインタプ
リタ（SUII）が、この包括的オブジェクトクラスの特定
の表現を生成するために、与えられた包括的オブジェク
トクラスのインスタンスデータを解釈する。すなわち、
その包括的オブジェクトクラスを表現する特定ユーザイ
ンタフェースの小道具の外見および動作は、その包括的
オブジェクトクラスのためにGUISにより提供されたイン
スタンスデータと、そのインスタンスデータを解釈する
ために使用されたSUIIとの双方に依存するだろう。本願
発明の重要な局面として、ある包括的オブジェクトクラ
スのインスタンスデータを解釈できるSUIIが複数個存在
し得る。したがってどのSUIIが使用されるかによって、
同一のインスタンスデータを有する同一の包括的オブジ
ェクトクラスに対する、複数個の異なる表現が存在し得
る。

たとえば図31は、OpenLookユーザインタフェースにお
けるGenListオブジェクトクラスのためのSUIIの動作を
示す。図31に示すチャートの左欄は、簡約メニューボタ
ンと、排他的設定と、スクロールリストという３つの異
なる特定の解釈の持つ性質のいくつかを説明している。
中央の欄は、これら３つの解釈の視覚的表現を示す。右
欄は、どの表面を選択するかを判定するうえでインタプ
リタが適用した解釈規準を示している。

与えられたオブジェクトのためにどのユーザインタフ
ェース表現を選択するかを決定するために、インタプリ
タは右欄に示される解釈規準を、GenListオブジェクト
のインスタンスデータと比較する。たとえば、GenList
オブジェクトが「10項目を有するGenList」という属性
と、「USE_MINIMAL_SCREEN_SPACE（最小領域を使用のこ
と）」というヒントとを指定している場合を考える。こ
のインスタンスデータは、ちょうど10項目を有するGenL
istオブジェクトの、画面上最小となるような小道具表
現を要求している。

図31のインタプリタは、GenListを具体化するために
使用し得るものとして３つの小道具を有する。いずれの
小道具も上記した例で指定された「項目数＝10」という
（必須の）属性基準を満たすことができるので、これら
３つのいずれも規則に合致した解釈となり得る。しかし
最善の解決策を見いだすためにさらにインタプリタは、
そのオブジェクトが、ヒントにさらに記載されていると
ころに従って、各小道具についてスタイルガイドにより
示唆された使用方法とどの程度合致しているかを調べる
ことにより、各選択肢の好ましさを評価する。

インタプリタを有する規則に従えば、スクロールリス
トは採用されない。なぜならばこのオブジェクトは17個
以上の項目を持っているわけでも、より少ない項目に対
して使用することを許可するようなヒントを持っている
わけでもないためである。同様に排他的設計も採用され
ない。なぜならばこのオブジェクトは２〜５個の項目を
持っているわけでも、このオブジェクトが持っている10
項目に対して排他的設定を使用することを許すようなヒ
ントを持っているわけでもないためである。このオブジ
ェクトは、簡約メニューボタンについての規則にのみ適
合する。なぜならばこのオブジェクトは、第１および第
２の基準、すなわち６以上16個以下の項目数を有するこ
と、および16項目以下であって、「HINT_USE_MINIMAL_S
CREEN_SPACE」という条件を有する第２の基準との双方
を満たしているためである。小道具のうちだた１つのタ
イプのものしか基準を満たさないので、SUIIはこのオブ
ジェクトをこの小道具の形式にする。仮にヒントが「HI
NT_USE_MAXIMAL_SCREEN_SPACE」というものであれば、
排他的設定もまた有力な選択肢となり、SUIIはこの２つ
の小道具のうち一方を選択しなければならない。その場
合にはSUIIは、たとえば「指定された要件のうちに、よ
り多くのヒントを有している選択肢の方を取る」という
ような、より一般的な規則に基づいてこの選択を行なう
であろう。

今たとえば、同一のインスタンスデータを有するGenL
istオブジェクトが別のインタプリタにより解釈される
場合を考える。特に、同一のオブジェクトおよびデータ
が図32に示す仮想的インタプリタによって解釈されるも
のとする。このインタプリタのスタイルガイドによれ
ば、GenListオブジェクトの解釈として２つの選択肢し
か示されていない。どちらを選択肢も10項目を表示する
ことができ、したがってこの場合にも、例として示した
GenListの（必須の）属性基準はいずれの小道具を用い
ても満足される。この場合インタプリタは、オブジェク
トを記述するヒントと属性との組合せと、各小道具につ
いての最適な使用方法を記載した規則とを使用する。

例として示したGenListは、グラフィックラジオボタ
ンの形式にすることについての規則を満足しない。なぜ
ならばこのオブジェクトは２以上５以下の項目数を持っ
ているわけでも、そのオブジェクトが10項目を有するグ
ラフィカルラジオボタンの形式となるべきであることを
示すようなヒントのいずれを持っているわけでもないた
めである。この例のGenListはしかし、スクロールリス
トの最初の基準、すなわち11以下の項目数を有するこ
と、という基準を満足する。

したがって図31および図32に示されるSUIIの例の何れ
においても、例として示したGenListオブジェクトに課
された「HINT_USE_MINIMAL_SCREEN_SPACE」というヒン
トにより、当初所望されたとおり、利用可能な小道具の
うち表示領域が最小のものがインタプリタによって選択
されるという結果が得られる。

図23ないし図26は特定のアプリケーションのための同
一の包括的UIオブジェクトおよびGUISが異なった特定UI
が指令された場合にどのように結果として異なった視覚
上の表示をもたらし得るかを例示する。図23において、
GenDocumentControlオブジェクトおよびアプリケーショ
ンGUISからのインスタンスデータが示される。図24は図
23のオブジェクトの可能性のあるNewWave解釈を示す。
図25は図23のオブジェクトの可能性のあるOpenLook解釈
を示す。図26は図23のオブジェクトの可能性のあるMoti
ff解釈を示す。

図27ないし図30の特定のアプリケーションのための同
一の包括的UIオブジェクトおよびGUISが、異なった特定
UIが指定された場合にどのように異なった視覚上の表示
を結果としてもたらし得るかをさらに示す。図28ないし
図30はそれぞれ図27のオブジェクトの可能性のあるNewW
ave、OpenLookおよびMotiff解釈を示す。

図31はOpenLookユーザインターフェース下でのGenLis
tオブジェクトのための代表的なSUIIのオペレーション
を例示する。対応するOpenLook SUITCから利用可能な
可能性のある小道具選択肢は左のカラムに示される。こ
のSUIIに従う小道具の表示および配列は中央のカラムに
示される。どの小道具選択を行なうべきかを判断するた
めに使用される決定方法は右のカラムに示される。

このように、代表的なインタープリタはどの小道具
（左カラム）かを選択し、決定された規準（左カラム）
に基づいてその配列（中央カラム）を選択する。規準を
テストするために使用される情報は、指定されたGenLis
tオブジェクトためのGUISのインスタンスデータ内に見
出される。

たとえば、あるアプリケーションはGenListオブジェ
クトのためのGUISにおいてあるインスタンスデータを特
定することができ、他のアプリケーションはGenListオ
ブジェクトのためのGUISにおいて異なったインスタンス
データを特定し得ることに注目されたい。図31の例証的
SUIIを使用するオペレーティングシステムは、したがっ
て、その異なったGUISのために２つのアプリケーション
に対して異なってGenListオブジェクトを示すことが可
能である。

図32は他の例証的なSUIIのオペレーションを例示す
る。図32のインタープリタはGenListオブジェクトに対
する仮想的なものである。左カラムは仮想的SUITC（図
示せず）からの可能性のある小道具を示す。中央カラム
はこのインタープリタ下でのその配列を示す。右カラム
は小道具を選択するために使用される規準を例示する。

図31および図32から、同一のGUISからの同一のインス
タンスデータを使用する同一の包括的UIオブジェクト
（たとえばGenList）は、異なった特定UIが選択された
場合、異なったUI表示を結果として生じ得ることが理解
されなければならない。たとえば、図31において、特定
UIはOpenLookであり、図32において、特定UIは仮想的UI
である。

図33は包括的ユーザインターフェースオブジェクト
（GenList）およびそのインスタンスデータならびにそ
の２つの可能性のある解釈、１つは仮想的UI下のもの、
他方はOpenLookUI下のもの、のさらなる表示を示す。

図34は包括的UIオブジェクトおよびそのそれぞれのイ
ンスタンスデータの代表的階層を示す。図35は可能性の
あるMotiffおよびOpenLook解釈を示す。図36は可能性の
ある仮想的グラフィカルUI解釈を示す。図37および図38
はそれぞれ上級および初心者モード下での可能性のある
仮想的解釈を示す。

図43はこの発明に従うオペレーティングシステムによ
るユーザ対話の解釈を示すダイナミックなブロック図を
与える。ユーザはテキスト上のダブルクリックマウスコ
マンドのような入力を与える。アプリケーションはユー
ザ入力コマンド情報（ダブルクリック）および文脈情報
（テキストを介する）を特定UIインタープリタに与え
る。SUIIは入力情報を解釈し、その意味をアプリケーシ
ョンに示す。これによりアプリケーションは、オペレー
ティングシステムに対して入力と一致した機能を実行す
るようにリクエストすることが可能である（たとえば、
ターゲットになった語を選択する）。

異なった特定UIは同一の入力を異なって解釈し得るこ
とが理解されるであろう。さらに、異なった解釈はコマ
ンドの性質だけではなく、コマンドが与えられる文脈に
も依存し得る。SUIIはユーザ入力解釈の詳細からアプリ
ケーションを隠蔽する。もちろん、上に説明されたよう
に、そのオペレーティングシステムによってサポートさ
れる多数の特定UIがあり得る。上に説明されたように、
異なった特定UIのための異なったSUIIはユーザ入力（コ
マンドプラス文脈）を異なって解釈し得る。

図41を参照して、オブジェクト指向システムのオペレ
ーションの一般化された表示を与えるダイナミックなブ
ロック図が与えられる。この発明はオブジェクト指向シ
ステムとして実現化されるが、それは手続型システムと
しても実現可能である（図39）。

現在の好ましい実施例において、各包括的UIオブジェ
クトはクラスを示す。アプリケーションのためのGUISは
インスタンスデータを包括的UIオブジェクトクラスメン
バーに与える。多数SUIIはインスタンスデータに基づい
て動作するための方法を指すメッセージを含む。

このように、たとえば、アプリケーションが第１の特
定UIのもとで実行している場合、包括的UIオブジェクト
は第１の特定UIのためのSUIIを指し、その第１のSUIIの
メッセージおよび方法は包括的UIオブジェクトのインス
タンスデータに基づいて動作する。他方、もしアプリケ
ーションが第２の特定UIのもとで実行していれば、包括
的UIは第２の特定UIのためのSUIIを指し、第２のSUIIの
メッセージおよび方法は包括的UIオブジェクトのインス
タンスデータに基づいて動作する。

たとえば、アプリケーションおよびSUIIは包括的UIオ
ブジェクトを介してコミュニケート可能であることが理
解されるであろう。たとえば、図31を参照して、アプリ
ケーションは包括的UIオブジェクトGenListを特定し、
メッセージ、「tomato」を削除する、を伝える。GenLis
tオブジェクトは、たとえばOpenLook特定UIのもとで実
行され、メッセージをOpenLook SUIIを送る。OpenLook
SUIIはそのメッセージを使って、UI表示から「tomat
o」名の除去を結果としてもたらす方法を認識する。

この発明の特定の実施例を示し説明してきたが、この
システムはこの発明から逸脱することなく異なって実現
化され得ることが理解されるであろう。たとえば、図39
に例示したように、この発明はオブジェクト指向システ
ムよりはむしろ手続型システムとして実現可能である。
さらに、たとえば、この実施例において、GUIOLCおよび
多数SUIIは別個のモジュールである。GUIOLCおよび多数
SUIIはこの発明から逸脱することなく単一のモジュール
として実現化され得る。

付録D:スタイルガイド スタイルガイドは特定の環境で動作している一団のア
プリケーションの全体にわたって視覚上および動作上の
双方の一貫性を促進するように意図されたドキュメント
である。この目標を達成するために、設計規則はユーザ
インターフェースおよび設計アプローチを詳細に記載す
る。しかしながら、すべての状況を予期することは不可
能である。その結果一貫性のある拡散が行なわれ、ドキ
ュメントのある部分は規則の根拠となる原理を説明し、
問題になっているアプリケーションの意図された「フィ
ール」を説明しようとする。これらの設計規則は統一お
よび一貫性を追求するため設けられる。アプリケーショ
ンプログラマはコヒーシブで一貫性のある一群のアプリ
ケーションの重要性のために設計規則に従うように求め
られる。たとえばHP New Wave環境：ユーザ対話設計
規則（User Interface Design Rules）を見られたい。

たとえば、以下は「Open Lookグラフィカルユーザ対
話アプリケーションスタイルガイドライン（Open Look
Graphical User Interface Application Style Guide l
ines）」からの抜粋である。これは（上下左右に「スク
ローリング」することによってユーザが一度に大きなド
キュメントの部分を見ることを可能にする）スクロール
バーのためのふるまい上および視覚上のガイドラインを
記載する。

「スクロールバーでのスクローリング：このセクショ
ンは貴方がスクロールバーにスクロール可能なテキスト
領域を与える際に貴方のアプリケーションに対して特定
する必要のある情報を記載する…」 「未知のサイズのスクローリングオブジェクト：幾つ
かの状況において、視野に入っているオブジェクトのサ
イズを決定することは不可能である。たとえば、データ
ベースキューリーの結果は必要とされる場合にのみ読込
まれるかもしれない。かかる状況は通常のスクロールバ
ーのふるまいを僅かに修正することを要求する。

・全体のオブジェクトのサイズがわかっていない場合、
比率インジケータの長さが任意の所与の点で知られてい
るオブジェクトの部分の長さを示すようにさせる。」 「もしユーザがエレベータをドラッグするかまたは端
部ケーブルアンカーをクリックするかのいずれかによっ
てケーブルの端部にスクロールすれば、既に読込まれた
データの端部まで視野をスクロールする。エレベータを
ちょうど端部でそのままにしておくと、それは誤解を招
く恐れがある、なぜなら現在の視野はすべてのデータの
端部ではないからである。

・エレベータがデータの端部でない場合、底のケーブル
アンカーから２、３画素上にエレベータを押し上げ、そ
の視野がデータの真の端部でないことを示す。ユーザに
今起こっていることを知らせるためにウィンドウの下部
にメッセージを出す。

・ユーザが再びエレベータをドラッグするかまたは下向
き（または右向き）矢印をクリックした場合、ユーザが
データの次の部分を読込みたい信号としてそのアクショ
ンを解釈する。」 「一旦新しいデータが読込まれると、スクローク可能
なオブジェクトはより大きくなり、貴方はそれに従って
エレベータの位置を調整する必要がある。」 アプリケーション開発者をこの何頁もの処理の必要性
から解放することがこの特許のすべてである。

フロントページの続き (31)優先権主張番号 ６８１．１０２ (32)優先日 1991年４月５日 (33)優先権主張国 米国（ＵＳ） (72)発明者 リクイスト，アンソニー・エム アメリカ合衆国、94501 カリフォルニ ア州、アラメダ、アビントン・ロード、 209

Claims (11)

(57)【特許請求の範囲】
1. 【請求項１】コンピュータシステムで動作するアプリケ
   ーションとともに使用するためのユーザインターフェー
   スを起動するための方法であって、 ユーザインターフェースを使用して実行されるべきある
   クラスの機能に対応する包括的オブジェクトクラスをコ
   ンピュータシステムにおいて与えるステップと、 そのアプリケーションにおいて包括的オブジェクトクラ
   スに対応する包括的オブジェクト仕様の形のインスタン
   スデータを特定するステップとを含み、インスタンスデ
   ータは属性規準およびヒント規準を含み、 前記属性規準は前記インスタンスデータを用いて選択さ
   れる特定ユーザインターフェース実現化例が満足しなけ
   ればならない規準であり、前記ヒント規準は前記インス
   タンスデータにおいて特定されることが許可されてはい
   るが要求されてはいない規準であり、かつ特定されてい
   る場合には、前記インスタンスデータを用いて選択され
   た特定ユーザインターフェース実現化例により満足され
   ることが許容されるが、要求されてはいない規準であ
   り、 そのクラスの機能を行なう際に使用するための可能性の
   ある特定ユーザインターフェース実現化例の選択を与え
   るためにコンピュータシステムで動作する少なくとも１
   つの特定ユーザインターフェースツールボックスおよび
   コントローラをコンピュータシステムにおいて与えるス
   テップと、さらに 前記特定ユーザインターフェースツールボックスおよび
   コントローラに対応する少なくとも１つのインタープリ
   タをコンピュータシステムにおいて与えるステップとを
   含み、前記インタープリタは可能性のある特定ユーザイ
   ンターフェース実現化例の選択肢から特定ユーザインタ
   ーフェース実現化例を選択するためにコンピュータシス
   テムにおいて動作し、その結果選択された特定ユーザイ
   ンターフェース実現化例は包括的オブジェクトクラスの
   ために特定された属性規準およびヒント規準の双方を満
   足させるようにされるが、ただしもしどの特定ユーザイ
   ンターフェース実現化例も包括的オブジェクトクラスの
   ために特定された属性規準およびヒント規準の双方を満
   足させなければ、その場合は前記インタープリタは包括
   的オブジェクトクラスのために特定された属性規準を満
   たし、かつすべてのヒント規準は満たさない別の特定ユ
   ーザインターフェース実現化例を選択するように動作可
   能である、方法。
2. 【請求項２】コンピュータシステムにおいて包括的オブ
   ジェクトクラスを与える前記ステップは包括的オブジェ
   クトクラスのライブラリを与えるステップを含み、前記
   ライブラリの各それぞれの包括的オブジェクトクラスは
   それぞれのクラスの機能を示す、請求項１に記載の方
   法。
3. 【請求項３】コンピュータシステムにおいて包括的オブ
   ジェクトクラスを与える前記ステップは、コンピュータ
   システムに、複数個の包括的オブジェクトクラスを与え
   るステップを含み、前記複数の包括的オブジェクトクラ
   スの各々は、前記ユーザインターフェースを用いて実行
   される機能の異なるクラスに対応し、さらに 前記インスタンスデータを特定するステップは、アプリ
   ケーション内において複数のそれぞれの包括的オブジェ
   クト仕様を特定するステップを含む、請求項１に記載の
   方法。
4. 【請求項４】複数のそれぞれの包括的オブジェクト仕様
   を特定する前記ステップは複数のそれぞれの包括的オブ
   ジェクトクラスの間のツリー階層関係を特定するステッ
   プを含む、請求項３に記載の方法。
5. 【請求項５】複数のそれぞれの包括的オブジェクト仕様
   を特定する前記ステップは複数のそれぞれの包括的オブ
   ジェクトクラスの間のツリー階層関係を特定するステッ
   プを含み、さらに 前記ツリー階層はどの視覚上のユーザインターフェース
   コンポーネントが目視可能であり、それら視覚上のユー
   ザインターフェースコンポーネントのどれが他のそれら
   コンポーネントによって隠されることが可能かを示す、
   請求項３に記載の方法。
6. 【請求項６】コンピュータシステムで動作するアプリケ
   ーションとともに使用するためのユーザインターフェー
   スを起動するための方法であって、 ユーザインターフェースで実行されるそれぞれのクラス
   の機能にそれぞれ対応する複数のそれぞれの包括的オブ
   ジェクトクラスをコンピュータシステムにおいて与える
   ステップと、 コンピュータシステムに与えられたそれぞれの包括的オ
   ブジェクトクラスのうちの指定されたものに対応する包
   括的オブジェクト仕様の形でインスタンスデータをアプ
   リケーション内で特定するステップとを含み、前記イン
   スタンスデータは属性規準およびヒント規準を含み、前
   記属性規準は前記インスタンスデータを用いて選択され
   た特定ユーザインターフェース実現化例が満足しなけれ
   ばならない規準であり、前記ヒント規準は、前記インス
   タンスデータ内において満足されることが許容されるが
   要求はされておらず、仮に特定されている場合には、前
   記インスタンスデータを用いて選択された特定ユーザイ
   ンターフェース実現化例により満足されることが許容さ
   れるが要求はされないものであり、さらに 指定された包括的オブジェクトクラスの機能のクラスを
   実行する際に使用するための可能な特定ユーザインター
   フェース実現化例の選択肢を与えるためにコンピュータ
   システムにおいて動作する特定ユーザインターフェース
   ツールボックスおよびコントローラをコンピュータシス
   テムにおいて与えるステップと、さらに 前記特定ユーザインターフェースツールボックスおよび
   コントローラに対応するインタープリタをコンピュータ
   システムにおいて与えるステップとを含み、前記インタ
   ープリタは可能な特定ユーザインターフェース実現化例
   の選択肢から特定ユーザインターフェース実現化例を選
   択するためにコンピュータシステムにおいて動作し、そ
   の結果選択された特定ユーザインターフェース実現化例
   は指定された包括的オブジェクトクラスのために特定さ
   れたそれぞれの属性規準およびそれぞれのヒント規準の
   双方を満足させるようにされるが、ただし仮にどの特定
   ユーザインターフェース実現化例も前記指定された包括
   的オブジェクトクラスのために特定されたそれぞれの属
   性規準およびそれぞれのヒント規準の双方を満足させな
   ければ、前記インタープリタは前記指定された包括的オ
   ブジェクトクラスのために特定されたそれぞれの属性規
   準を満足させ、かつすべてのヒント規準は満足しない別
   の特定ユーザインターフェース実現化例を選択するよう
   に動作可能である、方法。
7. 【請求項７】コンピュータシステムで動作するアプリケ
   ーションで使用されるユーザインターフェースを指定す
   るための方法であって、 コンピュータシステムにおいて第１の包括的オブジェク
   トクラスと第２の包括的オブジェクトクラスとを与える
   ステップを含み、かかる各包括的オブジェクトクラスは
   ユーザインターフェースを使用して実行されるべきそれ
   ぞれのクラスの機能に対応し、 第１の包括的オブジェクトクラスに対応する第１の包括
   的オブジェクト仕様の形で第１のインスタンスデータを
   アプリケーションにおいて特定するステップを含み、前
   記第１のインスタンスデータは第１の属性規準および第
   １のヒント規準を含み、前記第１の属性規準は前記第１
   のインスタンスデータを使用して選択された特定ユーザ
   インターフェース実現化例により満足されなければなら
   ない規準であり、前記第１のヒント規準は、前記第１の
   インスタンスデータにおいて特定されることが許容され
   ているが要求はされていない規準であり、仮に特定され
   ている場合には、前記第１のインスタンスデータを使用
   して選択された特定ユーザインターフェース実現化例に
   より満足されることが許容されているが要求はされてお
   らず、 第２の包括的オブジェクトクラスに対応する第２の包括
   的オブジェクト仕様の形で第２のインスタンスデータを
   アプリケーションにおいて特定するステップを含み、該
   第２のインスタンスデータは第２の属性規準および第２
   のヒント規準を含み、前記第２の属性規準は前記第２の
   インスタンスデータを使用して選択された特定ユーザイ
   ンターフェース実現化例によって満足されることが要求
   される規準であり、前記第２のヒント規準は、前記第２
   のインスタンスデータにより特定されることが許容され
   るが要求はされておらず、かつ仮に特定されている場合
   には、前記第２のインスタンスデータを使用して選択さ
   れた特定ユーザインターフェース実現化例によって満足
   されることが許容されるが要求はされず、 前記第１および第２の包括的オブジェクトクラスの各々
   に対して、複数の可能な特定ユーザインターフェース実
   現化例のそれぞれの選択肢を与えるようにコンピュータ
   システムで動作する特定ユーザインターフェースツール
   ボックスおよびコントローラをコンピュータシステムに
   おいて与えるステップと、 前記特定ユーザインターフェースツールボックスおよび
   コントローラに対応するインタープリタをコンピュータ
   システムにおいて与えるステップとを含み、該インター
   プリタは第１の包括的オブジェクトクラスインタープリ
   タおよび第２の包括的オブジェクトクラスインタープリ
   タを含み、 第１の包括的オブジェクトクラスインタープリタを使用
   して特定ユーザインターフェースツールボックスおよび
   コントローラから第１の包括的オブジェクトクラスのた
   めの第１の特定ユーザインターフェース解釈を作るステ
   ップを含み、その結果前記第１の特定ユーザインターフ
   ェース解釈は特定された前記第１の属性規準および前記
   第１のヒント規準の双方を満足させるようにされるが、
   ただしもしどの第１の特定ユーザインターフェース解釈
   も前記第１の属性規準および前記第１のヒント規準の双
   方を満足させなければ、前記第１の属性規準を満足させ
   るが前記第１のヒント規準のすべては満足させない別の
   第１の特定ユーザインターフェース解釈を作るために前
   記第１の包括的オブジェクトクラスインタープリタを使
   用し、さらに 第２の包括的オブジェクトクラスインタープリタを使用
   して特定ユーザインターフェースツールボックスおよび
   コントローラから第２の包括的オブジェクトクラスのた
   めの第２の特定ユーザインターフェース解釈を作るステ
   ップを含み、その結果選択された第２の特定ユーザイン
   ターフェース解釈は前記第２の属性規準および前記第２
   のヒント規準の双方を満足させるようにされるが、ただ
   しもしどの第２の特定ユーザインターフェース解釈も前
   記第２の属性規準および前記第２のヒント規準の双方を
   満足させなければ、特定された前記第２の属性規準を満
   足させるが、前記第２のヒント規準のすべては満足しな
   い、別の第２の特定ユーザインターフェース解釈を選択
   するために第２の包括的オブジェクトインタープリタを
   使用する、方法。
8. 【請求項８】コンピュータシステムにおいて動作するア
   プリケーションとともに使用されるユーザインターフェ
   ースを指定するための方法であって、 ユーザインターフェースで実行されるべきあるクラスの
   機能に対応する包括的オブジェクトクラスをコンピュー
   タシステムにおいて与えるステップと、 前記包括的オブジェクトクラスに対応するインスタンス
   データをアプリケーションで特定するステップとを含
   み、該インスタンスデータは属性規準およびヒント規準
   を含み、前記属性規準は前記インスタンスデータを使用
   して選択された特定ユーザインターフェース実現化例に
   より満足されなければならない規準であり、前記ヒント
   規準は、前記インスタンスデータにおいて特定されるこ
   とが許容されるが要求はされておらず、仮に特定された
   場合には、前記インスタンスデータにより選択された特
   定ユーザインターフェース実現化例により満足されるこ
   とが許容されるが要求はされない規準であり、 前記クラスの機能を実行する際に使用するための複数の
   可能な第１の特定ユーザインターフェース実現化例の第
   １の選択肢を与えるようにコンピュータシステムにおい
   て動作可能な第１の特定ユーザインターフェースツール
   ボックスおよびコントローラをコンピュータシステムに
   おいて与えるステップと、 前記クラスの機能を実行する際に使用するための複数の
   可能な第２の特定ユーザインターフェース実現化例の第
   ２の選択肢を与えるようにコンピュータシステムにおい
   て動作可能な第２の特定ユーザインターフェースツール
   ボックスおよびコントローラをコンピュータシステムに
   おいて与えるステップと、 第１の特定ユーザインターフェースツールボックスおよ
   びコントローラに対応する第１のインタープリタをコン
   ピュータシステムで与えるステップとを含み、該第１の
   インタープリタは可能な第１の特定ユーザインターフェ
   ース実現化例の第１の選択肢から第１の特定ユーザイン
   ターフェース実現化例を選択するようにコンピュータシ
   ステムで動作可能であり、その結果第１の選択肢から選
   択された第１の特定ユーザインターフェース実現化例は
   前記包括的オブジェクトクラスのために特定された属性
   規準およびヒント規準の双方を満足させるようにされる
   が、ただしもし第１の選択肢からのどの第１の特定ユー
   ザインターフェース実現化例も包括的オブジェクトクラ
   スのために特定された属性規準およびヒント規準の双方
   を満足させなければ、第１のインタープリタは前記包括
   的オブジェクトクラスのために特定された属性規準を満
   足させるが、前記包括的オブジェクトクラスに対して特
   定された前記ヒント規準のすべては満足しない、別の第
   １の特定ユーザインターフェース実現化例を第１の選択
   肢から選択するように動作可能であり、 第２の特定ユーザインターフェースツールボックスおよ
   びコントローラに対応する第２のインタープリタをコン
   ピュータシステムにおいて与えるステップを含み、該第
   ２のインタープリタは可能な第２の特定ユーザインター
   フェース実現化例の第２の選択肢から第２の特定ユーザ
   インターフェース実現化例を選択するようにコンピュー
   タシステムにおいて動作可能であり、その結果第２の選
   択肢から選択された第２のユーザインターフェース実現
   化例は包括的オブジェクトクラスに対して特定された属
   性規準およびヒント規準の双方を満足させるようにされ
   るが、ただしもし第２の選択肢からのどの第２の特定ユ
   ーザインターフェース実現化例も前記包括的オブジェク
   トクラスに対して特定された属性規準およびヒント規準
   の双方を満足させなければ、前記第２のインタープリタ
   は前記包括的オブジェクトクラスに対して特定された属
   性規準を満足させるが、前記包括的オブジェクトクラス
   に対して特定された前記ヒント規準のすべては満足しな
   い、別の第２の特定ユーザインターフェース実現化例を
   前記第２の選択肢から選択するように動作可能であり、 前記第１および第２の特定ユーザインターフェースツー
   ルボックスおよびコントローラのうちの１つならびに前
   記第１および第２のインタープリタの対応する１つを選
   択するステップと、さらに 選択されたコントローラおよび選択されたインタープリ
   タを使用して第１の特定ユーザインターフェース実現化
   例および第２の特定ユーザインターフェース実現化例の
   うちの１つを作るステップとを含む、方法。
9. 【請求項９】コンピュータシステムで動作するアプリケ
   ーションとともに使用されるユーザインターフェースを
   指定するための方法であって、 A.第１のクラスの機能に対応する第１の包括的オブジェ
   クトクラス、および第２のクラスの機能に対応する第２
   の包括的オブジェクトクラスをコンピュータシステムで
   与えるステップと、 B.前記第１の包括的オブジェクトクラスに対応する第１
   の包括的オブジェクト仕様の形で第１のインスタンスデ
   ータをアプリケーションで特定するステップとを含み、
   該第１のインスタンスデータは属性規準およびヒント規
   準を含み、前記属性規準は前記第１のインスタンスデー
   タを使用して選択された特定ユーザインターフェース実
   現化例により満足されなければならない規準であり、前
   記ヒント規準は、前記第１のインスタンスデータにより
   特定されることが許容されるが要求はされておらず、仮
   に特定されている場合には、前記第１のインスタンスデ
   ータを使用して選択された特定ユーザインターフェース
   実現化例によって満足されることが許容されるが要求は
   されない規準であり、 C.前記第２の包括的オブジェクトクラスに対応する第２
   の包括的オブジェクト仕様の形で第２のインスタンスデ
   ータをアプリケーションで特定するステップを含み、該
   第２のインスタンスデータは属性規準およびヒント規準
   を含み、前記属性規準は前記第２のインスタンスデータ
   を使用して選択された特定ユーザインターフェース実現
   化例によって満足されなければならない規準であり、前
   記ヒント規準は前記第２のインスタンスデータによって
   特定されることが許容されるが要求はされておらず、か
   つ特定されている場合には、前記第２のインスタンスデ
   ータを使用して選択された特定ユーザインターフェース
   実現化例によって満足されることが許容されるが要求は
   されない規準であり、 D.前記第１および第２の包括的オブジェクトクラスの各
   々に、複数の可能な第１の特定ユーザインターフェース
   実現化例のそれぞれの第１の選択肢を与えるようにコン
   ピュータシステムで動作可能な第１の特定ユーザインタ
   ーフェースツールボックスおよびコントローラをコンピ
   ュータシステムで与えるステップと、 E.前記第１および第２の包括的オブジェクトクラスの各
   々に、複数の可能な第２の特定ユーザインターフェース
   実現化例のそれぞれの第２の選択肢を与えるようにコン
   ピュータシステムで動作可能な第２の特定ユーザインタ
   ーフェースツールボックスおよびコントローラをコンピ
   ュータシステムで与えるステップと、 F.前記第１の特定ユーザインターフェースツールボック
   スおよびコントローラに対応する第１のインタープリタ
   をコンピュータシステムで与えるステップとを含み、 i.前記第１のインタープリタは前記第１の包括的オブジ
   ェクトクラスのためのそれぞれの第１の特定ユーザイン
   ターフェース実現化例を前記第１の特定ユーザインター
   フェースツールボックスおよびコントローラから選択す
   るように動作可能であり、その結果選択された第１の特
   定ユーザインターフェース実現化例はそれぞれの前記第
   １の包括的オブジェクトクラスに対して特定された属性
   規準およびヒント規準の双方を満足させるようにされる
   が、ただしもしどの第１の特定ユーザインターフェース
   実現化例も前記第１の包括的オブジェクトクラスの属性
   規準およびヒント規準の双方を満足させなければ、前記
   第１のインタープリタは前記第１の包括的オブジェクト
   クラスのために特定された属性規準を満足させるが、前
   記ヒント規準のすべては満足しない、別の第１の特定ユ
   ーザインターフェース実現化例を前記第１の選択肢から
   選択するように動作可能であり、さらに ii.前記第１のインタープリタは前記第２の包括的オブ
   ジェクトクラスのためのそれぞれの第１の特定ユーザイ
   ンターフェース実現化例を第１の特定ユーザインターフ
   ェースツールボックスおよびコントローラから選択する
   ように動作可能であり、その結果選択された第１のユー
   ザインターフェース実現化例は前記第２の包括的オブジ
   ェクトクラスに対して特定された属性規準およびヒント
   規準の双方を満足させるようにされるが、ただしもしど
   の第１の特定ユーザインターフェース実現化例も前記第
   ２の包括的オブジェクトクラスの属性規準およびヒント
   規準の双方を満たさなければ、前記第１のインタープリ
   タは前記第２の包括的オブジェクトクラスに対して特定
   された属性規準を満足させるが、前記ヒント規準のすべ
   ては満足しない、別の第１の特定ユーザインターフェー
   ス実現化例を前記第１の選択肢から選択するように動作
   可能であり、 G.前記第２の特定ユーザインターフェースツールボック
   スおよびコントローラに対応する第２のインタープリタ
   をコンピュータシステムで与えるステップを含み、 i.前記第２のインタープリタは前記第１の包括的オブジ
   ェクトクラスのためのそれぞれの第２の特定ユーザイン
   ターフェース実現化例を前記第２の特定ユーザインター
   フェースツールボックスおよびコントローラから選択す
   るように動作可能であり、その結果選択された第２の特
   定ユーザインターフェース実現化例はそれぞれの前記第
   １の包括的オブジェクトクラスの属性規準およびヒント
   規準の双方を満足させるようにされるが、ただしもしど
   の第２の特定ユーザインターフェース実現化例も前記第
   １の包括的オブジェクトクラスに対して特定された属性
   規準およびヒント規準の双方を満足させなければ、前記
   第２のインタープリタは前記第１の包括的オブジェクト
   クラスに対して特定された属性規準を満足させるが、前
   記ヒント規準のすべては満足しない、別の第２の特定ユ
   ーザインターフェース実現化例を前記第２の選択肢から
   選択するように動作可能であり、さらに ii.前記第２のインタープリタは前記第２の包括的オブ
   ジェクトクラスに対して特定されたそれぞれの第２の特
   定ユーザインターフェース実現化例を前記第２の特定ユ
   ーザインターフェースツールボックスおよびコントロー
   ラから選択するように動作可能であり、その結果選択さ
   れた第２のユーザインターフェース実現化例は前記第２
   の包括的オブジェクトクラスに対して特定された属性規
   準およびヒント規準の双方を満足させるようにされる
   が、ただしどの第２の特定ユーザインターフェース実現
   化例も前記第２の包括的オブジェクトクラスに対して特
   定された属性規準およびヒント規準の双方を満足させな
   ければ、前記第２のインタープリタは前記第２の包括的
   オブジェクトクラスに対して特定された属性規準を満足
   させるが、前記ヒント規準のすべては満足しない、別の
   第２の特定ユーザインターフェース実現化例を前記第２
   の選択肢から選択するように動作可能であり、 H.前記第１および第２の特定ユーザインターフェースツ
   ールボックスおよびコントローラのうちの１つを選択す
   るステップを含み、 i.前記第１の特定ユーザインターフェースツールボック
   スおよびコントローラを選択する場合には、前記第１お
   よび第２の包括的オブジェクトクラスのためのそれぞれ
   の第１の特定ユーザインターフェース実現化例を選択す
   るために前記第１のインタープリタを使用し、さらに ii.前記第２の特定ユーザインターフェースツールボッ
   クスおよびコントローラを選択する場合には、前記第１
   および第２の包括的オブジェクトクラスのためのそれぞ
   れの第２の特定ユーザインターフェース実現化例を選択
   するために前記第２のインタープリタを使用する、方
   法。
10. 【請求項１０】前記包括的オブジェクトクラスは、複数
    の選択肢から選択する包括的ユーザインターフェース機
    能を含むGenListClassの包括的オブジェクトクラスであ
    る、請求項１に記載の方法。
11. 【請求項１１】前記包括的オブジェクトクラスは、スク
    リーンイメージを使用してアクションを起動する包括的
    ユーザインターフェース機能を含むGenTriggerClassの
    包括的オブジェクトクラスである、請求項１に記載の方
    法。