「アラン・ケイが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の説明としては、たしか、ちと外れているはずです。

概念的(ってのか)にはMetaClassは、ClassにClassとしての機能(?)を提供するClassであり、
つまりSuperもSubも全部含めた各種Classたちがそれぞれ自分を表現するための手段の提供体であり、
個々のClassが何を表現しているか？とはまぁ関係ないです。

…こんなんで説明になっているでしょうか？なってないか…(^^;

#上記のことをもしご存知無かったのだとしたら、ここで以下↓のように言うのは猶予したほうが良かったかもなので、そうならば御免なさいです。

で、そういう相違があるにも関わらず(貴方が)相違を無視するのでしたら、
それは貴方自身が今した、「憶測でしゃべるのは、やめます」という宣言に、たぶん反しています。よね？

>GUI で抽象概念を表現するのは、あたかもパントマイムでものごとを伝えようとするかのごとく、困難なことです。

うむ。この説に対する反論(?)も、そろそろ新バージョンを考えないとならないんだろうな。

つまり、たとえば(即興で恐縮ですが)、「絵が抽象じゃないと、誰が言ったの？」と反論してみるテスト。

てゆーか、抽象化したものを即ち文字と呼ぶ、という解釈ならば、
今の(あるいはそれ以外の)「G」UI(だと「貴方が」)思っているモノは、
実はCUIである、という一見変な話が、なりたつかも知れないなあ、と。

人間側の過去の学習成果を流用して意味を伝達するという意味では、結局どっちも大差ないわけだしぃ。

>ぼくが現在の GUI に不満な点は、操作する対象 and/or 操作する行為を画面に表示させるという手順を必要とするという点で

「現在の」が「Win/Mac系の」を意味するのか、それより多くのものを含むのか、ってのが気になる所です。

あと、「行為」ってのは、なにもGUIに限った話じゃないと思うんですよ。
プログラミングにおいてはしょせん弱っちい俺が、はじめてrubyを体験したときに思ったことなのですが、
「ああ。これは、というか純粋OOP言語ってものは、その名の直感的意味に反して(^^;、
純粋に「行為」の羅列を記述する言語という作りになるのだなあ」と思ったんです。
この認識は今も間違いだったとは思っていません。
結局Objectをどう動かすか？という手順(だけ!)が書かれるんですよね、Scriptには。
#これを普通の言葉で一言でいえば多分、rubyは「手続き型OOP言語だ」ということになるんだと思います。

で、同じ事がUIにも言えるんじゃないかなと。
UIで表示(?)されたObjectをどう弄るか？という事柄をしか、表現していないし、
表現できないし、それで十分だし(^^;、というものなんじゃないかなーと。

そりゃそうと、

>「対象」「行為」のうち「行為」しか指定できないこと

え？貴方はアイコンをクリックしたことが無いんですか？

対象を選択するためのアイコンクリックってのは、よく行われることですよね？

まぁ選択じゃなくアクションにマップする権利もまた有りますが、それはそれ。
#そういう意味では、近年のWinとかで頻用されている「ツール」バーというものは、俺もかなーり違和感覚えてるんですけど、ね。
#WinはOOPっぽい世界から「逃げて」いるなあと。 ##そのほうが客の受けが良いのかどうかは知りません。

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

[G7 (3009)]

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

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

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

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

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

もしかして「全部ブラインドタッチだから問題ない」とかおっしゃるんでしょうか？
だとしたらそれは、GUI/CUIの差の問題じゃなく、user Interfaceつまりインタラクションの有無
の問題だと思いますし。

bashとかでファイル名補完とかをやるってのは、GUIでいえば「あのアイコンはこのへんに置いておいたよなあ」
ってやる…つまりいわゆる「手探り」状態と、似たようなものですよね。
補完せずフルにタイプするときは上記のようにマウスで選択するのと同じだし。

#だから、アイコンとかの「整列」をするってのは、最悪なんだよね。

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

[kubota (64)]

GUI は、画面にメニューなりアイコンなりを出して、それを人間が目で認識して、それに人間が反応する、という手順が必要ですね。目からの入力→手の反応に要する時間はおよそ 1 秒で、これはどんなに訓練しても速くなりません。マウスカーソルの操作にも、この反応サイクルが組み込まれています。「たしかこのへんに」という「予測」によって、その 1 秒を部分的に回避することはできますが、最初にまずマウスポインタがどこにあるかを認識しないといけませんし、最後にマウスポインタをそこに「ぴったりと」あわせるためにも目→手の反応時間をどうしても必要とします。GUI の本質を保ったまま、この反応時間を回避する方法はないですか、というのが論旨です。キーボードはこっちから打ちっぱなしなので、理論的には、いくらでも速く打てます。少なくとも、GUI に不可避な「反応時間」をうざったいと感じる程度にまで上達するのは、それほど難しいことではありません。もちろん、最初はポインティングデバイスのほうが楽でしょうが。

ショートカットキー? あれは GUI ではありませんし、「対象」「行為」のうち「行為」しか指定できない

“ショートカットキーは GUI ではありませんし、「対象」「行為」のうち「行為」しか指定できない”と読んでください。“GUI は「行為」しか指定できない”とは読まないでください。

ちなみに、「メタ」が「xxxのためのxxx」であろうと、「あらゆるxxxになることができるもの」であっても、いっしょです。コンピュータが「メディアとはあらゆる点でまったく縁もゆかりもない何か」となれる可能性を否定しているのです。「メタ」がどんな意味であろうと、「メタメディア」は何らかの形で「メディア」と関連するものでしょう?

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

[G7 (3009)]

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

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

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

スペルミスといっても単純打ち間違いだけじゃなく、思い違いつーか記憶/判断違いもあるわけで、
つまりCUIには、概念のProxyである文字(列)を間違えれば空振りする、という問題が常に有るわけです。

これを他山の石とするならば、GUIのほうでは、
今の作業に必要最低限のObject(やCommand)について、それらのProxy Objectを目の前に置いておく、
という手も無いでもないです。そういう意味でデスクトップなりなんなりの「手近な場所」に
対象物の「ショートカット」を置いておくってのは、まぁ生活の知恵(=Scriptingと同じ)かなと。

#ちなむと、CUIの文字打ち間違いは、GUIではショートカットの「リンク切れ」に相当すると思います。

あと、(人間から見て)アウトプットについてはご指摘の通りってのも言えますが、
一方でインプットを高速化出来ることが分野次第では期待できるわけで、
たとえばCADがCUIで出来て(「表示も」文字で数値とかを表示しろ、という意味です(^^;)いたら、
俺は使いたくないですね。
それこそ1枚(?)の図をインプット(読解)するのに何時間かかるか知れたもんじゃない。
作業効率(速度)という面で意趣返しをするならば(^^;、まぁこんなとこでしょうか。

あと、

>最初にまずマウスポインタがどこにあるかを認識しないといけませんし、最後
>にマウスポインタをそこに「ぴったりと」あわせるためにも

マウスは駄目ですんで忘れてください(^^;。
#つーかマウスで(ソフト?)キーボードを打つとかにして初めて、その勝負は対等になると思います(^^;
実用的には少なくとも画面に直接タッチするデバイス構成になってないと論外だと思ってます。
そういう意味では今はパソコンより新幹線駅(?)の券売機のほうがマシ。
いつも降りる駅のボタン(GUI)の位置なんざ覚えちゃいましたから、処理(表示じゃなく)の遅さにいつもイラついています(^^;

あとは画素数の問題だと予感しています。
リアルワールドを文字列コマンドで制御する人は(障害とかで仕方ない人を除けば)いないと思いますが、
それは計算機画面と比べて現実がユーザー(?)にもたらす情報の量つーか画素数が、むちゃくちゃ多いんで、
文字打ち込みじゃ情報量が不足するせい、だと思うんです。抽象化が"追いつかない"状況。
だから、計算機が(ちょっと)進歩して、とんでもない数の情報量を相手にするようになったら、
GUIの価値も生きるようになるかなーと。ついでに今風の眠いGUIらしきものは淘汰されるだろうなーと。

>“GUI は「行為」しか指定できない”とは読まないでください。

失礼しました。
#ただ、その路線だったとしても、前述のように、これまた面白い話が展開するらしいですけどね。

>「メタ」が「xxxのためのxxx」であろうと、「あらゆるxxxになることができるもの」であっても、いっしょで
> す。コンピュータが「メディアとはあらゆる点でまったく縁もゆかりもない何か」となれる可能性を否定しているのです

うーん。別口でも書きますが、なんか誤解を深めちゃったかな？

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

であるので、貴方のこの段落の説は、やっぱり変だと思います。

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

[kubota (64)]

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

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

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

で、GUI に対して CUI は入力間違いの可能性がある、というのはその通りでしょう。おそらく、言語ベースユーザインターフェース (CUI) のもっとも進んだ形は手書きとか音声認識とかになると思うのですが、新幹線の駅の名前を知らなければ、切符を買うことができない (一方、GUI なら「たしかこのへん」でも買えてしまうかもしれない) のは確かです。

ただし、新幹線の券売機を例にとるのは少々 GUI 側にバイアスがかかっています。それは、対象とする情報そのものが、もともと 2 次元情報 (地図) なので、GUI を設計するときにマッピングという操作すら不要になるからです。CAD の例なんか、もっと極端ですよね。操作したい対象そのものがもともとグラフィカルである場合には、GUI のほうがいいに決まっています。

エラーの可能性と、その場で操作可能なモノゴトの多様性とは、CUI、GUI を問わず、表裏一体であると思っています。GUI であっても、並べるアイコンの数が多ければ多いほど、その場で操作可能なモノゴトは多様になるけど、間違って隣のアイコンを指定してしまう危険性も上がる。

たとえば最大化ボタンとクローズボタンを押し間違える、なんてことは日常的にいくらでもありえることだし。その点、CUI は ls の代わりに rm と打ってしまった、ということはそう起こるものじゃない。ただしこれはもちろん、CUI の冗長性(いっぱい打たないといけない) と引き換えに得られたもので、どっちの利点というわけではありません。が、音声入力とかなら、ふつうの人間にとって、冗長性をほとんど感じさせず、かつ間違いも少ない入力方法になるのではないかと思います。

で、いまのぼく自身にとって GUI が不満なのは、CUI の「打ち間違い」と いう欠点は上達とともに減らすことができるけど、GUI の「反応時間」は 絶対に回避できない、ということです。

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のほうが、正しいってことになる。

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

[kubota (64)]

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

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

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

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

[G7 (3009)]

やっと放送見ました。
正確にいえば、こないだの土曜に録画し、日曜に見、メモと暗記(ぉ)をして、今週もまた月曜からVTRの無い仕事場に詰めてます。
なのでもし見間違いがあっても原典にあたって訂正できるのは今週末ですm(__)m

で、メタメディアですが、メディアとメタメディアの取り違え(あえて言うならば)をしたのは、
ケイ氏じゃなくNHK側のナレーションなのではないですかね?(^^;
明示的にメディアだと言い切ったところは、2個所くらい有ったように記憶していますが、
どっちもナレーションだったっす。

番組じゃないですが、 「他のいかなるメディアー物理的には存在しえないメディアですら，ダイナミックにシュミレートできるメディアなのである」「コンピュータそれ自体は道具ではない」 [chienowa.co.jp]
とのことだそうです。氏自体がメディアとメタメディアを混同したという線は、なさそうに思います。

あと多重継承の可能性を否定してる場面も無かったようですので、
(メタ)メディア「でしかない」という線も無さそうです。

#繰りかえしになりますが、心は(他だってそうですが心は特に)曇ってしまえば先が見えなくなります。
#メディアとして使うには心は不都合が多いと思います。
#特に、明晰な人(今回はケイ氏がソレであると仮定している)の言葉を、明晰でない自分が理解(笑)する際には、
#自分の心は理解を妨げ誤解(間違った思いこみ)を増やす元凶になることが多いので、
##ケイ氏も「人は自分の価値観からなかなか自由になれない」と言ってた
#いかに心をニュートラルに置くか?を大事にしたいと思っています。
#行間はむしろ読むべきじゃないと思っています。むしろ読みたいという甘い誘惑をいかに断ちきるかが…

それに、それ以前の問題として、なにも文字列や絵や音だけを載せるモノだけがメディアだ
というわけではないので(それじゃまるでWindowsの*Media*Playerです(^^;)、
メディアであっても既にそんなに悩む必要はないんではないかと。
プログラムを書く対象もメディアだし、それを動かすプラットフォームも(メタ性をさておいて、
その瞬間の単なる道具としてのソレを考えるならば)メディアであるわけですから。

で、更にその上にメタが付くわけですから。
さすがに単なる紙やコンパスだけでは、それ自体で「洞察力や思考力」を養うというわけにはいかないでしょうね。
やはり単なるメディアとは違う何かを(も)持っているのだろうなと。

ただ、「こえるもの」という、番組の最後に出てきたあの表現は、それこそ不味いというか、
ちと悪い意味で「子供向け」な表現だったかなと思いました。
嘘というわけでもないが真相も結局良く判らないよ、あれじゃ説明になってないよ、と思いました。
氏も、メタという概念を子供にもすんなり理解できる言葉を、見つけ損ねたのではないか?と邪推します。

余談の番組感想：
1：NHKに1時間もかけて解説&宣伝してもらえた(Free)ソフトたぁ、羨しいです(^^;
1.5：rubyはいつ出るんだろう?(^^;;;;;
2：自分ではなく他人に読ませたいために日本語プログラム言語が欲しいと思いました。
それこそSqueakを和訳したようなものが欲しい。
米国の子供たちがすんなり入っていったのは、やっぱりSqueakに表示されるprogramの言葉が母国語だという面がデカイかもなあと。
なんせ番組では日本人視聴者のためにSqueak画面の和訳がスーパーインポーズされてましたからね(^^;。
これじゃ隔靴掻痒です。あの表示がNHKじゃなくSqueak自体によって表示されていたならばドレほど素晴しいことか…
3：アプリケーションソフトこそが、メタのつかない単なるメディア、なのではないか?
4：相対性理論(高速移動で時間が遅れるアレ)を解説するソフトを子供が作ったってのが驚き。
作れたこと自体が驚きなのではなく、子供が誰か(大人かもしれない)へ物事を教える「ため」に
そのソフトを作ったわけで、子供は教わるものだと思い込んでいた自分としては衝撃的だった。不覚。

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

[G7 (3009)]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

うーんうーん…