Ars Technicaに関する最近の記事では、ノースカロライナ州立大学の心理学科が実施した最近の研究について説明しています。この研究では、ユーザーは、ダイアログ ボックスを取り除くために必要なことは何でもして、目の前のタスクに戻る傾向があることが示されました。それらのほとんどは、表示されているメッセージに関係なく、[OK] または [はい] をクリックするか、ダイアログを最小化するか、ダイアログを閉じます。表示されたダイアログ ボックスの一部は本物で、一部は偽物でした (ウイルス対策の警告を装った Web ページで表示されるポップアップなど)。応答時間は、これらのユーザーが実際にはダイアログ ボックスを読んでいないことを示しています。
では、これを知った場合、これはあなたのデザインにどのような影響を与えるでしょうか? また、それに対して何をしようとしますか (もしあれば)?
私は、誤った操作 (間違った場所をクリックするなどの不注意な操作) や間違い (ダイアログで [OK] をクリックするか [キャンセル] をクリックするなどの認知エラー) に直面しても堅牢なアプリケーションを設計しようとしています。これを行ういくつかの方法は次のとおりです。
これは、(1) 防御的にプログラムすること、および (2) できる限りユーザーに情報を提供し続けることの 2 つの核となるものに要約されます。システムのインターフェイスが使いやすく、期待どおりに動作する場合、煩わしいダイアログが表示されたときにどのボタンをクリックすればよいかを理解する可能性が高くなります。
また、私はモーダルを回避するために非常に一生懸命努力しているので、少なくともしばらくの間、ユーザーは私が使用しなければならないほとんどのダイアログを無視できます (そして、ユーザーが本当に注意を払う必要がある場合、何をすべきかを知るのに十分な情報があります)それ）。
システムを完全に絶対確実なものにすることは不可能ですが、上記の手法が正しい方向に大いに役立つことがわかりました。(そして、サプライズ説明報酬の開発に使用されるシステムや、広範なユーザー調査によって精査されたその他のツールに組み込まれています。)
まず、色とアイコンを使用することで、ユーザーが問題の深刻さを視覚的に認識できるようにする必要があります。赤は例外を、黄色は警告を、白は情報を伝えます。
第 2に、ダイアログ ボタンで動詞を使用すると、ユーザーがダイアログのテキストを読まなくても、システムに何をするように指示しているかがわかります。
最後に、まったく異なる通知パラダイムに関心がある場合は、Firefox と Internet Explorer に実装されている情報バーまたは通知バーを確認してください。StackOverflow は、同じタイプのメカニズムを使用して、ユーザーが新しいバッジを取得したときに通知します。
情報バーは邪魔にならず、画面の上部に留まり、ユーザーの注意を待ちます。素晴らしいデザインの比喩だと思います。
以下に、いくつかの実装チュートリアルを示します。
ダイアログのデザインに関する Microsoft のガイダンスは、情報バーの概念にも触れています。
すぐに、Steve Krug の本Don't Make Me Thinkが頭に浮かびます。
ダイアログ ボックスやユーザーに返されるステータス メッセージなどのデザインでは、単語が実際に何を言っているのかについて、図像や色のヒントを使用することをお勧めします。
そのため、エラー メッセージを赤、警告を黄色などで強調表示します。
JefRaskinによるHumaneInterfaceは一読の価値があります。ダイアログボックスは最後の手段であり、デザインが不十分であることを示しています。ほとんどは不要であり、あなたが発見したように、すべてユーザーによって無視されます。
ダイアログボックスがあるのはなぜですか？その問題を解決します-操作を確認するようにユーザーに依頼するのではなく、操作を簡単に元に戻すことができます。エラーを通知するダイアログボックスをポップアップしないでください-とにかく（または可能なことは何でも）実行しようとしている回復を実行してください。結果が1つしかないダイアログボックス（「OK」のみのボックスは悪魔です）は絶対に表示せず、アプリ内の情報を目立たないように表示します。
.NET Rocksのエピソードが頭に浮かびます (エピソード 338、"Mark Miller on the Science of Good UI"だと思います)。) はまさにこのトピックについて説明しています。この議論全体の鍵は、これが行き過ぎた基本的な UI デザインであるということだと思います。モーダルは、かつてはコミュニケーションの手段として受け入れられていましたが、今ではプログラミングの失敗作になっていることがわかります。ユーザーは、10 分の 6 の情報が、心配するほど適切ではないことを理解しています。その結果、彼らはすべてのモーダルを同じように扱います - 学習した無力感。モーダルが表示され、アプリケーション エラー X が発生したことが通知され、クリックできるのは「OK」だけです。私はモーダルを、おそらくあまりできないという考えと結びつけていますが、OK/はいをクリックすれば、必要なものに戻ることができます。
では、なぜ今でも使われているのでしょうか。おそらく開発者は、アプリケーション開発が単なる基本的なインターフェース以上のものになりつつあり、ユーザーが流動的な UI デザインを必要としているという事実を避けようとしてきたのでしょう。
ここで重要なのは、優れた UI デザインは、中断が (最も初心者のコンピューター ユーザーにとっても) 煩わしいものであることを示していることを理解することであり、アプリケーションの焦点がユーザーであるシームレスなユーザー エクスペリエンスを実現するよう努める必要があることを理解することだと思います。プロンプトとエラー報告によるアプリケーションのニーズ -- ユーザーが気にしない状況に陥ることを許可しないでください。
いくつかの提案
多くの場合、開発者はモーダル ダイアログ ボックスを使用します。これは、単純にコーディングが簡単だからです。
ただし、非モーダル通知は、多くの場合、ユーザーが処理するのにより便利です。
1 つの提案:
難しいこともあります...ファイルを開くときはどうしていますか？簡単な場合もあります...ファイルを上書きしようとしていることをユーザーに警告する必要がありますか? やみくもに [OK] をクリックしていると、警告にまったく耳を貸さない可能性があります。
ダイアログを使用する必要がある場合は、ダイアログ内のボタンに説明的なキャプションを付けます。
たとえば、[OK] ボタンと [キャンセル] ボタンの代わりに、"請求書を送信" や "戻る" など、ダイアログのコンテキストに適したものを使用します。
そうすれば、テキストはカーソルのすぐ下にあり、理解できる可能性が高くなります。
Mac OS X はほとんどの場合これを行います。 これが画像の例です。
編集：
これはより良い画像で、私は Apple Human Interface Guideline サイトで見つけました。これは素晴らしいリファレンスであり、非常に読みやすいものです。 そのサイトのこのドキュメントは、すべてダイアログに関するものです。
間違った質問です。「ユーザーをどのように処理しますか」は、間違った端から始まります。
正しい質問は、「ダイアログが目の前のタスクからユーザーの注意をそらすことを考えると、より良い代替手段はありますか?」です。
目標を達成するため、またはタスクを完了するために作業する場合、次の 3 つの状況を区別できます。
(1) アプリケーションは、ユーザーが目標を達成するために実行できるアクションはないと結論付けます。メッセージをポップアップ表示し、1 つのボタンで閉じることができます。とにかく結果は重要ではないので、読者がそれを理解しているかどうかは気にしません。
(2) 実行できるアクションが 1 つだけである、または代替手段がユーザーにとって無関係である。彼をまったく気にしないでください。
(3) 目標を達成する方法が 2 つ以上ある。ユーザーがこれらの中から選択できるようにします。これをはい/いいえの質問として定式化しないでください。(Vista では、メッセージ ボックスを置き換えるために、これを共通のダイアログ ボックスとして提供しています。) 可能な限り、これを元に戻せない選択にしないでください。
このルールの例外は、ユーザーがyes/no の質問を期待する状況です。しかし、もしそうなら、質問が通常のワークフローの一部ではないのはなぜでしょうか? ダイアログ ボックスは、通常のワークフローの外にあります。
ダイアログを使用する必要がある場合は、ユーモアを交えた同情的または風刺的で非常に短い説明テキストでユーザーに報酬を与えます。ときどき、ばかげたスキャンダラスなものを配布すると、すべてが読まれます。
ユーザーの常識は危険なほど低下しています。このユーザーを削除して、別のユーザーを挿入してください。
私が開発に多くの時間と労力を費やしたものを読まないユーザーには、ほとんど我慢できません: 1) アプリケーション 2) 説明書 それ以外は、読まないで「必要なことは何でも」実行するだけなら、あなたはあなたです自分で。私はそれを前もって述べます。私は自分のアプリケーションをできる限り直感的に使えるように設計していますが、それでも、子供が教室でふらふらしているのと同じように、突然サポートの電話をかける人がいます。私はそれに対して寛容ではありません。マニュアルを読み、ダイアログを読みましょう - 問題の 99% に対する答えはすぐそこにあります。
できることの 1 つは、OK ボタンを 3 秒間無効にすることです。
拡張機能をインストールすると、Firefox はこれを行います。
編集：わかりました、一部の人々はこれを面倒に感じています。まだ1秒くらいでいいと思います。それは、人々（私を含む）が持っているインスタントOKクリックの本能を抑制し、ダブルテイクを強制します. もちろん、会話が実際に読む必要がないものである場合、これでも人々を悩ませます。
この論文をお読みになることをお勧めします: 「Impact of High-Intensity Negotiated-Style Interruptions on End-User Debugging」、TJ Robertson、Joseph Lawrance、および Margaret Burnett 著、Journal of Visual Languages and Computing 17(2)、187- 202、2006 年 4 月。
それは同様の質問をしました。その結果、注意が必要であることをユーザーに知らせてから、座ってユーザーの応答を待ちました。ただし、ユーザーの邪魔をしないでください。それはユーザーが望んでいることではありません。
[Lightbox]( http://en.wikipedia.org/wiki/Lightbox_(JavaScript))モーダル ダイアログは、場合によっては効果的な手法のようです (Web 2.0 からの派生ですが、他のコンテキストでも実装できます)。
もう1つのポイント：元に戻す機能のダイアログボックスを忘れることができる場合（Gmailは、この概念を標準のWebアプリケーションの動作として支持しました）、それは考慮すべきことです.
上記の多くの良いアドバイス。本の推奨事項に追加したいだけです - Joel Splosky の「User Interface Design for Programmers」という本は読む価値があります。
確認は使用せず（よろしいですか？はい/いいえ）、元に戻すを使用してください。
ユーザーはメッセージを無視してクリックするだけで、できるだけ早く作業を再開しようとするため、ブロックされる警告をポップアップ表示しないでください。InternetExplorerの情報バーのようなブロックされていないものを使用します。
ダイアログボックスを一緒に使用することを避けることができます! 一部のプログラムには、エラーと警告を表示するミニバッファーがあります。それに加えて、やりたいことを入力する必要がある場合もあります。それは非常にクリーンで優れたソリューションです。私はメニューバーよりも好む傾向があります。
ただし、どうしてもダイアログ ボックスを使用する必要がある場合は、次の方法を試してください。
ダイアログ ボックスについてどう思いますか? 一言で言えば、それらは愚かで愚かなものです。それらを使用するプログラムは私の邪魔をし、ばかげた無意味な質問で私を遅らせます. また、多くの場合、ダイアログ ボックスを使用するプログラムはかなり馬鹿げています。
ダイアログ ボックスの最後に多肢選択式クイズを含めます。ユーザーは、テキストを実際に読んで理解したことを示す回答を選択する必要があります。選択肢の順序をランダムに切り替えて、常に同じものをクリックしないようにします。
文言とダイアログの仕組みを変更すると役立ちます。たとえば、[OK]/[キャンセル] ボタンがあると、ユーザーはほとんどのダイアログを無視できるようになります。通常のボタンを削除して、より長いコマンド リンクに置き換えた場合、ユーザーは各ボタンを読む可能性が高くなります。
まず、バカは痛いはずなのに、普段はそうじゃない…
次善の策は、問題の深刻度を伝えようとするアイコンを含めることです。ダイアログのアイコンが不吉に見える場合、読まない人の何割かは習慣を変えるかもしれません。何パーセントかは読まない。
私はこれを「オートパイロット」問題と呼んでいます。
