Thanks for the info - I wasn't aware of the new Ubuntu notification infrastructure. Notes below: <br><br><div class="gmail_quote">On Mon, Mar 9, 2009 at 10:42 PM, Matthew Paul Thomas <span dir="ltr"><<a href="mailto:mpt@myrealbox.com" target="_blank">mpt@myrealbox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
</div>Speaking for Ubuntu, we are making active efforts to reduce the number<br>
of elements in the notification area (aka "system tray"), with the items<br>
remaining there being system-wide things rather than<br>
application-specific things. We would not be willing to let Web<br>
applications insert icons there. (Similarly, recent versions of<br>
Windows have been more aggressive about hiding notification area icons<br>
by default.)</blockquote><div><br>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.<br><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
We also plan to make panel elements behave consistently as menus, rather<br>
than some being menus and others being buttons, so an onclick handler<br>
alone wouldn't work so well even if we allowed the icon.</blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>...<br>
<br>
Ubuntu 9.04 will feature initial work to ensure that notifications<br>
either pop up above other windows, or are interactive, but not both.<br>
(This is to avoid accidental clicks, and to allow interacting with<br>
whatever is under a popup notification without having to close it<br>
first.) Allowing arbitrary HTML in popup notifications would be<br>
basically incompatible with that. We would be happy to let Web pages<br>
show popup notifications using an icon and unstyled text, but not an<br>
onclick handler.</blockquote><div><br>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").<br>
<br>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". <br>
<br>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?<br>
<br>After reviewing the spec (<a href="https://wiki.ubuntu.com/NotifyOSD" target="_blank">https://wiki.ubuntu.com/NotifyOSD</a>) I see that there are fairly strict design guidelines for notifications, so I agree that arbitrary HTML is incompatible with Ubuntu display-only notifications.<br>
<br>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.<br>
</div>-atw<br></div><br>