@hadsn 後退ではあるけど＞＜； でも、例えばカレー粉ってカレー粉かも＞＜ インド人的にはなんでスパイス自分で混ぜないの！？ってなるっぽいけど＞＜

選択肢を減らす(おまかせだけにする)のもまたひとつのデザイン・・・＞＜
味・塩こしょう＊135g｜商品紹介｜おいしさで・しあわせをつくる ダイショー http://www.daisho.co.jp/item/detail/i/125210/

塩とコショウの容器をひとつにしたいと思う人は多そうだから、既に誰かがその為の機構の特許とってそう＞＜

コショウと塩の容器のデザインひとつ思い付いた＞＜(正しいデザインでは無い)
回すとコショウが出てきて、振ると塩が出てくる容器＞＜

テプラの刑が必要かもしれない＞＜

容器のデザインが適切では無いのであれば、コショウと塩も間違える＞＜

例えばだけど「どう見てもコショウでしょこれ」ってデザインの塩の容器であっても、ミルの機能を果たす部分、多くの場合廻せるというアフォーダンス？＞＜を持っていなかった場合、少なくとも「コショウの容器にはミルがついているものだ」と考える人が、同じように廻せてしまう蓋が無く、廻せる部分がなければ、蓋を廻して開けてしまいお清めの儀式をしてしまう事は無い＞＜(当たり前だ＞＜；)

廻せない容器でも、容器にミルのようなものありそれにより「これはコショウだ」と認識したあと、「そうではなくこれは廻せないぞ」と思っても、すでに起きてしまったスリップに気づく事は難しそう＞＜
「なるほど。これはミルを廻さないでも出てくるタイプのコショウの容器だ」

今さら気づいたけど、塩の容器をコショウの容器と認識してしまって、さらにコショウであればミルがついているであろうという推定をもクリアしてしまって、最終的にお清めをしてしまったの、ものすごくデザインの話であり、ちょうど長々と書いていた直感的とされるデザインとは？みたいな話そのままだ・・・・＞＜；

そういえば、どこからどう移動してるのかよくわかんないけど、埼玉東部にいるということはセイコーマートにも行けるんでは感＞＜(今羽のセイコーマートとか)

伝説が増えた・・・＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

なんでこの辺りの話が無視されちゃうのか・・・＞＜

https://mstdn.nere9.help/@orange_in_space/100853712326238480
https://mstdn.nere9.help/@orange_in_space/100853722092510581
https://mstdn.nere9.help/@orange_in_space/100853676432653894

このアカウントは、notestockで公開設定になっていません。

Rubyの予約語やら文法やらってなんにも自明ではないですよ？＞＜ 他の多くのプログラミング言語も、そして恐らく大半の自然語も＞＜

ビックリさせるなって、それ具体的にどうすんだ？＞＜ってなるし、ビックリさせないってつまりユーザーが思い描く動作をすべきってなるし、ユーザーが思い描く動作って、さっきから説明しまくってる物理的制約や論理的制約や物理的制約等とユーザーが得た情報(ノーマンの言葉で言うとシグニファイア)によってほぼ決まるので、それに基づいてデザインを・・・・ってなんの話だったっけ？＞＜

ていうか、オレンジが今解説しまくってて、上手く伝えられてなくて齟齬が発生してる部分であり根拠よりも重要なのこれかも？＞＜；
https://mstdn.nere9.help/@orange_in_space/100853840973923429

これ、オレンジが「デザイン！＞＜＃ 」って言いまくってる話でのオレンジ語で言うと「齟齬」かも？＞＜(ノーマンの表現だとミステーク？(であり、「ヒューマンエラーって言うな！」かも？＞＜))

このアカウントは、notestockで公開設定になっていません。

一億歩譲って、そのRubyのその概念が重要だとしても、プログラミングに初学者に必要なプログラミングの初学としての基礎とは言えない＞＜ 仮にそれがRubyならではのものならなおさら、プログラミングでは無くRubyを教える時に教えれば良い＞＜
プログラミングを学ぶ初学者にどう教えるか？という話であって、実用的なプログラミングの各固有環境にとって重要か否かなんて事は言ってない＞＜
初学者に「プログラミング」と例えば「Ruby」を混同させるなと言ってる＞＜

このアカウントは、notestockで公開設定になっていません。

ビジュアルプログラミング環境は、この論理的制約にプログラミングの基礎の部分、例えば分岐やら繰り返しやらと言うものを対応させて学ばせる事が出来る環境と言えるかも＞＜
(繰り返しになるけど、だからといって必ずそれで教えろとは言ってない＞＜)

(全然説明しきれてないけど、とりあえずショートカットすると＞＜；)
ビジュアルプログラミング環境は、この論理的制約を持ち込みやすいという特徴があるかも＞＜ ていうかGUIというものがそうかも＞＜(GUIは論理的制約を活用するデザインであるとも言えるかも＞＜)

