In Fennec 4.0, we implemented the w3c working draft of desktop notifications. This allows websites to post system level notifications. Users must opt-in. See: http://dougt.org/wordpress/2010/06/desktop-notifications/ We decided that there was not enough time to fully think through out Firefox desktop would show these notifications. On Android, it is easy -- there is a system notification bar that we could leverage. I think we should Show W3C Desktop Notifications in Firefox desktop, but I am unsure how they should be displayed. I am not sure if our existing alert service will work, and tend to think not.

We are currently planning to remove the existing alert service (toasts/growls used for updates and download complete messages). Let's meet up at some point to discuss design options for this. I'm not that familiar with the spec yet.

Lots of interest in this at SXSW. "It's in Chrome". /be

>Users must opt-in This is a key part in terms of the user experience, notifications needs to only be displayed if the user has explicitly opted-in for that particular site. Unlike additional local storage, or glowing the app tab, this isn't one of the privileges that we'll want to automatically grant for Web sites when they are appified (pinned, launched from a Web app dashboard, running in a prism style window, etc.) In terms of the spec, I think it would be more useful to have two levels of notifications: 1) what's proposed, delivering content (icon, title, description) -growl style message is displayed on screen 2) just ping the user -app tab glows (in browser) / dock icon bounces or taskbar icon glows (in prism style window) For instance, a Web app like gmail could use the growl alert when an email arrives (otherwise asynchronous), and it could ping the user and glow the taskbar icon when the user receives an incoming chat (synchronous). The simpler "ping the user" style of notification is something that we probably would want to turn on by default for any applications that are running as apps. This level of notification is useful for events like incoming chats, or calendar events. It's also a level of notification that is native to every OS (windows xp, vista/7, OS X, etc.) Currently we just glow app tabs when the title changes, and while this sort of works, it is really a hack.

Here's a mockup covering the different possible types of notifications, and user control over the levels. Two things to note: 1) Pulse and panels need to be different API calls, we should not downgrade a panel to a pulse, but rather only display a pulse when the site specifically asks for it. 2) we are requiring users to explicitly opt-in to receiving the panel alerts.

for (2), this sounds alot like a badging api and is separate from the API we are building in that WG. right now, we have some sort of tab highlighting in FF. It isn't API driven - we just detect when the page changes, and change the highlight/color of the tab. Sites, like gmail, already change the favicon based on the number of messages you have in your Inbox. (maybe that is still a google labs option). I think this pulse api should include an option/mechanism to update your favicon to do something similar. Thoughts? Thanks for the mockup - general question. On android, where there is a clear device level system for delivering notifications, we are going to use that. On the Mac, there is Growl for those that want a noisier environment. On windows, there might be something (not sure). Ubuntu has, what, libnotify. In those cases, should we just be defaulting to whatever the system providers. The UI used for the notification looks like it could be drawn by us. Do you have any thoughts on using the system verses using ff? Fwiw, i do not like the thunderbird style toaster -- it looks very out of place on just about every system (might be old data, haven't checked in a while).

oh, right... pulse and panels are not mutually exclusive. I might want pulse when I am using the browser so that i can see new messages arrive in a background tab. But, I also want to see a desktop notification when the browser is in the background and I am using, say, a text editor.

>right now, we have some sort of tab highlighting in FF. It isn't API driven we may want to expose support for this level of notification as well. There are really three distinct use cases: 1) ambient: if (and only if) the user is curious, they can glance at a location to see if there is new information, but otherwise the application does not capture their attention. 2) pulse: ALERT ALERT, THE APPLICATION NEEDS YOUR ATTENTION RIGHT NOW. captures the user's focus and is best used for things that are synchronous, like an incoming chat, or a calendar event. 3) panel: detailed information on things that may or may not be useful to the user (commonly used for twitter, email, application events, ongoing irc events). Generally speaking this level of notification system is significantly misused (One of your Firefox Extensions has an Update Available!), and on the whole it has probably done more harm than good. This is likely why both Windows and OS X do not ship with a native system that we can leverage. This is also why it's important to place the functionality behind a user pref by default, so we can guarantee a legitimate use case. >oh, right... pulse and panels are not mutually exclusive they also don't support downgrade, so it wouldn't be the case that panels would be converted to a pulse (if the user opted for that level but not panels). Invoking a pulse would need to be a special call for applications that specifically wish to capture the user's full attention. >On android, where there is a clear >device level system for delivering notifications, we are going to use that. Makes sense, we should try to use the favicon of the site though (if they don't specify an icon), since it is actually the one sending the message. >On the Mac, there is Growl for those that want a noisier environment. yep >On windows, there might be something (not sure). Natively the system tray with balloons, but those carry with them a strong connotation of frustration, clutter, and irrelevance (java would like to bother you until you smack it back down). A panel that appears and removes itself over time like growl will likely be preferable to users. Visually, we should style them like tooltips (pictured in the mockup), which is consistent with the system tray balloons. lot's of discussion on that control here: http://msdn.microsoft.com/en-us/library/aa511451.aspx >Ubuntu has, what, libnotify. I vaguely remember DBUS being mentioned in another bug, but I'm not really sure what it is, or if that is directly related.

GNOME has these desktop notifications: http://developer.gnome.org/notification-spec/ (I *think* that is still current for GNOME 3). There is also the slightly different spec at https://wiki.ubuntu.com/NotifyOSD which I'm not sure how much of it is Ubuntu-specific, but it looks like they thought more about the user experience issues. I have no idea about KDE.

> >Ubuntu has, what, libnotify. > > I vaguely remember DBUS being mentioned in another bug, but I'm not really > sure what it is, or if that is directly related. [...] > experience issues. I have no idea about KDE. Just a few clarifications: GNOME2 (and 3?) and Xfce use libnotify for desktop notifcations. KDE has kdialog which could be an alternative. D-Bus is an ipc system used (some parts of) GNOME, Xfce, and KDE4.

Mark Sutherlin has been working on some of the UX considerations for Notifications for a while now, and includes a number of platforms that were the original inspiration for Push Notifications. See https://wiki.mozilla.org/Services/Notifications/Push/UX.

Update for Mac: We might want to use Notification Center here, or not, depending on how "good" we can interact with it (maybe just use this if Fx is not focused and only for the first notification?). Growl has been removed in current versions (I don't know which Train, but it is definitely gone from Central, I think even Fx 17 Release).