Re: [whatwg] Notifications: the ability to specify notifications behavior

On 08/13/2014 04:36 PM, Jonas Sicking wrote:
 > On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar 
<robertbindar@gmail.com> wrote:
 >> Concerning web notifications, it would be very helpful for content 
and web
 >> apps
 >> to have a way of specifying the behavior their notifications should 
have.
 >> For instance, a chat client may not always want to play a sound when 
sending
 >> a notification pertaining to a new message. Or in the mobile web, an app
 >> may want to avoid waking the screen on every notification to save 
battery
 >> life. Web content could have a way to "suggest" these behaviors to 
the user
 >> agent.
 >
 > Agreed. We've run into similar shortcomings when writing mobile webapps.
 >
 >
 >>     new Notification('title', {
 >>         tag: 'tag',
 >>         behavior: {
 >>             vibration: true,
 >>             silent: true,
 >>             lights: false,
 >>             list: true,
 >>             noclear: true,
 >>             squash: true,
 >>         }
 >>     });
 >
 > It might be good to structure these such that the default is always
 > 'false'. That way it's more intuitive what behavior you get if you
 > leave out a property.

We can not say accurately if the default will always be false because
the platform may or may not support the behavior, or it might be overridden
by a user defined setting.

 >
 >>     * vibration - vibrate the device
 >>     * silent - "true" means do not play a sound when firing the
 >> notification(the sound
 >>                     is enabled by default in firefox for OSX, not 
available
 >> in Linux and Windows)
 >
 > The tricky thing with these is how to deal with situations when the
 > user has turned of audio or turned off vibration for notifications.

If the user turned off/on audio/vibration then UA will ignore any app 
specified
behavior. The user defined settings will always take priority over these
behaviors.

 > If the user has turned off audio for notifications, and the page
 > specifies "vibration: false", does that mean that this notification is
 > entirely silent? I suspect that's not what the user expected when
 > turning off audio.

If the user had previously turned on the vibration for notifications, 
then no,
the device will still vibrate, but otherwise the notification will indeed
be entirely silent.

 >
 >>     * lights - turn the screen on
 >
 > Agreed on this one.
 >
 >>     * list - add a new entry to the notification list
 >
 > I don't understand this one.
 >

Some platforms have a "notification center", like the notification tray
in Android. This behavior is about bypassing display in the notification
center.

 >>     * noclear - this notification shouldn't be closed when pressing the
 >> ClearAll button
 >
 > This one is interesting. I could see the value for notifications that
 > deliver progress notifications about an ongoing event to the user.
 > Though I hate the idea of users not being in control of their
 > notifications area. Perhaps it's ok that the notification doesn't get
 > cleared if a 'clear all' button is pressed, but that the user can
 > somehow explicitly clear that certain notification.
 >
 >>     * squash - every time you'll find a notification with the same 
tag, do
 >> not disrupt the
 >>                      user, just update the existing notification
 >
 > This is the main purpose of using tags. When would you not want this 
behavior?

It is the main purpose of using tags, but using this option we could specify
to the UA to update the notification silently, do not produce any other 
action
that could disrupt the user (play a sound every time, flash the screen, 
etc).
This behavior could be very useful for intensive notifiers like email 
updates,
maybe this name is not the best choice.

 >
 >> Again, the `behaviors` object is just a package of suggestions for how a
 >> notification should behave,
 >> but it is up to the user-agent to determine whether it wants to 
honor these
 >> behaviors
 >> (based on platform support, user settings, or even general user 
experience).
 >
 > I don't think it makes much difference to say "this is just a
 > suggestion". UAs won't magically know what's right and what's wrong.
 > If we can't on this list think of good heuristics to use, then I don't
 > think we should expect UAs to do either.
 >
 > / Jonas

By "suggestion" I meant that UAs should analyze if there are any user 
defined
preferences regarding those behaviors and if they are of course able to 
follow
them (an web app could pass "vibration: true" to the Notification 
constructor,
but a desktop browser will not be able to fulfil this request).

The heuristic I'm proposing is:
1) Does the platform/UA support it?
2) Is there a user defined setting that overrides this behavior?

Robert-

Received on Thursday, 14 August 2014 23:38:26 UTC