Wie In-App-Benachrichtigungen an Ihr Gesamtes Team Verteilt Werden

Wenn in einem gemeinsam genutzten Arbeitsbereich etwas mit einer Rechnung geschieht — eine Zahlung geht ein, ein Kostenvoranschlag wird genehmigt, eine Mahngebühr wird angewendet —, erhält jedes relevante Mitglied dieses Arbeitsbereichs seine eigene individuelle Benachrichtigung, nicht nur die Person, die zufällig die Aktion ausgelöst hat, oder eine einzige gemeinsame Benachrichtigung auf Arbeitsbereichsebene. Diese Verteilung wird von einem kleinen, im gesamten Produkt wiederverwendeten Stück Logik gehandhabt, und einige ihrer Designentscheidungen lohnt es sich zu verstehen, wenn Sie herausfinden möchten, warum Ihr Team die Benachrichtigungen sieht, die es sieht, und warum Sie manchmal keine für Ihre eigenen Aktionen sehen.

Eine Funktion, Jeder Benachrichtigungstyp

Jede Art von Benachrichtigung, die das Produkt erzeugt — eine Rechnung wird bezahlt, eine Zahlung geht ein, ein Kostenvoranschlag wird genehmigt oder abgelehnt, ein Kundenkommentar trifft ein, eine wiederkehrende Rechnung wird erzeugt, eine Mahngebühr wird angewendet — läuft über dieselbe zugrunde liegende Verteilungslogik, statt dass jeder Ereignistyp einen eigenen separaten Benachrichtigungscodepfad hätte. Die Funktion nimmt eine Arbeitsbereichs-ID, einen Benachrichtigungstyp, einen Titel und einen optionalen Text entgegen und erzeugt eine Benachrichtigungszeile pro aktivem Mitglied dieses Arbeitsbereichs. Das ist praktisch wichtig, weil es bedeutet, dass das Benachrichtigungsverhalten über jeden Ereignistyp im Produkt hinweg konsistent ist — dieselben Regeln darüber, wer wie benachrichtigt wird, gelten überall, statt dass jede Funktion im Laufe der Zeit still ihre eigene, leicht abweichende Benachrichtigungslogik entwickelt hätte.

Es Ist Eine Verteilung, Kein Einzelner Gemeinsamer Datensatz

Ein üblicherer, einfacherer Ansatz wäre, einen Benachrichtigungsdatensatz pro Ereignis zu schreiben und jedes Arbeitsbereichsmitglied dagegen abfragen zu lassen. Dieses Produkt tut das Gegenteil: Es schlägt in dem Moment, in dem das Ereignis auftritt, jedes aktive Mitglied des Arbeitsbereichs nach und fügt für jeden Einzelnen eine separate, unabhängige Benachrichtigungszeile ein. Der Grund ist der Lesestatus. Wenn fünf Personen sich einen Arbeitsbereich teilen und eine Zahlung eingeht, muss jede dieser fünf Personen in der Lage sein, diese Benachrichtigung unabhängig als gelesen zu markieren — dass ein Teammitglied die Benachrichtigung wegklickt, sollte sie nicht für die anderen vier verschwinden lassen. Eine Zeile pro Mitglied zu schreiben ist das, was unabhängigen Lese-/Ungelesen-Status ermöglicht, ohne eine separate Verknüpfungstabelle nur zur Verfolgung, wer was gesehen hat, zu benötigen.

Selbstbenachrichtigungen Werden Bewusst Unterdrückt

Die Verteilungslogik akzeptiert einen optionalen "Ausschluss"-Parameter, der immer dann verwendet wird, wenn die Aktion, über die benachrichtigt wird, von einem bestimmten bekannten Nutzer durchgeführt wurde — am häufigsten, wenn jemand selbst manuell eine Zahlung auf einer Rechnung erfasst. In diesem Fall wird diese Person von der resultierenden Benachrichtigung ausgeschlossen, weil es Lärm ist, keine Information, zu erfahren "Sie haben gerade das getan, was Sie gerade mitten dabei sind zu tun". Jedes andere aktive Mitglied des Arbeitsbereichs wird weiterhin normal benachrichtigt; nur der Akteur selbst wird übersprungen. Ereignisse, die keinen klaren einzelnen menschlichen Akteur haben — eine wiederkehrende Rechnung, die automatisch auslöst, eine Mahngebühr, die durch den geplanten Durchlauf angewendet wird —, haben nichts auszuschließen, sodass jedes aktive Mitglied benachrichtigt wird, da keines von ihnen es persönlich ausgelöst hat.

