よく「〜には二通りの人間がいる」と一刀両断に物事を分けて我田引水するやり口がある。
それに倣えば、アプリケーションを作る奴には二通りの人間がいる。まず作るやつと、まず悩むやつだ。
で、私の場合は、悩んじゃうんだ。というか、構想に走るタイプ（それで構想で終がちなんだけど…）。でも言い訳をさせてもらえば、妄想に走るという傾向もあるんだけど、アプリケーションを作る場合には、「それを作ることがコストに見合うの？」という問いかけが入るからなんだ。
そりゃ、北の祭、東の火事、西の喧嘩、南のなんだっけ？と東西南北を駆け回り、四季折々の花鳥風月を愛で、物見遊山に日々是詣でる、というわけじゃないが、仕事もあれば、遊びもあるし、寝るのだって楽しみたいさ、と誘惑に弱いものですから、できたら作らなくてもすんじゃうなら（あるいは、それなりに凌げるならば）そっちでいいよ、という。
要は、なんだ、端的にいえば怠け者なわけだな。
といったところだから、 Mutter Launcher を作るのにだって、「それこそごまんとある中で、いまさら新しいランチャーを作るの？」、という一人での梯子外しがあった。あったけど、でも、「思いついた名前で探したい」という最初の欲求を満たすものがなかったし、これはランチャーの中で位置付ければきちんとした発展の流れの一つとして意味あるじゃん、という構想に至って勢いついちゃって作ったんだ。
その作るに至った構想＝妄想をちょっと書き記して、「こんな妄想まで抱きながら作る人もいるんだな」と楽しんでいただければ、これ幸い。
いや、でも真面目な話、例えフリーソフトなんかの場合でも、ものを作る時にはその位置付けというのを作者は評価すると思う。そんな一サンプルとして楽しんでいただければ、というのも一つの願い。
とはいえ、出来上がったアプリケーションはといえば、自分の欲しいものと時間の兼ね合いで、いたってシンプルな機能なんだけど…
え？こんなこと考えている暇あるなら、作れって？
だからさ、こういうこと考えることが、また一つの誘惑という訳なんだ。
そもそも、そのランチャーっていうのは何だろう？
ちょっと言い替えると、ランチャーーというアプリケーションはどういった問題を克服するのに具合が良くて活躍しているものだろう。
それは、多数のアプリケーションの中から目的のアプリケーションを選び起動するまでのギャップを減らすために発生してきたアプリケーションのためのアプリケーションと位置付けることが出来ると思う。人間が直接お願いするには複雑なＯＳの世界を少しでも緩和しようという適応の結果として産まれた「シェル」のサブセットが「ランチャー」とも言えるだろう。
ログインすると当然のように規定のシェルが立ち上がるということ自体が凄く便利なことだよなぁ、と UNIX を使い始めた当初は感動したものだけど、それもつかの間、いろいろと不満も出てくる・・・・
UNIX ユーザーなら bsh → csh → tcsh/bash...etc 等へと移るにしたがって、DOS/Windows ユーザなら DOS → Windows 3.1/NT3.51 → Windows95/NT4.0 という道筋で、アプリケーション起動の依頼の仕方が多機能になってきたということが実感できると思う。
そんな進化を遂げたランチャーが、ユーザと OS の間のギャップをどのように減らそうとしたかを比較してみよう。
こういう場合、よく CUI と GUI という比較がされて、簡単には CUI → GUI というように発展を遂げたという位置付けがされる（あるいはそれを前提に CUI を擁護する）。あるいは、文字かアイコンかという比較も。
でも、ある時点での技術的な制限や OS の特性は捨象して、その適応戦略を位置付け直してみて、
という区別に重点をおいた方が、その形態比較が奇麗にできるんじゃないかと思った。
まず、「文字/綴り」による入力インタフェースは、コマンドラインという形に代表的だけど、入力位置を示すコマンドプロンプトだけがあって、あとはユーザが綴り（spell）を入力するのをコンピュータは待ち続ける（ここでは、識別最小単位としての文字とそれを入力するためのキーボードと言うのを前提）。
「綴り」も潜在的には数多くのコマンドの中から指定のものを選びだす行為だけど、原始的にはそのコマンドに対応する綴りをユーザが一字一句間違わずに入力することが必要となって来て、選ぶというのとは程遠い。つまりそれは spell のもう一つの意味、「呪文」という意味と相通じるもので、正確に唱えることでとある出来事を起こすことができる不思議な言葉なんだ（呪文を誤ると概ね変なことが起こるとこまでそっくり）。
この利点は、言葉というユーザ側が持つ習慣に依存することで（記憶の再生に頼ることで）、コンピュータの側からは入力を待てば良くて、また入力するために用意する空間も１行（コマンドライン line に引っかけて。あるいは、ある種の１レイヤー）だけで済むこと。また、その綴りの組合せによって多数のコマンドをそれぞれ対応することができるということ。
「文字/綴り」とは言ったけど、それは実体的な文字である必要はなくて、「ショートカットキー」「アクセラレータキー」やそれこそ呪文的な Emacs のコマンド、あるいはマウスの動作軌跡や Palm の Graffiti まで、ともかくある特定のストローク（一連の定型動作）をユーザの側が想起する、ということに強く依存するという点が一番の特徴だろう。
しかし、当然のようにその適応戦略は、コマンド起動とユーザのギャップを克服するのに対して、つねに綴りのインフレを問題としてかかえてしまう。
この２つの要求軸を満たそうとしても、増していくシステムの複雑さによって、区別するために単体のコマンド名の長さが長くなったり、そもそもコマンド数が増えるというインフレ圧力があって、当初の簡潔なコマンドライン入力も複雑さを押えることができなくなってくる。結果、ユーザが思い出せない（想起できない）という事態に陥ってしまう。
対して、「アイテム/オブジェクト」による選択インタフェースは、コンピュータの側からユーザに対して選択可能項目を積極的に提示することで、ユーザが行なう動作が「選択」という動作であるというというころに、「綴り」との大きな違いがある（それが絵であるか、文字であるかはここでは問わない）。
またこれは、ユーザ側に次の点で負担を軽減する、という目論みでもある。それは、「入力したいものを正確に想起/入力する必要がない」「画面上に表示された内容から正しく目的のものを選び出すことができるだけで良い」（再認識できれば良い）、という点。
いわば、画面という空間に行動/記憶が実体化されているわけだ。
しかし、こちらもまたあるインフレ圧力を抱えていて、それはユーザに提示しなければいけない選択項目数の増加である。
という要求軸を満たそうとしても、そのままではシステムの複雑さが増すに従って高まる項目数のインフレ圧力を処理できない。また、副次的に、その増加は、実際にユーザにとっての作業空間（デスクトップ）上を占めてしまう、という別の問題も起こってしまう。
こうして、２つの軸として始めたのは、どれぐらい/どのようにユーザ側の能力/記憶に依存するのか、コンピュータの側でサポートするのか、という対比軸でも読みとれることになる。
さて、前の２つを基本原則として、２つにそれぞれにあるインフレの圧力に対応する策としては、
といった要素の様々な組合せがありえる。
その中でも特に Mutter Launcher を位置付ける上で考えたのが、
だった。
これらは、それぞれにお互いへのあゆみよりともいえる。
検索結果の表示は（ユニークに決まれば補完）はコンピュータの側からの選択アイテムの提示であるし、逆に複数のアイテムを取りまとめるアイテムの導入は、特にそれが階層を持った場合には、ユニークな場所までそれを展開していくストロークは綴りを打ち込む動作と類比できる。
さて、ここまで来て、大まかに現状のランチャーの２区分である
の２区分を位置付けられると思う。
それぞれ、今までの整理の流れを当てはめると、コマンド型は「文字/綴り」型、ボタン/メニュー型は「アイテム/オブジェクト」型を継承/実現化したものというように位置付けられる。
いわゆる GUI アプリケーションの中で、これらの２分類も明確に別れているわけではなくて、特にボタン/メニュー型ではキーボード操作への適応の意味合いも含めて、「文字/綴り」の操作を導入するなど、ある意味明確な２分類というより、お互いに交じわっている部分もある。
さて、先にまとめられた２つのタイプでも、やっぱり次のような問題があるんではないかと思った。
「ボタン/メニュー」型では、常にある階層などに整理する必要があり、また使用時にはその静的な階層を追って検索していく必要があること。そのために、やっぱり対象が多くなるとどうしても繁雑になり勝ちだということ。
もちろん、対象アイテム数が少ない場合には、とあるアクション（ホットキーやマウスが近付く）で必要な時だけ現れるランチャーなどは特にその威力を発揮する。
また例え数が増えたとしても、目に見えて選択できるという意義は大きい。だからこそ標準のスタートメニューはアプリケーションのインストールで自動的に保守されることとも相挨って、例えその繁雑さがあっても標準的な道案内として効果がある（そして、それを模倣/継承して使いやすく置き換えるアプリケーションという存在もある）。インターネットでも Yahoo! のような検索サイトが「ディレクトリ型」と呼ばれる所以でもあると思う。
一方でいえば、コマンド型の方はといえば、それ自体としては完成度が高いんだけど、いかんせん UNIX 出自というのが祟って、Windows の exe 管理（PATH 変数に設定されない場所にある）や、普段目にするスタートメニューと exe 名との違い、そもそも exe 名が連想しにくい（exe 名はほとんどが8文字に圧縮されている）ことから、ちょっとギャップがあるものが多かったりする。
そして、件の検索ということでいえば、あくまでまだコマンドラインの由来でもある「ライン＝１行」という制約の中にあって、特に検索結果の表示においてユーザの入力と出力結果がわかれていることが不満で、GUI に慣れて来て軟弱化（これを軟弱化と言ってまうのもある種の偏向だけど）した身としては、あと数個ならば文字を打ち込むまでもなく「選択」したいという思いが出てくる。
こういった判断には、キーボードやマウスの操作への好き嫌い、他の環境との兼ね合いなども個人的な要素も影響してくる。
けれども、私自身の思いとしては、
という方向への展開がアプリケーションの系譜としてあってもいいんじゃないか、と。
これは全文検索型のランチャーともいえて、それは各種の辞書アプリケーションやさらには Infoseek や Namazu 等の全文検索型のようなインターフェースをランチャーの世界に持ってくるということだった（中身を全文検索する Infoseek や Namazu と違って、あくまでファイル名の集合をテキストと見做しての検索だけど）。
つまり、対象ユーザの状況としては、まず起動したいものの一部分の言葉でも思いつくことを前提としている（ここに関してはユーザ側に依存する）。それに従って、アプリケーションの側は動的にリストを絞りこんで、ユーザ側が簡易に判断できるレベルまで複雑さを緩和する。そんな関係を導入したかった。
具体的には、ユーザの主たる入力としては「綴り」にした。そして、１字１字打っていくという動作が潜在的に持っていた、集合の中から「選択」するという行ないを、リストの形で動的に視覚/実体化することで、ユーザの想起をサポートするということだった。そういう意味で、綴り型を継承する位置付けとしていた。
また、入力とリストを分け、リストを選択操作可能としたおかげで、部分文字列での検索との親和性が良くなった。今までのコマンドラインでは、最終的に文字で打ち込んで行って決定する必要があったために「前方一致」という制限があったのが、そこに縛られる必要がなくなったからだ（まぁ、UNIX でいえば、locate というより強力なやつがいるけど。さらには、find や grep やらを組み合わせれば、そもそも強力な検索機能となっている）。
※実際の動作イメージは リンク先の図を参照
だから、ボタン/メニュー型を支援するために「文字/綴り」型のやり方を導入するパターンではなくて、コマンド型を支援するために「アイテム/オブジェクト」型のやり方を導入するという方向性を取った、というようにもまとめられると思う。
こんな風に考えて、これは面白い試み、と自分でも位置付けられたものだから、怠け者もその活動の夜を迎えて動き始めたんだ（と、一人納得）。 でも、そういったのがすぐ見つかっていたら、やっぱり作らなかったろうけど（でも、後で見つけた…。 検索ランチャー栞との比較 を参照）。
さて、Mutter Launcher について、現状との対比については、大体前章のような感じとして落ち着いた。しかし現状だけではなくて、今後考えられる展開との対比もその価値づけのためには大切で、それによってもっと関係が明確になることも多い。もちろん、Mutter Launcher に追加するネタにもなる（作者の時間があればね）。
実は、そうしてランチャーの役割を位置付けてみると、emacs での shell-mode 上で、全てがバッファ内のテキストとして扱われる平面性というのは、shell 自体が持っている補完機能等と相挨って、未だに柔軟性や能力において「文字/綴り」型としてはやっぱり凄いものではないかと見えてくる（emacs の学習コストや動作コストはおいておいても。Windows では、 ComWin なんかがそういった感じに当たるかな）。
それでも検索型では、対象の側が持っている文字列（それが登録されたものであれ）ということに限られる場合が多い。その点を考えると、よりユーザの想起をサポートする意味で、ある種の自然言語対応だって良いだろう。
「ワープロ」と指定すれば「MS-Word」や「一太郎」「Ami-Pro」「Word Perfect」がリスト化される（その辞書は最適解がなかなか難しそうだけど）
「絵が書きたい」という指示に対してそれに対応するアプリションがリスト化される
あぁ、でもそういうことだと、Microsoft BOB → MS-Office のアシスタントという「ソシアル・インタフェース」流の流れが出てきてなんとも萎えてくるものもあるけれども。
さらには、ランチャーが起動するものの範囲や連係を広げたっていい。
既に、Windows なら拡張子への関連づけ、Mac OS だったら各ファイルのタイプとクリエータ情報で、これは実現している。
これも既に実現済。形態論のところで出てきたのをそのまま当てはめれば、Web ブラウザでの URL 指示部分などは見事に UNIX シェルの適応戦略を模倣してきたといえる。
例えば Mutter Launcher でいえば（手前ミソ…）、検索する範囲はローカルにあるものではなくて、インターネットのもの（検索や辞書サイトへのプロキシー）でも良いんだし、あるいは名前や概念に拘らずファイルの中身への grep だっていいわけだ。この例が手前味噌過ぎるので、別な例を挙げれば、Internet Explorer や Netscape Navigator は、いつのころからか URL に指定した文字列がアドレスとして認識できない場合には、それを検索サイトに渡すようになってきているという広がりの例ならば、より多数の人が経験していることと思う。
今より常時接続が当然な環境になった場合には、ランチャーとして起動/召喚する先は単に Web サイトということだけではなく、いわゆる ASP 形態のアプリケーションだっていいわけで、もしかしたら来年ぐらいには Office は時間売りで ASP の形へのショートカットがインストールされることになるかもしれない。あるいは、それはいわゆるアプリケーションや Web サイトではなくて、テレビ番組なのかもしれないし。とかね（まぁ、Microsoft が特に Windows のデスクトップを、COM と絡ませて HTML & Web への透過性を目指して以降邁進している道だけど）。
後で知ったけど、Mac OS に附属のアプリケーションの 「Sherlock 2」が、こういったデスクトップ上へ呼び出し可能なリソースへの一元化した入口を用意していて、使い勝手もなかなか良い。
そう考えると、実は「ランチャー」という言葉自体がとても坐りの悪い言葉だということに気がついてくる。言ってしまえば「ランチャー」というのはどちらかといえば開発者側の言葉なんだと思う。
一面だけ見れば確かに「発射＝起動」することなんだけど、ユーザの一連の中で起き直して見れば、その役割は画面/デスクトップ/プロセス空間にある物（オブジェクト）を召喚することなんだと置き換えることができる。「What do you want to launch?」ではなくて、「Where do you want to go?」でもなくて「What do you want to bring?」なんだと思う（この方が、あくまで世界の部分集合を持ってくる覗き窓という語感がでると思う）。
なんだ、そう考えると、結局のところデスクトップのポータル争いという気もして来た…
前では「自然言語認識」的な話になったけど、そんな複雑な話でなくても、ボタン/メニュー型の階層管理（特にスタートメニューにいえることなんだけど）で、もっと単純で、より効果的（かも知れない）対応策はあると思う。
別に、凄い発想ではなくて、たんに今の主にベンダーによるジャンルに加えて、種類によるジャンル分けをユーザに表示することだけで、初心者には少しは違ってくるんじゃないだろうか。つまり、「Word」じゃなくて「ワープロ」や「書類作成」といった言葉を想起する人への支援ということと、管理と通常使用が一緒くたの内容（例えば、いつでも「アンインストール」という項目が見えるというノイズ）を分けるということだ。
そういうのは、例えば「〜ホーム」とか、メーカーのプレインストールマシンに付いてくる独自デスクトップといった形で試みが続いているけど、今一つ成功しているとは思えない。これらは、何といっても新しいソフトのインストールに自動的に追従していけない、閉じた世界のものなのが痛い。
そうなってくると、標準である「スタートメニュー」が、種類別表示といった感じでそういったものをサポートする意義は大きいと思うのだが・・・（当然、各ベンダーへのインストール指針やその対応も必要だけど）。まぁ、自分で辞書を持って現在のディスク内容などから自動的に分類分けや一覧作成といったことをすれば、先の初心者向けデスクトップや各種ランチャーでも結構なことはできると思う。
と、そんなことをいろいろと考えたりして、こういった機能のいくつかは Mutter Launcher への実装も考えたけど、個人的なコスト（ここでは作るコストも入る）が見合わなかったことで当面は没になった。
そして、これが作る側の動機付けとしては一番重要なんだけど、こういった「ランチャー」の範囲を考えてみてもニッチな欲求を満たすものとして現状ではその存在意義があるし（個人的にはもちろんだけど、現状としての他との差別化）、カバーするものが当面は出てこない（出てくる価値がない？）ようだし、という結論にも至ったことも、Mutter Launcher 作成の気持ちをドライブさせる原動力となった。
こうして Mutter Launcher を位置付けるためにランチャーの流れを追って見ると、複雑な事象を少しでも簡略化してユーザに提示しようとしている流れの一つとして、ランチャーなんかもいろいろと創意工夫をしているよな、と思えてくるし、こんな風にそこからポータル争いまでが実は繋がっていないこともないな、とかも考えられないこともない（ある意味、いつでも妥協点で成り立っているとも）。
そして、ランチャーという小さなものとはいえ、立派なアプリケーションとして、その進化要因はコンピュータに人間をサポートさせることの効果をあげるためのものなんだなぁ、というのが、当然といえば当然の、この文章の全体のまとめですね。
ユーザインターフェース全般については、アラン・クーパーの「About Face: The Essentials of User Interface Design」（邦訳は「ユーザーインターフェイスデザイン―Ｗｉｎｄｏｗｓ９５時代のソフトウェアデザインを考える」ISBN:488135368）を参考にしている。邦訳は読んでいないので分からないけど、原書を読む限り、邦題の「Ｗｉｎｄｏｗｓ９５時代の〜」という文句のために、今となっては損をしている本だと思う（「Ｗｉｎｄｏｗｓユーザーインターフェイス事典」ISBN:4881356534 といった、How-To とはちょっと違う内容。クーパーの「コンピュータは、むずかしすぎて使えない！」ISBN:488135826X より前の作品で、内容的には重なるところも多い）。
この本は、市販製品の GUI 設計において、GUI 全体の傾向や各部品が持っているデザインの背景や意図を広く解説することで適材適所を指南し、さらにはあるべき設計を提示しようという本。先進性を求める場合には向かないけど、GUI について様々な特徴や本質を言葉できちんと展開できているので、どういう場面で役立つかのヒントになる内容になっている。
買ったまま全然読んでなかったんだが、今回この文章を書いている途中で読んでみたら、彼がオブジェクト中心になったユーザインタフェースを「selection」で象徴させていたのを読んで、「「文字/綴り」による入力インタフェース」「「アイテム/オブジェクト」による選択インタフェース」という対比もそうずれたものではないことが確認できたし、彼の本で整理できた部分も多かった。
彼の「selection」は、厳密には、命令が先にありきの「verb-object」型に対して、オブジェクトが先ありきの「object-verb」型の特徴という対比の中でのことなので、私のものとは少しずれる部分もあるけれども、いずれにせよ GUI を特徴づけようという点では参考になることが多かった。
より広くは、これは旧聞に伏す名前かもしれないけれど、やっぱり「誰のためのデザイン？―認知科学者のデザイン原論」ISBN:478850362X を挙げてお茶を濁したところでお終いにしたい（あまり、その任に私は向かないから）。
さて、この文章でまとめたようなことは、もちろん作る前もある程度は考えていた。けれどもネタばらしをすれば、きちんとこんなことを考えたのは作った後になって、 POBox という文章入力支援のアプリケーションに、Palm（私は Visor だけど）上で出会ったからだった。
POBox は、Palm 互換 OS 上での動作が有名な（UNIX 版もある）、特にペン入力での支援を目的としたアプリケーションなのだけれど、この支援の仕方というのが、検索と予測が上手い具合に融合されていて、PDA での文章入力という繁雑な作業を軽減してくれる。
例えば、「い」という文字列を入れると、「い」で始まる単語のうち出現頻度の高いものが例えば「い」「以下」「良い」「インターフェース」といった形で表示される。これは、ある程度日本語の文脈（前に入れた文字）と履歴の考慮はあるんだけど、ある意味凄く馬鹿正直な選択候補を出してくる。つまり、高機能自然言語解釈 AI による最適化とかとはちょっと違う作りになっている（辞書をチューニングして、あるユーザモデルに特化すればもっと違う風に見えるだろうけれど）。
もしかしたら、POBox の単純さにがっくりする人もいるかもしれないけど、私はこのある意味馬鹿正直で選択権はユーザ側に任せたサポートの仕方が、とても気に入っていて、「記憶」「検索」には優れて「判断」があまり得意ではない（というか、あまり簡易で適切なアルゴリズム/実装が進んでいない）コンピュータの世界では、「判断」を実体化（プログラム化）する時間をかけるより、最後の部分は人間にまかせればいいんじゃん、という選択肢は常にあると思うし、そう間違った判断ではないと思う。
もちろん、研究の場合は別だし、そこまでいわずとも、全面的にこの単純戦略が有効かといえばそういうことでもない。目的（フレーム）が明確に絞れれば、定型とその穴埋め的なもので文章を作るテグレットの 「直子の代筆」 的なものがある。あるいはこれはあるのかどうか知らないけど、POBox 的に文章を逐次的に生成していく上での支援をもう少し範囲を広げて、より複数の品詞単位を扱うというのは、有効な方法だと思う。特に、携帯電話／PDA などのように制限された環境や、障害者や老人への支援という意味などで。
まぁ、状況での制限が強いプログラム言語の世界では、フレームワークだとかスケルトンがあったり、VB や Developer Studio なんかのエディタで文脈に応じた入力候補がリスト化される、といったものが既に実現しているけど。
また、その POBox の作りとして、検索や、リストの動的な絞り込みや、それらの総合としてアプリケーションが人間を支援する部分の単純さが、Mutter Launcher を作るにあたって考えたことと、とても繋がりがあると思った（あくまで、アイディアとしての繋がり。Mutter Launcher が実装として繋がっているということじゃないですよ、さすがに）。
実際に増井さんの Web サイトで「予測/例示インタフェース」に関する文献を読んでみると、増井さんが単純な仕組みでユーザの支援効果を出すという点に重きを置いてその分野にアプローチをしていて、実際に実装もいくつか行なっている（POBox もその一つ）のを読んで、やはり POBox から感じたことは間違いじゃなかったことが確認できた。さらに、「ユーザへの適応」（簡単にいえば、ユーザをより個別化してアプリケーションの側で最適化していくような仕組み）という流れの試行錯誤を、より深い背景を含めて知ることが出来た。
その「確認できた」という論文については、 彼のサイトで公開されている論文「適応/予測型テキスト編集システム」や「予測/例示インタフェースシステムの研究」を参照。
また、こういったインタフェースに関する詳しい考察を知りたい人は、 増井さんの Web サイトで、「予測/例示インタフェース」に関する文章を参照のこと。
Mutter Launcher も、思った以上に自分を支援してくれてとても重宝している。支援の仕方としては単純だし、とても小さい範囲でのことなんだけど、それだけでも日々の動作は変わるもんだ、というのを改めて実感した。その小さな実感を言語化する上でも、増井さんの単純さに重きを置いたアプローチの論文がとても参考になった。
で、彼には 「富豪的プログラミング」という、こう、心意気を感じさせる、読むと元気が出る文章（？）があって、この文章からも増井さんのある種の単純さへの傾向を読みとれると共に、そうか POBox は確かに単純さとともに、富豪的な仕上がりでもあるんだな、ということも分かる。
さらにいえば、確かにコンピュータが人を支援するという面でも、ある意味、こういうドーンと構えた富豪的な姿勢で行きたいものだと、思ったりする。これはある種の誤読かもしれないれども、あんまりこまごまとコンピュータに支援させる姿勢というのは、アプリケーションをあまりに繊細にしてしまうきらいがあるし、ある種の貧乏症でもあると思う。
「富豪的」については、ともかく、彼の文章を参照して下さい。
でも、そういうことを言いつつも、最後の「選択」で間違って、患者に間違った薬を投与してしまうとか、着陸先として別な空港を指定しちゃうとか、そういう可能性はあって、Undo の効かない実世界が絡むとなかなか難しいものがある、というインターフェースやユーザへの支援についての試行錯誤は続くんだけど（「単純さ」といったって、どんな単純さかによって良くも悪くもなるんだし）。
また、こうしていろいろと考えてみると、複雑さとその回避方法のいたちごっこという気もしてきて、そもそも母集団（検索対象）の整理をした方がいろんな意味で効果的なんじゃないかという段階も出てくる。ということを考えると、PC なんかやめて PDA に移った方が・・・、いや、そもそもそういった電子ガジェットの前を離れた方がいいんじゃないか・・・
そして、本当の富豪は、コンピューターなんてものの複雑さに悩まないんじゃないか、とか思い至る今日この頃…
そして、その点だけでは、怠け者と富豪は似ないこともないとかなんとか…
というところで、終りにしたい。