Notices by orange (orangeinspace@mstdn.nere9.help@mstdn.nere9.help), page 32

でも、マストドンのGUIデザインのダメな所殴って修正版作ったらオイゲンさんめちゃくちゃ凹むと思うよ＞＜ ていうか、そういう指摘に耳貸せず凹むタイプが一番UXデザインに向いてないけど＞＜

マストドンのGUIデザインも「どうすればいいのか？」の情報がほぼ無い＞＜ なにが出来るという情報しかないし、それですら「なにが出来ない」という形式になってたりする＞＜

RustやHaskellが初心者向きかは置いておいても、「じゃあどうすればいいんだよ？」に答えていないエラーメッセージは初心者に優しくないというかそもそも人間に優しくないよね＞＜
「○×△ёエラーです」とかいわれても「だからどうした＞＜」になっちゃう＞＜

そうすれば、土木構造物の大半をそのままに、信号システムを弄る事で、現在の編成有効長よりも長い有効長にして、その分をノーズの延長に使うって出来そうな＞＜
(車両基地とかはギチギチだろうけど＞＜；)

ふと思ったけど、新幹線って路線かなり限られてるし、現在の16両(や各区間の)の編成長の外に「ノーズ分編成長」みたいなのを信号システムに追加して長くするって出来ないのかな？＞＜
例えば、実際の車両の先端からhogeメートルの位置を信号システム上の先端にして、ATCの境目とかポイントの接触限界の情報を別に持たせて、例えばホームからノーズ部分を飛び出させて停車させる　みたいなの＞＜

なんかそういう未開の部族の言い伝えを調査する時に、20世紀以降の接触の記憶や別の調査グループが来た時の出来事も言い伝えにすぐ混じっちゃって、混じったまま大昔の言い伝えとして証言するから全然歴史の調査にならなくなっちゃうみたいななんかそういうの読んだ記憶が＞＜

orange_in_space、_が使えない事がある問題と、文字数制限で使えない場合がある問題がある＞＜

orangeはだいたい既に使われてますになってるけど_in_spaceは空いてる＞＜

開発環境の紙の分厚い説明書とか、読むとこんなことも出来るのか！＞＜ってわくわく感があったよね＞＜ あとDelphiについてきたライブラリの構造のポスター（？）とか＞＜

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

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

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

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

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

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

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

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

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

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

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

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