[Usability]Re: Notification Area guidelines
- From: Olivier Crete <tester tester ca>
- To: Lars Weber <lars brokenbits de>
- Cc: Mark McLoughlin <mark skynet ie>, usability gnome org, desktop-devel-list gnome org
- Subject: [Usability]Re: Notification Area guidelines
- Date: Wed, 12 Mar 2003 13:19:41 -0500 (EST)
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]