Re: [whatwg] Notifications improvements
On Aug 11, 2014 8:38 AM, "Peter Beverloo" wrote:
> On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson wrote:
> You raise an interesting question. Given the following notification:
>
> var notification = new Notification('Title', {
> body: 'Hello, world!',
> icon: '/my-icon.png',
> items: [
> { title: 'Message 1', body: 'Contents of message 1' },
> { title: 'Message 2', body: 'Contents of message 2' },
> { title: 'Message 3', body: 'Contents of message 3' }
> ],
> buttons: [
> 'Reply',
> 'Reply to all',
> 'Forward'
> ],
> date: new Date('2014-08-11T16:35:00'),
> progress: 40
> });
>
> What do we expect to be displayed?
I agree, this is a very interesting question. My thinking had been
that this should be supported. But I hadn't thought of that not all
platforms that can render a progress bar can render one at the same
time as a bullet list, or a set of buttons.
And then there's of course the question how the above would be
rendered, I.e. does the progress bar go above or below the list? Or is
that UA defined.
Suggestions for how to deal with this is definitely welcome.
I think we can expect that the "date" is simply displayed next to the
notification. Just like the icon is. That's how every notification
system I can find do it. Dates really are more about adjusting UI
which is already there, rather than adding new UI. So I would expect
that to mix fine with all other types of data.
Buttons, progressbar and lists are indeed a problem though. Does
anyone know what limitations we have as far as platforms go?
At a first glance, it seems like we might be able to get away with
defining that buttons are always at the bottom, and progress bars are
just above buttons but below everything else. But quite possibly
things aren't that simple.
Lists are trickier. They even seem tricky on their own. Do they go
before or after the text body? It seems like you might even want to
have a list in with text both before and after. Or should we say that
you can't have lists at the same time as a text body?
/ Jonas
Re: [whatwg] Notifications improvements
On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson wrote:
> On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo
> wrote:
> > Hi Andrew,
> >
> > On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson
> wrote:
> >>
> >> On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren
> >> wrote:
> >> > On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson
> >> > wrote:
> >> >> I understand your concern that is driving this proposal: you don't
> >> >> want to provide rich APIs that can't be well implemented on every
> >> >> platform, and thereby fragment the web platform. I just don't want to
> >> >> see us go down this path of adding these new notification types that
> >> >> are so limited in ability that people will just keep using general
> >> >> notifications anyway - I'd rather just stick with the existing API.
> >> >
> >> > Are you unenthusiastic about any of the proposed additions (what about
> >> > those already added?) or is this more about the more "complex"
> >> > features such as indication of progress?
> >>
> >> I'm (somewhat) unenthusiastic about the new semantic types, because
> >> I'm not sure they'd get enough uptake to be worth the effort to
> >> implement (note that this is just my personal opinion - I'm no longer
> >> as heavily involved in the notification work within Chromium, so Peter
> >> B's opinion carries much more weight than mine when it comes to
> >> determining what we'd implement).
> >
> >
> > I find myself being in favor of the semantic types.
> >
> > The primary reason for this is that it allows us to provide a much more
> > consistent user experience, especially on platforms where we don't
> control
> > rendering of the notification, compared to HTML notifications. On Chrome
> for
> > Android we want to provide for a consistent user experience, where
> > notifications should be visually indistinguishable (aside from clarifying
> > the origin) from those created by native apps. The proposed semantic
> types
> > would get us there.
> >
> > Furthermore, support for HTML notifications will be much more difficult
> to
> > implement across the board. Some mobile OSes, notably Firefox OS and iOS,
> > wouldn't support this at all. Others, such as Android, theoretically
> could
> > support it, but won't because it means creating an entire WebView --
> causing
> > very significant memory pressure on already resource constrained devices.
>
> To be clear, I'm not arguing for HTML notifications - as I said in my
> original post to this thread, HTML notifications were removed from the
> spec for various good reasons. But I think it's a mistake to just bake
> in canned notification types. What if a developer wants a progress bar
> with a cancel button? A progress bar with a timestamp? A list
> notification that contains an event with timestamp? Or some other
> different notification that doesn't specifically match one of your
> curated templates, but could easily be built if you gave him a
> lower-level set of primitives?
You raise an interesting question. Given the following notification:
var notification = new Notification('Title', {
body: 'Hello, world!',
icon: '/my-icon.png',
items: [
{ title: 'Message 1', body: 'Contents of message 1' },
{ title: 'Message 2', body: 'Contents of message 2' },
{ title: 'Message 3', body: 'Contents of message 3' }
],
buttons: [
'Reply',
'Reply to all',
'Forward'
],
date: new Date('2014-08-11T16:35:00'),
progress: 40
});
What do we expect to be displayed?
I *think* Android can mix and match some of those, but expect at least
progress bars and lists of items to be mutually exclusive. I don't have a
good answer for this right now. UAs rendering their own notifications could
support this more easily, but it will still raise interesting UX questions.
Thanks,
Peter
Re: [whatwg] Notifications improvements
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo wrote:
> Hi Andrew,
>
> On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson wrote:
>>
>> On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren
>> wrote:
>> > On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson
>> > wrote:
>> >> I understand your concern that is driving this proposal: you don't
>> >> want to provide rich APIs that can't be well implemented on every
>> >> platform, and thereby fragment the web platform. I just don't want to
>> >> see us go down this path of adding these new notification types that
>> >> are so limited in ability that people will just keep using general
>> >> notifications anyway - I'd rather just stick with the existing API.
>> >
>> > Are you unenthusiastic about any of the proposed additions (what about
>> > those already added?) or is this more about the more "complex"
>> > features such as indication of progress?
>>
>> I'm (somewhat) unenthusiastic about the new semantic types, because
>> I'm not sure they'd get enough uptake to be worth the effort to
>> implement (note that this is just my personal opinion - I'm no longer
>> as heavily involved in the notification work within Chromium, so Peter
>> B's opinion carries much more weight than mine when it comes to
>> determining what we'd implement).
>
>
> I find myself being in favor of the semantic types.
>
> The primary reason for this is that it allows us to provide a much more
> consistent user experience, especially on platforms where we don't control
> rendering of the notification, compared to HTML notifications. On Chrome for
> Android we want to provide for a consistent user experience, where
> notifications should be visually indistinguishable (aside from clarifying
> the origin) from those created by native apps. The proposed semantic types
> would get us there.
>
> Furthermore, support for HTML notifications will be much more difficult to
> implement across the board. Some mobile OSes, notably Firefox OS and iOS,
> wouldn't support this at all. Others, such as Android, theoretically could
> support it, but won't because it means creating an entire WebView -- causing
> very significant memory pressure on already resource constrained devices.
To be clear, I'm not arguing for HTML notifications - as I said in my
original post to this thread, HTML notifications were removed from the
spec for various good reasons. But I think it's a mistake to just bake
in canned notification types. What if a developer wants a progress bar
with a cancel button? A progress bar with a timestamp? A list
notification that contains an event with timestamp? Or some other
different notification that doesn't specifically match one of your
curated templates, but could easily be built if you gave him a
lower-level set of primitives?
>
> Implementation wise, Chrome recently switched to rendering Notifications
> using a new message center implementation, which already supports rich data
> such as progress bars, timestamps, lists and buttons. On Android many of
> these features will come down to calling an extra method on the Java
> Notification.Builder.
>
>> I am quite enthusiastic about adding support in the API around
>> allowing users to interact with notifications after the parent page
>> has closed, however.
>>
>> >
>> > Having a new field timestamp that carries a particular point in time
>> > related to the message seems quite useful for instance and not very
>> > intrusive.
>>
>> Perhaps I'm not understanding how this would be used. What would such
>> a notification look like for (say) a calendar event ("Your 1PM meeting
>> starts in 5 minutes") versus a countdown timer ("In 73 seconds, your
>> hard boiled egg will be done cooking")? Would we have to provide a
>> format string so the UA knows where to inject the time remaining, or
>> would it always have to be put at the end? Do we need to specify
>> granularity of updates (i.e. if I have a stopwatch app, I probably
>> want to update every second, but for a calendar app, updating every 5
>> minutes is probably sufficient, until we get down to the last 5
>> minutes)?
>
>
> I would argue that this is a feature that should be defined by the UA or
> platform. I'm not sure whether using a counting notification is the right
> way to implement a count-down -- I would expect normal, foreground UI
> displaying a counter, and a notification if that UI was moved to the
> background and the counter expired.
>
> The timestamp doesn't necessarily need to be in the future either.
>
>> At least for me, a calendar notification that is constantly updating
>> its countdown every minute but has no snooze functionality is actually
>> a mis-feature, because it's distracting.
>
>
> The notification wouldn't visually re-announce itself on every update.
>
>> Again, I don't want to be overly negative about this - maybe there are
>> use cases like list notifications where the new API would be really
>> useful, but as soon as I start thinking about more complex display
>> scen
Re: [whatwg] Notifications improvements
On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo wrote: > I think the benefit of being able to closely match the UI and UX of native > notifications on the platforms is something that's enabled by using > declarative properties, whereas that would be near impossible to do with > HTML notifications. As long as advanced features, especially more compatible > ones (say, buttons or timestamps) can be feature detected by developers so > that they can provide a fallback when they're not available, I would be in > favor of extending the future set with Jonas' declarative proposals. Cool! I had not though about the need to feature detect. At least for progress/list/timestamp. My thinking had been to require that the UA provide a textual fallback on platforms that can't render those widgets natively. However I think you are right that we'll need feature detection here. We might even need two types of it. First of all not all UAs are going to implement all of these features right away. So obviously they won't provide any fallback rendering either. Detecting this seems important. Second, it might be good to enable pages to detect platforms where a progress bar is rendered as a native progress bar, rather than as text fallback. This way the page can choose not to use a progress bar and instead create its own fallback. An important point here is for pages that don't choose to test for the latter, will still get a useful rendering of the notification. / Jonas
Re: [whatwg] Notifications improvements
Hi Andrew,
On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson wrote:
> On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren
> wrote:
> > On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson
> wrote:
> >> I understand your concern that is driving this proposal: you don't
> >> want to provide rich APIs that can't be well implemented on every
> >> platform, and thereby fragment the web platform. I just don't want to
> >> see us go down this path of adding these new notification types that
> >> are so limited in ability that people will just keep using general
> >> notifications anyway - I'd rather just stick with the existing API.
> >
> > Are you unenthusiastic about any of the proposed additions (what about
> > those already added?) or is this more about the more "complex"
> > features such as indication of progress?
>
> I'm (somewhat) unenthusiastic about the new semantic types, because
> I'm not sure they'd get enough uptake to be worth the effort to
> implement (note that this is just my personal opinion - I'm no longer
> as heavily involved in the notification work within Chromium, so Peter
> B's opinion carries much more weight than mine when it comes to
> determining what we'd implement).
>
I find myself being in favor of the semantic types.
The primary reason for this is that it allows us to provide a much more
consistent user experience, especially on platforms where we don't control
rendering of the notification, compared to HTML notifications. On Chrome
for Android we want to provide for a consistent user experience, where
notifications should be visually indistinguishable (aside from clarifying
the origin) from those created by native apps. The proposed semantic types
would get us there.
Furthermore, support for HTML notifications will be much more difficult to
implement across the board. Some mobile OSes, notably Firefox OS and iOS,
wouldn't support this at all. Others, such as Android, theoretically could
support it, but won't because it means creating an entire WebView --
causing very significant memory pressure on already resource constrained
devices.
Implementation wise, Chrome recently switched to rendering Notifications
using a new message center implementation, which already supports rich data
such as progress bars, timestamps, lists and buttons. On Android many of
these features will come down to calling an extra method on the Java
Notification.Builder.
I am quite enthusiastic about adding support in the API around
> allowing users to interact with notifications after the parent page
> has closed, however.
>
> >
> > Having a new field timestamp that carries a particular point in time
> > related to the message seems quite useful for instance and not very
> > intrusive.
>
> Perhaps I'm not understanding how this would be used. What would such
> a notification look like for (say) a calendar event ("Your 1PM meeting
> starts in 5 minutes") versus a countdown timer ("In 73 seconds, your
> hard boiled egg will be done cooking")? Would we have to provide a
> format string so the UA knows where to inject the time remaining, or
> would it always have to be put at the end? Do we need to specify
> granularity of updates (i.e. if I have a stopwatch app, I probably
> want to update every second, but for a calendar app, updating every 5
> minutes is probably sufficient, until we get down to the last 5
> minutes)?
>
I would argue that this is a feature that should be defined by the UA or
platform. I'm not sure whether using a counting notification is the right
way to implement a count-down -- I would expect normal, foreground UI
displaying a counter, and a notification if that UI was moved to the
background and the counter expired.
The timestamp doesn't necessarily need to be in the future either.
At least for me, a calendar notification that is constantly updating
> its countdown every minute but has no snooze functionality is actually
> a mis-feature, because it's distracting.
>
The notification wouldn't visually re-announce itself on every update.
Again, I don't want to be overly negative about this - maybe there are
> use cases like list notifications where the new API would be really
> useful, but as soon as I start thinking about more complex display
> scenarios, I immediately want to start having more control over the
> formatting of the text being displayed, and i wouldn't get that with
> this proposal.
>
I think the benefit of being able to closely match the UI and UX of native
notifications on the platforms is something that's enabled by using
declarative properties, whereas that would be near impossible to do with
HTML notifications. As long as advanced features, especially more
compatible ones (say, buttons or timestamps) can be feature detected by
developers so that they can provide a fallback when they're not available,
I would be in favor of extending the future set with Jonas' declarative
proposals.
Thanks,
Peter
Re: [whatwg] Notifications improvements
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren wrote:
> On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson wrote:
>> I understand your concern that is driving this proposal: you don't
>> want to provide rich APIs that can't be well implemented on every
>> platform, and thereby fragment the web platform. I just don't want to
>> see us go down this path of adding these new notification types that
>> are so limited in ability that people will just keep using general
>> notifications anyway - I'd rather just stick with the existing API.
>
> Are you unenthusiastic about any of the proposed additions (what about
> those already added?) or is this more about the more "complex"
> features such as indication of progress?
I'm (somewhat) unenthusiastic about the new semantic types, because
I'm not sure they'd get enough uptake to be worth the effort to
implement (note that this is just my personal opinion - I'm no longer
as heavily involved in the notification work within Chromium, so Peter
B's opinion carries much more weight than mine when it comes to
determining what we'd implement).
I am quite enthusiastic about adding support in the API around
allowing users to interact with notifications after the parent page
has closed, however.
>
> Having a new field timestamp that carries a particular point in time
> related to the message seems quite useful for instance and not very
> intrusive.
Perhaps I'm not understanding how this would be used. What would such
a notification look like for (say) a calendar event ("Your 1PM meeting
starts in 5 minutes") versus a countdown timer ("In 73 seconds, your
hard boiled egg will be done cooking")? Would we have to provide a
format string so the UA knows where to inject the time remaining, or
would it always have to be put at the end? Do we need to specify
granularity of updates (i.e. if I have a stopwatch app, I probably
want to update every second, but for a calendar app, updating every 5
minutes is probably sufficient, until we get down to the last 5
minutes)?
At least for me, a calendar notification that is constantly updating
its countdown every minute but has no snooze functionality is actually
a mis-feature, because it's distracting.
Again, I don't want to be overly negative about this - maybe there are
use cases like list notifications where the new API would be really
useful, but as soon as I start thinking about more complex display
scenarios, I immediately want to start having more control over the
formatting of the text being displayed, and i wouldn't get that with
this proposal.
Re: [whatwg] Notifications improvements
For what it's worth. I'm not actively working on notifications at the moment. If anything is about to be implemented please ping the relevant issue and I'll try to prioritize it somehow. More detailed design sketches appreciated. On Wed, Aug 6, 2014 at 12:16 AM, Jonas Sicking wrote: > The place that this has come up in FirefoxOS is when notifying about > incoming emails. We would like to display the sender and the subject > for each newly arrived email. > > At first this seemed like a pretty unusual edge case, but after > looking at chrome-apps notification API they had this exact feature. > So it seemed like this has come up elsewhere too. This is now https://github.com/whatwg/notifications/issues/21 > The goal of a Date field for notifications is quite different. It's to > enable a notification that's associated with an event that happend, or > is going to happen, at a different time than when the notification API > JS call happened. Ah yes, we discussed this but I forgot to track it somewhere: https://github.com/whatwg/notifications/issues/20 >>> We also need to keep state on the Notification object if the user has >>> clicked the notification or not. >> >> Why is that? > > Relying on the application to track this perfectly has two problems. > > First off it means that applications has to register a ServiceWorker > handler for all notification objects and run any logic related to > handling a click right away. Rather than simply handle it next time > the application is started, which would save on both CPU and battery. The current service worker proposal does not have a feature of having a handler per notification. Rather, you register for "notificationclick" and get an event for each such thing. Up to the discretion of the user agent of course. > Second, it's much more error prone to track this in application space > given potential for bugs, crashes and IO errors. If we do this it would be the first thing that would actually require changing a Notification object instance. At the moment the whole thing is static. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson wrote: > I understand your concern that is driving this proposal: you don't > want to provide rich APIs that can't be well implemented on every > platform, and thereby fragment the web platform. I just don't want to > see us go down this path of adding these new notification types that > are so limited in ability that people will just keep using general > notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more "complex" features such as indication of progress? Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Tue, Aug 5, 2014 at 11:44 PM, Jonas Sicking wrote: > On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson wrote: >> >> On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking wrote: >>> >>> On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson >>> wrote: >>> > >>> > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >>> >> >>> >> Hi All, >>> >> >>> >> We've on and off discussed various features added to notifications. >>> >> It'd be great to move forward with some of these improvements. >>> >> >>> >> I think the most low hanging fruit would be to add the following as >>> >> data that can be displayed in a notification: >>> >> >>> >> * Progress bar >>> >> * Lists of title/body pairs >>> >> * Date (for things like "event will happen in 10 minutes") >>> >> >>> > >>> > So, many of these cases were what the original HTMLNotification API was >>> > supposed to address. This was eventually shot down for a number of >>> > (good) >>> > reasons: too much complexity on the implementation side, and more >>> > importantly, the fact that these more complex notifications aren't >>> > compatible with various platform notification frameworks and so this >>> > would >>> > be a source of platform/UA incompatibility. It's not clear to me that >>> > re-adding support for these use cases one at a time as distinct >>> > notification >>> > types is really a good path forward, or that it's necessarily >>> > "low-hanging >>> > fruit" unless we have a good idea for how to deal with the >>> > platform-compatibility issue. >>> >>> Actually, given that the UA has a very high degree of semantic >>> understanding of these properties, I think it should be doable to >>> implement on top of all existing platform notification systems. In all >>> of the above cases you can come up with a reasonable string to add to >>> the end to render the content. This is what pages have to do right now >>> anyway. >> >> >> I had assumed from the examples you gave that the goal of these new >> notification types was to have dynamically updating notifications (progress >> bar, timestamps that update with a countdown to an event, etc), which it >> wasn't clear could be cleanly implemented across all platform notification >> systems without significant jank. > > For dates the idea is definitely to enable the notifications to be > dynamically updated by the platform. > > For progress bars my expectation was not that it would be > automatically updated. Instead it would be updated using the exact > same mechanism that we have for notifications today, i.e. using the > "tag" mechanism. So the jank would be the same whether OS > notifications supports rendering progress bars or if they are just > able to render text. OK, so the idea is that you'd display a new progress bar notification with the same tag as an existing progress bar notification, and the browser would see that they are the same and just update the progress bar? Or would we pull down and re-display a new progress bar? If we're just updating the existing progress bar, then I guess for compatibility, the old notification would still get the normal events as if it had been replaced? > > For lists the idea is not to update them any more or less than for > plain text content. Just like with text content pages will likely want > to update them occasionally, but that's not a core aspect of the > feature. > > >> The intent for things like progress bars >> would be that they have greater visibility than your typical "5 seconds and >> then hidden" email notification, which also may not be doable with many >> notification frameworks. > > This is a quite interesting idea. I hadn't thought of that. > >> I'm slightly dubious about adding >> new semantic notification types (I'd still rather give app developers the >> tools to build their own richer notifications instead of giving them a >> canned set), but it's definitely worth discussing further. > > I'm not sure I understand this argument. If you are concerned about > having poor fallback on platforms that can't render the UI components > discussed above, then surely that concern is even greater if we enable > pages to build their own rich notifications? I have a couple of concerns: 1) Anything more than plain text + icon notifications won't map well to native notification platforms. If we're going to build support in the API for something that isn't well supported by native notification platforms, then we should get the most bang for our buck and build something that's flexible enough to meet many use cases. 2) I don't feel like the limitations with the current API are addressed by adding 3-4 pre-canned notification types. I feel like the current notification API addresses a broad swath of use cases, and there's a long tail of unaddressed cases that we can't serve well with any pre-canned notification types - if we want to try to address those long-tail cases, then I'd rather have us address them with a flexible API that gives developers more control over the notificati
Re: [whatwg] Notifications improvements
On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren wrote: > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >> I think the most low hanging fruit would be to add the following as >> data that can be displayed in a notification: >> >> * Progress bar > > Tracked here: https://github.com/whatwg/notifications/issues/17 Sweet! >> * Lists of title/body pairs > > What exactly is this for? The place that this has come up in FirefoxOS is when notifying about incoming emails. We would like to display the sender and the subject for each newly arrived email. At first this seemed like a pretty unusual edge case, but after looking at chrome-apps notification API they had this exact feature. So it seemed like this has come up elsewhere too. >> * Date (for things like "event will happen in 10 minutes") > > Should this be part of a generic alarm API? The goal of the Alarm API is to enable a website to do some processing (and possibly open full UI) at a particular wallclock time. An alarm clock application is a primary example of this. The goal of a Date field for notifications is quite different. It's to enable a notification that's associated with an event that happend, or is going to happen, at a different time than when the notification API JS call happened. For example a calendar application might want to create a notification. The notification should be created and displayed to the user 10 minutes before the event is about to happen, but the timestamp shown next to the notification should at first say "in 10 minutes". As time passes the timestamp should change to "in 9 minutes" ... "in 5 minutes" ... "now" ... "1 minute ago" ...etc. The only way you could do that right now is to 10 minutes before the event happens create a notification which says "CoolMeeting in 10 minutes", then after a minute replace that with "CoolMeeting in 9 minutes" etc. This both has the problem that the application needs to constantly be running and replace the notification. It would also mean that the notification would render the platform provided timestamp. This might look something like "CoolMeeting in 10 minutes. Just now". Another use case is when creating notifications for text messages (or other messaging systems). A text message carries the time when it was created, which might be very different from when the message was received by the user's device. It would here be nice to immediately create a notification which says "Message from Anne, 6 minutes ago" without that again creating the double timestamp like "Message from Anne, 6 minutes ago. 2 minutes ago". >> We also need to keep state on the Notification object if the user has >> clicked the notification or not. > > Why is that? Relying on the application to track this perfectly has two problems. First off it means that applications has to register a ServiceWorker handler for all notification objects and run any logic related to handling a click right away. Rather than simply handle it next time the application is started, which would save on both CPU and battery. Second, it's much more error prone to track this in application space given potential for bugs, crashes and IO errors. / Jonas
Re: [whatwg] Notifications improvements
On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson wrote: > > On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking wrote: >> >> On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson >> wrote: >> > >> > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >> >> >> >> Hi All, >> >> >> >> We've on and off discussed various features added to notifications. >> >> It'd be great to move forward with some of these improvements. >> >> >> >> I think the most low hanging fruit would be to add the following as >> >> data that can be displayed in a notification: >> >> >> >> * Progress bar >> >> * Lists of title/body pairs >> >> * Date (for things like "event will happen in 10 minutes") >> >> >> > >> > So, many of these cases were what the original HTMLNotification API was >> > supposed to address. This was eventually shot down for a number of >> > (good) >> > reasons: too much complexity on the implementation side, and more >> > importantly, the fact that these more complex notifications aren't >> > compatible with various platform notification frameworks and so this >> > would >> > be a source of platform/UA incompatibility. It's not clear to me that >> > re-adding support for these use cases one at a time as distinct >> > notification >> > types is really a good path forward, or that it's necessarily >> > "low-hanging >> > fruit" unless we have a good idea for how to deal with the >> > platform-compatibility issue. >> >> Actually, given that the UA has a very high degree of semantic >> understanding of these properties, I think it should be doable to >> implement on top of all existing platform notification systems. In all >> of the above cases you can come up with a reasonable string to add to >> the end to render the content. This is what pages have to do right now >> anyway. > > > I had assumed from the examples you gave that the goal of these new > notification types was to have dynamically updating notifications (progress > bar, timestamps that update with a countdown to an event, etc), which it > wasn't clear could be cleanly implemented across all platform notification > systems without significant jank. For dates the idea is definitely to enable the notifications to be dynamically updated by the platform. For progress bars my expectation was not that it would be automatically updated. Instead it would be updated using the exact same mechanism that we have for notifications today, i.e. using the "tag" mechanism. So the jank would be the same whether OS notifications supports rendering progress bars or if they are just able to render text. For lists the idea is not to update them any more or less than for plain text content. Just like with text content pages will likely want to update them occasionally, but that's not a core aspect of the feature. > The intent for things like progress bars > would be that they have greater visibility than your typical "5 seconds and > then hidden" email notification, which also may not be doable with many > notification frameworks. This is a quite interesting idea. I hadn't thought of that. > I'm slightly dubious about adding > new semantic notification types (I'd still rather give app developers the > tools to build their own richer notifications instead of giving them a > canned set), but it's definitely worth discussing further. I'm not sure I understand this argument. If you are concerned about having poor fallback on platforms that can't render the UI components discussed above, then surely that concern is even greater if we enable pages to build their own rich notifications? My goal has been two-fold: * Don't limit the web to the lowest common denominator of the platforms on which it runs. * Don't encourage pages that simply don't work unless you use the right OS. The "pre canned" capabilities enable us to on OSs that have advanced capabilities enable web developers to take advantage of those for the most commonly requested notification content. While still enabling users on OSs that don't have such capabilities to still get a useful experience. / Jonas
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: > I think the most low hanging fruit would be to add the following as > data that can be displayed in a notification: > > * Progress bar Tracked here: https://github.com/whatwg/notifications/issues/17 > * Lists of title/body pairs What exactly is this for? > * Date (for things like "event will happen in 10 minutes") Should this be part of a generic alarm API? There's also a request for transient/toast notifications: https://github.com/whatwg/notifications/issues/11 > Second, we really need to figure out the story around handling user > clicking notifications after the user has closed the original page. There's a proposal for that in a separate thread: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0204.html > We need to change the GC behavior. Right now it seems like if a > Notification object is created, but no event listeners are attached, > because the page is expecting to use the SW event to listen for > clicks, the notification won't be kept alive and so the SW can't get > to any of its data. Notification objects can go away, but the notification concept cannot be GC'd. > We also need to keep state on the Notification object if the user has > clicked the notification or not. Why is that? > We should also consider enabling passing a URL to the Notification > constructor which is opened when the user clicks the notification. > Probably this should attempt to reuse an existing tab with said URL if > one is open. That might be an interesting way to let service workers spawn a new window. > Third, we should look at enabling minimal user input through the > Notification. It's very common for notifications to support having one > or more buttons that the user can click. It would also be good to > enable putting a simple text-input in the notification. This area is > definitely more complex though so happy to put this last. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking wrote: > On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson > wrote: > > > > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: > >> > >> Hi All, > >> > >> We've on and off discussed various features added to notifications. > >> It'd be great to move forward with some of these improvements. > >> > >> I think the most low hanging fruit would be to add the following as > >> data that can be displayed in a notification: > >> > >> * Progress bar > >> * Lists of title/body pairs > >> * Date (for things like "event will happen in 10 minutes") > >> > > > > So, many of these cases were what the original HTMLNotification API was > > supposed to address. This was eventually shot down for a number of (good) > > reasons: too much complexity on the implementation side, and more > > importantly, the fact that these more complex notifications aren't > > compatible with various platform notification frameworks and so this > would > > be a source of platform/UA incompatibility. It's not clear to me that > > re-adding support for these use cases one at a time as distinct > notification > > types is really a good path forward, or that it's necessarily > "low-hanging > > fruit" unless we have a good idea for how to deal with the > > platform-compatibility issue. > > Actually, given that the UA has a very high degree of semantic > understanding of these properties, I think it should be doable to > implement on top of all existing platform notification systems. In all > of the above cases you can come up with a reasonable string to add to > the end to render the content. This is what pages have to do right now > anyway. > I had assumed from the examples you gave that the goal of these new notification types was to have dynamically updating notifications (progress bar, timestamps that update with a countdown to an event, etc), which it wasn't clear could be cleanly implemented across all platform notification systems without significant jank. The intent for things like progress bars would be that they have greater visibility than your typical "5 seconds and then hidden" email notification, which also may not be doable with many notification frameworks. Anyhow, I'm very supportive of any efforts to deal with the whole notifications-for-closed-windows issue. I'm slightly dubious about adding new semantic notification types (I'd still rather give app developers the tools to build their own richer notifications instead of giving them a canned set), but it's definitely worth discussing further. > > This is different from generic HTML->text conversion I think, since > HTML is very rich and there's a bigger risk of generating unuseful > text. > One thing that we *could* do is to add API for detecting which of > these properties will be rendered "natively", and which ones will use > some form of UA-provided fallback. This way an advanced page could > compensate for lacking capabilities in more advanced ways, whereas > less advanced authors would get reasonably good automatic fallback. > > >> Second, we really need to figure out the story around handling user > >> clicking notifications after the user has closed the original page. > >> > >> At the very least we need the ability to send a message to a > >> ServiceWorker when the user clicks a notification. This way the SW can > >> decide if UI should be shown, and if so if an existing window can be > >> reused or not. > >> > >> SW integration will require some other changes too. > >> > >> We need to change the GC behavior. Right now it seems like if a > >> Notification object is created, but no event listeners are attached, > >> because the page is expecting to use the SW event to listen for > >> clicks, the notification won't be kept alive and so the SW can't get > >> to any of its data. > >> > >> We also need to keep state on the Notification object if the user has > >> clicked the notification or not. > >> > >> We should also consider enabling passing a URL to the Notification > >> constructor which is opened when the user clicks the notification. > >> Probably this should attempt to reuse an existing tab with said URL if > >> one is open. > >> > >> > >> Third, we should look at enabling minimal user input through the > >> Notification. It's very common for notifications to support having one > >> or more buttons that the user can click. It would also be good to > >> enable putting a simple text-input in the notification. This area is > >> definitely more complex though so happy to put this last. > >> > > I think if we want to address the "more complex data type" use cases > above, > > then this needs to be part of that proposal - for example, I'm not sure > how > > valuable having something like a "Date/Event" notification would be > without > > a "Snooze" button. > > I'm not sure that's true. Notifying that an event is going to happen > in 10 minutes would still be useful even if the user can't "snooze" > that notification. > >
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo wrote: > > On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking wrote: >> >> We need to change the GC behavior. Right now it seems like if a >> >> Notification object is created, but no event listeners are attached, >> because the page is expecting to use the SW event to listen for >> clicks, the notification won't be kept alive and so the SW can't get >> to any of its data. >> >> We also need to keep state on the Notification object if the user has >> clicked the notification or not. >> >> We should also consider enabling passing a URL to the Notification >> constructor which is opened when the user clicks the notification. >> Probably this should attempt to reuse an existing tab with said URL if >> one is open. > > > Notifications should just be serialized and re-created on demand, since they > can outlive both pages and workers. > > If a page creates a notification, events for which should be delivered to a > Service Worker, then won't be able to re-use the existing object anyway. We > can't rely on a SW to stay alive between [creating a notification, > interacting with the notification] either. Since the |data| property exists, > developers can use that (or the notification's title) instead of using the > equality operator. > > I believe we had some discussion about a launch URL earlier on. There are > various race conditions: what if the user presses twice on the notification > in quick succession - will we open the page twice? What is a page with that > URL has already been opened? What if there are two? Deferring to a Service > Workers solves these. The |notificationclick| event could be allowed to open > windows, too. I completely agree. The spec needs to separate the notion of a UI-visible notification, from the Notification object instance. / Jonas
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson wrote: > > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: >> >> Hi All, >> >> We've on and off discussed various features added to notifications. >> It'd be great to move forward with some of these improvements. >> >> I think the most low hanging fruit would be to add the following as >> data that can be displayed in a notification: >> >> * Progress bar >> * Lists of title/body pairs >> * Date (for things like "event will happen in 10 minutes") >> > > So, many of these cases were what the original HTMLNotification API was > supposed to address. This was eventually shot down for a number of (good) > reasons: too much complexity on the implementation side, and more > importantly, the fact that these more complex notifications aren't > compatible with various platform notification frameworks and so this would > be a source of platform/UA incompatibility. It's not clear to me that > re-adding support for these use cases one at a time as distinct notification > types is really a good path forward, or that it's necessarily "low-hanging > fruit" unless we have a good idea for how to deal with the > platform-compatibility issue. Actually, given that the UA has a very high degree of semantic understanding of these properties, I think it should be doable to implement on top of all existing platform notification systems. In all of the above cases you can come up with a reasonable string to add to the end to render the content. This is what pages have to do right now anyway. This is different from generic HTML->text conversion I think, since HTML is very rich and there's a bigger risk of generating unuseful text. One thing that we *could* do is to add API for detecting which of these properties will be rendered "natively", and which ones will use some form of UA-provided fallback. This way an advanced page could compensate for lacking capabilities in more advanced ways, whereas less advanced authors would get reasonably good automatic fallback. >> Second, we really need to figure out the story around handling user >> clicking notifications after the user has closed the original page. >> >> At the very least we need the ability to send a message to a >> ServiceWorker when the user clicks a notification. This way the SW can >> decide if UI should be shown, and if so if an existing window can be >> reused or not. >> >> SW integration will require some other changes too. >> >> We need to change the GC behavior. Right now it seems like if a >> Notification object is created, but no event listeners are attached, >> because the page is expecting to use the SW event to listen for >> clicks, the notification won't be kept alive and so the SW can't get >> to any of its data. >> >> We also need to keep state on the Notification object if the user has >> clicked the notification or not. >> >> We should also consider enabling passing a URL to the Notification >> constructor which is opened when the user clicks the notification. >> Probably this should attempt to reuse an existing tab with said URL if >> one is open. >> >> >> Third, we should look at enabling minimal user input through the >> Notification. It's very common for notifications to support having one >> or more buttons that the user can click. It would also be good to >> enable putting a simple text-input in the notification. This area is >> definitely more complex though so happy to put this last. >> > I think if we want to address the "more complex data type" use cases above, > then this needs to be part of that proposal - for example, I'm not sure how > valuable having something like a "Date/Event" notification would be without > a "Snooze" button. I'm not sure that's true. Notifying that an event is going to happen in 10 minutes would still be useful even if the user can't "snooze" that notification. / Jonas
Re: [whatwg] Notifications improvements
In principle I agree that the specification should be implementable by all major platforms. However, I also think that there is an important trade-off to make here, since they are an increasingly important part of the user experience offered by an applications -- most notably when applications can have background activities. Windows 8's Toast Notifications are the most basic ones, exactly matching what the Web Notification API provides today. Both iOS and Android have various features on top of this, with Android's notifications being much richer than most other platforms'. Some desktop user agents implement their own rendering, and therefore have much more freedom than having to defer to an operating system. I would love to be able to expose a reasonable subset of those features to users, but we'll have to be very conscious about the impact this can have in terms of interoperability. I don't think we should strictly hold back because of platforms which choose to be conservative in the Notification features they offer, as long as (1) developers can feature detect the differences, and (2) they can degrade gracefully. Perhaps we can start with investigating buttons? iOS 8's interactive notifications will introduce support for them. On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking wrote: > > Second, we really need to figure out the story around handling user > clicking notifications after the user has closed the original page. > > At the very least we need the ability to send a message to a > ServiceWorker when the user clicks a notification. This way the SW can > decide if UI should be shown, and if so if an existing window can be > reused or not. Yes. See my e-mail about this in May; we should continue discussing Service Worker integration there. Anne has yet to make the changes. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296806.html On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking wrote: > > We need to change the GC behavior. Right now it seems like if a > Notification object is created, but no event listeners are attached, > because the page is expecting to use the SW event to listen for > clicks, the notification won't be kept alive and so the SW can't get > to any of its data. > > We also need to keep state on the Notification object if the user has > clicked the notification or not. > > We should also consider enabling passing a URL to the Notification > constructor which is opened when the user clicks the notification. > Probably this should attempt to reuse an existing tab with said URL if > one is open. Notifications should just be serialized and re-created on demand, since they can outlive both pages and workers. If a page creates a notification, events for which should be delivered to a Service Worker, then won't be able to re-use the existing object anyway. We can't rely on a SW to stay alive between [creating a notification, interacting with the notification] either. Since the |data| property exists, developers can use that (or the notification's title) instead of using the equality operator. I believe we had some discussion about a launch URL earlier on. There are various race conditions: what if the user presses twice on the notification in quick succession - will we open the page twice? What is a page with that URL has already been opened? What if there are two? Deferring to a Service Workers solves these. The |notificationclick| event could be allowed to open windows, too. Thanks, Peter On Thu, Jul 10, 2014 at 9:04 AM, Andrew Wilson wrote: > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: > > > Hi All, > > > > We've on and off discussed various features added to notifications. > > It'd be great to move forward with some of these improvements. > > > > I think the most low hanging fruit would be to add the following as > > data that can be displayed in a notification: > > > > * Progress bar > > * Lists of title/body pairs > > * Date (for things like "event will happen in 10 minutes") > > > > > So, many of these cases were what the original HTMLNotification API was > supposed to address. This was eventually shot down for a number of (good) > reasons: too much complexity on the implementation side, and more > importantly, the fact that these more complex notifications aren't > compatible with various platform notification frameworks and so this would > be a source of platform/UA incompatibility. It's not clear to me that > re-adding support for these use cases one at a time as distinct > notification types is really a good path forward, or that it's necessarily > "low-hanging fruit" unless we have a good idea for how to deal with the > platform-compatibility issue. > > > > > > Second, we really need to figure out the story around handling user > > clicking notifications after the user has closed the original page. > > > > At the very least we need the ability to send a message to a > > ServiceWorker when the user clicks a notification. This way the SW can
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote: > Hi All, > > We've on and off discussed various features added to notifications. > It'd be great to move forward with some of these improvements. > > I think the most low hanging fruit would be to add the following as > data that can be displayed in a notification: > > * Progress bar > * Lists of title/body pairs > * Date (for things like "event will happen in 10 minutes") > > So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily "low-hanging fruit" unless we have a good idea for how to deal with the platform-compatibility issue. > > Second, we really need to figure out the story around handling user > clicking notifications after the user has closed the original page. > > At the very least we need the ability to send a message to a > ServiceWorker when the user clicks a notification. This way the SW can > decide if UI should be shown, and if so if an existing window can be > reused or not. > > SW integration will require some other changes too. > > We need to change the GC behavior. Right now it seems like if a > Notification object is created, but no event listeners are attached, > because the page is expecting to use the SW event to listen for > clicks, the notification won't be kept alive and so the SW can't get > to any of its data. > > We also need to keep state on the Notification object if the user has > clicked the notification or not. > > We should also consider enabling passing a URL to the Notification > constructor which is opened when the user clicks the notification. > Probably this should attempt to reuse an existing tab with said URL if > one is open. > > > Third, we should look at enabling minimal user input through the > Notification. It's very common for notifications to support having one > or more buttons that the user can click. It would also be good to > enable putting a simple text-input in the notification. This area is > definitely more complex though so happy to put this last. > > I think if we want to address the "more complex data type" use cases above, then this needs to be part of that proposal - for example, I'm not sure how valuable having something like a "Date/Event" notification would be without a "Snooze" button.
[whatwg] Notifications improvements
Hi All, We've on and off discussed various features added to notifications. It'd be great to move forward with some of these improvements. I think the most low hanging fruit would be to add the following as data that can be displayed in a notification: * Progress bar * Lists of title/body pairs * Date (for things like "event will happen in 10 minutes") Second, we really need to figure out the story around handling user clicking notifications after the user has closed the original page. At the very least we need the ability to send a message to a ServiceWorker when the user clicks a notification. This way the SW can decide if UI should be shown, and if so if an existing window can be reused or not. SW integration will require some other changes too. We need to change the GC behavior. Right now it seems like if a Notification object is created, but no event listeners are attached, because the page is expecting to use the SW event to listen for clicks, the notification won't be kept alive and so the SW can't get to any of its data. We also need to keep state on the Notification object if the user has clicked the notification or not. We should also consider enabling passing a URL to the Notification constructor which is opened when the user clicks the notification. Probably this should attempt to reuse an existing tab with said URL if one is open. Third, we should look at enabling minimal user input through the Notification. It's very common for notifications to support having one or more buttons that the user can click. It would also be good to enable putting a simple text-input in the notification. This area is definitely more complex though so happy to put this last. / Jonas
