Re: [Webpush] The Push Experience

[Luke Crouch <[e-mail]>]

Just my $0.02 ...

I spent the better part of 2-3 weeks in January learning how web push
messages work, and yes - I had absorb notifications, service workers, push
api, and vapid. I updated some MDN docs and examples along the way, and
tried to contribute patches to libraries where I could.

But, adding *another* spec at this point feels too much like
https://xkcd.com/927/.

I'd personally rather spend time coding the best push experience into
*libraries* like the node module and the wordpress plugin to make it
accessible to more developers.

-L

On Wed, Feb 24, 2016 at 10:44 PM, Benjamin Bangert <[e-mail]>
wrote:

> This may not be entirely on-topic for the webpush ietf spec per-se,
> but I know a lot of the right people are on this list, so I'm going to
> throw this out here. If this was already proposed elsewhere, and
> there's work proceeding on it, great, link me to it so we can choose a
> version to support. :)
>
> First, a little background.
>
> Almost a month ago, Firefox 44 was released which included Push
> support along with data payloads per the recent WebPush draft 02.
> Since its release, we've seen some interesting uses of it, the least
> of which was lots of dropped messages due to missing TTL headers which
> the recent spec additions remedy.
>
> The most glaring issue though, is some of the difficulty from early
> adopters actually trying to use it. This shouldn't be too surprising,
> because to provide a compelling Push experience, a developer must
> understand and utilize at least 4 specs, possibly 5...
>
> DOM API's
>
> Notification API: https://notifications.spec.whatwg.org/
> ^^ There's also WebNotification API on W3C, how do developers ever
> figure this out??
>
> Service Worker API: https://www.w3.org/TR/service-workers/
> Push API: https://www.w3.org/TR/push-api/
>
>
> IETF
> WebPush: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/
>     Dep, HTTP Encryption:
> http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00
> VAPID: https://datatracker.ietf.org/doc/draft-thomson-webpush-vapid/
>     Dep, JWT: http://tools.ietf.org/html/rfc7519
>
> (Additional Dep. specs left out)
>
> This is.... rather overwhelming to many web developers. Nevermind
> trying to figure out what drafts of what specs each browser has
> actually implemented. So far we have already seen libraries drop to
> the lowest common denominator, which so far means we have not been
> carrying data payloads even though Firefox supports it, because Chrome
> does not.
>
> This doesn't include how you ask for permissions for these things,
> because technically the Notification permission is separate from the
> Push permission, but afaik, both Chrome and Firefox will accept one of
> them as both to reduce clutter. So you might have accepted
> notifications without knowing you get push when the tab is closed,
> though lots of users probably can't make that distinction..... ugh.
> How these permissions are squashed, and for which browsers, appears to
> be completely ignored by the docs I've seen. Do the doc writers even
> realize browsers are squashing these permissions?
>
> None of these specs speak to the user experience. Does the service
> backing my browser allow 200 or 2000 notifications to be queued? Will
> they all be shown? Do I want them to be? Does the browser implement
> safeguards to prevent my screen from being flooded with these? Is
> there a spec dictating the UX for how to handle 100 queued
> notifications in a way that doesn't make the user immediately delete
> the program (like the ask for permission spec)?
>
> Even ignoring the above paragraph, which some could perhaps consider a
> browser detail that should not be mandated (so we can all compete on
> how compelling our notification spam management is), there's more
> important questions for our developers. How do I code this in a way
> that works on more than one browser given there's 4-5 API's at various
> draft states implemented at different stages in each browser?
>
> For that last question specifically, I'm proposing there a
> meta-specification, perhaps called the Push Experience (I'm bad at
> naming specs, no clever initials like VAPID), which essentially acts
> as a global version pegging for the various spec dependencies needed
> for a good Push experience.
>
> I.e.
>
> Push Experience Draft 1:
>   - Notification API Draft N:
>   - Service Worker API Draft Z:
>
>   ....
>
> This way it's clearly documented to a developer what the overall set
> of available API's they can work with are, as a base minimum for each
> browser. I'm not a spec-writer myself, so I don't even know what group
> this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec
> pegging specs from a variety of groups together to provide a cohesive
> whole that a developer won't lose their mind over implementing. I'm
> not sure there's much precedent for this, as I haven't heard of any
> other emerging web tech's that involve so many specs in such a variety
> of locations (back-end and front-end web dev).
>
> I'd be happy to collaborate on this, or for some others to take over
> this entirely, as I do believe having something like this is very
> important to developers attempting to use Push. I'm not sure what the
> appropriate venue for something of this nature to be, since it would
> appear to tie together specs in at least 3 different spec groups.
> Maybe it’s not a formal spec at all, but some other collaboration to
> agree on minimum definitions for each phase, like the ACID 2 vs. ACID
> 3 browser tests so that a developer could easily see ‘How ready is my
> browser for a Push Experience?’.
>
> Thoughts?
>
> Cheers,
> Ben
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>