Re: [Usability] Notification area abuse has started...

[Sean Middleditch <elanthis awesomeplay com>]

On Mon, 2003-09-15 at 09:59, Reinout van Schouwen wrote:
> http://linuxtoday.com/developer/2003091201726NWGNRL
> 
> Somehow we have to get the message across that the notification area is
> for *notification* purposes, not for stupid gimmicks. If we don't stop
> this abuse, the notification area will be like a windows systray nightmare
> in no time...

This needs to be taken care of with a good API, IMO.  As I recall (yes,
I'm not very informed on this ^^; ) the notification area is just a
place for an app to place any generic widget.

The API needs to be super-simplified and streamlines, and only needs to
do what 90% of apps are *supposed* to use the notification area for. 
Apps that *really* want to abuse it, or have legitimate specific needs,
can use the more advanced 'generic widget' API.

What does the API need to allow?

 - Show alert: specify an icon and/or a text message.  (i.e., a
buddy-chat icon and the text 'New message from Sean
<elanthis jabber org>')
 - Specify a callback on user click: for example, this may open/raise
and focus the chat window for an IM alert.  This would also
automatically close the alert.  (Tho that is likely a UI detail.)
 - Cancel alert: situation requiring user attention may have appeared,
then disappeared.  Example: buddy logs in - user doesn't care if the
buddy logs out again a couple second later, all while the user was away
from the desk.  Also, battery events, if the office loses power for a
second, the 'on batter power' message doesn't need to persist.

 That, from my readings of all the posts on the proper usage of
notification area, is all that *most* apps will ever need.  If the API
is simple, clear, and only does the above, it gets rather hard to abuse
it.  If the apps has no 'active alerts', no icon is shown, nor is any
text message shown.

 If the API also requires an 'app ID' (possibly pulled apps X ids) and
'event ID', the advanced user can have extra control.  For example, if
the app Stupid App Designed By Windows Monkeys abuses the protocol to
have a permanent alert to always show a useless icon, the user could
open gconf-editor and add 'stupid-app/resident' to the block list for
the notification area, stopping the permanent alert, but allowing the
app to still send *real* alerts, as they'd have a different tag
(stupid-add/real-alert, or whatever).

 Some use cases:

 * GAIM

  - Buddy logs in: create new alert w/ icon gaim-new-buddy (using icon
theme spec) and the text, 'Buddy FooBar is now available for chat'. 
Callback is set to open a new chat window to FooBar.
  - Same buddy logs out: cancels previous alert; icon and text message
immediately disappear.  Perhaps a new timed alert shows the message
'Buddy FooBar' is no longer available for chat.'  In later case, no
callback is registered - clicking on the icon will just 'close' the
alert immediately.
  - Disconnected from Jabber server: new alert w/ icon
gaim-disconnected, and the text, 'Lost connection to Jabber server.'
  - New IM: new alert w/ icon gaim-new-message and the text, 'New
message from FooBar'.  The callback raises/focuses the window.

 * GNOME CD Player

  - New audio CD inserted: alert w/ icon gnome-music-media and text,
'Music CD "Led Zeppelin III" inserted to CD drive.'
  - Current track changes: alert w/ icon gnome-music-track and text,
'Now playing track "Gallow's Pole" on album "Led Zeppelin III".'
  - CD drive hiccups, CD playing suddenly fails: alert w/ icon
gnome-music-error and text, 'An error has occurred while trying to play
music from the CD drive.'

 * Rhythmbox

  - Most the same as GNOME CD Player, perhaps reusing the exact same
messages.  Just add additional text/code for 'Net Radios and local
play-lists, in addition to CDs.

 * Power Management

  - AC power ceases: icon gnome-power-ac-fail and text, 'The system has
lost A/C power.  Now running on Battery 0, approximately 1.24 hours of
runtime remaining.'
  - A/C power restored: cancel lost power alert, new alert 'The system
has regained A/C power.  Now charging Battery 0.'
  - Imminent shutdown: new alert w/ icon gnome-power-shutdown, '10
minutes of batter power remaining.  System will automatically shutdown
in 5 minutes.  Save all work and exit all apps immediately.'

 * Hardware Monitor

  - New device inserted: icon and text, 'New [device type] device
[device name] connected'.  Callback will open the device: nautilus for
storage, camera app for digital cameras, scanner app for scanner,
network monitor for net device, etc.  Or, if the device requires further
attention, the configuration app may be launched, asking for mount point
or so on.
  - Device removed: icon and text, 'Device [device name] has been
disconnected from the system.'  This should probably have an automatic
timeout cancel after X seconds (in most cases, the user removed the
device themselves, they already know it's gone).
  - Hardware failure (device still connected, but malfunction has been
detected, such as access timeout on storage device): icon and alert,
'System has detected a problem with device [device name].  [recommended
fix]'.  The fix will vary for device - removable devices may recommend
they be removed and reconnected, built-in devices may recommend a
(*gasp*) reboot (internal modems sometimes require this), and so on. 
This alert is useful, as a hardware malfunction may cause a user grief,
but the hardware-nature of the problem may not be noticable - i.e.,
Nautilus hanging trying to access a storage device.  The alert will
notify the user of what is causing the problem, and given them feedback
on how to correct it.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.