On 08/13/2014 04:36 PM, Jonas Sicking wrote:
On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar <robertbin...@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.
* 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 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.
* lights - turn the screen on
Agreed on this one.
* list - add a new entry to the notification list
I don't understand this one.
* 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?
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
I know there is still plenty of room left for discussions around this
behaviors package, but I have only 3 weeks left of my internship and I
would like to implement a prototype of this idea and give it a try
in Firefox OS.
My thought is to firstly introduce a small package of behaviors that
would include "lights", "vibration" and "disrupting"
(and maybe "noclear" too).
The default value for all these 3 behaviors is false.
As I said in a previous email, "disrupting" behavior specifies to the UA
to update the notification silently and 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,
If you have any name suggestions or feedback about these initial
options please let me know.
Robert-
