[whatwg] Persistent SharedWorkers

Thanks for the info - I wasn't aware of the new Ubuntu notification
infrastructure. Notes below:

On Mon, Mar 9, 2009 at 10:42 PM, Matthew Paul Thomas <mpt at myrealbox.com>wrote:

>
> Speaking for Ubuntu, we are making active efforts to reduce the number
> of elements in the notification area (aka "system tray"), with the items
> remaining there being system-wide things rather than
> application-specific things. We would not be willing to let Web
> applications insert icons there. (Similarly, recent versions of
> Windows have been more aggressive about hiding notification area icons
> by default.)


This makes sense - one of my fears is that the system tray would end up
filled with a bunch of icons, which is information overload - this seems
like a good step to limit that.

One other alternative would be for the browser itself to have a single
system tray icon when it is running in the background, and clicking on this
icon would yield some way to view individual worker status via a menu or
other popup. Would this be an acceptable solution? If not, is there a
recommended way on Ubuntu for applications to maintain a visible footprint
on the system without keeping a window open?


>
> We also plan to make panel elements behave consistently as menus, rather
> than some being menus and others being buttons, so an onclick handler
> alone wouldn't work so well even if we allowed the icon.


This might argue in favor of the "single icon for the browser which pops up
status UI for workers" solution rather than individual icons per worker.


> >...
>
> Ubuntu 9.04 will feature initial work to ensure that notifications
> either pop up above other windows, or are interactive, but not both.
> (This is to avoid accidental clicks, and to allow interacting with
> whatever is under a popup notification without having to close it
> first.) Allowing arbitrary HTML in popup notifications would be
> basically incompatible with that. We would be happy to let Web pages
> show popup notifications using an icon and unstyled text, but not an
> onclick handler.


This is a good thing, as it's important for notifications not to
inappropriately steal input. However, it sounds like the API allows
displaying a notification, where no user interaction is possible (not even
"dismiss").

It seems like a very common use case is calendar notifications, where you
want to pop up one of these notifications, and provide two options for the
user: snooze and dismiss. Another example of a common notification would be
new mail notifications (ala Outlook), where a brief new email notification
is displayed, and the user has some way to click on it to view that email -
the notification spec describes this case, and suggests that the user would
click on "the envelope icon in the top panel".

So it seems like the two design goals ("applications can display
notifications, but the user can't interact with them") and ("we limit which
applications can display UI in the top panel") conflict, since the top panel
icon becomes the primary way that users respond to notifications?

After reviewing the spec (https://wiki.ubuntu.com/NotifyOSD) I see that
there are fairly strict design guidelines for notifications, so I agree that
arbitrary HTML is incompatible with Ubuntu display-only notifications.

I'm torn - I think that users on some platforms will expect to be able to
interact with notifications (it's a very common design pattern), so I don't
want to restrict the cross-platform functionality too much. But some
platforms fundamentally don't support interactable notifications (Palm's
webOS allows banner apps that contain only a single string of text, and I
don't think I'd be comfortable restricting the API to just that
lowest-common-denominator case). Perhaps the solution is for us to keep
interactable notifications in the API, but on Ubuntu those notifications
would be displayed within the browser window itself, with some change to the
browser's status bar icon to reflect pending notifications.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090310/77e53a3b/attachment.htm>

Received on Tuesday, 10 March 2009 11:57:09 UTC