XなんとかBackgroundほれほれ

[↑一覧] [新着] [ホームページ]

最近では、C マガジン '90 8 月号の「恥ずかしながらドジりました」の岩谷宏 氏の記事がよかった。内容があまり C 言語と関係ない所もよい。

岩谷氏は「ユーザインタフェイス」と表記しているが、今回は UI と書くこと にする。まず、UI の統一の必要性を説明する場合に、自動車に例えることがある という指摘がある。「自動車は、どのメーカーのものでも、ハンドル、アクセル、 ブレーキなどの位置と操作方法が統一されているので、ある自動車を運転するこ とができる人は、他の自動車を運転することもできる。」という点を、UI の一貫 性という意味で解釈すれば、UI のよい例と考えることができるわけだ。

これに対して、コンピュータの場合は？ DynaBook を他の人に使わせてみると 面白いのだが、まず電源を入れることができない人が多い。次に、その人が電源 を切れないことに驚くのである。たかが電源スイッチの位置という考え方もある が、このような所で混乱させる設計は、やはり面白くないのだ。面白いのか面白 くないのか、はっきりせず申し訳ない。:-)

なお、DynaBook の設計をせめているのではない。電源スイッチの色だけ赤か白 にした方がよかったかもしれないし、位置に検討の余地があったかもしれない。 電源スイッチを短時間にクリックしたために電源が切れなかった場合には、 （DynaBook の電源を切るためには、電源スイッチを 0.7 秒程度以上、押した状 態で保持しなければならない）画面中央に「電源を切りますか？」と表示し、確 認の上で電源を切る、という所まで配慮した方が、初心者への対処としては望ま しい。

UI の統一に関する精神的解釈が、岩谷氏と私とで根本的に異なっている。車の 操作性というのは、要するに、ブレーキが左でアクセルが右に付いていることを 言っているのである。もし、世の中の半数の自動車がブレーキが右、アクセルが 左に配置されていたら、運転手が混乱し、それこそ事故の原因になることは反論 の余地がないだろう。余談ながら、昔は自動車についても UI は統一されていな かったと思う（ブレーキが右の自動車があったらしい）。

また、ブレーキが左、アクセルが右である必然性はあるだろうか？ つまり、 すべての自動車のブレーキが右、アクセルが左に付いていて、何か決定的な問題 があるか？ 人間の利き足がどちらだから…という議論は勘弁願いたい。このよ うに、どちらを選択しても問題ないが、統一されていなければ混乱を招く例は多 い。

岩谷氏は「コンピュータシステムの UI は、そのシステムのタイプや目的に応 じて適切に違っていなければ困るのではないか」と指摘している。私としては違 っていなくても困らないが、適切でなければ困ると思う、が、これは些細な問題 にすぎない。それより、システムのタイプ・目的と同時に、利用者も想定してお く必要を強調したい。例えば銀行自動預金引き出し機が、目の不自由な人の利用 を想定せずにタッチパネル方式のものにリプレースされたため、今まで押しボタ ンの位置を手探りし、なんとか預金を引き出せた人が疎外されてしまった、とい う結果は望ましいだろうか？

ここで、岩谷氏の意見への１つめの異論を書きたい。氏は、将来マイカーにナ ビゲートシステムが搭載され、これがマウスで画面をポイントするような方法で あると、都内の交通渋滞と交通事故の規模が今の 10 倍に増えるだろうと指摘し ている。この根拠が私には全くわからない。

例えば、羽田からNIFのある麹町まで自動車で移動することを想定しよう。 羽田でマイカーに乗り込む。ナビゲートシステムの地図を表示し、麹町のＮＩＦ をポイントする。あとは車が現在の交通量、位置などを計算し、麹町まで連れて 行ってくれるはずだ。さて、交通渋滞と事故が 10 倍になる要素は、一体どこに あるのか？

まさかとは思うが、ハンドルやアクセルの操作をマウスで行うつもりなのだろ うか？ それとも、人類はいつまでたっても自動車を運転する時には、ハンドル を切りながら速度を制御して右折・左折しなければならない、という暗黙の了解 があるのだろうか？ 「左折」ボタンを押すだけで、次の交差点を自動的に左折 するような自動車は、未来においても実現不可能かもしれない。が、これでは面 白くも何ともないので、私は、「左折」という命令だけで左折できる自動車が当 然実現できる、という前提で話を進める。

蛇足だが、ハンドルやアクセルの操作がマウスで実現できるかどうかは、別問 題であるから、ここでは述べない。

つまり、左に曲がりたい時には、「左折」というコマンドが実行されるだけで、 車体のセンサーが周囲の風景を適切に 3 次元モデリングし、どのような加速度で どのように曲がれば物や人に接触せず、法規を守り、車内の人に不快な加速度を 与えず…という処理を行うことができるとしよう。

自動車の運転シミュレーターを、マウスだけで操作できるように設計してみる と面白いかもしれない。画面上には、リアルタイムで自動車の前後左右が表示さ れていると仮定してもよい。私なら、「左に曲がる」「右に曲がる」という画面 上のボタンをポイントし、さらにクリックするようなインターフェースは設計し ないだろう。例えば、画面を左・中央・右の 3 つのエリアに分割し、そこにマウ スを移動すると、左折・右折できる案はどうか。マウスに 2 つ以上ボタンがあれ ば、左のボタンで左折、右のボタンで右折というのはどうだろう。

しかし、GUI の統一を批判的に見るなら、マウスで目的のパーツをポイントし た上で、クリックする、というような統一された操作を暗黙の了解にしては筋が 通らないのである。GUI の統一とは、まさにこのような所が肝心だ。例えば、マ ウスに２つ以上のボタンがあった時に、ウインドウ上の何かをクリックするには どのボタンを使うか、というような仕様を統一しておこう、というのが GUI 統一 理論の本質だと思う。

