Re: [Usability]Notification Area guidelines

[Wesley Leggette <wleggette gate net>]

So we have a notification panel, which acts as a server to that receives
non-vital messages from applications and displays them with an icon
and/or pop-up, context menu, dialog box, or whatever presentation gets
decided on. The big deal is that once a user clicks on, reads, and
dismisses a notification, it is gone. (Also, for that matter,
notifications should automatically disappear without having been
dismissed if they are no longer relevant. This would be a good argument
for having them go away when an application exits. But then, there can
be exceptions if the message still applies after the app is closed).

The difference between the notification panel and a dialog box is that a
dialog box is obtrusive for vital RIGHT NOW information, while the user
can deal with the messages in the notification area at his own pace,
right?

I would imagine that it would make the most sense for the notification
panel to be a server, and client apps would send messages indicating how
the user should deal with the message, presentation style (if there are
choices), icon and other visual cues like badges, and if the icon should
be automatically dismissed when the application quits. The server should
return a reference item to the client so the client can send a "dismiss
notification" message if the app thinks the situation is no longer
relevent.

So there is the question of how the notification server will know if the
caller app is dead. Should it wait for dismiss notification messages, or
check and see if a process is still live?


----

Then we have status panel. This is different, n'est pas? So we can talk
about whether there should be a status area (system tray) or just use
applets, but is this not a seperate issue that notification areas?


Is this a valid distinction? Can we design a pure notification area
without dealing with status icons?

Also, how do you get developers to use the notification area properly?
Auto expire messages?

-Wesley Leggette



On Wed, 2003-03-12 at 05:11, textshell neutronstar dyndns org wrote:
> On Wed, Mar 12, 2003 at 01:20:00PM +1100, Jeff Waugh wrote:
> > <quote who="Rodney Dawes">
> >
> > > the Notification Area is an applet, as the alignment on the panel doesn't
> > > affect the resizing when icons are added/removed. The notification area is
> > > also something that should really just *always* be on the panel.
> > 
> > I agree. I have a proposal to post later on about how to implement the
> > notification area in a different way, which would hopefully solve some of
> > its problems due to being an applet.
> > 
> > I don't believe that applets are 'evil' and should be crushed at all costs,
> > however. They certainly have their place. We just need to define it better.
> > 
> 
> I think we have a Problem with mixing applets and notify-icons. I think 
> the main difference of these two is the life cycle and the associated 
> technical details. (applet if it is running all the time, notify-icon if 
> it appears while running an application either always or to notify of 
> events in or detected by that application). These are technical details so 
> we shouldn't bother the users to much with them.
> 
> So what I propose is: Remove to UI differences between these two (execpt 
> creation) and use the technically right thing. Of course a nice UI 
> guideline how the different types of "things in the panel" should behave 
> (and typical look that shows the user what type a "thing" is) should be 
> discussed.
> 
> That way we get good positioning with changing situation for applets and 
> notify-icons. This would IMHO mean move the features of the Notification 
> Area into the panel and make notify-icon panel citizens like panels 
> (without restore on next panel start, that's task of the application they 
> are associated with).
> 
> Then we can debate the question of notify-icon vs applet on technical 
> merits, and the question of behviour and look on usability merits.
> 
> I think much of the work on panel applets is needed anyway so we might as 
> well try to unify these two.
> 
> 
> > > > 	+ Only icons or labels or a combination of both should be in the
> > > > 	Notification Area. No buttons, toggles etc.
> > > 
> > > I'd suggest that labels shouldn't go here either. The Notification Area
> > > should be for a *minimal* amount of necessary notification, with as much
> > > affect as you can get out of it. If your status icon needs text beside it
> > > to display anything useful, and the tooltip isn't enough, it probably
> > > should not be an icon in the status tray.
> > 
> > Imagine a battery icon that has to display percentage or time remaining
> > within its very small icon space. I strongly approve of labels in nicons.
> > 
> 
> A simple percentage might be ok, but nothing more esp. not labels labeling 
> other information. But i think most stuff should be as simple and small as 
> possible.
> 
> 
> > > > 	+ Right click or Shift-F10 should display a context
> > > > 	  containing:
> > > > 	    o A "Remove Icon" option - see below.
> > > > 	    o A "Preferences" option if the icon behaviour may be
> > > > 	      customized.
> > > 
> > > These seem to assume that the status icon is a separate process from
> > > the main application process, which is typically not true.
> > 
> > My interpretation of this section is that in some cases, the icon is
> > completely unrelated to any other process (or really, user application). A
> > network connection applet might be a useful example here. It doesn't
> > actually relate to any other program, it just gives you status/notification
> > info about your network connection.
> > 
> > Say I stop using PPP and am connected directly to my network, and feel that
> > the status icon is less useful to me, do I:
> > 
> >   a) Go to the network control panel and turn off the "Show status icon"
> >   checkbox, or
> > 
> >   b) Right click on the status icon and click "Remove Icon"
> > 
> > I think b is exceptionally useful in this use case - certainly, it is a
> > different issue when it comes to things like GnomeICU/Gaim icons, which are
> > directly related to another window/application (ie. they are the same
> > thing).
> 
> I don't think user should have to worry about such things with PPP. They 
> either use something that is alway on the panel and can be used to connect 
> to the internet, or they use something that is on the panel as long as a 
> connection is up. I don't think users adding and removing a thing on the 
> panel in such cases is a good goal.
> 
> This is a good boundery case: a PPP "thing" on the panel that should 
> visible if and only if there is a PPP connection. This could be an ui non 
> applet process running all the time (respawned by gnome-session) or an 
> applet that hides itself in some way (not possible at the moment).
> 
> I think every thing in the panel should have a "Remove <thing>" or "A 
> Close <think>" or "Hide <thing>" in the context menu. The user should have 
> a consistent way to get rid of stuff on the panel. Maybe it would be 
> useful to have it read "close" if it came to the panel by starting an 
> application, "hide" if it is notification of something(e.g. an new email 
> icon, but not an mailbox monitor) and "Remove" if the user added it 
> explicitly using add to panel. This would IMHO give the users an intuitiv 
> understanding of the lifetime/cycle of the thing in question.
> 
> Preferences should be shown if useful. For applets it shows the 
> Preferences of the applet in other cases it should show the application 
> Preferences Dialog. If the application has a complex config dialog with 
> tabs or a treeview the notification applet page should be shown.
> 
> > [...]
> > 
> > - Jeff
> 
> 
> Martin H.
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
-- 
Wesley Leggette <wleggette gate net>