"Aktives Mitglied" Wird Zum Zeitpunkt der Benachrichtigung Geprüft, Nicht Zum Zeitpunkt des Ereignisses

Die Liste, wer benachrichtigt wird, wird in dem Moment, in dem das Ereignis geschieht, frisch abgerufen, indem die aktuelle Arbeitsbereichsmitgliedschaft abgefragt wird — sie ist keine statische, im Voraus entschiedene oder aus früherer Zeit zwischengespeicherte Liste. Das bedeutet, dass Mitgliedschaftsänderungen sofort und korrekt widergespiegelt werden: Wenn jemand vor fünf Minuten aus einem Arbeitsbereich entfernt wurde, erhält er keine Benachrichtigung für etwas, das jetzt geschieht, und wenn jemand gerade hinzugefügt wurde, ist er ab diesem Zeitpunkt in der Verteilung für Ereignisse enthalten, ohne dass ein separater "Synchronisierungs"-Schritt nötig wäre, damit neue Mitglieder anfangen, Benachrichtigungen zu erhalten.

Kommentarbenachrichtigungen Haben Ihre Eigene Lesestatus-Kopplung

Kommentarbenachrichtigungen haben speziell ein zusätzliches Verhalten, das über das allgemeine System gelegt ist: Das Öffnen des Kommentar-Threads eines Dokuments löscht zusätzlich zu dem, was in der eigenen Lesestatus-Verfolgung des Kommentar-Threads geschieht, auch die "neuer Kommentar"-Benachrichtigung für dasselbe Dokument. Ohne diese Kopplung würde ein Kommentar eines Kunden gleichzeitig an zwei separaten Stellen als ungelesen erscheinen — der Benachrichtigungsglocke und einem separaten Badge für ungelesene Kommentare am Dokument selbst — und es gäbe keine einzelne Aktion, die beide löscht. Das tatsächliche Lesen des Kommentar-Threads wird als ausreichende Bestätigung dafür behandelt, dass Sie die Benachrichtigung darüber gesehen haben, sodass sie den Eintrag in der Benachrichtigungsglocke automatisch löscht, statt zu verlangen, dass Sie die Benachrichtigung separat wegklicken und den Kommentar separat lesen.

Fehler Werden Protokolliert, Nie dem Nutzer Angezeigt

Falls die Benachrichtigungsverteilung selbst aus irgendeinem Grund fehlschlägt — ein Datenbankproblem, ein unerwartetes Mitgliedschaftsabfrageergebnis —, wird der Fehler abgefangen und serverseitig protokolliert, aber er blockiert oder erscheint niemals als Fehler bei demjenigen, der die zugrunde liegende Aktion ausgelöst hat. Das Erfassen einer Zahlung, das Genehmigen eines Kostenvoranschlags oder jede andere Aktion, die zufällig eine Benachrichtigung auslöst, wird immer basierend auf ihrer eigenen Logik gelingen oder fehlschlagen, völlig unabhängig davon, ob der Benachrichtigungs-Nebeneffekt zufällig funktioniert hat. Das spiegelt dieselbe Nach-bestem-Bemühen-Philosophie wider, die auch bei der Prüfprotokollierung an anderer Stelle im Produkt verwendet wird: Benachrichtigungen sind ein hilfreicher Nebenkanal, kein Tor, von dem die Hauptaktion abhängt.

Was Das Für Den Alltag Bedeutet

In einem gemeinsam genutzten Arbeitsbereich sollten Sie erwarten, dass jedes Teammitglied — außer demjenigen, der eine manuelle Aktion persönlich durchgeführt hat — eine Benachrichtigung für alles Bedeutsame sieht, was mit einer Rechnung geschieht, in Echtzeit, mit vollständig unabhängigem Lesestatus pro Person. Wenn Sie keine Benachrichtigung für etwas sehen, das Sie selbst getan haben, funktioniert der Ausschluss wie beabsichtigt, kein Fehler. Und wenn ein Teammitglied, das kürzlich aus dem Arbeitsbereich entfernt wurde, scheinbar immer noch über Dinge benachrichtigt wird, oder ein neu hinzugefügtes Teammitglied nichts von vor seinem Beitritt sieht, funktioniert auch beides genau wie beabsichtigt — die Benachrichtigungsliste ist immer eine Live-Momentaufnahme der aktuellen Mitgliedschaft, keine einmal festgelegte feste Liste.

