Re: [Webpush] The Push Experience

[Benjamin Bangert <[e-mail]>]

This wouldn't be a new spec, it'd mainly be a way to see what versions
of which specs various browsers/push-services had implemented in which
browser versions.

Maybe a website that just indicates what features of which specs are
supported on which browsers, ala:
https://html5test.com/

And indicate what features are supported by the Push-Service for that browser.

Where you can see at a glance what features are available for which specs.

Cheers,
Ben

On Thu, Feb 25, 2016 at 8:06 AM, Luke Crouch <[e-mail]> wrote:
> 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
>
>