ランプが横に10個並んでいて、スイッチが例えば3x3で9個並んでいたら、ランプとスイッチの対応に気づける人はほぼ居ないかも＞＜ それは論理的制約が無い状況と言えるかも＞＜

ランプが横に10個並んでいて、ランプそれぞれの手前にひとつづつシーソースイッチがあったとして、一番左のスイッチは、一番左のランプに対応するであろう　みたいなのも論理的制約かも＞＜
その上で、各シーソースイッチのうち、奥側に倒されているものに近いランプが点灯し、手前に倒されているものは消灯していたら、奥が点灯であり手前が消灯であると多くの人が推定するかも＞＜
全てのランプが消灯し、全てのスイッチが奥になっていたら、点灯は手前であると解釈する人の方が多いかも＞＜
(シーソースイッチを知らない文化圏の人であっても、1:1でスイッチがある事の法則性に気づけば、「それをどうにかすれば変化する」と、対応に気づける程度の多くの文化圏であればたぶん気づけるかも？＞＜)

例えば、さっきの電池ボックスの話で、単3電池だったとして、電池ボックスが電池の形状をしていて、さらには電池の形状のラベルが貼ってあり、かつ、それに気づく事が出来た人の多くは、電池を正しい向きで取り付ける事が出来るかも＞＜
これは文化的制約とは別の論理的制約と言う(用語がある)もの＞＜

元の話的に一番重要な、論理的な制約の話全然書いて無い＞＜；

この物理的制約はGUIでも応用されてたりもするし、ビジュアルプログラミング環境でも応用されてたりするかも＞＜

平たい板であれば引くことが出来ない「ように見える」は文化的制約であり学習であると言えるけど、それだけじゃなく「引くことが出来ない」そのものが物理的制約になっている事が重要かも＞＜
物理的制約は、究極には操作する者が理解せず短期的な意味でそうする意図を持たなくても、結果的に大きな目標を達成できるという使い方もされている＞＜
例えば建物の避難設備がその代表例かも＞＜

このアカウントは、notestockで公開設定になっていません。

命令数が少ないCPU上では複雑なソフトウェアは実行できないみたいな意味不明な話になっちゃう＞＜(命令数が少なければ多くの場合より複雑になるだろうけど、その複雑とその前の複雑は違うものを指してる＞＜)

その文脈上の複雑云々の本質と、プログラミングの初学の人に教える基礎(から各言語の作った人が勝手に作った部分をなるべく排除した)という文脈での複雑性って別物かも＞＜
それ、「デジタル回路は複雑である」くらいに雑な意味での複雑になっちゃうかも＞＜
(全然向いてない)初学者向けビジュアルなプログラミング環境で大規模なソフトウェアを作ろうとしても複雑になるのは当たり前みたいな・・・そういう事じゃなく＞＜

もちろん、デザインとしては、どっち向きでつっこんでもおkにする方が優しいかも＞＜(その上で、文化的な制約により「どっちの向きなのこれ？＞＜；」って混乱を避けるためだけに、一方を指示するラベルを貼るのもありかも)

単3乾電池の電池ボックスも多くの場合物理的制約による直感的・・・かつその失敗によるエラーを起こさせたり、それを減らすために図示によって、正しい向きでセットさせるデザインであることが多いかも＞＜
電池の＋極の突起を使って、逆には填まらないようにしたり、ちょっと微妙なのでも逆につっこんだ場合に電極に触れないようにしたり＞＜
電池ボックスそのものがビジュアルに逆方向の取り付けを防止する形状が分かりにくい時には、取り付け部の底に、向きがわかるように図があったりする＞＜
これは、電池をそこに取り付ける必要があるとだけわかっていれば、それ以上の知識がなくとも物理的制約により正しく取り付けられる可能性があると言える＞＜
これはある程度直感的なデザインと言えるかも＞＜

『直感的』の多くが文化的な制約であることも多いけど、それだけじゃなく、例えば物理的制約も『直感的』とされることも多いかも＞＜ 例えば掴めるとっては、引くことも押すこともできてしまう＞＜ 一方で、平たい板であれば少なくとも引くことはできない＞＜
引くことができない物に引けるかのようなデザインをするのは『直感的』では無いと言えるかも＞＜

このアカウントは、notestockで公開設定になっていません。

誰のためのデザイン？ 増補・改訂版の第3章がだいたいその話だけど、長すぎてどこを引用すればいいのかわからない＞＜；

ノーマンの本持ってくる？＞＜；

オレンジのさっきの文脈上のそれは、その言語の作者が勝手に決めた部分以外みたいな意味＞＜
(もちろんScratchとかにもそれらのデザイナが勝手に決めただけの部分もあるけど、ビジュアルだとより切り離しやすい＞＜(この部分を説明しようとすると、ノーマンの本から長文引用しないといけなくなる＞＜；))

