Re: [Usability]Re: Notification Area guidelines

On Wed, 2003-03-12 at 18:29, Mark McLoughlin wrote:
> Hi Jeff,
> On Wed, 2003-03-12 at 13:21, Jeff Waugh wrote:
> > I think 'notification' and 'status' succinctly sum up the first two use
> > cases you mentioned (ie. the ones we actually want to support). Notification
> > is for short term, attention-grabbing information ("new mail"), status is
> > for long-term, at-a-glance information ("connected to network", "battery
> > percentage", etc).
> > 
> > Many apps will want to use both. Examples:
> > 
> >   - IM apps show connectivity / number of buddies status, but also
> >     notification of new messages / buddies.
> > 
> >   - A battery applet will show remaining battery life, but also notify when
> >     the battery is fully charged or close to spent.
> > 
> >   - A network/dialup applet will show connectivity / usage status, but also
> >     notification of connections and disconnections.
> > 
> > Should an application use only the same icon space for notifications? I
> > guess this will be mostly answered with the balloon messages stuff (you can
> > notify without changing the status icon).
> > 
> > Of course, some applications should really only show "true' notifications.
> > Examples:
> > 
> >   - Distribution update notification tools
> > 
> >   - New email
> > 
> >   - Someone attempting to share/view your desktop (authentication query)
> > 
> >   - Administrator rights granted period (su/sudo)
> 	The first time I read this I agreed, but on thinking about it some more
> I'm not so sure. I don't think "pure notification" icons - i.e. ones
> that appear blinking for a while and then dissappear again - will be
> such a good idea in most cases.
> 	In most cases I think it might be better to implement notification
> using a status icon. E.g. the "New email" notification may actually be
> made a part of status icon telling you how many unread emails you have.
> If a new email arrives the icon would flash for a few seconds and stop.
> Same goes for the "battery fully charged" or "network disconnected"
> notifications.
> 	I suppose what I'm saying is that in most cases the notification will
> be of a change in status - status that will be shown in a status icon -
> and would be better indicated by the status icon itself.

This is a good point. If we have a "notification server" that deals with
all client app notifications, maybe we could have a status server too.
And then, a simple server pref could be implemented to let users decide
wether they want notification icons and status icons together,
notifications on status icons to bubble with status icons, or the icons
to appear in seperate places, etc. For example:

- Group status icons and notification icons together in one tray
	- (Then automatically have notification bubbble come from the
		application's respective status icon)
- Seperate status icons and notification icons in seperate trays
	- Either have status bubbles come from status icons and
		notification bubbles come from new notification
		icons or...
	- Have all new notification bubbles come from new and 
		dismissable notification icons.

On the client application API side of things, the client app would send
a create status icon message to the server, which would of course return
the appropriate handle. Then the client app could send update status
messages, and destroy icon messages. The client app would deal with
notifications by sending a create notification message with icon, text
message, and default action attributes. The server would then create a
new icon for the text bubble or attach a bubble on a status icon
depending on user settings and if the client app even has a status icon
registered with the server. When the user deals with the notification,
the server will send a message to the client app.

And of course, the server should be able to detect wether the client
process is even running so it can destroy notification and status icons
when the app is closed but didn't send a destroy status and notification
icon message. This would safeguard the server from crashes and bad
programming practices.

> 	I'm uncomfortable with recommending the "flashing icon which
> dissappears again" for notification because:

Notification icons should probably only diappear once the user clicks on
the icon or text bubble to indicate she has read the message. (also, it
might be a good idea to always have some sort of text bubble, but let
the user decide if the bubble will appear automatically, or only when
she clicks on the notification icon.)

> 	1) Icons appearing and dissappearing may be somewhat disconcerting.
> 	2) You're likely to miss this notification. You might be gone to get a
> joffee, reading a book or chucking something at your cube buddy ...
> whatever. When you get back, in most cases I'm guessing you'll still
> want to see that latest status.
> 	I'm not saying there'll never be a good case for it, just that in most
> cases I don't think it would be the best way of doing it.
> Good Luck,
> Mark.
> _______________________________________________
> Usability mailing list
> Usability gnome org
Wesley Leggette <wleggette gate net>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]