GUIのなんでもかんでも例示でプログラムしてしまおうという 若干無謀な試みである。 「図形エディタでラバーバンドをどのように描くか」といった ことまで例示で指定する。 描画モードのようなものまで例示でプログラムできる。 Interface Builderでは設計モードと デモモードのふたつのモードをいったりきたりして静的な画面を 作っていくが、これに「Train」「Show」のふたつのモードを 追加する。Trainモードではユーザは実際のアプリ操作と全く 同じマウス/キー操作を行ない、その途中でShowモードにして 操作に対応するアプリのアクションを指定することができる。 システムは例示されたアクションから本当のアクションを 推定する。例えばTrainモードにおいてマウス押下とマウス 移動を指定し、Showモードでその間に点線を引くと、 システムは「マウスドラッギングにより点線が移動する」 ことを推論する。推論の間違いを訂正するため(プレファレンス) パネルを使用する。 描画エディタにおいてオブジェクトの生成や属性変更によく使用される パレットも簡単な操作で作ることができる。

マウスを押し下げたままでShowモードに移動するには特殊キーを 使用する。ではその特殊キーを含むインタフェースはどうやって 作るのだろうか?? 結局インタフェースを類型化してユーザが 選択できるオプションを増やしただけということのような 気がするが...

Unistrokeというひと筆書きアルファベット。 A: ↑ B: ＞ C: ＜ という風に、対応があまりない。 ペンを見ないで書けるのが特徴。 評価は3ページぐらい書いてあるが、認識アルゴリズムに 関しては何も書いていない。 練習すると、字と字の間のスピードが速くなるらしい。 練習により3.2文字/秒程度までは速くなる。 提案のようにストロークを割り当てた根拠は無い。 意外と、右向けストロークよりも左向きの方が速いことも 多いらしい。 Unistrokeによるメールアプリを実際にかなりの間ユーザに 使わせて評価を行なった。

確かにちゃんと評価は行なっているが、そもそもの アイデアがどうってことないし根拠もないので、有用性が よくわからない。

グリッド上でのレイアウト操作例をシステムが汎化するが、 ユーザに汎化プロセスを提示してユーザに選択させるという 「共同作業」により汎化を助ける。 たくさんの例を与えればより正確な汎化が可能であるが、 少ない例から各種の配置アルゴリズムを計算してそれを 別の例に適用した結果をユーザに提示してその中から選択 させることにより正しいものを選ぶ方が楽との考えである。 制約の手法はオブジェクトの数が変わると困るが、配置 アルゴリズムを使うときはオブジェクトの数が増えても 大丈夫である。 人と共同してアルゴリズムを決めるという意味では Kochhar_CCADのフロアプラン配置手法と似ている。 アルゴリズムは「内挿」及び「繰返し」により推論する。

(1)
(2) (3)

という操作から

(1)
(2)
(3) (4) (5)

というのを推論するのが内挿で、

(1)
(2) (3)
(4) (5)

と推論するのが繰返しである。 これらをいろいろ組み合わせてアルゴリズムを作り、 適用結果をユーザに提示する。

アイデアには面白いところも多いが、実際にはあまり有用では なさそうである。 Dawkinsのように人為的に虫を作るのに似ているか？ (1993/12/16 増井)

ペンコンピュータで図形エディタを作るとき、認識モジュール と構文解析モジュールがインクリメンタルに情報をやりとり しながら動くようにするとうまくいくよ、という話

Degen_MarkerTapeをテレコを使わず全て音声だけで 操作できるようにしたシステム。命令もAckも音声で行なわれる。 これでなんとか階層的に(カテゴリ分けなどして)音声データを 機械に格納しようとしているが、現在どのモードにいるのか わからなくなってユーザが混乱することもあるという。

Schmandt氏はPhoneSlave(Schmandt_Illusion参照) などといった(割としょうもない)音声IFをずっと研究している ようである。