Re: Notification Area guidelines

[Olivier Crete <tester tester ca>]

Hi,

I'm one of the core GnomeICU developers and as such a user of the notif 
area.. From our development and testing, I have a few comments on the 
whole thing. Also some personal comments.

First, on the single/double click, we had lots of discussion on our 
mailing list and we tried both and I came to the conclusion that one or 
two click is not really important as long as all applets behave the same.. 
and behave the same a KDE too. We currently use double-click because 
that's how our gnome1 applet worked, but if the standard if one click, we 
have no problems with that.

Second, on hiding the window. I noticed that Windows MSN and AIM have the 
behavior of the "X" button as a pref. I really really dislike the idea of 
"closing the main window doesnt close the application", but some people 
are getting used to it. But I agree that many users feel the need for some 
way to hide the main window. The way we currently to this (taken from our 
gnome1 applet too) is that if users double-click on the icon when there is 
no new message, it will show/hide the main window. I agree that this is 
not perfect ui-wise, and it would be good if we had a better way to do 
this.

I think having a "remove" on notication area icons is bad. If it is used 
properly (ie not used for stuff which is not really required), users will 
see no reason to hide icons. And I dont think specific prefs should be 
made from there, but we could still have a prefs item that would open the 
main prefs dialog for the application, if that's logical in the apps case.

Balloon messages are absolutely needed. The should indeed timeout and a 
max timeout should probably be enforced (even if its not in the spec). 
Messages should also be clickable by the user to get more information, 
this is something that msft has right. So the spec should probably be 
enhanced to send back the "click" message to the application. I know 
Kopete on KDE already has balloons, so this is really something needed.
We want to be able to show new messages in balloons if there is no 
conversation with a user (just like windows MSN again).

Overuse of the notif area should be prohibited, daemons should NOT show up 
there and normal applications should also not show up. If this is allowed 
everyone and there mother will start putting icons there like has happened 
on windows and we will need a function to hide part of the icons. So this 
has to be done cleanly from the beginning and only applications that 
actually notify the user of somethign should be there. I dont want a 
RealPlayer icon there or a xmms icon. On that topic, monitors probably do 
not belong there and should have their own applet.. Since they are 
self-contained anyways. Stuff like control shortcuts probably do not 
belong there either.. The RandR thing on windows is nice, but it should 
probably be its own applet. 

Also, it should probably be limited to icons. If we can icons and text, 
more stuff will need to be added (to know panel orientation/size, etc). So 
the implementation should probably enforce that.

The current implementation really sucks... 
I also need a way to find out if there is a currently visible tray icon 
and if messages are implemented because if there are no balloons 
displayed, there are cases when the app will need to pop a real window 
instead. The systray widget should also take care of surviving a crash of 
the panel (the application has to do that for now) and should probably 
have a build-in gtkimage to enforce consistency. Btw balloon messages 
might need to be shared with other applets that might want to communicate 
with the user, like ressource monitors. 

The balloon should go away after a while, but we should be able to 
continue blinking until a user action is taken when required. Everyone 
else does that and it seems to only reasonable way to go.

The notification area should probably a "non-removable" applet, so
that its always there, but maybe not show up if there is no icon in it.

For user testing, I think the gnomeicu team of developers dans 
testers/early users will be very happy to help out with that.

-- 
Olivier Crete
Tester
olivier crete tester ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

On Wed, 12 Mar 2003, Lars Weber wrote:

> Mark McLoughlin <mark skynet ie> wrote:
> > 	+ Right click or Shift-F10 should display a context
> > 	  containing:
> > 	    o A "Remove Icon" option - see below.
> 
>         WRT hiding/removing of a status icon there seem to be three
> different possible approaches:
> 
>         1. To not allow hiding/removing of the icon at all.
> 
>         2. To allow the removal of the icon through context-clicking and
>            to have a corresponding setting (show/not show status icon) in
>            the application's preferences.
> 
>         3. To allow the hiding of the icon through context-clicking and to
>            have the possibility of un-hiding icons through the context
>            menu of the notification area.
> 
> [...]
> > 	+ Should the icon blinking time out? After how long?
> > 
> > 	+ When/why should balloon messages be used? What types of
> > 	  information should they contain?
> > 
> > 	+ Balloon messages should always have a timeout. Need to
> > 	  define the timeout length.
> 
>         It might make sense to not differentiate between balloon messages
> and notification through blinking because that way it's easiest to define
> when either has to be used in a way that will be implemented consistently
> between apps; i.e.:
> 
>         o By default the icon never blinks but shows a ballon message
>           instead to notify the user.  (Balloon times out after n
>           seconds.)
> 
>         o If balloon messages are disabled the icon blinks for n seconds
>           instead of showing the balloon message.
> 
>         o If the application has something that it wants to display to the
>           user for longer than n seconds, it should use a special icon
>           instead of blinking.
> 
> Regards,
> Lars
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>