Another alternative is to put the user in charge here. And let the
user on a per-application basis configure things like:
* Can this application create notifications at all
* Do those notifications turn on the screen
* Do those notifications show up on the lock screen
We could then preconfigure those settings such that the email app by
default do not turn on the screen.
The experience on iOS appears to be that notifications is the mobile
version of popups, and that it's good if the user can control how a
given applications notifications are displayed.
However if we don't want to do that (or don't have time to), I'm fine
with adding a moz-prefixed property to the Notification constructor
dictionary which allows an application to say that the screen should
not be turned on.
> 2) This bit depends on how gaia implements replacement via tag, but we might
> also want to be able to express meta-data that allows us to effectively
> show/update a notification without triggering the toaster/ringtone/vibration
> fireworks show.
The idea from the spec is that if you use a replacement, then a new
toaster/whatnot is *not* triggered.
If you do want a new toaster/whatnot, then delete the old message and
create a new one.
Note that the spec still is lacking the ability to get references to
notifications created by a previous run of the app, in order to remove
those notifications. Anne is working on defining a function to do
> 3) We want to be able to provide our own time-stamp associated with the
> notification, something not supported by the WHATWG API but supported by
> Chrome's notification extension API at
. If you got the
> new e-mail yesterday but we only fetched it now, it'd be arguably nicer if
> we could use the timestamp of the message rather than when the notification
> was generated.
I think iOS uses a similar feature when displaying calendar
notifications. They use it to display the time of when an upcoming
event starts. This way the notification doesn't just contain the text
"Event X starts in 10 minutes", but rather instead contains the text
"Event X" and next to it is a dynamically updating timestamp.
Sounds like this setup would work even for timestamps in the past.
Anne, this is something that I think we should examine adding to the
standard given how many notification systems now have seen the need
for it (iOS, Chrome, us).
> 4) A single text/plain body for the notification is insufficient for us to
> best delineate the different salient bits of info about new mails which
> could include all of: message author, message subject, message body snippet,
> account on which this message was retrieved. This could be improved by
> either supporting a weak form of mark-up or supporting additional structured
> information to be included in the notification which is amenable to a
> standardized presentation that would also work for e-mail. For example, the
> aforementioned Chrome extension API at
takes an optional
> 'items' attribute which is an array of objects with 'title' and 'message'
> properties which might be sufficient for both our ungrouped (1 message per
> notification) and grouped (> 1 message per notification) needs.
This one I'm much more worried about. Getting into too fancy content
in the notification means that we're quickly going to run into
problems with realestate I think.
Looking at the UX drafts, I wonder if we can get that behavior by
being smarter in gaia. I.e. could gaia have smarts such that once we
get enough notifications from the same app, we group them together.
And if there's enough of them we display the title and text on the
same line and cut off the text as needed.
Maybe if we add a "groupable" flag to the notification the app can be
in control over if grouping for the notification makes sense or not?
Another option would be to make the API support explicit grouping. So
that you can create a notification group which carries some metadata.
Then add a set of opened notifications to that group. Maybe by giving
the group a tag, and then being able to set a group-tag on each
> The set of options that jump out at me are:
> - your notifications are too fancy; we don't even have screen real estate
> for all that!
> - evil hacks by overloading the 'tag' field
> - pursue adding more stuff to the WHATWG/W3C API and be very sorry about not
> pursuing it in the past
> - pursue standardizing the Chrome API even though it doesn't appear to be
> targeted as a web API because their use cases are very similar to our
> use-cases (although B2G v1.0/v1.1 devices don't really have the screen real
> estate for the buttons.)
Generally speaking we should always aim for that everything that we
add ends up in the spec. If for no other reason because generally we
should assume that if we have a need, that others have similar needs.
However I'm not sure how sorry we should be about not pursuing this in
the past. We shouldn't wildly guess at what needs app authors will
have. A while ago we did talk through "future notification needs" with
the UX team and many of the requirements above did not come up there.
However we did discuss some other ones (such as progress bars), which
we started working on. Though arguably we could have worked harder on
getting those features added to the spec.
Either way, maybe a good next step here, if we need to make progress
faster, is to set up a meeting and discuss what immediate needs we
have for use cases that the current API doesn't solve.