もし 20 年後、2010 年の 7 月 22 日にまだ FPRG があって、私がアクセスで きる環境にあったら、どうなったか検証してみたい。ただ、うっかり忘れるかも しれないので、事前に気付いた方がいらっしゃったら、教えていただけるとあり がたい。

    *

ここで、２つ目の異論を書く。なお、氏の記事に関しての異論はこの２つであ り、他の大部分の意見には共感したのである。殆ど賛成、その通り、と思った中 から、わざわざ異論のある所だけ書いたのだ。

岩谷氏は、AppJugemJugemuGokoNoSurikirePaipoPaipo() が何をするのか空で言 えるようになったころは、プログラマーは老人と化しているだろうと指摘するの であるが、実際私にも上の関数が何をするのか皆目わからない。(^_^;)

プログラムを書いて飯を食っている人間として、ひとつ言わせていただくと、 実際にこんな関数の名前や、引数の順序を覚える気は、さらさらないのだ。本当 に覚えなければならないのは、もっと大域的な概念であり、現実に些細なことは 知らなくても、まともにプログラムは書けるのである。その秘密は何か？

上の関数が何をするのかわからん、と書いたが、今、X Window ハンドブックを 適当にエイっと開いて、ぱっと目に付いた関数を選んでみよう。

（げげ…）

   XSetWindowBackgroundPixmap(display, window, background_pixmap);

ところが、逆は難しい。ウインドウのバックグラウンドパターンをセットした いと思った時に、上の関数名を思いつくだろうか…やはり、そのために関数名を 暗記しなければならないか？

私は小中高校、そして学生時代を通じてカンニングをしたことがない。一度、 高校生の時にカンペ（カンニングペーパー）が回覧されてきたことがある（学校 名を詮索しないように）(^_^;)。これを見てしまった私は、解答用紙を白紙にし てから提出したのだ。

別にカンニングがいけないとか、モラル云々を考えたのではなく、単にそれま で一度もカンニングしたことがなかったので、記録を更新するという意味だけが あったのだ。一見カッコいい行為になってしまったが、そういう訳だから、別に 偉くも何ともない。

しかし、X Window のプログラムを書くのに、関数マニュアルを見てはいけない という話は、一度も聞いたことがないし、これからもないだろう。私は、こうい う時にはどんどんマニュアルを参照する。だから、関数名を厳密に暗記する必要 も、引数の順序も種類も完璧に記憶するつもりは全くない。「XなんとかBackground ほれほれ、という関数があったな〜」程度に記憶すればよい。オンラインのマニ ュアルを Background という文字列で検索すれば、正確な情報はすぐに確認でき る。

さて、Background をセットする時に、「XなんとかBackgroundほれほれ」とい う関数を使う、という程度の知識を身につけるのに、何年かかるか、そして老人 になってしまうかどうかは、その人次第だろう。え、まだ覚えられない？

    「XなんとかBackgroundほれほれ」

これからの社会は、情報過多が発展した「情報爆発の後」時代である。丸暗記 の技術は過去の遺物にし、小学校からカンニングの方法をちゃんと授業で教え、 迅速な検索能力を取得した人材を育ててほしいものである。

結論をまとめると、岩谷氏の「ものすごく長い名前の関数を大量に覚えなけれ ばならない」という意見に対して、私は「適当なイマジネーションのあるプログ ラマーなら、ものすごく長い名前の関数をちゃんと覚える必要は全くない」と主 張する。

    *

私には被写体がないので、あまりビデオカメラで録画したいとは思わないが、 子供が生まれると、せっせとビデオで録画している人が結構いるのは気になる。 ビデオテープは単なるアナログ情報を磁性体上に記録するわけで、長期間の保存 に向いていない。数年前に録画した番組を見てみるとよくわかる。画質鮮明とい っても、20 年もたてば、どうなることやら。写真をプリントすれば、今ではカラー でも百年持つそうだから、安心だが。

「百年ビデオ」は磁性体の性質上困難かもしれないが、デジタルビデオが実現 したらダビングで情報が劣化しないので、原理的には解決する。もちろん、社会 的に実現するわけがない。DAT の成り行きがよい教訓である。

ブレンビーで思いだしたが、手ブレが補正できるのなら、コントラストを補正 したり、肌色をきれいにみせたり、肌あれを補正したり、顔の輪郭をきりりとひ きしめる、という美人ビデオというのも、できそうな、気がする。あ、それなら ダビングすればするほど画質がよくなるから…。(^_^;)

据置型のビデオデッキでは、ビクターの VHS と C-VHS を一台で利用できる、 というのがアピールポイントが高い。これを見て、一つ SONY さんにお願いした いことがある。昔、βはなくなりません、という広告があった筈だが、その割に 最近βのデッキの新製品が少ないのでは…ということではない。:-)

私はビデオデッキはβのものを１台しか持っていないので、将来はもう一台買 うかもしれない（予算ができたら）。それまでに、ぜひ作って欲しいのが、VHS と 8mm を一台で利用できるビデオデッキである。各社の企業戦略があろうから、 現在このようなビデオデッキが作れる可能性が最も高いのは SONY だけと思った わけだ。機構的に実現不可能に近いのかもしれないが。

でも、よく考えると、予算ができそうにないから、やっぱりどうでもいい。

    *

日本ソフトバンク

Ｃ言語フォーラム、恥ずかしながらドジりました、岩谷宏

(BGM: GOING FOR THE ONE by YES)

    COMPUTING AT CHAOS RUINS -127-
    1990-07-22, NIFTY-Serve FPROG mes(3)-052
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1990