このアカウントは、notestockで公開設定になっていません。

@cuezaku 単純にダウンロード数1位のはPawooアプリっぽい？＞＜

@cuezaku オレンジが使ってるのはSubwayTooter＞＜

ビジュアルプログラミング環境は、単なるその言語の作者の都合でしかない文法や語と切り離して、概念で理解させる事が出来るからこそ、初学に向いてる＞＜(必ずそれで教えろとは言ってない＞＜ 一応)
何が本質であり、何が本質ではないかを教える事が出来る＞＜

ついでにツッコミいれると、プログラミングの初学にビジュアルプログラミング環境(Scratchとか)を使う事を否定するのも、プログラミングを理解できていないひとつの証拠になるから否定しない方がいいよ＞＜
概念と実装を混同してるよ＞＜
概念と実装、自明な物事とそうではない物事を混同するから、まずタッチパネルを操作する子を見ても嘆かわしく思っちゃうんだよ＞＜
オレンジ的には概念と実装の混同の方が嘆かわしいよ＞＜

まずタッチパネルを操作しようとした事に疑問を感じる事自体、これで指摘したように、サリーとアン課題で誤答するのと基本的には変わらないんだよ＞＜ より条件が複雑になっただけで＞＜
https://mstdn.nere9.help/@orange_in_space/100852904690475012
人が何かを操作する時、何か行動する時には、それが正しかろうが誤りであろうがなぜそうするのかを推定し、そして仮にそれを奇妙だと思うのであれば、「なぜ自分はそう行動しないのか？」「 何によってどう、そう行動しないと学習したのか？」 振り返って考えるべきかも＞＜

x動作できないのと　o操作できないのと
＞＜；

で、その上で、この子たち何才なの？＞＜(さっきの心の理論の話にも出てくるけど、すごく小さい子はそんなに複雑な論理的思考できないよ？＞＜)

ニンテンドーSwitch上のマリオカートのどこに、それをレバーなりスティックなり十字ボタンなりで操作するという情報がある？＞＜
実際にプレイしていないから知らないけど恐らくチュートリアル画面にあるのでしょ？＞＜
じゃあ、そうだったとしてその画面を見てなかった子はどうなる？＞＜
プレイしている場面を観察して、スティックだか十字ボタンか知らないが、その操作と画面の動きが一致していることに気づけた子だけ、その操作で動かそうとするかも＞＜
もしかしたら、それを理解した上でも、操作を直接邪魔せずに介入するために、「タッチパネルでも操作可能なのではないか？」と推定する賢い子もいるかもしれない＞＜

例えば、マッチで火をつけられるか？ 百円ライターを使って火をつけられるか？ チャッカマンを使えるか？ それぞれ別の知識であって、それぞれ説明無しには気づけないよ？＞＜
マッチのどこに、百円ライターのどこに、チャッカマンのどこに「火を起こせる」というシグニファイアがある？＞＜
そんなもの無いんだよ＞＜ それで火を起こせると知っている人が使う前提のデザインだから＞＜

これ別に現代っ子だからじゃないよ？＞＜ 単にその世代ごとの脳内のモデルの違いであって、タッチパネルを操作した事は無いけどボタンを押した事はある老人がタッチパネルを動作できないのと何も変わらないよ＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

@cuezaku ・・・＞＜

これ＞＜ https://mstdn.nere9.help/@orange_in_space/100461644787857965

書きたい本の前書き書いた感＞＜