Wie Dies Mit dem E-Mail-Digest-System für Kommentare Zusammenhängt

Kundenkommentare speisen speziell auch einen zweiten, separaten Benachrichtigungspfad: einen E-Mail-Digest, getrennt von der oben beschriebenen In-App-Benachrichtigungszeile. Die In-App-Benachrichtigung verteilt sich sofort, eine Zeile pro aktivem Mitglied, in dem Moment, in dem ein Kommentar eintrifft. Der E-Mail-Digest hingegen wartet absichtlich eine kurze Verzögerung, bevor irgendetwas versendet wird, und setzt diese Verzögerung jedes Mal zurück, wenn ein neuer Kommentar aus demselben Gespräch eintrifft — sodass ein Ausbruch mehrerer Kommentare hintereinander eine einzige Zusammenfassungs-E-Mail erzeugt, statt eine E-Mail pro Kommentar. Die beiden Systeme ergänzen sich, statt sich zu überschneiden: Die In-App-Benachrichtigung ist für nahezu-Echtzeit-Sichtbarkeit gebaut, während Sie aktiv im Dashboard arbeiten, und der E-Mail-Digest ist dafür gebaut, Sie auch dann zu erreichen, wenn Sie es nicht sind, ohne Ihren Posteingang zu überfluten, falls ein Kunde mehrere Kommentare hintereinander hinterlässt. Beide werden vom selben zugrunde liegenden Ereignis ausgelöst, aber sie werden von zwei unabhängigen Logikstücken mit unterschiedlicher Toleranz für Sofortigkeit gegenüber Bündelung gehandhabt.

Benachrichtigungstypen Auf Einen Blick

Die aktuelle Menge an Benachrichtigungstypen deckt die Momente im Lebenszyklus einer Rechnung ab, die am direktesten die Aufmerksamkeit eines Teams benötigen: Eine Zahlung wird gegen eine Rechnung erfasst, eine Rechnung erreicht den Status vollständig bezahlt, ein Kostenvoranschlag wird von einem Kunden genehmigt, ein Kostenvoranschlag wird abgelehnt, ein neuer Kundenkommentar trifft auf einem freigegebenen Dokument ein, eine wiederkehrende Rechnung wird automatisch aus einem Zeitplan erzeugt, und eine Mahngebühr wird automatisch angewendet. Jedes davon entspricht einem spezifischen, konkreten Moment statt einer vagen Aktivitätszusammenfassung — die Designabsicht ist, dass jede Benachrichtigung, die ein Teammitglied erhält, entweder umsetzbar oder zumindest für sich genommen wissenswert sein sollte, statt der Art von wenig wertvollem Aktivitätslärm, der Menschen dazu bringt, ihre Benachrichtigungen ganz zu ignorieren.

Lesestatus Wird Pro Benachrichtigung, Pro Nutzer Verfolgt

Da jede Verteilung eine unabhängige Zeile pro Mitglied erzeugt, ist das Markieren einer Benachrichtigung als gelesen ebenso auf genau eine dieser Zeilen zu einem bestimmten Zeitpunkt beschränkt — ein Teammitglied, das eine bestimmte Benachrichtigung als gelesen markiert, hat keine Auswirkung auf die identisch aussehende Benachrichtigung in der Liste eines anderen Teammitglieds, da es sich um wirklich separate Datenbankzeilen handelt, selbst wenn sie aus demselben einzelnen Ereignis stammen. Eine "Alle als gelesen markieren"-Aktion ist ebenfalls verfügbar, und sie funktioniert auf dieselbe Weise: Sie löscht jede derzeit ungelesene Benachrichtigung, die speziell dem anfragenden Nutzer gehört, und lässt den Ungelesen-Status jedes anderen Mitglieds vollständig unberührt. Die überall in der Oberfläche angezeigte Anzahl ungelesener Benachrichtigungen wird ebenfalls pro Nutzer berechnet, als Live-Zählung der eigenen ungelesenen Zeilen dieses Nutzers, statt als irgendeine Art gemeinsamer oder arbeitsbereichsweiter Zähler.