安全じゃなさそう＞＜；
orange
さんがブースト
モード表示、端っこに小さく M03 とか出てる（そしてそれが20個ぐらいある）のを確認しないと駄目だって話する？？？？？
orange
さんがブースト
まずリアルタイムな操作を要求するのにモーダルでステートだらけでしかもそれが目視で確認できない悪意のあるUIなマシニングセンタの話する？
これもオレンジが言ってる旅客機のコクピットのモードの問題に近いかも＞＜
ユーザーが混乱しないためにモードを持つのはむしろおkで、モードが多すぎてユーザーがかえって混乱したりユーザー認識と機械側のモードの齟齬が発生したりするのは、航空事故調査とかで言われてるように危険かも＞＜
orange
さんがブースト
「vi こそが “本物の” エディタである」みたいな言説で好きなのが「キーを押すと即座に対応する文字が出るのは typewriter である。真のエディタは edit するものなのであって、キーを押すとデフォルトでは対応する編集操作が実行される vi こそが真のエディタであり、他のものは第一にはエディタではなくタイプライターであるといえる」みたいなやつ (うろおぼえ)
orange
さんがブースト
「コントロールが暗黙の状態を持たないこと」みたいな意図で stateless と言いたいわけだけど、逆にコントロールが自身と関連付けられた状態を明示的に表現しているという点ではむしろコントロールは state をはっきり持っているように見える、という命名と実態のギャップが悩ましい
オレンジは、「(主に航空関連ではたぶん主流な)モードはなるべく少なければ少ないほどよいって発想では無かったりする」けど短く説明するの難しい・・・＞＜(オレンジは、サンフランシスコの事例をもとに考えれば、操作する人が混乱/状況の混同するミスを避ける助けになる場合には(見かけ上の)モードをわけるべきって発想＞＜)
orange
さんがブースト
そういうのはリアルタイム性がどうとかの別要素の方が支配的な気がする
ボタンが多い方が簡単だよ方式のUIって例えばアナログモデリングシンセやハイテク旅客機のコクピット＞＜
重要なパラメータは一対一でインジケータ付きスイッチやらツマミやらが用意されてる＞＜
あと、なにかテキストタイプしてる時以外は無意識に手の位置がFPSの位置になっちゃってる事かなり多い＞＜；(左手WASD右手トラボ＞＜；)
こういう風に絞り込みの場面でキーボード使うことはオレンジも多いかも＞＜；
一方でオレンジはマウスというかトラボに手が移動することを苦に感じないかも＞＜
代わりに(？)GUIでの操作時に何ステップかかるかはかなり気になるし、深すぎるGUIってかなり嫌い＞＜
(ボタンが多い方が(モードが減るので)操作が簡単だよ主義でもあるし＞＜)
orange
さんがブースト
orange
さんがブースト
コントロール面に関しては「なんでテキストでできることをわざわざ『位置』の問題に変換するの？」という気持ちが強いですね。
プレビュー面に関しては、昔からそういう仕組みはあるしそうしたいならそうする、くらいしか。
orange
さんがブースト
これはディスプレイレイアウトを選択する用のスクリプトの実行例なんだけど、たとえば右だけ使いたいときは <M-c>nun<C-m> したり、両方使いたいときは <M-c>uun<C-m> したりする。上下キーや C--p / C-n での選択はしない。
よくわかんないけど、たぶんそのスライドバーが小さすぎるのかも？＞＜；
orange
さんがブースト
クリックで目的値に行ってもそこを問題にしているわけではなくて、結局そのあとの微調整で左右に揺らすので……
ツマミを掴む事を要求する方式のスライドバーはオレンジも嫌いかも＞＜
自分で実装する時はクリックした(というかボタンを押した)場所の値にまずなるようにしてる＞＜
orange
さんがブースト
ボリュームコントロールとかもそうなんだけど、マジで「スライダーを狙った位置に持っていく」ののストレス半端ない (マウスカーソルの感度の話はしてないよ)
ちょっと違うけど、メディアプレイヤー系のの物でダイレクトに操作できるシークバーが無いものを使うのもわりと耐えられない＞＜；
あと長すぎる時間に対してバーが短いシークバーもものすごくストレス＞＜(youtubeの長時間動画とか)
オレンジが前に作って使ってた動画用のメディアプレイヤーは、シークバーが全体表示とスケール固定の物が2段並んでる方式だった＞＜(15年くらい前なので細かい仕様忘れちゃったけど)
- ＠orange_in_space
2017年 4月に登録
