Webアプリケーションでメッセージと通知を定義/分類する方法
これに関するさまざまなスタイルガイドやUXガイドラインのコンテンツを見てきましたが、ユーザーとシステム間で発生するさまざまなタイプの通信の設計を一貫して実装しやすい、もっとシンプルなシステムがあるかどうか疑問に思いました。私の最初のアイデアは、重要度/緊急度マトリックスを使用して、各組み合わせに異なる重みを割り当てることです。たとえば、重要度は高、中、低にランク付けでき、緊急度は即時、中間、後でランク付けできます。このタイプの分類がエラー、警告、ステータス、アラート、および他のタイプのメッセージングと通知に使用されているのを見た人はいますか？それとも他のアプローチを提供できますか？
私はインパクト（重要度ではなく）と緊急度を見て、これらを使用して優先度を作成する必要があるようです。では、これらの各カテゴリを評価または分類する良い方法はありますか？また、これらを特定のルックアンドフィールにリンクして、フロントエンド開発者が簡単に実装できるようにするにはどうすればよいでしょうか。
更新
最近のフロントエンド開発フレームワークのいくつかを見ると、CSSがHTML要素に適用されているため、メッセージと通知を分類する必要がある場合があります。 Foundation 5.0の例
そしてBootstrap 3.0
質問をさらに明確にするために、私はユーザーの視点から、ユーザーがどのような種類のメッセージを表示することを期待し、どのような動作をする必要があるか（Webアプリケーションのコンテキストで）の観点から見てみようとしています。フロントエンド開発フレームワークは、スタイルについてのいくつかのアイデアを提供しますが、予想される動作との強いつながりを作りません。メッセージと通知を一貫して記述および分類するために使用できるシステムまたはスキームについて話しているため、これはビジネスルールから独立している必要があります。
（明確にするために答えを編集しました）
質問をもう一度読んでみますが、ステータス、警告、エラーなどのカテゴリにメッセージを分類する方法のほうが優れているようですこれらのを自動的に分類することはできません。これはビジネスケースの知識が必要だからです。時間をかけて充実させる分類のマトリックスを維持できます。
ITILの一部である、イベント管理とインシデント管理に関するいくつかの情報を以下に追加します。これらは、特定のケースで役立つ場合があります。
Priorityは通常、impactおよび緊急度。情報、警告、および例外は、イベントによって生成される情報のレベルです。
ITILには、影響/緊急度に応じて優先度を説明するマトリックスがあります。
ITILは、影響と緊急度に応じて優先度を決定することを提案しています。箱から出して、これは事件フォームに当てはまります。優先度は、次の表に従って緊急度と影響から生成されます。
Urgency 1 Urgency 2 Urgency 3 Impact 1 Priority 1 Priority 2 Priority 3 Impact 2 Priority 2 Priority 3 Priority 4 Impact 3 Priority 3 Priority 4 Priority 5（ソース： http://wiki.servicenow.com/index.php?title=ITIL_Incident_Management ）
私はより多くの情報を追加しています。私が受け取ったコメントから、そもそも緊急性と影響をどのように得るかが誰にとっても明らかではありません。
注意する必要があるのは、影響/緊急度の分類が組織とビジネスケースに依存することです。
緊急度分類の例
Category Description High (H) The damage caused by the Incident increases rapidly. Work that cannot be completed by staff is highly time sensitive. A minor Incident can be prevented from becoming a major Incident by acting immediately. Several users with VIP status are affected. Medium (M) The damage caused by the Incident increases considerably over time. A single user with VIP status is affected. Low (L) The damage caused by the Incident only marginally increases over time. Work that cannot be completed by staff is not time sensitive.（ソース： http://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority ）
さまざまなイベントタイプを考慮して、ITILは3つのカテゴリ（情報、警告、および例外）について説明します。
情報イベントは通常、通常の動作境界内のイベントです。これらは、ほとんどのITサービス管理ツールを埋める傾向がある「良い」イベントのタイプです。これらのイベントは通常、何かが正常に機能したことを示しています。
警告は、問題の初期の指標または潜在的な指標です。ただし、警告は「異常な」何かへのフラグであり、必ずしも否定的ではないことを理解する必要があります（例：誰かが6週間操作しないとログインします）。
例外はインシデントの最も典型的な前兆ですが、必ずしもインシデントにつながるとは限りません（たとえば、パワーユーザーが開始すると、CPUが設定されたしきい値を超えるとスパイクします）処理ジョブ）。例外イベントは、今後さらに問題が発生する可能性があるため、IT運用スタッフにとっては一般的に興味深いものです。
（ソース： http://itsm.certification.info/event2.html ）
注意すべき点の1つは、イベント管理とインシデント管理はリンクされているが、完全ではないということです。情報/警告/例外の形式のイベントがなくてもインシデント（つまり、影響/緊急性により優先順位が与えられる）が発生する可能性があります（たとえば、ユーザーが何かが動作していないと言うために呼び出した場合、監視が例外をスローする場合と比較して）サービスがダウンしています）。
私が見た中で最高のメッセージと通知はすぐに良いコピーライターによって書かれています。
メッセージで発生する傾向があるのは、必要なときにメッセージが書き込まれることであり、これは一定期間に発生します-通常はさまざまな人が行います。これは不整合の原因になります。
私はすべてのエラーメッセージと通知のリストを保持しますそれらが発生したときの簡単な説明（おそらくそれらに付随する画像を伴う）を使用します。次に、それをgood copywriterに、使用するスタイルに関する情報と共に提供します。そうすれば、すべてのメッセージを変更しなくても、メッセージの緊急性とスタイルの一貫性を確保できます。
優先順位は影響、緊急性、および結果の関数であるため、単純にマトリックスを作成してもそれほど多くは追加されません。メッセージの優先度が低、中、高のいずれであるかを自分で判断する必要があります。それより正確なものはほとんどメリットがなく、マニューシャに集中することができます。
ユーザーとのコミュニケーションは、どのプラットフォームのどのアプリケーションでも重要な機能であるため、これを正しく実行する必要があります。そうしないと、アプリケーション全体のUXに悪影響を与える可能性があります。序文：
Webの初期の頃は、コンテンツは静的で、手作業でコーディングされていました。サーバー側の関与は最小限であり、エラーの可能性は低かった。最近では、Ajax呼び出しやデータベースなど、すべての新しいテクノロジーを自由に使用できるようになっているため、状況は逆転しています。エラーは頻繁に発生し、予期されるものであり、アプリケーションはそれらを適切に処理する必要があります。
（jQuery-初心者から忍者-著者は私をエスケープしますが、後で編集します）
明らかに、適切に処理できるようにするには、分類する必要があります。だからここに私が見たいくつかの方法といくつかの提案があります。
4レベル
他のいくつかの回答がここに記しているように、多くのデスクトッププログラム（および一部のWebアプリ）には、重要、タスククリティカル、警告、情報の4つのレベルの分類があります。個人的には、これは非常に良い方法だと思います。これにより、いくつかの異なるタイプのエラーメッセージにアクセスできるようになります。 N.B .:私は慣れ親しんでいるので、用語とともにWebアプリについて主に話しますが、概念はグローバルに適用されます優先度/緊急度
質問で説明したシステムと同様に、多くのシステムは緊急度による分類方法を使用しています。たとえば、データがすべて破棄されようとしているというメッセージは非常に緊急であり、最初にユーザーに表示する必要があります。ペルーで2年後に出演する未知のアーティストがいるという通知は、それほど緊急ではなく、最後まで残すことができます。これは、最初に何を表示するか、何を待機するかを決定するインテリジェンスを備えているため、ユーザーとのコミュニケーションがより効率的になるため、優れたシステムです。ただし、実際の分類が欠如しているため、私はこれのそれほどのファンではありません。メッセージが表示される順序を決定するだけであり、現在のタスクにとって重要なものを示す機能はありません。
いくつかの考え
効率的で分類された通知システムを実現することが最終目標です。おそらくそれは多くの精製を必要とします。実際、ほぼ間違いなくそうなるでしょう。ただし、このようなシステムの基礎は、ここで説明する両方のシステムの混合である必要があると思います。つまり、一種の重要度別、時間認識システムです。両方のシステムのコンポーネントを使用すると、そのような通知は、アクションが実行される順序に基づいて論理的な順序でユーザーに配信され、ユーザーのワークフローのどれだけが中断するかが明確になります。
これをWebアプリに実装するのは比較的簡単です。CSSを使用したクラスベースのスタイル設定と、通知コンテンツを含む要素に格納されているデータ属性のJS分析によって、これがすぐに行われることがわかります。より堅牢なシステムを構築するには、サーバー側でバックアップする必要がありますが、既存のCSSスタイルを使用することもできます。
ウェブ通知
Webアプリの世界における最近の開発は、通知APIです。これにより、デスクトップWebアプリはユーザーにデスクトップ通知を送信でき、アプリの外部に表示されます。これはおそらく通知システムの開発に役立つ可能性があります。本当に緊急のメッセージは、アプリ内通知ではなくデスクトップ通知に表示される可能性があります。
もちろん、この新しいAPIはすべての通知に使用できます。ただし、そのサポートは制限されており（執筆時点では、Chrome、Firefox> 22およびSafari）、CSSがこれらの要素を処理しないため、スタイルと分類を異なる方法で行う必要があります。代わりに、アイコンオプションをいくつかのアイコンで使用する必要があります。各アイコンは、重要度の異なるレベルを表します。ただし、これはユーザーには一目で通知の重要度が明確ではないことを意味する場合があります。一部のブラウザー（FF、Safari）では、ユーザーが通知をキャンセルするのを待つのではなく、4秒後に通知が自動的にキャンセルされます。
重要度と緊急度をどのように区別しますか？あなたが緊急と分類したものは何でも、それは同様に重要ではないでしょうか？
通常、Webアプリケーションはこれを念頭に置いて構築されています。私がJava/jeeプラットフォームで構築したすべてのWebアプリケーションは、ある種の logging を使用しました。現在、これらのログステートメントには、警告、デバッグ、エラーなどのさまざまなレベルがあります。これらがシステム（files/dbなど）に書き込まれる重大度は、コントローラーファイルによって制御されます（たとえば、ユーザーが報告した内容を再現したい場合、開発者がデバッグ文をオンにして、それらを確認できるようにします。）
システムで致命的なログが検出された場合、サポートクルーにエラーとその詳細が通知されます。通常、すぐに注意が必要です。多くの企業は、他のスタッフがビープ音を鳴らす前に、典型的な待ち時間を持っています。技術担当者が調査中と言って30分以内に信号を返さない場合、メッセージは上位の機関などに送信されます。この先見性を持って申請する必要があります。
ただし、アプリケーションでエンドユーザー間でのメッセージングが許可されている場合、ユーザーに通知できる緊急メッセージのセットが異なる場合があります（Ex P1は件名が非常に重要なメッセージまたは赤い感嘆符を意味するため） 、例:)
目的は、適切なメッセージを適切な人に適切なタイミングで届けることです。あなたの質問は重要なカテゴリーと重要性のグローバルな考えに焦点を当てているようですが、通常、特定の役割または個々のユーザーでさえ、特定のメッセージ/アラートを他より優先します。
機械学習と人間によるキュレーションを組み合わせて使用して、これらの設定を適用し、データを整理できます。それをその観点から見ると、エラーや警告などの必要性が見つかる可能性がありますが、高/中/低の重要度の評価は、パブリッシャーよりも実際に視聴者に依存する可能性があるため、あまり役に立たないと思います。 /世界平均の関連性。
ユーザースペースのサイズと目的のタスクに応じて、Stumbleuponのようなモデルを使用してユーザーをペアにすることができます。たとえば、ユーザーAがユーザーBに投票する質問に投票する傾向がある場合、ユーザーBによる投票は増加する必要があります。ユーザーAのビューでのそのメッセージの可視性。もちろん、メッセージに関する他の指標を使用して言うこともできます。過去の使用状況に基づいて、これらの新しいメッセージはユーザーAに最も関連しています。
このような一部のシステムは、単なるメッセージではなく、ワークキューです（すべてのメッセージ自体が、実行する必要がある作業の単位です）。これらは、上記の関連するユーザーの優先順位を特定することでメリットを得ることができますが、タスクを「要求する」という考えと、要求されていないタスクを可視性にプッシュすることも含める必要があります。次に、ユーザー優先度を使用して、要求されていないタスクのうち誰が最も高いかを判断します。
Time Management から、このマトリックスをさらに簡略化したクラスを覚えています。
Urgent | |
--------------------------
Not Urgent | |
--------------------------
Not Important | Important
すべての新しい概念と同様に、シンプルな方が良いです。
他のポスターに続いて、ロールまたはアプリケーションレベルで適用されるマトリックスは、個々のメッセージにタイプ/重要性を割り当てるための単一のシステムを作成する最も適切な方法だと思います。各レベルの色とアイコンの使用を指定するマトリックスを作成できると思います。
他の人が述べたように、すべての状況ですべてのユーザーに適用されるルールを作成することはできないため、これらのレベルはロールまたはアプリケーションレベルで適用する必要があります。ただし、このようなシステムでは、たとえばクラス（<span class="major-error">など）を使用して、これらのルールを簡単に適用できます。これにより、非技術スタッフはビジネス要件を技術仕様にすばやく変換でき、技術スタッフはこの種の機能をコンテンツ管理システムに簡単に構築できます。