タスクの本質
指定：コラボレーションWebアプリケーション。 簡単にするために、これはCRMまたはタスクトラッカーであると想定します。
必須：応答が必要なアプリケーション内のイベントをタイムリーにユーザーに通知するため。
問題は何ですか？
厳密に定義された作業シナリオと固定ユーザーロールを持つ特定のアプリケーションがあれば、すべてが非常に簡単になります。 しかし、これはそうではありません。 設計プラットフォームに基づいて、ビジネスプロセスの会計および自動化のさまざまなシステムを開発しています。 また、通知システムはプラットフォームレベルで実行する必要があるため、後で任意のアプリケーションで使用できます。
最初のパンケーキ最初のクイックフィックス
最初は、最も単純なバージョンのアラートが実装されました。他のユーザーが行ったすべての変更をユーザーがアプリケーションに入力したときに表示されます。 少しの変更でこのメソッドは存在する権利がありますが、データ量とユーザー数が増えると、無限のリストが得られ、表示する必要がなくなります。
変更のリストが大きすぎることに加えて、このブロック「新機能」には他の問題があります。
- データにどのような変更が発生したか（どのフィールドが変更されたか、どのように変更されたか）
- これらの変更を誰がいつ行ったかは不明です。
- （ユーザーとして）これらの変更への応答が私から必要であるかどうかは不明です
これらのすべての質問に答えるには、各トランザクションに関する最も詳細な情報を保存するアクションログがあるように思われます。
ただし、実践が示すように、アクションログを使用してアプリケーション内のイベントに関する操作情報を取得するのは不便です。 原則として、変更に関するこのような詳細な情報はまれなケースで必要になります-「報告」の間にヘッドによって使用されます。 そして、リアルタイムでは、従業員は選択的な情報ほど詳細である必要はありません-興味のある変更に重点を置いています。 たとえば、「上記の例から」「ケースの仕上げ」の後、次のような情報を見たいと思います。
本日12:48 PMに、 イワノフはケースP4D1：出願書類の準備を完了しました。
Petrovには 、ケースP4D2：クライアントからの元のアプリケーションの受信 が割り当てられます 。
これは、私がこれらのIvanovsとPetrovsのリーダーであり、可能な限りそれらを制御したい場合です。 私がペトロフの場合、このフォームでアラートを受信する方が便利です。
P4D2：クライアントからの元のアプリケーションの受信に割り当てられます 。 締め切りは2日です。
アラートは、ユーザーやイベントごとに異なるように構成する必要があることがわかりました（ありがとう、キャップ） 。 ユーザーが本当に必要とするアラートのタイミングと内容を分析します。
アラート分類
発生源別
- 興味のあるデータが変更されました。 たとえば、タスクが私に割り当てられている場合、これを知りたいです。 私とは関係のないタスクが作成または変更された場合、私は興味がありません。
- 設定された時間が到着しました。 たとえば、1週間前に、今日の15:00に電話することに同意しました。 今週のこれが私の唯一の合意ではない場合、それについては安全に忘れてしまうでしょう。 したがって、リマインダーを受信するのは適切なタイミング（またはその前の時間）で役立ちます。
- 特定のイベントが発生しました。 たとえば、間違ったパスワードを使用して、または禁止されたIPアドレスからアプリケーションを入力しようとしました。 それ（私はアプリケーションの管理者として）興奮することができます。
誰に通知する必要があるか
- すべてのユーザー。 実際には、同じイベントについて全員に通知する必要があることはほとんどありません。 これが、すべての従業員が知っておくべきある種の企業ニュースでない限り。
- 特定の役割を持つユーザー。 管理者は、どのユーザーロールでどのアラートを表示するかを構成します。
- 特定のユーザー。 一部のユーザーには一意のアラートセットが必要であり、このセットを構成するためだけに新しいロールを作成することは意味がありません。 その後、特定のユーザーにアラートを割り当てることができます。 これが必要になる可能性のある別の状況は、管理者がユーザーが表示するアラートを選択することを気にしない場合です。 この場合、特定のユーザーの設定も保存する必要があります。
- 計算されたユーザー。 たとえば、タスクを作成するときは、[責任]フィールドで指定されたユーザーのみに通知する必要があります。 どのタスクの担当者を事前に（セットアップ段階で）知らないため、特定のユーザーにアラートを割り当てることはできません。 データを保存するとき、この情報はすでにシステムにあります-これはアラートを作成するときに使用します。
通知方法別
- リアルタイム アラートはリアルタイムで届きます。 イベントが発生するとすぐに、ユーザーはブラウザで直接、またはトレイのポップアップウィンドウの形式でメッセージを受け取ります。 注意を引くために、メッセージが点滅して音がする場合があります。
- SMSで。 この通知方法は、イベントへの対応がすぐに必要であり、ユーザーがリアルタイム通知にアクセスできない場合に意味があります。 通常、この方法は、インターネットにアクセスせずに、または単にブラウザを常に開いたままにすることなく、「フィールドで」働いている従業員に重要なイベントを報告するために使用されます。
- メールで。 電子メールメッセージ形式の通知は、即時の応答を必要としないまれなイベントに使用するのが理にかなっています。 ユーザーが適切なタイミングでアプリケーションにいなかった場合のフォールバックとして、電子メールアラートを使用することもできます。
- ニュースフィードで。 このようなアラートは、出現時にはまったく注意を引きませんが、ユーザーの主導でいつでも表示できます。 むしろ、これらはアラートではなく、アプリケーション内のイベントの個人的な履歴です。
賞味期限別
- 通常、データベースには保存されません。 彼らはユーザーに彼にとって重要な出来事を知らせました-彼らはブラウザにメッセージを送るか、メールで手紙を送りました-そして、それが受取人に届いたかどうかについて私たちは制御できません。 このオプションの問題は、ユーザーが通知を受け取れない場合があることです（たとえば、ユーザーがメッセージを読まずにブラウザーを閉じた場合、またはメッセージがスパムになった場合）、それについてはわかりません。 そして、ユーザーは自分が何かを見逃したことを知りません。
- 読み取り後に自動的に削除されます。 適切なオプションは、アラートが多数あり、アラートテキストの情報が少ない場合です。 ユーザーがメッセージを1回読むだけで、すぐにタスクの完了を開始できる場合。
- 既読としてマークされ、明示的な削除が必要です。 現在タスクについて学習する場合に適していますが、後で完了できます。 その後、通知はリマインダーとしてリストに残り、タスクが完了したら、手動で削除できます。
- しばらくすると自動的に削除されます。 多くの通知があり、時間の経過とともに関連性が失われる場合（たとえば、同僚の誕生日に関する通知や特定の日の勤務スケジュールの変更に関する通知など）は、ユーザーが読んでいるかどうかに関係なく、指定した時間後に自動的に削除するのが理にかなっています
結果
そのため、分析ではすべてのニーズが考慮されます。 彼らは何も忘れていないようです。 ここで、アラートを生成できる設定を考え出す必要があります。 インターフェースの美しさについてはまだ考えていませんでしたが、構成構造は次のようになりました。
注意深い読者は、この設定で通知の保存期間が選択されていないことに気付くでしょう。 この設定は、個々のアラートではなく、より高いレベル（アプリケーション全体）で設定できると判断しました。 おそらくこれは一時的な解決策であり、有効期間の微調整は依然として必要です。 経験が示されます。
おわりに
記事の冒頭で既に述べたように、見つかった解決策は理想的であると主張していません。 将来的にそれが何らかの形で補足されたり、完全に変更されたりする可能性があることを除外しません。 コメントで、建設的な批判や問題を解決するためのその他のオプションを満たすことを期待しています。