「アラン・ケイがNHKに出演」記事へのコメント

たまたま途中から観てました。

[yuzo (2738)]

たしか、コンピュータはメタメディア、とかなんとか言ってたような。

--
---------- yuzo ----------

Re:たまたま途中から観てました。

[kubota (64)]

ぼくも最後のほうだけしか見てないのですが、 コンピュータはメディアでしかないと思ってるのか、 というふうに思いました。 GUI を考案した人らしい考え方だと思います。 最後のほうだけしか見てないので、予断は禁物ですが。

Re:たまたま途中から観てました。

[G7 (3009)]

>コンピュータはメディアでしかないと思ってるのか、というふうに思いました。

#これの主語は「ケイ氏は」ですよね?

ん?「メタメディア(yuzoさん発言より)」と「メディア」とは、別モノなのでは?

俺ぁ番組まだ見てないですが、他の人によると「キャンバス」なのだそうで、
単なるメディアというのとはちょっと違う話だったのではないか、と推察します。

#ところで、再放送されたら、このスレは復活するんだろうか?(笑)
#それともまたしてもわざわざ誰かが別スレ立てるんだろか?
#少なくとも情報の共有化という意味では、酷いメディアだよな現状のスラドは。

>GUI を考案した人らしい

Re:たまたま途中から観てました。

[kubota (64)]

だから「メタメディア」が「メディア」とどういうふうに違うのか、というのを番組をぜんぶ見てないからわかりません、というわけです。ただ、従来のメディアと比べていかに優れていようとも、それが「メディア」と呼ばれる範疇にとどまるのなら、コンピュータの可能性を十分に捉えているとは言えないと思うのです。

