Manchmal ist das Auf und Ab der Webtechnologie faszinierend. Service Worker sind da, und neben dem Offline-Netzwerk (lesen Sie Jeremy's Buch), was vielleicht ihr bestes Merkmal ist, können sie Push-Benachrichtigungen über die Push API ermöglichen.
Ich verstehe den (wortwörtlich gemeinten) Push, das geschehen zu lassen, vollkommen. Es gibt eine allgegenwärtige Stimmung, dass wir wollen, dass das Web gewinnt, wie es in dieser Branche auch sein sollte. Verlieren im Web bedeutet, auf all den verschiedenen Plattformen nativen Apps zu unterliegen. Native Apps sind nichts Böses – sie sind lediglich wettbewerbsfähig und exklusiv auf eine Weise, wie es das Web nicht ist. Das Web zu einer tragfähigen Plattform für jede Art von „App“ zu machen, ist ein Gewinn für uns und ein Gewinn für die Menschen.
Eine Sache, die native Apps gut können, sind Push-Benachrichtigungen, was ihnen einen Wettbewerbsvorteil verschafft. Einige Entwickler entscheiden sich deshalb für Native-Apps. Aber jetzt, wo wir sie tatsächlich im Web haben, gibt es Widerstand aus der Community und sogar von den Browsern selbst. Firefox unterstützt sie und führte dann eine Benutzereinstellung ein, um sie vollständig zu blockieren.
Wir sehen Artikel wie Moses Kims Don’t @ me
Push-Benachrichtigungen sind ein klassisches Beispiel dafür, wie gute UX-Absichten schiefgehen, weil wir keine Grenzen kennen.
Nur sehr wenige Leute preisen Push-Benachrichtigungen in den Himmel. Und doch! Jeremy Keith schrieb über ein großartiges Experiment von Sebastiaan Andeweg. Anstatt einer aufdringlichen und störenden Push-Benachrichtigung…
Hier ist, was Sebastiaan untersuchen wollte: Was wäre, wenn dieser letzte Schritt nicht so aufdringlich wäre? Hier ist der alternative Ablauf, den er testen wollte
- Eine Website fordert den Benutzer auf, die Erlaubnis zum Senden von Push-Benachrichtigungen zu erteilen.
- Der Benutzer erteilt die Erlaubnis.
- Eine Menge komplizierter Dinge passieren im Hintergrund.
- Wenn die Website das nächste Mal etwas Relevantes veröffentlicht, sendet sie eine Push-Nachricht mit den Details der neuen URL.
- Der Service Worker des Benutzers empfängt die Push-Nachricht (auch wenn die Seite nicht geöffnet ist).
- Der Service Worker ruft den Inhalt der in der Push-Nachricht angegebenen URL ab und speichert die Seite im Cache. Leise.
Es hat funktioniert.
Stellen Sie sich eine PWA-Podcast-App vor, die offline funktioniert und leise neue Podcasts empfängt und zwischenspeichert. Super. Jetzt brauchen wir ein Berechtigungsmodell, das stille Benachrichtigungen zulässt.
Update: Hier ist Sebastiaan Andewegs Folgeartikel PushAPI ohne Benachrichtigungen, in dem er auf die Denkweise, den Code und die Demo hinter all dem eingeht.
Ich finde den ersten Schritt aufdringlich. Was ist störender und nutzloser als eine Benachrichtigung? Eine Benachrichtigung über die Erlaubnis zu Benachrichtigungen.
Ich stimme zu, es ist ein wenig vermessen. Im Beispiel der Podcast-Web-App wäre es perfekt, eine nicht aufgeforderte Zustimmung zu den stillen Updates einzuholen.