警告や問題についてユーザーに通知する必要がある場合があります。しかし、多くの場合、特にそれが一般的な問題である場合、ユーザーは警告を無視して続行します。多くの場合、ユーザーは警告を見たことさえ覚えていませんが、ログを確認すると、いくつかの警告が表示されていることがわかります。では、何か重要なことをユーザーに伝えようとしているときに、どうすればユーザーの注意を引くことができるでしょうか?
これは、保存を許可する前にすべての問題を解決するようユーザーに強制するほど単純ではありません。多くの場合、さまざまな理由 (通常、すぐには解決できない問題、またはまったく解決できない問題) で、ビジネス ルールによって厳密には許可されていないデータを保存する必要があります。
私たちはより良い警告/エラー処理システムを念頭に置いていますが、それは大いに役立つと思いますが、他の人が何をしたかを見たいと思っています.
ユーザーに警告に注意を向けてもらいたい場合は、適度に使用してください。
Vista の UAC の大きな問題は、あまりにも多くの通知を受け取っているため、誰が何へのアクセスを要求しているかを正確に読み取るのをやめてしまい、何も考えずに許可を与えることです。
もう 1 つの例は、ファイルをごみ箱に送るときのエクスプローラーでの削除確認です。「削除」を押した直後に「OK」を押すことに慣れすぎて、何らかの理由でファイルがビンに移動されず、すぐに削除されるというダイアログが表示されていたという事実を見逃していました。
私の個人的な修正: ごみ箱の削除確認を無効にしました。何かをビンに移動できない場合でも、メッセージが表示されます。今回は、それが重要である可能性があることがわかっているので、注意を払います。
結論:ユーザーに大量のメッセージを送信しないでください。そうしないと、重要な警告が雑音に紛れてしまいます。
警告の品質によって、ユーザーが無効なデータを送信するのを防ぐことはできません。無効なデータの送信を許可すると、無効になります。
ルール システムに送信する必要があるデータがある場合、そのデータは送信前に有効である必要があります。ただし、ユーザーが作業を保存できるようにすることは別の問題です。ユーザーが作業を保存できるようにし、データが有効になったときにルール エンジンに送信する必要があります。
基本的な問題は、ユーザーが読むのが好きではなく、仕事をするために一人にされたいだけだということです:)。
これに対抗する最良の方法は次のとおりです。
長いエラー/警告メッセージは単に読み取られません。ユーザーは5番目の単語に到達し、「これには時間がかかりすぎます。仕事に戻りたいだけです」と思います。
私のアドバイスは3つに要約されます。
必須データを含むフォームがある場合は、フィールドを赤で色分けするか、アスタリスクで強調表示して必須であることを示します。すべての必須フィールドに入力するまで、[OK] または [確認] ボタンを無効にします。
データが不完全または一貫性のないフィールドの場合は、ツールチップを表示するか、フィールドを色分けして、何か問題がある可能性があることをユーザーが認識できるようにします。フォームのどこかに目立つように警告のリストを表示することもできます。ただし、データ入力を停止しないでください。ユーザーを苛立たせ、怒らせるだけです。
私はあまりにも頻繁に [OK] をクリックしたり、何も考えずにダイアログが消えるように条件付けられた操作を行ったりしていることを認めなければなりません。通常、これはそれらの数が多すぎる場合に発生します。
心理学者であると主張するつもりはありませんが、異常なことに注意を払い、繰り返しのことを除外するのは自然なことだと思います。
それを念頭に置いて、重要でない対話を邪魔にならないようにして、本当に重要な対話がより注目されるようにすることを検討する価値があるかもしれません.
トースター メッセージと、Google がオンライン アプリでメッセージを処理する方法は、重要でないことをユーザーに通知する方法の本当に良い例だと思います。
--編集-- 投稿を読み直し
た今、「考えさせないで」でこれを読んだことを覚えています。素晴らしくわかりやすいユーザビリティが満載の素晴らしい小さな本 (数十ページ)。オンラインの使いやすさにやや重点を置いていますが、オフラインのアプリケーションにも確実に適用できます。
これが私たちが計画したものです。基本的に、これらのエラー/警告などを保存するために Bugzilla っぽいものを作成します。しかし、それは他のいくつかの答えとも関連しています。
単純な MessageBox を使用する代わりに、Visual Studio のようなエラー ウィンドウに警告/エラーを表示します。問題がある限り、このウィンドウに表示されます。
データが保存されている場合は、すべての警告/エラーをデータベースに保存します。誰でも現在の問題を確認できるようになりました - おまけです! また、これらの問題は、アプリで常に検出するのではなく、データベースからロードすることができます。
ユーザーが次のようないくつかのアクションを実行できるようにします。
これらすべてのアクションをデータベースに記録して、説明責任を果たします
一言でいうと以上です。現在、問題はつきまとっており、解決されるまでユーザーの目の前に置かれています。問題を追跡できるので、噛まれた場合にボールがどこに落ちたかがわかります。うまくいくことを願っています！
以前のサイトでこれを実装することはできませんでしたが、ユーザーがメッセージを読んで確認したことを示すチェックボックスをオンにする（そしてその応答をログに記録する）必要があるカスタムダイアログボックスを作成したいと思いました。これはISO-xxxx企業向けだったので、この種の官僚主義はこの種の間違いに対する論理的な対応でした。
私の他の、はるかに不吉なアイデアは、「いいえ」または「キャンセル」をデフォルトのオプションにすることでした。最終的に、彼らはTab-Enterキーストロークを軽くたたくようになり、それからあなたはそれを元に戻すでしょう。
システムを壊せ！
正直なところ、エンドユーザーに明示的に理解せずに何かをさせたくない場合は、やめさせてください...
「Windowsエラー/警告メッセージ」全体が非常に厄介ですが、プログラムが何かをできないと言うまで、私は決して気にしません...そして、「なぜしないのか」と自問することを余儀なくされます.
答えをググる時間...またはRTFM
このアプローチを使用することが常に実行可能であるとは限らないことはわかっていますが、可能であれば...彼らは耳を傾けます!
私は、問題があることをほのめかしながら、できるだけ長く無視するプログラムが好きです。私が考えていることの 1 つ (ただし、私はそれを使用したことがないので漠然としています) は、エラー/警告 (Web ブラウザーの遍在するスロバーに少し似ていますが、エラー用) のステータス インジケーターを配置することです。このアイコンは信号のように状態が変化し、遅かれ早かれ対処しなければならない問題がプログラムにあることを示します。データの問題が後で修正できる場合は、おそらく黄色で警告されます。現在のジョブを完了する前に修正する必要がある問題は赤色です (フォーム データの場合、現在のフォームではなくトランザクション全体を意味します)。明らかに色が足りません。色覚障害者のためのサポートが必要ですが、そのアイデアは理解できます。インジケータをクリックすると、問題のリストが表示されます (おそらく、なぜそれが問題なのか - コードの仮定が役に立たない、または間違っている場合に人々が指摘できるようにするため)、問題を選択すると、それを修正できるフィールドにジャンプできます。
最終的にどのような方法を使用するにせよ、おそらく行うべきことの 1 つは、警告に目を通し、警告が実際に必要かどうかを判断することです。私はあまりにも多くのプログラムが、受け入れられる完全に合理的な入力について警告したり、プログラムの通常の動作について警告したりするのを見てきました。これは、人々が警告をクリックするように条件付けするのに役立つ種類のものです。警告のログがある場合は、そこから始めることができます。彼らは条件付けられているかもしれませんし、本当に問題がなく、誰かが物事が変わったことをあなたに話していないのかもしれません.
色とアイコンを使用します。
緑-すべてがOKです（または期待どおりに何かが起こったことを確認します）
黄色-警告。ユーザーは問題を調査する場合としない場合があります
赤-エラー。解決するためにユーザーの操作が必要なもの。
また、（他の人がこのスレッドで行っているように）控えめに使用することをお勧めします。
プラグインをインストールするときは、Firefox の方法がとても気に入っています。[OK] ボタンが無効になり、5 秒間カウントダウンが表示されます。その後、使用者はそれを無視することを選択できます。
Web アプリケーションの場合、JavaScript メソッドの alert() および confirm() は、やや基本的ではありますが、ユーザーが何かを実行するのを防止したり、警告された内容にユーザーが明確に同意したりする効果を実現します。
アクションがビジネス プロセスに大きな混乱を引き起こさないその他の状況では、たとえばフォームが送信された後、ページの上部に小さな警告ボックスを表示することがよくあります。
たとえば、私たちのアプリケーションでは、いくつかの場所で場所の検証が必要です (有効な都市/州/郵便番号)。
場所が絶対に重要な場合は、フォームで必須にします。
アプリケーションのいくつかの側面で場所が必要な場合は、confirm() を使用して、有効な場所がないと特定の機能を使用できないことを理解してもらいます。
場合によっては、デフォルトの場所を使用します。その場合、次のページの上部に、デフォルトの場所が使用されていることを示すメッセージ/警告ボックスが表示されます。
自分で使用するためにログ メッセージを作成している場合 (その使用がユーザー自身に直接利益をもたらす場合でも)、ユーザーに問題を報告してもらう唯一の方法は、アプリケーションにログ メッセージを作成させることです。
間違っている可能性のあるユーザー入力を処理する場合、スペル チェックで使用される赤い波線のようなものを使用したり、ユーザーが作業を行っているときに問題のある領域を強調表示したりすることを検討しましたか? ほとんどのユーザーは、バグのあるソフトウェアを使用してダイアログを無視するように訓練されていますが、そのようなメッセージは、ユーザーがエラーを修正する必要があることを明確にする場合があります。
それぞれの例外的な状況が発生する理由がよくわかりますか? これらの各メッセージで何を達成しようとしていますか:
明らかなタイプミスや間違いがないかどうか、ユーザーにデータを確認させる
より多くの情報が利用可能になった後の段階で、他の誰かにデータをレビューしてもらう
このユーザーと後の段階でデータを見ている他の人に、行われた仮定について通知します
ユーザーが自分の行動の結果を確実に理解できるようにする
これらの目標のいずれかを別の方法でより効果的に達成することはできますか?
いくつかのアイデア (自動的に特効薬と見なされるものはありません):
メッセージは短く関連性のあるものにし、追加情報を提供しない言語 (「お願いします」など) を除外し、ユーザーに期待されることを伝えます (つまり、「郵便番号が空です」の代わりに「郵便番号を入力してください」を使用します)。
ユーザーが理解できる言葉を使用し、常に十分な情報を提供し、できるだけ具体的にするようにしてください。
さまざまな種類の警告とエラーに対して、さまざまな外観のメッセージを使用します (フォント、色、画像、場合によってはアニメーションとサウンドを使用します)。
プロセス全体を再検討して、後で誰かが警告とともに送信された情報を処理する必要があるようにします。
次に情報が画面に表示されたときに警告を視覚化 (つまり、問題のある領域を強調表示) して、後でより多くの情報が利用可能になったときに解決できるようにします。
警告にサインオフを追加します。たとえば、ユーザーが警告を無視する必要があるたびにパスワードを入力するように要求します。
アクションを元に戻せるようにして、警告が本当に必要ないようにします