Re: [whatwg] Notifications: the ability to specify notifications behavior
On Sat, Sep 6, 2014 at 7:15 PM, Robert Bindar wrote: > That's what I meant. I filed an issue on the github page for that > https://github.com/whatwg/notifications/issues/24. Thanks. As I mentioned earlier I'm not sure when exactly I'll get around this. If something is urgent please let me know privately and I'll try to sort something out. If anyone is interested in helping out with editing let me know. A good start for that would be one or more pull requests. -- http://annevankesteren.nl/
Re: [whatwg] Notifications: the ability to specify notifications behavior
On 09/06/2014 03:02 AM, Anne van Kesteren wrote: Do you mean the Notifications API? As with most standards we're not really touching the UI space at the moment. That's what I meant. I filed an issue on the github page for that https://github.com/whatwg/notifications/issues/24. Robert
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Sat, Aug 30, 2014 at 2:46 AM, bindar wrote: > I have read the spec again and I could not see any information regarding the > actions a replacing notification should trigger. Firefox OS for instance > triggers these actions every time. Do you mean the Notifications API? As with most standards we're not really touching the UI space at the moment. -- http://annevankesteren.nl/
Re: [whatwg] Notifications: the ability to specify notifications behavior
Jonas Sicking wrote: > On Fri, Aug 29, 2014 at 9:18 AM, Robert Bindar > wrote:>> 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.> I don't think we'll >> want to default "lights" and "vibration" to false. > And I still have concerns that exposing "vibration" as a boolean could > mean that a notification goes completely silent, even though neither > the user or the application intended for that. > > Also, how is "disrupting" intended to work? As I understand it, the > current spec already defines that if you create a notification using a > tag of an already-existing notification, that it just updates that > notification without otherwise notifying the user. > > So how are you envisioning that disrupting would alter that behavior? > > / Jonas I agree with you on "lights", we rather have fewer apps that would create so many noifications that would drain the battery. About "vibration" and "sound", I know they will be kind of useless at some point, but as long as we do not have a way to let the user specify notifications settings we could let the apps to suggest to the UA which behavior their notifications should have, without ending up annoying the user or waste resources. I have read the spec again and I could not see any information regarding the actions a replacing notification should trigger. Firefox OS for instance triggers these actions every time. Robert
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Fri, Aug 29, 2014 at 9:18 AM, Robert Bindar wrote: > 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. I don't think we'll want to default "lights" and "vibration" to false. And I still have concerns that exposing "vibration" as a boolean could mean that a notification goes completely silent, even though neither the user or the application intended for that. Also, how is "disrupting" intended to work? As I understand it, the current spec already defines that if you create a notification using a tag of an already-existing notification, that it just updates that notification without otherwise notifying the user. So how are you envisioning that disrupting would alter that behavior? / Jonas
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 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-
Re: [whatwg] Notifications: the ability to specify notifications behavior
Den 15-08-2014 kl. 01:54 skrev Michael Henretty:
On this note, it would be useful if content could query the UA for the
default behaviors of any notifications it would send. Also, it would be
nice to know which of these behaviors could be overridden by the "behavior"
options. Perhaps something like:
var promise = Notification.getBehaviors();
promise.then(function (behaviors) {}
with behaviors looking something like this:
{
"vibrate": {
"default": true,
"overridable": false
},
...
}
So, each behavior would have a default (which the system determines through
platform support and user settings), and whether or not the behavior is
overridable for the current content script. The way an app could have the
information necessary to degrade gracefully.
I would rather have the user agent automatically choose a suitable
fallback if it didn't support the combination of behaviors you
requested, or if they were disabled by user preferences.
But I think that would require the behaviors to be specified by content
at a higher level.
/Jesper Kristensen
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Aug 15, 2014 1:57 AM, "Anne van Kesteren" wrote: > > On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar wrote: > > 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. > > Well, if we introduce new dictionary members they will default to > false. So I guess what Jonas was asking for is that we should think of > names that make sense given that. Of course, they will just be hints > anyway due to platform conventions and user overrides. That's not necessarily true. Dictionary members default to "absent" if they don't have a default value. So we could treat default as different from both true and false. But it tends to make for a confusing API to treat optional boolean arguments as different from false. / Jonas
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Fri, Aug 15, 2014 at 1:54 AM, Michael Henretty wrote: > On this note, it would be useful if content could query the UA for the > default behaviors of any notifications it would send. Also, it would be > nice to know which of these behaviors could be overridden by the "behavior" > options. Uhm, what about fingerprinting, privacy, etc? -- http://annevankesteren.nl/
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar wrote: > 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. Well, if we introduce new dictionary members they will default to false. So I guess what Jonas was asking for is that we should think of names that make sense given that. Of course, they will just be hints anyway due to platform conventions and user overrides. -- http://annevankesteren.nl/
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Thu, Aug 14, 2014 at 4:37 PM, Robert Bindar
wrote:
>
> On 08/13/2014 04:36 PM, Jonas Sicking wrote:
> >
> >> * 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.
On this note, it would be useful if content could query the UA for the
default behaviors of any notifications it would send. Also, it would be
nice to know which of these behaviors could be overridden by the "behavior"
options. Perhaps something like:
var promise = Notification.getBehaviors();
promise.then(function (behaviors) {}
with behaviors looking something like this:
{
"vibrate": {
"default": true,
"overridable": false
},
...
}
So, each behavior would have a default (which the system determines through
platform support and user settings), and whether or not the behavior is
overridable for the current content script. The way an app could have the
information necessary to degrade gracefully.
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
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-
Re: [whatwg] Notifications: the ability to specify notifications behavior
On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar 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
