ビスケットのあれこれ

ビジュアル言語ビスケット(Viscuit)に関するあれこれを書いてゆきます.

ビスケットのインタフェース(子ども編)

2010-08-21 23:58:46 | 1
ビスケットのインタフェースに関しても面白い話があるので,書いてみる.
子ども向けにインタフェースを工夫した話と,教える側向けのシステムの話と.

まずは,子ども向けの話.

ビスケットはよく「何歳から使えますか」という質問を受けるが,最低年齢のネックはマウスである.

幼稚園児はマウスは難しい.手が小さいというのもあるし,ボタンを押しながらマウスを動かすというのは結構難しい.もちろん,中にはさくさくと出来ちゃう子もいるんだけど,ここで言っているのは,まったくコンピュータを触ったことが無い子どもの最低レベルだと思っていただいていい.ワークショップをやる場合,一人でも付いて来れない子どもがでると,そこに引っ張られて,スタッフが一人張り付き,という状態になってしまう.最低レベルで見るのが安全.

タブレットPCだと,クレヨンで絵が描けるような操作なので,4歳くらいなら大丈夫だと思う.

あと,意外と難しいのがクリック.クリックは,マウスボタンが押されてから,マウスを動かさずに,ボタンを離す,という操作である.ところが手が小さいと,ボタンを押すときにマウスが動いてしまう.指先だけ動かしてボタンを押すというのが難しいらしく,握る感じでボタンを押すので,マウスが動いてしまう.

なので,クリックとドラッグを判別させるようなUIは難しいのでなし.

ペンの場合は,実はクリックよりもドラッグの方が楽だったりする.ペンによるクリックは小さな点を打つことになるけど,上手じゃない子は小さな点が打てずに,長い点(線)になってしまうのである.

ビスケットでは,ライブラリーのボタンなどを使って手を抜いて作ってしまった箇所もあるのだけれど,基本的には,クリックではなくて,マウスダウン(ボタンが押された瞬間)だけで反応させるようにしている.これだと,どんな子でもうまく操作できるようだ.

あと,感圧式タブレットを使うようにすると,マウスオーバーも使えない.結構悲しい.

ペンコンピュータには,ゼスチャー認識などが付いているものもあるが,もちろんそういうのは全部OFFにする.ビスケットはWebで動いているが,以前,ゼスチャを認識して「戻る」操作が発行されてしまい,作品が消えた,という恐ろしいことが起きたことがある.あと,長押しで右クリックみたいなのも,禁止.ペンにボタンが付いてる場合もあるが,そのボタンも禁止.

あと,全画面表示も重要.ブラウザの画面のままだと,閉じるボタンや,戻るボタンを,間違って押してしまう人がいる.当然作品は消える.Javascriptで禁止できるようにすればいいんだな.

これくらいで,やっと初めてコンピュータを触る子にも安心して使ってもらうことができる.

困るのは,相手先の,たとえば学校のパソコン室のPCを使うような場合.設定を変えることもできないので,そのままでやるしかない.普通は参加者はそのPCには慣れているので,問題はないけれど.そのPCにインストールされている他のソフトと比べて,ビスケットは低学年でも使えるため,小さい子にとっては初めてこのPCを触るというケースもある.で,そういう誤操作は何人かやってしまう.あきらめるしかない.

いずれにせよ,現場で実際に子どもが触っている様子を観察するのは,インタフェースの改良には不可欠である.

そうやって観察していると,子どもに教えられることも多い.

いまでこそ,ゴミ箱の無いインタフェースもよく見るようになったけど,少なくとも初期のビスケットには,いらなくなった部品やメガネを捨てるための,ゴミ箱があった.そこに捨てなくても,画面の外に出したりすれば捨てられるのだけれど,わかりやすさのために用意していた.

年長の男の子がビスケットを使っている様子を観察していると,彼はそのゴミ箱を使おうとしない.で,どうしているかというと,いらなくなった部品やメガネは,それを出してきたところに戻しているのであった.「捨てる」のではなくて,「お片づけ」をしていたのである.そもそも,ブロックでも積み木でも,遊び終わったら箱に片付けるのであって,捨てたりはしない.

我々が,いかにコンピュータの上に作られた奇妙なお作法に毒されているか,という例であった.