この、相手の脳内のモデルの推定の不足、多くの人が陥るし、だからこそ世の中の大半のヒューマンインタフェースデザインはめちゃくちゃであり、多くのモノを作る人は「説明書を読め」と言ってしまう＞＜
その推定は必須では無いと考えているのか＞＜
でも、その相手がどう考えるのかの推定って、自閉症のチェック等にも使う、サリーとアン課題(参考 心の理論 - Wikipedia https://ja.wikipedia.org/wiki/%E5%BF%83%E3%81%AE%E7%90%86%E8%AB%96 )が複雑化したようなものであり、逆に言うと単純化すれば、サリーとアン課題のようなものと言えるかも＞＜

開発者(/製作者)は「だって(説明書/エラーメッセージ/操作パネル等々に)書いてあるじゃん？」て思う＞＜
ユーザーは「そんな訳がわからない事書かれてるの気づけないよ！」とかなる＞＜
人それぞれ、状況それぞれで脳内のモデルは異なるし、人はその異なるモデルに基づいて操作しようとする＞＜
相手の脳内のモデルの推定無しに何かを指示しようとしたり教えようとしても、食い違いがあるので上手く行かない＞＜ さっきのプログラミングどうやって教えるか？の話もそう＞＜

「なにもしてないのに壊れた」と、「ここをこうしたら壊れた」の両方を同時に考えられるようになると、ヒューマンインタフェースのデザインができるようになるのかも＞＜

このアカウントは、notestockで公開設定になっていません。

発電機作らなくても、電池を作れば発電機に使う永久磁石も作れる＞＜(そのための電磁石を動かせる) 忘れちゃいけない＞＜；

あああああ！＞＜； 電池！＞＜；(なんで思い至らなかったんだろう？＞＜；)
https://mstdn.nere9.help/@orange_in_space/100847563178619470

これに書いたような事も電子回路学んでたらすでに出来るよね＞＜ 電子回路でも同様に必要な考え方だし＞＜ でもそういうのが全く無い人には当たり前だけど全く無い＞＜
https://mstdn.nere9.help/@orange_in_space/100852694112700581

そういうのもそうで、ロジック回路でデジタルの基本を学んだ上でならプログラミングで同じ事する時の文法も楽に覚えられるかも＞＜ 丸暗記なんて事にならずに＞＜

オレンジ的にはそこ全く逆に考えてて、その文脈上の文法、つまり概念を理解する前の文法って丸暗記でしかなく、当人にとってなんも意味もない文字列なんだから覚えられなくて当然かも＞＜
だからこそ、概念を先に理解する必要があって、概念を理解するためには考え方そのものが必要かも＞＜

このアカウントは、notestockで公開設定になっていません。

例えば、必要な作業はなにか？とか、何々を作る時には何が必要か？みたいなの、プログラミング出来る人々なら当たり前に考えられる考え方だけど、プログラミング出来ない人って、その発想がない人それなりにいるし、そういう人にいきなり直接プログラミングを教えてもついていけなくても当たり前かも＞＜

なので、オレンジが「(この人をプログラミング出来る人にしよう！＞＜；)」って思った時には、プログラミング直接教えるより前に、まず考え方を変えるように誘導する事多い＞＜

ていうか、プログラミングをできるようにするって、その人に技能をつけるんじゃなく、その人の考え方をまるっきり変えさせるに近いと思う＞＜
それほど難なくプログラミング出来る人になる人は、元からプログラミング出来る人に近い考え方をを持っていて、そうではなくプログラミングを学ぼうとすると落ちこぼれ気味になりやすい人って、元々の考え方がプログラマ的な考えからかなり遠くにあるんだと思う＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

行き先が多種多彩なのにラインカラーを重視してない交通機関は、麦茶とコーラとめんつゆが走ってるようなもの＞＜

例えば、砂糖と塩を間違える人はネタで言われるほどには発生するけど、砂糖とワサビを間違える人はあんまり居ない＞＜
麦茶とコーラとめんつゆの間違いは聞くけど、めんつゆとオレンジジュースを間違えたって話はそれほど聞かない＞＜

慣れでぼーっとしてる時にでも間違いに気づけるように作ってこそ、ヒューマンセンタードデザイン＞＜

旅客「案内」上重要＞＜
例えば、目的の駅を路線図で見た時に水色の線が通っていて、現在居る駅にも水色の線が通っていてつながっていれば「水色の電車に乗ればいいのか！」ってわかる＞＜

このアカウントは、notestockで公開設定になっていません。

そういう意味で、湘南新宿ライン＆上野東京ラインって、案内のデザイン上めちゃくちゃだよね＞＜ 運用上どうにもならないけど＞＜
上野東京ラインが出来る前でも高崎線と宇都宮線を間違えて戻る人見た事何回かあるし＞＜

行き先が限定されるのならそれでも何とかなる＞＜ 例えばhoge駅に行きたいのならばfuga行きに乗ればいいみたいな＞＜
でも、fuga行きかpiyo止まりかnantoka乗り入れかkantoka直通かどれかみたいな事になると、地元民以外にはさっぱりわからない＞＜

このアカウントは、notestockで公開設定になっていません。

あと微妙に関係ないけど、相鉄の最近のヨコハマネイビーブルーの車体色、誤乗防止はもちろん安全のデザインとしてどうなの？＞＜って謎＞＜
あれって、視力低い人でも車両があること判別できるの？＞＜

逆に、大阪環状線乗り入れの列車があれほど多種多彩なのにラインカラーちゃんと重視してないの、デザインとして微妙だと思う＞＜

東京での（電車線での）車体色で誤乗防止、はじまりは、旧国電（省電）時代の山手線と京浜東北線との誤乗防止だったはず＞＜

このラインカラーの話、ある程度東西差もあると思う＞＜ 東京は歴史的経緯でラインカラー重視してる事業者多い＞＜（車体色を誤乗防止の要素として重要視してる） 大阪の場合はラインカラー重視してるの地下鉄くらいかも＞＜