「メディア」の本質は「表現」だと思うのですが、つまり、何かを表現したものはそれを「メディア」と呼んでも構わない。ただ、それなら人間の使う道具はどんなものでもその使い道を表現したメディアだ、と言えないこともないのですが (そし

Re:たまたま途中から観てました。

[G7 (3009)]

>「メタメディア」が「メディア」とどういうふうに違うのか
>それが「メディア」と呼ばれる範疇にとどまるのなら

他の人に先越されちゃいましたが、メタという接頭語をケイ氏が「間違わずに」使っているとすれば、
メタメディアという意見が「メディアの外挿(ってのか)」を意図していたとは、思い難いです。

逆にいえばこれは氏がメタを「間違って」使っていたかどうか？に依存する問題なわけで、
間違ったかどうかはそれこそ番組自体を見ないと判らないという意味では、
あなたの懸念も一応間違いではない(可能性がゼロではないから)ものの、
やっぱり飛躍しすぎだとは思います。

Re:たまたま途中から観てました。

[kubota (64)]

「メタ」については、そうですね。ケイさんの思想をしらずに憶測でしゃべるのは、やめます。ただ、「・・・を超えるもの」という意味で「メタ」だとしたら、「メタなんとか」という言葉で「すべて」を指し示すことができてしまいます。それだと、「コンピュータはメタxxxだ」の「xxx」に何を持ってきても (たとえば「食器」とか)、正しくなってしまうので、言う価値がない言葉となってしまいます。(自明なことは言う価値がない)。ですので、「メタメディア」という言葉は、「メディアを超えたなんでもすべて」ではなく、「現在実現しているメディアを超えるモノだが

Re:たまたま途中から観てました。

[G7 (3009)]

>「・・・を超えるもの」
>という意味で「メタ」だとしたら、「メタなんとか」という言葉で「すべて」を指し示すことができてしまいます。

あのー。それは「スーパー」であって「メタ」では無いはずなのですけども。

相変わらず俺も正しく説明できないレベルで恐縮なんですが、とりあえず俺が知っている、
その二つの語の使い分けの例としては、SuperClassとMetaClassってのが有ります。

貴方が今心配(?)しているソレは、SuperClassとは何ぞや?を説明する話としては有効ですが、
(Superとは別物であるところの)MetaClassの説明としては、たしか、ちと外れているはずです。

Re:たまたま途中から観てました。

[G7 (3009)]

>>「対象」「行為」のうち「行為」しか指定できないこと
> え？貴方はアイコンをクリックしたことが無いんですか？

ごめん。論旨を誤読してました。この部分は撤回。

で、撤回訂正した後ででも、貴方が何を悩んでいるのか、よくわからないんです。

>操作する対象 and/or 操作する行為を画面に表示させるという手順を必要とするという点で
>す。ショートカットキー? あれは GUI ではありませんし、「対象」「行為」のうち「行為」しか指定できない

これって、GUIに固有な問題ですか？
CUIだって同じじゃないですか？
プログラム名とファイル名をキー入力(またはScriptに書いて

Re:たまたま途中から観てました。

[kubota (64)]

GUI は、画面にメニューなりアイコンなりを出して、それを人間が目で認識して、それに人間が反応する、という手順が必要ですね。目からの入力→手の反応に要する時間はおよそ 1 秒で、これはどんなに訓練しても速くなりません。マウスカーソルの操作にも、この反応サイクルが組み込まれています。「たしかこのへんに」という「予測」によって、その 1 秒を部分的に回避することはできますが、最初にまずマウスポインタがどこにあるかを認識しないといけませんし、最後にマウスポインタをそこに「ぴったりと」あわせるためにも目→手の反応時間をどうしても必要とします。GUI の本質

Re:たまたま途中から観てました。

[G7 (3009)]

>GUI は、画面にメニューなりアイコンなりを出して、それを人間が目で認識して、それに人間が反応する、という手順が

ならばCUIは、対象物を捕らえる作業を文字または文字列の入力で代替するために、
「捕まえ損ねる」可能性があるリスクを、あえて無視というか先送りしてしまう、
というやり方だと(対抗するならば)言えますよね。

投入した命令がスペルミスだったら、後からLazyにエラーであることが報告される。
逆にいえば、エラー報告の手段を別途用意しないとならない。本質的にエラーが生じえる点が1つ多いことになる。

スペルミスといっても単純打ち間違いだけじ

Re:たまたま途中から観てました。

[kubota (64)]

ckquote>xxxのためのxxx、というのは実は間違いな説明(ごめんなさい)で、より正しくは、xxxのためのyyy、ですね。yyy==xxxである義務は無い。

そのとおりですね。説明が悪かったです。ただし、その yyy が xxx を目的としたものであるということには変わりがありません。つまり、メタメディアは、メディアを目的としたものですね。メディアでないものを目的としたものではありません。

字面の議論じゃなくそういったココロの読み取りくらいやってくれてもよかったのに、と思いました。間違ったことを書いたのはこっちなので、あまりデカいこと言えませんが

Re:たまたま途中から観てました。

[G7 (3009)]

>字面の議論じゃなくそういったココロの読み取りくらいやってくれてもよかったのに

それをやりだすと際限なくProjectXに近づくので(ぷ)、やめましょうよ。

というか無理です。
特に意見が食い違ってる時に顕著に起きる現象なのですが、
「こんなことを言うなんてどうかしてる！」と思うような意見を相手が言うであろう、
と自分が想像することは、これは一種の失礼(=ココロの問題)にあたるわけでして、
かといって自分が納得する意見を相手が言うだろうと想像することは、たぶん正しくない。

実際、本音言えば「おいおい待ってくれよ」というご意見↓に、*今回も*出会ってしまったわけでして。

>メタメディアは、メディアを目的としたものですね。メディアでないものを目的としたものではありません。

うわ。「目的」まで話を広げましたか。うーんうーん。なんか違和感感じます…

#要するに、今回結構「思いがけないお言葉(の連続)」なんです。これをどうやって「読め」と…。無茶言っちゃいけない。

ところで、
番組の最後のほうだけを見たとき、ケイ氏は計算機をメディア(だかメタメディアだか)
「でしかない」と言った(のを貴方は目撃した)のですか？
メディア(だかメタメディアだか)「である」と言った(に過ぎない)のではなくて、ですか？
後者ならば多重継承により計算機が(メタ)メディア*以外*の性質をも同時に帯びる可能性を
否定せずにすむ(そして貴方のご懸念も解消するはず)のですが、そういうことではなく？

>それは、対象とする情報そのものが、もともと 2 次元情報 (地図) なので、GUI を設計するときにマッピングという操作すら不要

あ。こりゃ失礼。
券売機の画面に表示されるのは地図ではなく、単に駅名を路線に沿った順に整列させた文字列(を囲んだ長方形たち)です。
その「位置」を俺は覚えちゃったぜ、という話です。同じ駅名の表示位置はいつも(しかも多分どの駅の券売機でも)同じなので。

地図上の位置と画面上の位置はトポロジカルに同じだろという議論も出来ないでもないですが、
それはちょっとこの場合は考えすぎかと。なぜなら路線順でない順番で画面を配置しても
同じ現象(俺が覚える)は出来るから。

あと、さすがに地図そのものを表示したら、使いづらいと思いますよ(^^;
実地図だと駅どうしの感覚が均等じゃないので、東京と新横浜を押し間違える人が続出しそうだし、
子供は博多まで手が届かない(?)とか、そもそも画面からはみ出すとか、UIとしてさんたんたる状況になろうかと。

つまり、駅名が等間隔になるように、それこそ「マッピング」をしているわけです。

こんなふうに、 WYSIWYGとかいう実体指向だけがGUIだというわけでは無いはずです。

>たとえば最大化ボタンとクローズボタンを押し間違える、なんてことは日常的にいくらでもありえることだし。その点、CUI は ls の
>代わりに rm と打ってしまった、ということはそう起こるものじゃない。

GUIじゃないけど似た話な俺の体験談として、あるアプリの、「ログとり」ボタンと「終了」ボタンとの
キー定義が隣接(Functionキーの9と10だったか)してて押し間違いを頻繁にしたので、定義を変更して
互いに遠いボタンになるようにした、ということがありました。

一方、lsを間違えてslだかow(qwertyキーで)と叩き間違えて不思議な出来事に遭遇することは
(たまたまそういうコマンドをinstallしてれば)無いでもないわけで。

何言いたいかというと、それはUIのタイプの問題じゃなく、「距離」の問題だ、ということです。
lsとrmを間違えないのは、2つの間の「距離」が遠いからです。
Windowsの(ぷ)CloseとMaxを間違えるのは、近いからです。#あれはwin3.1時代と比べて明らかに改悪だよなー

ならば遠くすればいいんです。他に支障が無い範囲で。
文字列ならば出来るだけ違う文字列に。ボタンならば離れた位置に。

どっちかというと、キー叩きとクリック(画面タッチでもいい)との間の「訓練度」に差がついちゃう*理由*を、
考えたほうが良いような気がしています。
俺としては、「キーにしかホームポジションという概念が無い」という点がデカイと思っています。
ポインティングデバイスにもホームポジションに相当する概念を持ち込むことが出来れば、
(そしてもうひとつ、以前もどっかで書いたが、キーと同様の「先行入力」の仕組を実装すれば：
先行入力が出来ない環境ではexpectよろしく計算機のPromptを待つ必要がありますから)
その差はかなり埋まるんでないかと。

#そういう意味では、上のMenuをWindowに取り付けたWindowsとかより、画面に取り付けたMacのほうが、正しいってことになる。
#Menuの位置がWindowにつられて移動したりしないから。

ブラインドタッチとかで本能的小脳的にキーを叩いている瞬間(ご指摘のような「訓練度」が問題になる状況)って、
脳にとって、文字(列)の抽象性とかは、あんまり関係なくなっちゃってるんじゃないかと思うんです。
本能的にぶったたいてる状態。

うーん。なんとか問題を分解して解消することが可能なような気がするんだよな。

ただ、もちろんですが、今主流のGUIには無理っぽいです。

Re:たまたま途中から観てました。

[kubota (64)]

どっちかというと、キー叩きとクリック(画面タッチでもいい)との間の「訓練度」に差がついちゃう*理由*を、 考えたほうが良いような気がしています。 俺としては、「キーにしかホームポジションという概念が無い」という点がデカイと思っています。 ポインティングデバイスにもホームポジションに相当する概念を持ち込むことが出来れば、 (そしてもうひとつ、以前もどっかで書いたが、キーと同様の「先行入力」の仕組を実装すれば： 先行入力が出来ない環境ではexpectよろしく計算機のPromptを待つ必要がありますから) その差はかなり埋まるんでないかと。

まず「ホームポジション」ですが、それは現状の GUI ならマウスを持ったときにまずマウスカーソルがどこにあるかを探さないといけない、という問題を解決しよう、ということですね。もしそれを解決できる方法があれば、GUI の持つ問題のひとつが解決することになると思いますが、それって、画面タッチ方式だともとより存在しない問題なのではないでしょうか。（もし、画面タッチ方式の場合でさえ画面上にホームポジションがほしい、ということでしたら、手の下に隠れて見えない部分を見るために手がホームポジションから動かないといけなくなり、ホームポジションがある、ということの利点が薄れてしまいます）。

「先行入力」というのがどういうイメージのものかよくわかりませんが、画面に GUI 要素を表示するより先に入力するのを許容する、ということでしょうか。その場合には、ぼくがずっと問題にしてきた、「目で見てから判断して手が動くまでの 1 秒の反応時間」が省略できますね。ただし、その場合、表示されていない GUI 要素をポイントするには誤差がつきものでしょうから、誤差をどこまで許容するかのチューニングが難しそうです。誤差と言わずに、GUI 要素の大きさや配置の問題、と言ってもいいです。小さな誤差しか許容しないようにすれば誤操作が増えるだろうし、大きな誤差を許容するようにすると画面に並べられる GUI 要素の数が減ってしまいます。GUI 設計者は、どこに妥協点をもっていくか、というセンスが問われますが、仮に最高の妥協点を見出せたとしても、それでも妥協点はしょせん妥協点でしかありません。間違った操作をする危険性と、表示可能な GUI 要素数の制限の両方を、ちょっとずつ受け入れているのです。

Re:たまたま途中から観てました。

[G7 (3009)]

>画面タッチ方式だともとより存在しない問題なのではないでしょうか。

そうだと思います。俺がマウスは駄目でタッチが良いぞと言った理由は、それと大体同じだと思います。

>手の下に隠れて見えない部分を見るために手がホームポジションから動かないといけなく

ペン(スタイラス)にしましょうかね。人間の手より細いペンには、手の下の隠れる部分を見えるようにする効果が確かに有るので。
#尤も俺はペンを物凄く短かく持つ癖があるので、字や絵が手で隠れてヘボヘボになる人だったりしますが(笑)。

あるいは、ホームポジションについては、バイオリンみたいな楽器を弾く左手に、なにかヒントが有るかも知れないと思っています。
無理かな…

あと、楽器で参考になる所があるとすれば、手の位置を固定する手段、ですかね。
バイオリンとかの左手は、ネックの裏にまわした親指が重要な役割をしますし、
ギターの右手も手か腕のドコかが何かに触れることで位置決めをしてることが多い。
俺はPalmをいじるときは小指を本体側面に当てて位置決めをしてます。そういう感じかな。

>画面に GUI 要素を表示するより先に入力するのを許容する、ということでしょうか。

そうです。そして現行主流のGUIにおいてソレを無理にしている最大の元凶が、
(話は飛びますが)オーバーラップ窓やDialogBoxだったりするように思います。
あの、ユーザーの意図と非同期にフォーカスを勝手に奪って割りこむという、仕組が。
そんなことはGUIが見本としているのであろう現実界においても、滅多に無いことです。

なので、少なくとも、これから選択肢が現れるであろう画面の一角(リージョン)は、
最低でもユーザーが実際に選択するまでは、不可侵(他の何かによってOverapされない)でないと不味いと思います。
そうしてはじめて、先行入力をどうするか?を考えることができると思います。

>表示されていない GUI 要素をポイントするには誤差がつきもの

うーん。どうしよう(^^;;;;;;;;;;;

じゃあ次を考えてみます。CUIの文字「列」入力とは何かというと、インクリメンタルサーチであるわけですよね。
文字列を1文字打つごとに選択肢が26分の1(笑)に絞られるわけです。

それって、一発で入力が確定するのを諦めたことにより、選択肢を沢山表現できるようになったわけで。

ということは、そのメリットを幾らかGUIに採り入れようとしたら、
…ん?階層化メニューということになっちゃうぞ?????(ぉ

うーんうーん…