山本強
あるとき、某社の社長のすすめで、戯氏とともに北大大型計算機センターの山本先生の部屋を訪ねた。
ＳＧＩのアイリスのデモをしながら、先生が私達に一つの質問をした：
「ユーザーインターフェースの本質は何だと思う？」
私は「寛容性でしょうか？」と答えたが、
先生は「速い事だよ。」と言った。
今考えると、寛容性（ユーザーが理解に苦しまないという事）も、結局は速いという事に含まれているように思える。--CUE
＃↓のっけからクタリングきぼん。なんて名前の頁に書いたものか自分でも判らんくなったので、とりあえずここに。
今ふと考えたんだが。
「速い」のがいいということは、未来が先取りできればもっと良いということだよな？(暴論
今の(G)UIの何が馬鹿だって、ユーザの操作イベントが「どの」UIオブジェクトに食われるかが、ハッキリしない点。
ユーザ操作の真っ最中に窓がしゃしゃり出て、ユーザが或る窓へ入力してるつもりだった情報を
掠め取っていく、なんてことが茶飯事だ。これは困る。
Unix系のCUIがその破綻を滅多にきたさない。
理由は、イベントの入り口が唯一であり、かつ入力と出力が下手にマルチスレッド化されてない(ことが多い)ので、
もしプログラムの中にUIオブジェクトが有ったとしても(cursesを使ったりすれば、そういう状況は珍しくない)
操作と出現、つまりイベントの生産と消費、の順序が狂ったりしないからだと思う。
バッファリングされた入力は、「ユーザにとって判っている」UIオブジェクトへ、(常に)向かえばいいのだ。
それが既存インスタンスだろうと未出現インスタンスだろうと構わない。ユーザが「わかって」いればいいのだ。
で、それ(特に未出現に対する操作)ってつまり、未来の予言では？(^^;
実際Unixのテキスト画面だと、しばしば「先行入力」をやっちゃうんだよね。
まだ出現してないUIに対してキーを打ち込む。そしてそれで問題なく動く。
ところで人間って、理解するために予言(正確にいえば予測)もするよね。
その予想を裏切らないUIはつまり、予想に対して寛容(というのもなんだが)なのでは？
今のGUIは、予測を裏切(り得)るから、駄目なんだと思う。
そして、裏切ってないように見せたいがために、ユーザが入力「したいと思う」より先にUIを見せる、つまり速度を上げる
ってのは、いささか不毛なやりかたなんじゃなかろうか？と、ふと思った。
だって、どう考えても、きりがないもん。--戯
少なくとも「春風」の柳生(だっけ)の爺さんを斬れなかった「電光石火」の宮本武蔵くらいに、不毛だと思う。
柳生の爺さんはつまり、「速度を上げる以外の方法でも、予測を完全に近づける方法は、あるよ」と
言っていたんじゃなかろうか？
UIに限っていえば、Unix CUIの「バッファリングと、厳密(?)な順序性」は、我々計算機野郎にとって大きなヒントになると、俺は思う。
＃先生のあの話に対してずっと感じていた違和感は、これだったんじゃないかな＞俺
余談：スポーツ工学とUI工学って、合体しないのかな？
ヘビーな話は置いとくとしても、少なくとも、ユーザの手を奪う位置＆タイミングで出る(Modal)Dialogは
やばい存在だ…ってのは十分に既知なのだったよね。
そりゃそうだ。リアルワールドでも「邪魔すんな」という言葉は有るわけだし。
よしんば邪魔するのが適切だと判断された場面だとしても、
邪魔される手が邪魔する手に「触れた瞬間」にいきなり、その後の行動の選択が確定してしまう恐れが有る
(DialogにY/Nボタンが表示されてることを比喩してまーす)んじゃ、それはまともな邪魔ですらない。
ん。するとDialogつーか邪魔オブジェクトに本来必要な機能は、Y/Nボタンを出すことじゃなく、
「ちょっと待て」とユーザの操作を「止める」ことなんだろうな。
もちろんY/Nの選択をさせるなんて論外(それではY/Nを押すという操作を「進めさせた」ことになってしまうので)。
本当に「止める」ことが必要だろう。
うーん。そうすると、操作を再開するための操作(^^;をどう定義づければいいのかが謎だが。
あと上記のような意味で先行入力を許すシステムならば、先行入力を捨てちゃう仕組みも必要だろう。
ん？すると、どこまで入力を受け付けてくれたか？をユーザにFeedbackする仕組みも、要るかな？
こりゃ結構大変かも。判りやすい形でFeedbackできるんだろうか？
リアルワールドでも(^^;このFeedbackはしばしば存在しないので、諦めるって手も有るかな。 -戯
このページを編集 (3715 bytes)
 |
以下の 1 ページから参照されています。 |
This page has been visited 4687 times.