Push-Nachrichten gezielt und verständlich einsetzen
Gewöhnliche Aufgabenhinweise so planen, dass Nutzen, Zeitpunkt und nächster Schritt zusammenpassen.
Eine Push-Nachricht unterbricht eine andere Tätigkeit
Eine Push-Nachricht ist sinnvoll, wenn ihr Anlass für die empfangende Person wichtig und ihr nächster Schritt verständlich ist. Sie erreicht Menschen häufig außerhalb der gerade geöffneten Anwendung. Deshalb reicht es nicht, jedes neue Ereignis technisch zustellen zu können. Die Gestaltung muss beantworten, warum dieser Hinweis eine Unterbrechung verdient und welche Handlung daraus tatsächlich folgt.
Unser eigener fiktiver Fall betrifft gewöhnliche Aufgaben und Prüfungen in einer Arbeitsanwendung. Es geht nicht um Notfallalarmierung oder eine garantierte Erreichbarkeit. Wir entwickeln eine vollständig ausgeführte Entscheidungsfunktion für Themenwahl, Erlaubnis, Gültigkeit, Abstand und Ruhezeit. Der Code bereitet einen möglichen Versand vor. Er verschickt selbst keine Nachricht und liefert keinen Nachweis über einen tatsächlich erreichten Sperrbildschirm.
Diese Trennung ist praktisch wichtig. Ein zulässiger Anlass kann trotzdem wegen fehlender Erlaubnis entfallen. Ein zur Übermittlung vorbereiteter Hinweis kann später veraltet sein. Ein vom Versanddienst angenommener Auftrag ist noch kein Beleg, dass eine Person ihn gelesen hat. Verlässliche Gestaltung verwendet für diese Zustände unterschiedliche Begriffe und leitet aus einem technisch erfolgreichen Zwischenschritt keinen abgeschlossenen Arbeitsvorgang ab.
Den Nutzen vor dem ersten Erlaubnisdialog erklären
Eine sinnvolle Einladung entsteht am passenden Arbeitsschritt. Wer gerade eine Aufgabe beobachtet, kann verstehen, warum deren Änderung interessant ist. Eine sofortige allgemeine Nachfrage beim ersten Öffnen verlangt dagegen eine Entscheidung ohne konkreten Zusammenhang. Beschreiben Sie vor der Systemabfrage den Anlass und den erwartbaren Umfang. Menschen sollen beurteilen können, ob diese Art Hinweis zu ihrer Nutzung passt.
Die eigene Themenwahl und die Erlaubnis des Betriebssystems sind verschiedene Ebenen. Eine eingeschaltete Kategorie kann keine verweigerte Systemerlaubnis ersetzen. Umgekehrt bedeutet eine erteilte Systemerlaubnis nicht, dass jede denkbare Mitteilung fachlich erwünscht ist. Unser Beispiel verlangt beides und verwendet für die Web-Erlaubnis die Zustände default, denied und granted. Nur der letzte Zustand erlaubt überhaupt eine Versandvorbereitung.
Bei fehlender Erlaubnis fragt die Entscheidungsfunktion nicht selbst erneut nach. Sie liefert einen passenden Grund zurück. Die eigentliche Anwendung muss weiterhin bedienbar bleiben und ihre Aufgaben auch innerhalb der Oberfläche zeigen. Ein verweigerter Hinweis ist kein Grund, wichtige Inhalte zu verstecken oder Menschen in wiederholte Nachfragekreise zu drängen. Die Systemabfrage gehört in einen ausdrücklich ausgelösten passenden Bedienablauf.
web.dev: Permission UX · MDN: Notifications API
Themen getrennt steuern und gewöhnliche Hinweise begrenzen
Unser Fall kennt die Themen Aufgaben und Prüfungen. Die Person kann diese Themen getrennt wählen oder beide ausschalten. Das ist überschaubar und an tatsächlichen Arbeitsanlässen orientiert. Eine lange Liste technischer Ereignisnamen wäre dafür wenig hilfreich. Ebenso unverständlich wäre ein einziger Schalter, der notwendige Arbeitsinformationen mit beliebiger Werbung und unwichtigen Wiederholungen vermischt.
Im Web bestehen Erlaubnis, aktives Abonnement und eigene Themenwahl nebeneinander. Unter Android kommen die plattformspezifischen Einstellungen und Benachrichtigungskanäle hinzu. Diese Mechanismen haben nicht überall dieselbe Bedeutung oder dieselbe Bedienoberfläche. Unser Beispiel verwendet einen ausdrücklich vereinfachten gemeinsamen fachlichen Entscheidungsstand. Es behauptet nicht, damit die vollständige Android- oder Browserintegration bereits implementiert und auf jedem Gerät geprüft zu haben.
Eine zusätzlich eingetragene Dringlichkeitsbehauptung darf die vereinbarte Themenwahl nicht heimlich umgehen. Der gezeigte Code wertet kein beliebiges urgent-Feld als Sonderbefugnis aus. Auch eine Ruhezeit bleibt davon unberührt. Wenn ein Produkt tatsächlich gesonderte kritische Hinweise benötigt, müssen Zweck, technische Plattformregeln und die Zustimmung dafür eigenständig entwickelt werden. Normale Aufgabenhinweise werden dadurch nicht nachträglich zu Alarmtechnik erklärt.
Android: Notification Permission · Notification Channels
Anlass, Zeitpunkt und Haltbarkeit ausdrücklich modellieren
Ein Ereignis besitzt im Beispiel eine feste Kennung, ein Thema, einen Erzeugungszeitpunkt und ein Ablaufdatum. Die Zeitpunkte werden als konkrete UTC-Zeitwerte übergeben. Ein Ereignis, dessen Zeitpunkt noch in der Zukunft liegt, wird nicht verarbeitet. Ein bereits abgelaufenes Ereignis ebenfalls nicht. Das verhindert, dass eine alte Aufgabenänderung nur wegen einer später wieder verfügbaren Verbindung weiterhin als aktuelle Unterbrechung erscheint.
Die Haltbarkeit richtet sich nach dem Anlass. Eine kurzfristige Abstimmung kann nach wenigen Minuten bedeutungslos sein. Eine allgemeine Prüfaufgabe kann länger bestehen. Diese fachliche Gültigkeit unterscheidet sich von der technisch erlaubten Aufbewahrungszeit bei einem Versanddienst. In einer echten Integration sollten beide zusammenpassen. Der Empfänger muss einen inzwischen erledigten Vorgang zudem beim Öffnen verständlich darstellen können.
Die Entscheidungsfunktion prüft Zeittypen und die Reihenfolge von Erzeugung und Ablauf. Sie empfängt ihren aktuellen Zeitpunkt aus dem aufrufenden Programm. Dadurch sind Randfälle ohne Warten reproduzierbar. Die festen Zeiten der Prüfungen sind ausdrücklich gewählte Testeingaben und keine Messung realer Zustellverzögerungen. Für die tatsächliche Übermittlung wären zusätzliche Nachweise mit dem gewählten Dienst und realen Geräten erforderlich.
Ruhezeiten nach der tatsächlichen Ortszeit auswerten
Unser Beispiel verwendet bewusst die feste Zeitzone Europe/Berlin und ganze Stunden für die Ruhezeit. Die normale Einstellung reicht von 22 bis 7 Uhr. Bei einer Ruhezeit über Mitternacht liegt eine Stunde entweder nach dem Beginn oder vor dem Ende. Für ein Zeitfenster am selben Tag gilt die entsprechende gemeinsame Begrenzung. Identischer Beginn und identisches Ende werden als unklare Eingabe zurückgewiesen.
Die Entscheidung verwendet nicht einfach einen dauerhaft angenommenen Abstand von UTC. Stattdessen ermittelt Intl.DateTimeFormat die jeweilige Berliner Stunde für einen konkreten Zeitpunkt. So berücksichtigt der ausgeführte Code die Zeitumstellung. Die nächste zulässige Minute wird entlang tatsächlicher UTC-Zeitpunkte gesucht. Das lokale Ende der Ruhezeit kann dadurch an den beiden Umstellungstagen in unterschiedlichem Abstand liegen.
Der Suchraum ist auf 36 Stunden begrenzt. Die gewählte Form mit vollen Stunden bleibt überschaubar. Sie ist keine vollständige Bibliothek für beliebige weltweite Kalenderregeln, Feiertage oder reisende Geräte. Wer mehrere Zeitzonen oder minutengenaue persönliche Fenster braucht, entwickelt dafür einen erweiterten Vertrag. Die konkreten Fälle dieses Beitrags belegen die implementierte Berliner Regel einschließlich der beiden Zeitumstellungen des Jahres 2026.
Abstand und Ruhezeit gemeinsam berechnen
Zwischen zwei vom Versanddienst angenommenen normalen Hinweisen sieht unser Beispiel mindestens fünfzehn Minuten Abstand vor. Diese Zahl ist eine bewusst gewählte Produktregel und keine allgemeingültige Empfehlung für jede Anwendung. Der letzte bekannte Annahmezeitpunkt wird als äußerer Zustand übergeben. Die Funktion selbst speichert ihn nicht. Ist noch kein solcher Zeitpunkt vorhanden, entsteht daraus keine zusätzliche Wartezeit.
Zunächst wird der frühestmögliche Zeitpunkt aus aktuellem Zeitpunkt und Mindestabstand berechnet. Erst für diesen Kandidaten wird die Ruhezeit geprüft. Das ist ein wichtiger Randfall: Ein Hinweis kurz vor Beginn der Ruhezeit könnte durch den Mindestabstand erst in die Ruhezeit hineinrutschen. Eine Prüfung nur des ursprünglichen Zeitpunkts würde diese Kombination übersehen. Unser tatsächlicher Versuch enthält genau diesen Ablauf.
Liegt das nächste erlaubte Fenster am oder nach dem Ablauf des Ereignisses, wird der Hinweis ausgelassen. Eine Verschiebung darf aus einem veralteten Anlass keinen neuen aktuellen Anlass machen. Bei einer späteren erneuten Auswertung müssen Erlaubnis, Themenwahl und Gültigkeit nochmals geprüft werden. Das zurückgegebene Verschiebedatum ist keine dauerhafte Versandfreigabe, die spätere Änderungen der Einstellungen ignorieren dürfte.
Den vollständigen Entscheidungsbaustein lesen
Der folgende JavaScript-Baustein enthält die tatsächlich ausgeführte Regel. Seine möglichen Ergebnisse sind Auslassen, Verschieben und Zur Übermittlung vorbereitet. Das letzte Ergebnis enthält eine neutrale Überschrift, einen allgemeinen Text und den festen Weg zur Mitteilungsübersicht. Es enthält keinen frei aus einem Ereignis übernommenen vertraulichen Inhalt. Die spätere Anwendung kann nach dem Öffnen die berechtigten Einzelheiten laden.
Der Kontext enthält außerdem die Ereigniskennungen bereits bekannter Annahmen. Eine solche Kennung verhindert in dieser Planung die erneute Vorbereitung desselben Ereignisses. Das ist eine Kontrolle eines übergebenen Zustands und keine atomare Warteschlange. Zwei gleichzeitig laufende Aufrufe mit demselben alten Zustand könnten beide denselben Vorschlag erzeugen. Genau diese Grenze muss vor einer schreibenden produktiven Integration ausdrücklich gelöst werden.
const TOPICS = new Set(['tasks','reviews']);
const MINUTE = 60_000;
const COOLDOWN = 15 * MINUTE;
const clock = new Intl.DateTimeFormat('de-DE', {
timeZone:'Europe/Berlin', hour:'2-digit', hourCycle:'h23'
});
const validTime = value => Number.isSafeInteger(value) && value >= 0 && value <= 8_000_000_000_000_000;
function isQuiet(at, quiet) {
if (!quiet.enabled) return false;
const hour = Number(clock.formatToParts(new Date(at)).find(p=>p.type==='hour').value);
return quiet.start < quiet.end ? hour >= quiet.start && hour < quiet.end
: hour >= quiet.start || hour < quiet.end;
}
function nextAllowed(at, quiet) {
if (!isQuiet(at,quiet)) return at;
let candidate = Math.floor(at/MINUTE)*MINUTE + MINUTE;
// UTC instants advance, while the local hour follows Berlin's time-zone rules.
for (let i=0;i<36*60;i++,candidate+=MINUTE) {
if (!isQuiet(candidate,quiet)) return candidate;
}
throw new Error('Kein zulässiges Zeitfenster im begrenzten Suchraum.');
}
export function decidePush(event, prefs, context) {
const invalid = {status:'skip',reason:'invalid_input'};
if (!event || !prefs || !context || !prefs.quiet) return invalid;
const q=prefs.quiet;
if (!/^DEMO-[0-9]{3}$/.test(event.id) || !TOPICS.has(event.topic)
|| !validTime(event.createdAt) || !validTime(event.expiresAt)
|| event.expiresAt <= event.createdAt || !validTime(context.now)
|| !Array.isArray(prefs.enabledTopics) || prefs.enabledTopics.some(t=>!TOPICS.has(t))
|| typeof q.enabled !== 'boolean' || !Number.isInteger(q.start) || !Number.isInteger(q.end)
|| q.start < 0 || q.start > 23 || q.end < 0 || q.end > 23 || q.start === q.end
|| !['default','denied','granted'].includes(context.permission)
|| typeof context.hasSubscription !== 'boolean' || !(context.acceptedEventIds instanceof Set)
|| (context.lastAcceptedAt !== null && (!validTime(context.lastAcceptedAt)
|| context.lastAcceptedAt > context.now))) return invalid;
if (event.createdAt > context.now) return {status:'skip',reason:'not_yet_created'};
if (event.expiresAt <= context.now) return {status:'skip',reason:'expired'};
if (!prefs.enabledTopics.includes(event.topic)) return {status:'skip',reason:'topic_disabled'};
if (context.permission !== 'granted') return {status:'skip',reason:'permission_missing'};
if (!context.hasSubscription) return {status:'skip',reason:'subscription_missing'};
if (context.acceptedEventIds.has(event.id)) return {status:'skip',reason:'already_accepted'};
const earliest = context.lastAcceptedAt === null ? context.now
: Math.max(context.now,context.lastAcceptedAt + COOLDOWN);
const at = nextAllowed(earliest,q);
if (at >= event.expiresAt) return {status:'skip',reason:'expires_before_window'};
if (at > context.now) return {status:'defer',until:at};
// Preparation only: no subscription endpoint, provider call or delivery claim.
return {status:'ready_to_submit',eventId:event.id,path:'/mitteilungen',
title:event.topic==='tasks'?'Neue Aufgabe':'Prüfung erforderlich',
body:'Weitere Angaben finden Sie in der App.'};
}
Verständliche Texte ohne unnötige Einzelheiten wählen
Die Beispielüberschrift heißt Neue Aufgabe oder Prüfung erforderlich. Der Text verweist auf weitere Angaben in der App. Damit wird der allgemeine Anlass verständlich, ohne Kundennamen, Vertragsinhalte oder interne Details auf einer möglicherweise mitlesbaren Fläche auszugeben. Ein neutraler Text ist allerdings kein vollständiger Datenschutzmechanismus. Welche Inhalte auf einem Gerät sichtbar sind, hängt auch von dessen tatsächlichen Einstellungen ab.
Ein guter Hinweis beantwortet im verfügbaren Platz, was passiert ist und welcher nächste Schritt sinnvoll ist. Er muss nicht jede Einzelheit wiederholen. Nach dem Öffnen sollte die Anwendung den aktuellen berechtigten Zustand zeigen. Ein gelöschter oder bereits abgeschlossener Vorgang benötigt eine verständliche Erklärung. Ein Klick auf eine alte Mitteilung darf nicht in einen beliebigen fremden Datensatz oder eine unverständliche Fehleransicht führen.
Der feste Weg zur Mitteilungsübersicht ist im kleinen Beispiel bewusst einfach. Eine produktive Anwendung kann einen gezielten Verweis auf einen Vorgang verwenden, muss aber die Berechtigung beim Öffnen erneut prüfen. Eine in der Nachricht enthaltene Kennung ersetzt diese Prüfung nicht. Auch ein scheinbar interner Link darf weder neue Rechte verleihen noch vertrauliche Angaben allein aufgrund seines Vorhandenseins ausgeben.
Vorbereitet, angenommen und gelesen auseinanderhalten
Unsere Funktion beendet ihre Aufgabe vor dem eigentlichen Versand. Sie ruft keinen Browserdienst, keinen Android-Dienst und keinen Pushanbieter auf. Der Zustand ready_to_submit bedeutet deshalb nur, dass die gezeigten Produktregeln aktuell passen. Erst die spätere Integration kann einen Übermittlungsversuch unternehmen. Dessen Antwort muss wiederum mit ihrer tatsächlichen Bedeutung gespeichert und ausgewertet werden.
Eine Annahme durch einen Dienst kann für Wiederholungsregeln wichtig sein, ist aber keine Lesebestätigung. Ein Gerät kann später offline sein oder die Darstellung verändern. Eine Person kann den Hinweis ignorieren. Daraus folgt, dass eine fachliche Aufgabe nicht allein durch das Absenden oder Öffnen einer Nachricht als erledigt gelten darf. Der tatsächliche Bearbeitungszustand gehört in die Anwendung.
Auch beim verlorenen Rückkanal nach einer Annahme entstehen eigene Wiederholungsfragen. Der reine Planungsbaustein löst diese nicht. Eine reale Warteschlange braucht eindeutige Kennungen, atomare Reservierung und nachvollziehbare Übergänge zum Versanddienst. Welche Form von Bestätigung vorliegt, wird passend zum Anbieter dokumentiert. Eine pauschale Aussage wie garantiert nur einmal zugestellt wäre durch unseren kleinen Test nicht gedeckt.
51 tatsächliche Prüfungen mit beiden Zeitumstellungen
Der Baustein wurde mit 51 Bedingungen in Node 24.22.1 ausgeführt. Die Fälle betreffen fehlende Erlaubnis, fehlendes Abonnement, abgeschaltete Themen, zukünftige oder abgelaufene Ereignisse, bekannte Annahmen und falsche Eingabetypen. Außerdem werden der exakte Abstand von fünfzehn Minuten, dessen verbleibende Minute und die Kombination mit dem Beginn der Ruhezeit kontrolliert. Keine dieser Prüfungen versendet eine echte Nachricht.
Für die Berliner Ruhezeit wurden ein gewöhnlicher Winterabend sowie die Frühlings- und Herbstumstellung 2026 durchgespielt. Der Morgen beginnt dabei jeweils um 7 Uhr Berliner Ortszeit. Der zugehörige UTC-Zeitpunkt unterscheidet sich. Zusätzlich werden der genaue Beginn um 22 Uhr, das genaue Ende um 7 Uhr und ein Ruhefenster am Tag geprüft. Die Abbildung verwendet die tatsächlichen Ergebnisse dieser Fälle.
Ein gesonderter Fall zeigt, dass die bloße Planung eine Kennung nicht als angenommen speichert. Ein wiederholter Aufruf mit unverändertem Zustand kann daher erneut vorbereitet zurückgeben. Das macht die fehlende atomare Versandsicherung ausdrücklich sichtbar. Weitere Fälle bestätigen, dass vertrauliche freie Ereignistexte nicht in die neutrale Nachricht kopiert werden und eine beliebige Dringlichkeitsmarkierung die Einstellungen nicht aushebelt.
Für eine echte App zusätzlich auf realen Geräten prüfen
Eine vollständige Integration braucht die konkrete Plattform. Im Web gehören unter anderem der sichere Kontext, der Service Worker, das Abonnement und dessen tatsächlicher Lebenszyklus dazu. Unter Android gelten die Anforderungen der jeweiligen Zielversion sowie Erlaubnisse und Kanaleinstellungen. Diese Begriffe sind keine austauschbaren Schalter. Sie werden anhand der aktuellen offiziellen Dokumentation und der tatsächlich unterstützten Geräte umgesetzt.
Die Abnahme folgt realen Aufgaben: Erlaubnis erteilen, verweigern, später ändern, Thema abschalten, Gerät zeitweise ohne Verbindung verwenden und einen alten Hinweis öffnen. Prüfen Sie auch, ob der Hinweis nach einer tatsächlichen Aufgabenänderung noch sinnvoll ist. Die reine Ausführung unserer Entscheidungsfunktion beantwortet diese Integrationsfragen nicht. Sie liefert dafür die klaren Produktregeln, die die Verbindung zur Plattform erhalten muss.
Betriebssysteme können Hintergrundverhalten und Darstellung unterschiedlich behandeln. Eine technische Funktionsprüfung sollte deshalb ihren Gerätestand und ihre beobachteten Ergebnisse festhalten. Behaupten Sie keine Zustellquote oder Sekundenfrist, wenn sie nicht unter passenden Bedingungen gemessen wurde. Gerade gewöhnliche Arbeitsmitteilungen brauchen eine verlässliche Übersicht innerhalb der Anwendung, damit ihre fachliche Aufgabe nicht vom zufälligen Wahrnehmen einer Unterbrechung abhängt.
Die Qualität anhand von Aufgaben statt bloßen Klickzahlen beurteilen
Eine häufig geöffnete Nachricht ist nicht automatisch hilfreich. Vielleicht war ihr Text so unklar, dass Menschen jedes Mal nachsehen mussten. Fragen Sie, ob der Hinweis einen relevanten Schritt erleichtert hat und ob er zum richtigen Zeitpunkt kam. Beobachten Sie Abmeldungen, Beschwerden und unnötige Wiederholungen. Solche Befunde helfen, Anlass, Text und Häufigkeit gezielt zu verbessern.
Für diese Bewertung sind sparsame passende Daten sinnvoll. Aus Zustellversuchen sollte nicht ungefragt ein umfassendes Bewegungsprofil der Nutzung entstehen. Welche Auswertung erforderlich und zulässig ist, wird für die reale Anwendung gesondert geklärt. Unser Beispiel sammelt keine Nutzungsdaten und behauptet keine rechtliche Freigabe eines Benachrichtigungskonzepts. Es zeigt nur, wie die beschriebenen Regeln technisch nachvollziehbar ausgeführt werden.
Eine kleine gut benannte Themenauswahl und ein verständlicher Ruhezeitvertrag können hilfreicher sein als viele schwer erklärbare Sonderstufen. Legen Sie für jede zusätzliche Ausnahme dar, welches Nutzerproblem sie löst. Wenn niemand den Unterschied zwischen zwei Kategorien beschreiben kann, entsteht wahrscheinlich zusätzliche Verwaltung ohne klaren Nutzen. Die sinnvolle Einheit bleibt der tatsächliche Anlass und seine Wirkung auf die empfangende Person.
Eine Ruhezeit ist eine Produktregel und keine Gerätefernsteuerung
Das errechnete Zeitfenster bestimmt in unserem Baustein nur, wann die Anwendung einen gewöhnlichen Hinweis vorbereiten würde. Es ändert weder die Lautstärke des Geräts noch dessen eigene Nicht-stören-Einstellungen. Solche Ebenen bleiben getrennt. Auch außerhalb der gewählten Ruhezeit kann das Betriebssystem eine Mitteilung anders darstellen oder zurückhalten. Eine im Produkt erlaubte Uhrzeit ist deshalb kein Versprechen über eine sichtbare oder hörbare Unterbrechung.
Diese Unterscheidung hilft auch beim Erklären der Einstellungen. Eine Person soll verstehen, welche Kategorie sie auswählt und welche Zeitregel die Anwendung darauf anwendet. Die Geräteeinstellungen können zusätzlich wirken. Nach einer Änderung wird ein wartender Hinweis vor seiner Verarbeitung erneut betrachtet. Für Support und Abnahme ist dadurch klar, ob ein Produktfilter, eine fehlende Berechtigung oder die tatsächliche Plattform untersucht werden muss. Die Benennung des jeweiligen Zustands verhindert unnötige Vermutungen über verlorene Nachrichten.
Eine Pflegevereinbarung für Ereignisse und Vorlagen festlegen
Mitteilungen gehören zur Produktpflege. Wenn sich der Status einer Aufgabe ändert, kann ein früherer Auslöser überholt sein. Wenn neue Themen hinzukommen, müssen Auswahl, Voreinstellungen und Erklärung zusammenpassen. Wenn eine Vorlage überarbeitet wird, darf sie keine vertraulichen Details aus neu ergänzten Feldern übernehmen. Die neutrale Vorlage unseres Beispiels macht diese Grenze bewusst sichtbar und leicht überprüfbar.
Dokumentieren Sie die Bedeutung jedes Zustands. Ausgelassen ist kein Fehler des Versanddienstes. Verschoben ist kein angenommener Auftrag. Angenommen ist keine fachlich erledigte Aufgabe. Diese Begriffe helfen bei Support und Wartung, weil ein Problem dann an der richtigen Stelle untersucht wird. Ohne solche Trennung kann ein fehlender Hinweis fälschlich als verlorene Aufgabe erscheinen oder umgekehrt eine unbearbeitete Aufgabe als abgeschlossen gelten.
Gute Push-Nachrichten ergänzen eine verständliche Anwendung. Sie haben einen konkreten Anlass, respektieren Auswahl und Zeitpunkt und führen zu einer passenden nächsten Handlung. Der vollständige Entscheidungsbaustein ist dafür eine begrenzte überprüfbare Grundlage. Erst die gesondert geprüfte Verbindung zu Plattform, Warteschlange und tatsächlichem Arbeitsprozess macht daraus ein verlässliches Benachrichtigungsangebot für die eigenen Nutzer.
Zustände richtig einordnen
| Ergebnis | Bedeutung im Beispiel |
|---|---|
| Auslassen | Zum Beispiel abgelaufen, ausgeschaltet oder ohne Erlaubnis |
| Verschieben | Nächsten passenden Zeitpunkt ermitteln, später erneut prüfen |
| Zur Übermittlung vorbereitet | Produktregeln passen, noch kein Versandversuch |
| Vom Dienst angenommen | Äußerer Zustand für Abstand und Wiederholung, kein Lesebeleg |
| Aufgabe erledigt | Eigenständiger fachlicher Zustand in der Anwendung |
Checkliste für verständliche Hinweise
- Relevanten Anlass und nächsten Schritt benennen.
- Nutzen vor der Systemabfrage erklären.
- Themenwahl und Systemerlaubnis getrennt behandeln.
- Verweigerung respektieren und In-App-Aufgabe erreichbar halten.
- Erzeugungszeit, Ablauf und Ruhezeit ausdrücklich festlegen.
- Mindestabstand vor der Ruhezeitentscheidung berücksichtigen.
- Vor späterem Versand Einstellungen und Gültigkeit erneut prüfen.
- Vertrauliche Inhalte aus der neutralen Vorlage heraushalten.
- Annahme, Anzeige, Lesen und Bearbeitung nicht gleichsetzen.
- Warteschlange und tatsächliche Plattform auf realen Geräten gesondert prüfen.
Quellen und Prüfstand
Primärquellen am 09.11.2026 geprüft. Eigener fiktiver Entscheidungsbaustein mit 51 tatsächlich ausgeführten Node-Bedingungen. Keine Push-Nachricht verschickt, kein realer Plattformempfang gemessen und keine Notfall- oder Zustellgarantie.
