デスクトップアプリに通知を表示するにはどうすればよいですか？
私たちは、ビデオ会議/相談のために顧客を受け入れるコンサルタントがいるデスクトップアプリを持っています。
このアプリでは、着信顧客（つまり、現在相談が必要な顧客）と待機中の顧客（着信顧客の後にサービスされる顧客）がいます。
私は数/ステータスが変化するアプリの上部に永続的なバーがあることを考えています。キューに入っている顧客の数に応じて（たとえば、3分ごとに更新されます）。
このようにして、コンサルタントは、Webアプリケーションのどこにいても、何人の顧客がキューに入っているかを知ることができます。
これを処理するためのより良い方法があるかどうか疑問に思っていますか？
私が検討することはいくつかあります。コンサルタントは画面をクライアントと共有していますか（私たちは彼にそれを見せたくありません）？それは目立たないようにするべきですか、それともコンサルタントに概要を与えるべきですか？他のチャネル（存在する場合）では、通知はどのように表示されますか？コンサルタントはクライアントを知っていますか？クライアントはコンサルテーションの前にクエリを記入しますか？
これらはここにないので、検討することをお勧めします。しかし、あなたの最初の考えでは、私は次のことを前提としています。コンサルタントは画面を共有していません（または、特定のウィンドウを共有している場合）。通知は、概要を説明するよりも控えめで正確でなければなりません。最後に、クライアントが戻ってきたか、呼び出し要求に追加の背景を提供したかどうかに関する情報は、別の場所にあります。
あなたは私がここで見る3つのアプローチを取るかもしれません：
- あなたが提案したように;上部の静的通知
プロ：驚きはありません。コンサルタントはどこで通知を探すべきかを知っているので、キューが長い場合、またはストレスがかかると、なんらかの快適さが得られます。
Con：通知は静的であり、コンサルタントはそこにいるだけで慣れるので、インターフェースの静的要素として認識されます。したがって、通知としての重量を失います。 - コンサルタントが顧客数を含む前回の電話を終えた後の隅にある通知（トーストメッセージ）。
Pro：必要なときに適切な情報を提供します。
Con：それをどのように実装できるかわかりません。さらに、コンサルタントはこの情報を必要とするかもしれません。 - 「ビデオ通話」ボタンがあるキューの数。
プロ：必要な場所に適切な情報を提供します。キューが表示されている場合は、通話を開始します。通話を終了したばかりの場合は、別の通話を開始します。
Con：この領域をカスタマイズできる必要があります。
カウントとともに上部に通知を表示すると、コンサルタントの注意をそらす可能性があり、適切なコンサルテーションなしに現在の顧客をまとめるようにプッシュする可能性があり、顧客を満足させない可能性があります。
コンサルタントにキューに入っている顧客については通知しますが、カウントは表示しない、煩わしくないインジケーターがあると考えてください。
通知に関するマイクロソフトのガイドライン は次のように述べています。
通知の情報は有用で関連性がありますが、重要ではありません。その結果、通知は即時のユーザーアクションを必要とせず、ユーザーはそれらを自由に無視できます。
情報は急速に変化し、継続的なリアルタイム情報ですか？？たとえば、処理の進捗状況、株価情報、スポーツのスコアなどです。その場合は、急速に変化する情報には適していないため、通知は使用しないでください。
この情報は有用で関連性がありますか？情報を受け取った結果、ユーザーは行動を変えたり、不便をかけたりしませんか？そうでない場合は、情報を表示しないか、ステータスウィンドウまたはログファイルに入れてください。
情報は重要ですか？ 必要な場合は、モーダルダイアログボックスやメッセージボックスなど、注意が必要で簡単に無視できないインターフェイスを使用して情報を表示します。プログラムがアクティブでない場合は、プログラムのタスクバーボタンを3回点滅させ、プログラムがアクティブになるまで強調表示したままにすることで、重要な情報に注意を引くことができます。
主要なターゲットユーザーはITプロフェッショナルですか？その場合、ログファイルエントリや電子メールメッセージなどの代替フィードバックメカニズムを使用します。 ITプロフェッショナルは、重要ではない情報のログファイルを強く好みます。さらに、サーバーはリモートで管理されることが多く、通常はユーザーがログオンせずに実行されるため、通知が無効になります。
この情報は、ユーザーとアプリケーションとの直接的な対話の結果ですか？その場合、ダイアログボックスを使用する代わりに、アプリケーション内でこの同期情報を直接表示します、メッセージボックス、バルーン、またはインプレースUI。
設計コンセプト
優れたユーザーエクスペリエンスを促進する効果的な通知は次のとおりです。
非同期。イベントは、Microsoft Windowsまたはアプリケーションとのユーザーの現在の対話の即時の直接的な結果ではありません。
便利です。通知の結果、ユーザーがタスクを実行したり、動作を変更したりする可能性があります。
関連性があります。通知には、ユーザーが気にかけていてまだわからない役立つ情報が表示されます。
重要ではありません。通知はモーダルではなく、ユーザーの操作を必要としないため、ユーザーは自由に無視できます。
Actionable。アクションの実行を提案する通知の場合、通知をクリックすると、そのアクションが開始されます。ただし、アクションはいつでも延期できます。
適切に表示されます。通知の表示（期間、頻度、テキスト、アイコン、および対話性）は、その状況と一致します。
迷惑ではありません！イベントを穏やかにユーザーに通知することと、ユーザーを困らせることの間には細かい境界があります。
この情報があなたの正しい選択に役立つことを願っています。
新しいユーザーが参加すると情報が更新されるため、静的な通知バーを使用することはお勧めできません。特に、前述のスタイルで更新されたデータに気付かない場合があります。 Facebookやその他の通知トレイなど、badges
この通知の位置は、そのフィールドに関連するコンテンツの位置、つまりユーザーとキューに関連するデータを見つける場所、およびその通知をクリックしたときの動作。
通知以外にコンテンツにそのような種類のものがない場合、左下でトーストしてみることができます。これは、ほとんどのユーザーがウィンドウを使用しているためです。ユーザーが通知を受け取る場所。 
またはそれがMacの場合は右上に試してください 
数ではなく、誰がキューに入っているかを示します。
一人が去り、新しい人がつながると想像してください。この場合、クライアントの数は同じになりますが、状況は変更されました。
キュー内の顧客の1人が非常に貴重なクライアントであると想像してください。たとえば、VIPまたは、製品の購入に非常に近いパートナーまたはクライアントです。
そのため、次のようなものを使用することをお勧めします（通常、キューにクライアントが多くない場合）： 
そして、次のようなもの（キュー内のクライアントが5を超える場合）： 
また、クライアントに（ステータスを示すために）バッジを付ける方法を示しました。
ここでの問題は、お客様が2種類あるため、通知は最善のアプローチではないということだと思います：着信顧客（つまり、今相談が必要な顧客）と待機中の顧客（着信顧客の後にサービスされる顧客）。
次のように、オペレーターが両方のタイプの衣装を同時に比較し、それらの間の比率を理解しているチャートを表すとしたらどうでしょう。
着信または待機中の顧客がいない場合、グラフは空になります。オペレーターには常に管理するコスチューマーがいて、「デッドタイム」がないと想定しているため、オペレーターがパイプラインにいる顧客の数を定量化するのに役立ちます。そしてそれに基づいて、「何か」が発生したとき、または現在のステータスが変更されたときに使用する必要があるので、通知があることは価値をもたらしません。これは、この場合とは異なります。