国民宿舎はらぺこ 大浴場

ざっと読み終えた感想。。。概ね同意できるのですが、些か卑屈すぎるような気もしないでもなかったり。。。

マーフィーの法則にこんなのがある。

It is impossible to make anything foolproof because fools are so ingenious.

(誰でも正しく扱えるもの — Fool-Proof — を作りあげるのは難しい。何故ならバカは思いも寄らないことをしでかすことができるからだ。)

まぁこういう事ばっかり逃げ口実に使うのは良くないことではあるのですが、人間が完全にミスを犯さないでいられることが不可能であるのと同様に、人間に完全にミスを犯させないでいられるようなシステムを作ることもまた、不可能なのです。

なので、できるだけミスを誘発せずに済むような UI を開発しようとすることは確かに正しいことではあるのですが、想定しうるミスのすべてをシステムがカバーすべきか否かは、他の不具合を混在させる可能性の影響範囲を十分に考慮した上でのトレードオフであるべき、とは思うのですよ。

もちろん、プログラム設計に自信があって、十分なテストが行われる時間も用意されているのであれば、できる限りのことを実践してみるのも悪くは無いとは思うのですが。

図1 ミステーク「インターネットバンキングはここからログインするんだな」

ﾜﾛﾀ。これはひどい。。。　あ、図はリンク先の記事を辿って見てちょ。

でも Web サイトの場合、本来のメインコンテンツではなくて新規の追加コンテンツに誘導しようとしてこういうことやっちゃうサイトってのはよくあるやね。あと、ユーザー側が勝手にメインコンテンツだと思っていたものとは違うものに製作者側が誘導しようとする場合とか (Real.com とかな)。まぁ、その場合は UI が製作者の意図通りに動いているわけだからまったく問題ないわけだけんども、目先の利益のためだけにユーザーの利益を損なうような UI デザインはさすがに NG よね。

スタンドアロンの場合は好例が思いつかんけど。。。最近の通信カラオケの高機能なリモコンなんかは番号入力と検索のメニューが同列になってて時々操作を見失うことはあるかな。

さまざまな状況から各コントロールの有効性を判断してJavaScript などで動的にイネーブル／ディスエーブル表現を切り替えるのはなかなか大変ですが、GUIの基本的な作法の1つとして、またエラーを発生させないための工夫として、取り組んでいくべきだと思います。

Javascript デスカ。あんまりこの辺の UI 制御で多用してしまうのもどうかと思ってしまうのですが。。。

ボタンについては、disable すべきシチュエーションというのは、そのボタンによって送信されるフォームにおいて、必須項目の入力が満たされていない場合か (この場合は満たされ次第 enable にする)、あるいはごく一定の時間のみデータの送信を行わないようにしたい場合、のどっちかになると思う。後者は、例えばチャットで、メッセージを送信してサーバーからの応答待ちになる場合、サーバーからの応答が得られるまで続けてのメッセージ送信をさせたくない場合、とか (はっきりいってそんな実装にする必要はまったくないと思うけどね)。

で、ボタン以外のコントロールについては、enable/disable 制御を行う場合、さまざまなシチュエーションが考えられるわけだけど、これの実現については、まぁ、優先順位はそんなに高くは無いと思う。入力項目を disable する、というのは、その項目については入力する必要が無いことを示す、ということ。確かに親切設計ではあると思うんだけど、サーバー側のプログラムがまともに作られていれば、多くの場合、「間違えて入力されちゃった」というヒューマン・エラーは大きな損害にはなり得ないからね (個人情報を求めるようなケースでは微妙なところだけど)。

いろいろなWebアプリケーションを見ていると、多くのフォーム画面にクリアボタンが配置されています。しかしよく考えてみてください。その画面にクリアボタンは本当に必要でしょうか？ 単に「フォームにはクリアボタンを配置するもの」という理由のない慣習からそうしているだけのケースが多いようです。HTML で簡単に作れてしまうのも原因でしょう。

多くの Web 技術関連書籍で、サンプルプログラムなどにおいて当たり前のようにクリアボタンが用意されていたりするのも原因だと思う。「それが Web アプリにおけるフォーム様式の慣例だ」という誤解を広める役には十分立っていたんではないかな。この手の「出せば売れる」技術参考書ってのはダメプログラマーを量産する役にしか立っていないからな～。

ここで注意しなければならないのは、ユーザーに提示される選択肢はすべて有効性が確保されていなければならないということです。先述のとおり、現在の状況からユーザーにとって生産的な意味を持たない選択肢は隠す（またはディスエーブルにする）必要があります。ところが現実には、無効な値を選択できてしまう制限コントロールを多く目にします。例えば、チケットなどの予約をするシステムで、過去の日付や「2月31日」といった存在しない日付が選択できてしまうなどです。1つの画面内にいくつかの制限コントロールがあって、あるコントロールの選択項目に応じて別のコントロールの内容の有効性が変わってしまう場合には、JavaScript などで「有効な選択肢だけが見える」ように動的に選択肢を制御しなければなりません。これも徹底して実装するのはそれなりに大変なことですが、「選択できる項目はすべて有効である」というシステムの信頼性を保つために、できる限り努力することが望まれます。