それで,ビスケットのインタフェースでは,子どもの直感に反するようなことは出来るだけしないように気をつけている.たとえば,画面に大量に置かれた部品がいらなくなったとき,画面をいっぺんに消去するようなコマンドが欲しくなるが,そういうものは用意されていない.一つずつ片付けなければならない.わざと面倒な手順のままにしてある.作成した時間と同じだけ時間がかかる.同じような理由で,UNDOやCOPYもない.

コンピュータに対して,情報編集装置としては見せないように気をつけているのである.世の中には効率よく情報を編集する装置としてのコンピュータは満ち溢れているし,コンピュータは情報を編集するためにある,という間違った見方をしている大人が大勢いる.そんな間違った認識を正して,プログラミングというコンピュータの本当の魅力を伝えたいから,ビスケットを作っている.なので,情報編集装置としては,わざと不便にしてあるのである.

面白いことに,コンピュータに慣れた大人は,だんだんいらいらしてくるみたいだが,初めての子どもほどその片付けも楽しんでやっている.小学校高学年くらいになると,情報編集装置としてのコンピュータも知ってしまっているようだが,ビスケットは違う遊び方をするのだということに途中から気づいて,すぐに慣れてくれるようだ.

UNDOが無い話,多摩美の須長先生とも意見が合った.先生が作ってらっしゃるZuzieというシステムにもUNDOは無いそうだ.コンピュータがそのレベルの便利なツールだと思って欲しくない,というのだそうだ.

もう一つ,子どもはわからないけどとにかくやってみる,という性質が強い.ビスケットのように自由度の高いシステムの場合(プログラミング言語はすべてそうだと思うが),とにかくやってみるという方法だと.ぐちゃぐちゃになりやすい.

そこで,ビスケットでは,使える部品の種類が,入門用と上級者とで変わるような仕掛けにしている.入門用では画面に見えているものが少ない.いろいろと知ってくるにしたがって増えるようにしてある.そのあたりの話は(教える側編)に書くことにしよう.

ビスケットの設計方針

2010-08-21 10:11:03 | 1
ビスケットを作ろうと思ったのが2002年末頃で,それから数ヶ月後にはほぼ今と変わらない設計ができていた.その設計の話.

子どもや,コンピュータが苦手だと思っている人に,プログラミングの楽しさを知ってもらいたい.こういった動機は,プログラミンなど,初心者向けプログラミング言語に共通していると思う.ただし,僕は数学が苦手な人でも,プログラミングの楽しさを知ってもらいたいと思っている.コンピュータと数学は密接に関連してるようだけれども,基本的な部分はそれほどでもない.できるだけ数学の香りがしないようなプログラミングにしたかった.

プログラミングを教えるといったとき,いったい何を教えたら,プログラミングを教えたことになるのか.逆に,何は教えたくなかったのか.そこが重要である.

僕は大学でもいろんなプログラミング言語に接してきたし,自分で非常に変わったプログラミング言語を作ったりもしてきたので,広い視点でそれを考えることができた.

変わった言語の代表としてPrologというのがある.実行の順序が決まっていないし,変数はあるけど一度値が決まってしまったら変更することができないし.僕が昔遊んでたのは,Prologに2進数を教えて,足し算を教えたら,自動的に引き算を計算してくれる.足し算を計算の手順としてではなく,計算の関係として表現する.手順ではなく関係で表現されているので,関係を逆にたどることもできて,引き算になったりするのである.そんな不思議な性質がある.FPという言語は実際の計算はしないで,計算式を計算の対象にする.計算式を入力したら,別の計算式が出力される.コンパイラみたいなものだ.

プログラミング言語というのは,今の時代に使われいるものよりも,ずっと広い.変わった種類のものが沢山ある.いろんなプログラミング言語の歴史の中で,オブジェクト指向は比較的最後の方に出てきて,複雑なシステムを作りやすいという理由で,それが今のメインストリームとなったわけだ.

オブジェクト指向は実用にはすごく役立つのだけれど,最初から教えるのはどうかと思っている.というのは,オブジェクト指向のありがたみは,ある程度複雑なプログラムにならないとわからないからである.まずは,オブジェクト指向を使わないでプログラムを書いてみて,プログラムが大きくなるとぐちゃぐちゃになる体験をして,それからオブジェクト指向のすばらしさに触れるべきだと思う.

話は脱線したが,そういう多様なプログラミング言語があるなかで,何を教えるのがよいのか,何は教えたくないのかをエイヤと決めるのがデザインである.

