Re: [whatwg] Notifications improvements

2014-08-11 Thread Andrew Wilson
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com wrote:
 Hi Andrew,

 On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote:

 On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
  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
 scenarios, I immediately want to start having more control over the
 formatting of the text 

Re: [whatwg] Notifications improvements

2014-08-11 Thread Peter Beverloo
On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com wrote:

 On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com
 wrote:
  Hi Andrew,
 
  On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com
 wrote:
 
  On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
  wrote:
   On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
   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

2014-08-11 Thread Jonas Sicking
On Aug 11, 2014 8:38 AM, Peter Beverloo bever...@google.com wrote:
 On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com 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

2014-08-08 Thread Peter Beverloo
Hi Andrew,

On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote:

 On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
 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

2014-08-08 Thread Jonas Sicking
On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo bever...@google.com 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

2014-08-06 Thread Andrew Wilson
On Tue, Aug 5, 2014 at 11:44 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson atwil...@google.com wrote:

 On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com
 wrote:
 
  On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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 notification content
rather than cherry-picking individual use cases.

I understand your concern that is driving this proposal: you don't
want to provide 

Re: [whatwg] Notifications improvements

2014-08-06 Thread Anne van Kesteren
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com 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

2014-08-06 Thread Anne van Kesteren
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 jo...@sicking.cc 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

2014-08-06 Thread Andrew Wilson
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com 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

2014-08-05 Thread Anne van Kesteren
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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

2014-08-05 Thread Jonas Sicking
On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson atwil...@google.com wrote:

 On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com
 wrote:
 
  On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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

2014-08-05 Thread Jonas Sicking
On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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

2014-07-11 Thread Andrew Wilson
On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com
 wrote:
 
  On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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.

 That's a fair point - I guess I was thinking that these new notification
types were a natural fit for canned new buttons/input elements (i.e.
snooze for events, 

Re: [whatwg] Notifications improvements

2014-07-10 Thread Andrew Wilson
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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.


Re: [whatwg] Notifications improvements

2014-07-10 Thread Jonas Sicking
On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com wrote:

 On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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

2014-07-10 Thread Jonas Sicking
On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo bever...@google.com wrote:

 On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking jo...@sicking.cc 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