Re: Levels of Importance or Priority

I agree with Doug's concern about contending notification priority. In Mountain Lion notifications have an implicit priority based on a notification's recency, and do not support developer-defined priorities. We cannot rely on apps, native or web, to act as good citizens, and have no intention of supporting this.

Is Android the only platform that supports notification ordering? It appears Growl only affects the visual, and possibly aural, aspects of the notification. I also see a problem of defining this property's intended effect, since various platforms order notifications differently. This property also has very little to do with the web notifications themselves, and only dictates (a single) platform behavior, which hinders future versions of the spec due to a need for backwards compatibility support.

I do not see this being a high priority item for this feature-complete draft of the spec.

Regards,
Jon

On Sep 3, 2012, at 7:00 AM, Adrian Yanes <adrian.yanes@nokia.com> wrote:

> On 09/03/2012 07:16 AM, ext Navarr Barnier wrote:
>> I remember the last time this was brought up the same conclusion was
>> reached and it devolved into an argument about priority and how
>> websites will fight over priority.
>> 
>> Looking at this fresh, and personally being familiar with the
>> notification system in Google's Android version 4.1; as well as the
>> fact that Notifications are currently opt-in on (I think all?) vendor
>> implementations, a priority system makes a lot of sense.
> 
> 
> I totally agree. Not only in Android but in systems such as Growl (the
> main notification framework for OS X), the priorities are present as well:
> 
>> From Growl's developer documentation[1]:
> 
> -----
> Priority
> 
>    Every notification has a priority. The priorities are:
> 
>    -2
>        Very low
>    -1
>        Moderate
>    0
>        Normal
>    +1
>        High
>    +2
>        Emergency
> 
> 
>    Priorities are clamped to this range. For most notifications, Normal
> is reasonable.
> 
>    Not all displays use priority. In those that do, priority may affect
> font, color, or size, or some combination of these. It may also cause a
> sound (or a different sound) to be played when the notification is
> displayed. All of this is up to the display designer.
> 
>    The user can override priority for each notification name.
> 
> ----
> 
>> 
>> I think we can learn a lot from Android's implementation of a
>> notification priority system, and I think it would be a good idea to
>> move forward basing a priority system off of it.
> 
> +1 to this.
> 
> Regards,
> 
> Adrian.
> 
> 1 - http://growl.info/documentation/developer/introduction.php
> 
> 
>> 
>> On Sun, Sep 2, 2012 at 9:42 PM, Doug Turner <dougt@dougt.org> wrote:
>>> The real problem with this suggest is that the importance will very
>>> greatly and the user agents will have a terrible time figuring how to
>>> expose this sanely.  I worry about a rush to the bottom (or rush to
>>> everyone using the greatest importance).
>>> 
>>> Even in your example, you have two use cases that we all can agree are
>>> super important -- a school shooter and a weather alert.  These would
>>> be using whatever the highest importance we defined.  However, you
>>> also are talking about some sales app that your customers are using.
>>> Would those notifications also have the same high priority?
>>> 
>>> Thanks,
>>> Doug
>>> 
>>> On Wed, Aug 29, 2012 at 2:14 PM, Michael Fairchild
>>> <mfairchild365@gmail.com> wrote:
>>>> As of right now in the Web Notifications API, there is no way to set the
>>>> importance of a notification.  I think this is a very important feature and
>>>> should be considered for adoption.
>>>> 
>>>> I have noticed that in a few other threads, the concept of levels of
>>>> importance or priority (I will refer to it as priority from here on out)
>>>> have been brought up.  However, the concept has received a lot of
>>>> resistance.  I want to argue for the adoption of it in the Web Notifications
>>>> API.
>>>> 
>>>> I am currently working on a Visitor Chat system, in which a visitor can go
>>>> to a web site and start a chat with an operator.  I have implemented Desktop
>>>> Notifications in Google chrome to help notify operators of new chat
>>>> assignments.  I have also implemented other notification features such as
>>>> sounds.  The issue that I am having is that some of the operators that are
>>>> assigned to the system are also assigned to answer calls and emails.
>>>> Company Policy and their current system configuration does not allow for
>>>> sound to be enabled, thus they have to rely on seeing desktop notifications
>>>> when a new assignment comes in.  Unfortunately, the the Desktop
>>>> Notifications are too small and often go unnoticed, thus resulting in a loss
>>>> of customers.
>>>> 
>>>> While a solution to this problem could be to create a custom notification
>>>> application, I believe that a better course of action would be to use a
>>>> specification such as Web Notifications.
>>>> 
>>>> My instance is also not a lone instance where a higher priority notification
>>>> would be useful.  Some other examples would be weather application that
>>>> notifies you when there is a tornado warning in your current location.  Or
>>>> an alert application for a university that displays a notification when
>>>> there is a shooter on the camps.
>>>> 
>>>> While I don't care how the UA handles the higher priority notifications, I
>>>> think the priority should be defined in the API.  Some browsers might choose
>>>> to center them on the screen, others might make them bigger, others might
>>>> make them flash.  How it happens, is not important.  There are also several
>>>> ways that non visual UAs might handle higher priority notifications.
>>>> 
>>>> I know the issue of who should assign the priority (API or end user) was
>>>> mentioned before.  While I see the concern, the notification priority should
>>>> be defined in the API and up to the programmer.  If the user does not like
>>>> it, they can turn off the notifications.  Or the programmer could implement
>>>> a feature to let the user select the priority of notifications for the site.
>>>> 
>>>> --
>>>> Regards,
>>>> Michael Fairchild
>>>> 
> 
> 

Received on Wednesday, 5 September 2012 18:36:30 UTC