*変数,レジスター,状態
値が格納される場所である.普通は数値が格納されるけれど,数値以外に文字やもっと複雑なデータを格納することもできる.変数は数学では中1で習ったと思うけど,結構難しい概念だと思う.ほとんどの言語に変数があるので,これがコンピュータの基本だと思っている人もいるかもしれないが,実は必須ではない.変数の無い言語もけっこうある.

プログラミンにも変数は無いようだ.プログラミンとビスケットに共通しているのは,画面に絵を配置して,状態を表現しているということである.状態の違いは絵の配置で表現されるので,人間が見ただけで今の状態がわかる.

Scot Kimが提唱したVisibilityという考え方がある.コンピュータと人間のインタラクションをわかりやすくするために,コンピュータの内部状態をすべて人間が見える形で表現して,その表現上で計算をすべきである,というもの.僕はその影響を受けたシステムやプログラミング言語をいくつか作ってきた.ビスケットもその流れである.プログラミンも一部そうであるが,旗という大域的な状態が一つあって,それがオブジェクト間の通信にもなっていたりするので,厳密なVisibilityではない.人間からは今どの旗なのか見えない.

Visibilityに従ったシステムでは人間に隠された状態(つまり変数)はなくて,メモリーは画面の絵の配置のみ,ということになる.

*繰り返し,制御構造
これもまったく必須ではない.BASICなどの影響で,繰り返しや制御構造を教えることが,プログラミングの基礎だと思われているかもしれないが,それがない言語も沢山ある.フローチャートに毒された考え方で,僕は教えたくない.このシーケンスを教えてしまうと,同時に動くものが表現しにくくなる.Visibility的に言うと,いまどこを実行しているかという印(プログラムカウンタ)を想像して追っかけてゆく,ということをやらなければならない.複数動く,その印が複数いろんなところにあるので,余計わかりにくくなる.プログラミングやデバッグにはそういう見えないものを追っかけてゆくセンスが必要であるけど,それは入門用には見せたくない.

じゃあ後はいったい何が残るのか.というと,
プログラムとは微少変化の記述の集まりである,
ということになるか.微少変化とは,単純な機能と言い換えてもよい.

そもそも,コンピュータの基本である機械語の命令の一つ一つは,短い時間でレジスターやメモリーの値を変化させる,ということしかできない.微少変化である.その変化を並べて順に実行させることで複雑な計算になる.逆に言うと,プログラミングというのは,やって欲しいことを,微少変化に分解して,記述する,ということである.その分解こそがプログラミングに必要なセンスであり,その上で組み合わせによってどんどん複雑な動きが作れるという体験をさせたいのである.

情報機器を使いこなすセンスというのも,言ってみれば,やりたいことを限られた機能に分解して実行できるかどうか,なのかもしれない.その最も基本的な能力を特訓することがプログラミングなのかもしれない.

逆にこれだけはやりたくないこと.それは,機能をなんでも探してしまうことである.プリミティブの組み合わせでできた複合的な機能なのに,組み合わせて作ろうとせずに,単体でその機能を探してしまう.組み合わせのすごさを知って欲しいのに,逆効果である.

まとめると,プリミティブの数は極力少なく,組み合わせ能力は非常に高く,ということであろう.このあたり,実用をある程度犠牲にしてもよい,教育用言語だからでもある.

「プログラミン」と「ビスケット」を比べてみる

2010-08-20 17:17:17 | 1
文部科学省が「プログラミン」という子ども向けプログラミング言語を公開した.
いろいろと盛り上がっているようで,プログラミングというコンピュータのもっとも基本の部分にこうやってフォーカスが当たるのは歓迎したい.

とはいえ,ビスケットを必死でやっている僕としては,黙っているわけにもいかないので,どういう部分が違うのか,ということを書いてみたいと思う.インタフェースがプヨプヨ動くとか音が出るとか,そういう見た目の違いは,比べればわかるので.

なにせ,ソフトウェアなのだから,設計上のいろんな部分で,いかようにでも選択できる.作る人の物の考え方がはっきりと表れてしまうし,思想を明確に強く持っていないと,設計全体がすごく揺らいでしまう.

プログラミンとビスケット,根本的に違うのは,コンピュータのどういう魅力を子どもに伝えたいか,という部分だとおもう.これは作者がプログラミングそのものをどのように感じているのか,ということでもあるのだが.

僕は設計では,基本原理の部分をどこまで小さくできるか,という点に力を注いだ.同じことができるなら,基本機能の組み合わせでできる方をよしとする.機能はやみくもには増やさない.