だからさっさとカレンダーコントロールを実装しろと。＞ブラウザベンダ

はっきり言って、コンボボックスで 31 個もある項目から一つを選択させるという UI 実装は便利じゃないんだよね。だからおいらから言わせてもらえばここはがんばるべきところではない。フツーにテキストで入力させちゃったほうがよっぽど便利だし、送信する直前に Javascript でチェックして再入力を促す程度でもそんなにストレスは無いと思う。

カレンダーコントロールもどきを Javascript で作ってしまうという手も。。。できるのかなぁ (^_^;

「ユーザーは間違えない」ということを前提にシステムをデザインすることは、開発者にとっての大きな挑戦です。それはエラーメッセージの廃絶を目指すことであり、プログラムをクラッシュから防ぐというもう1つの責任を果たすためのハードルがさらに高くなることを意味します。しかしこれはとても価値のある挑戦でしょう。極度な専門技能を要するシステム開発の世界において、実質的な意味でユーザーのことを守ることができるのは開発者だけだからです。

。。。。。。有用な車輪は共有しようぜ (-.-)ﾎﾞｿｯ

・有効値の範囲を広げる。

上記の方法はエラーを防ぐための一般的な考え方ですが、ユーザーからすれば、可能な操作が一方的に制限されるという意味であまり気持ちのよいものではありません。理想は、ユーザーの動きを制限するのではなく、システム側の動きに柔軟性を持たせることです。そのためには、有効値の範囲を広げて、ユーザーができるだけ好きな書式で入力できるようにします。

簡単なところでは、「半角を全角に」「ひらがなをカタカナに」「ハイフンやスペースなどを消去」といった文字列処理をシステム側で行い、ユーザーがそのような制約を気にしなくても済むようにします。よく電話番号などのテキストボックスに全角数字で入力すると、「電話番号は半角数字で入力してください」といったエラーメッセージが表示されますが、どうすればよいのかをシステム側が知っているのなら、それはシステム側が行うべきなのです。

書式についての但し書きがないフォームに値を入力するのって、逆に不安を覚えるけどな (^_^; 。そこまでシステムに信頼を預けられるユーザーって。。。いるんだよねでもｗ

ちなみにバグがもっとも混入しやすい処理ってのはまさしく文字列処理でございまして、バグの混入を回避する設計指針として、できる限り文字列処理を減らすという手法は結構有効だったりするわけなんですけれどね。特に最近流行りの PHP みたいなステートメントがビルトインな言語で文字列処理やるのはホネでしょうなぁ～。まぁ、Perl で正規表現のほうがバグ混入率はむしろ上がるんだけどねｗ。

目的を達成するためにユーザー自身によって確実に判断してもらわないと後でユーザー側にリスクが発生するような入力項目では、安易なデフォルト値は設けない方がよいでしょう。例えば、ショッピングサイトのユーザー登録のフォームなどで「今後メールニュースで最新情報を受け取る」というチェックボックスにデフォルトでチェックが入っていたり、支払い方法を選ぶラジオボタンで「提携クレジットカードで支払う」といった有料のオプションがデフォルトで選択されていたりすると、後になってユーザーが困る恐れがあります。

いやだからそれは運営側が狙ってやってるんだってば（とかゆｗ）。メールニュースなんてデフォルト ON がむしろ常識じゃね? つか、ﾃﾗｳｻﾞｽｗｗｗｗｗ

図8 必要な項目の再入力をお願いする画面

これまた卑屈極まる。。。ｗ

個人的に、システムが低姿勢である必要はあんまりないと思うんだけどなぁ。メッセージは丁寧であることよりも、簡潔かつ明瞭であることのほうが重要だと思う。

このような「システムがインテリジェントに作業を補助する」動きは、やり過ぎるとかえってユーザーを混乱させるからです。

そしてさりげなく MS-Office 批判。抜け目無ぇなあｗｗｗｗｗｗ

んで、最後に。Web アプリの場合、必ずしも入力が、システムが出力したフォームを介して行われるとは限らないので、UI 部分について極力エラーを出さないように設計したのだとしても、サーバ側においては異常系の処理をしっかり実装することは肝要だったりするのであります。

当たり前ですか。当たり前ですね。

でも結構、これ、見落とす開発者多いんだよね。

「フォームで制限しているんだからこういう値が入ってくることはないでしょ」なんつって。

頼むから http の仕組みから勉強しなおしてくれ、って感じで。