もっと戻ると,僕は物理に感動した人間だ.物理のすごさはたった1行の式で世界の動きが記述されているということ.その式にいろんな初期値や条件をいれることでいろんな動きが出てくる.美しい世界の一つの例だと思う.

コンピュータはソフトウェアでいろんな世界を作ることができる.ごたごたした汚い世界も作れるし,物理のように1つの式だけで記述される美しい世界も作ることができる.だから,ソフトウェアを作る人は,そういう目を養うべきだと思っている.

レゴで,いろんな特殊パーツが入っていて,それでお城とか作れるやつ.そういうのをよしとするか,それとも基本キットだけで作ろうよ,という立場か,の違いみたいな.

プログラミンは機能が全部アイコンで表現されていて,たとえば右に進むとか,左に進むとかが別のアイコンになっていたりする.プラス・マイナスを使ってよければ,右と左に進むというのを一つにして,「横に動く」という言い方にして,プラスなら右,マイナスなら左のようにやってしまうところだが.ここは,右と左は別の機能に分けたようだ.ところが,速く進む,ゆっくり進むは,なぜか数値で入力させている.ここはアイコンに徹して,右に動くを3個入れたら,速く右に動く,という意味にさせたり,GUIでアイコンが左右に伸びるようにさせて,速く動かすには横長のアイコンにする,みたいな設計でもよかったと思う.それから,速度を,X秒あたりYのように分数で表現するのは敷居が高そう.そもそも速度なんて概念を知らなくても,コンピュータの面白さを伝えることができるわけだから,その辺りは...

ビスケットは,メガネで全部表現している.絵がどのように動くか,絵がぶつかったらどうするか,そういったことをメガネだけで表現している.右に動く,左に動く,回転する,ゆっくり回転する.全部,メガネの中に絵を置く,置き方だけで表現する.ただし,そういう制約があるので,なんでもできるわけではない.ビスケットは,何か表現したいことをなんでも素直に表現できる,という部分は犠牲にしている(最初にやりたいことが決まっている人は,プログラミンの方が素直に表現できるかもしれない.たとえば,ビスケットでできないことの一つに,クルクル回転しながら横に動く,という動きがある.これはプログラミンだと「右に動く」と「回転する」を組み合わせればすぐにできる).

もうひとつ,相対座標を教えるかどうか,という部分.

たとえば,魚の絵があって,右に動くようにしたとする.その魚を反対向きにおいたら,どっちに進むべきか,という問題.いまここで「右に」と言ったけど,そもそもその魚はどっち向きに描いた絵なのか.プログラミンは「右」は画面に対しての右なので,絵がどっち向きであろうが画面の右に動く.ビスケットは,絵に対してどっち向きかが重要なので,魚が右向きに描かれているのであれば,「右にすすむ」じゃなくて,「前にすすむ」である.前に進むのであるから,魚の絵を反対向きにおいたら,その魚にとっての前,つまり左に進むのである.魚を下向きにおいたら当然下に進む.こういうのを相対座標と呼ぶ.これ,結構難しくて.大人でも,勘違いすることがある.

相対座標はロボットの制御などにも重要だけど.プログラムの楽しさを知るために相対座標を知らなきゃいけない,というのちょっと違う気がするので,相対座標を採用していないプログラミンは,一つの考え方ではあると思う.ただし,そうであるなら,絵を回転させる操作はどうなのか...

ビスケットでは,ワークショップでは使ったことはないが,回転を禁止するモードというのが実はある.これを使うと,絵は回転させることはできないので,ステージに置いた絵も,メガネに置いた絵もそのままである.メガネを複数置いて,どんな複雑な動きをさせても,絶対に絵の向きは変わらない.

僕は,未就学時に対するビスケットの場合は,回転を禁止する設定でもよいのではないかと思っている.その理由は,ビスケットのワークショップそのものの考え方だけれど,適当にやったら何か動いて楽しい,というのではなくて,しっかりと自分がやっていることを理解して,自分が自由自在に制御可能な範囲で遊んでほしい.ということがあるからである.回転は4年生くらいからでもいいかもしれないなぁ.

で,ビスケットでもっとも大事にしたいのは「子ども同士が教えあう」という部分.教えあいが起きるためには,子ども自身が「この知識は有用で,他人にとっても有用に違いない」と思わなければならない.そう思わせるような,子どもにも理解可能な世界観と,子どもが理解・説明できる言葉と.

そんなことを常に改良しながらやっているわけだ.