Re: [Usability] notification - design proposal

[Rodney Dawes <dobey free fr>]

On Mar , 2004-04-06 at 15:53 -0400, Sean Middleditch wrote:
> Hello all,

Hello. (I bet you weren't expecting annotated greetings)

>  On the GUI application I'm working on now (mostly for
> research/experimentation) I was thinking about adding notification
> features utilizing the notification-area tray.  That thing is fairly
> heavily abused but, as has been pointed out, there really isn't any
> documentation or established models to follow in regards to its usage. 
> My attempt here is to propose what I plan on implementing in my app and
> gather any feedback on that.  When implemented in my app (which is quite
> simple, i might note) it could provide a mini-testground to see if the
> model does indeed work well and, if so, perhaps we can finally get
> something added to the HIG or elsewhere to make this standard
> procedure.  I'd also like to propose some basic API layouts, since a
> solid single API is pretty much the only way to make sure all
> applications get it implemented the same way.


>  The model I'm basing this off of is used already in Apple's Safari for
> error messages.  Basically, errors/problems are reported in popups
> dialogs, similar to what most apps use now.  However, these popups do
> not appear unless the document window they relate to is already
> focused.  I.e., if Document A (http://www.gnome.org in Epiphany, say)
> has an error (DNS lookup) but currently Document B is focused (that's
> what I'm working on) the popups will not appear.  As soon as you focus
> Document A, however, they will appear.

This sounds like it could easily get confusing or out of hand. Though,
the hiding of
the dialog widget is easily doable. It would also just create a place
where we can
have more inconsistencies, since some error dialogs really should just
be shown no
matter what, and totally steal everything away from the user.

>  At the same time the user is alerted that there is something wrong.  In
> OS X, this is done over the dock.  (Which I don't like from a
> design/usability perspective, btw - see my advogato diary for an almost
> indepth writeup on why)  In GNOME, this would be done most likely using
> the window list and/or Metacity, by coloring the window orange or
> whatnot.  (Is there not already facilities for doing this?  Is there a
> reason the window list doesn't?  Just not implemented yet?)  I'd also
> like to use the notification-area.  

In theory, there is a window hint for ALERT, which would ideally make
the window flash
in some manner. This is what happens in Windows, when windows set the
ALERT hint or
however that works there. I am not sure that using the notification area
for this, is
the best, or even one of the better solutions.

>  For the notification area, an icon representing the app would appear. 
> Clicking this icon would focus the document window (and, thus, cause the
> popup error messages to appear) and remove the notification icon.  Note
> that since the icon only appears if the popups are being suppressed, the
> icon will never appear if the document window is focused when the error
> occurs.  Which is good, becaue the notification icon would be useless in
> that case.

The application icon could easily be confusing. I can see why you chose
to suggest its
use, but clicking on an application icon, and then being bombarded with
error dialogs,
can be overwhelming. Also, how would this work with tabbed interfaces,
like epiphany,
for example? And, how would it work with the case where I have multiple
windows, on
multiple desktops, for the same process, and an error comes up on
another workspace?
Currently, I think Epiphany and Galeon show the dialog on the workspace
of the window
parent where it occurred, but since the dialog is modal, you can no
longer click or
type into the other windows on the other workspaces.

>  For the API/wrapper I'd like to write for my app (in Python), and what
> I would like to see be made a standard part of whichever library is
> appropriate (egg at first, probably), a function would be present to
> register a dialog into this system.  It will be assumed this dialog is
> now already visible/shown.

I presume that you mean s/now/not/ here. 

>  The functions would check if the parent window is focused.  If not, it
> would attach an event callback to the window, and add the notification
> area icon (if one is not already present, in the event of multiple
> errors) and add the dialog to a list of pending error dialogs.  The icon
> added would when clicked do nothing other than focus the relevant
> document window and remove itself.  When the document window is focused
> (and the event callback triggered) all the pending error dialogs for
> that window would be shown.

Does "focus" here mean switch to the appropriate workspace and select
the window for
accepting keyboard and mouse input? Or does it mean to move the window
to the current
workspace, and raise it for accepting keyboard and mouse input? Why
would we show
*all* the pending error dialogs? If several different errors or warnings
occurred, am
I really going to want to have to click through a bunch of dialogs to
get back to my
application? Or should I really only care about the last error?

>  Additionally, the API would have a function to "recall" an error. 
> Given the handle of a dialog window, the function would check to see if
> the dialog is already shown; if it is, it's destroyed.  If the dialog is
> pending, its removed from the pending list.  If the pending list is now
> empty, the notification icon is removed.  This allows temporary errors
> to auto resolve.  For example, if Evolution were auto-checking mail once
> every 10 minutes, and the check fails once (server rebooting after a
> kernel update, say), the error dialogs would be added.  I might be
> working in a terminal window so I wouldn't get interrupted by popups
> stilling my keyboard focus.  If I don't bother to check Evolution until
> another 10 minutes pass, when Evolution re-checks the server and
> connects successfully, then I'll never be bothered by the error dialogs
> at all.

It seems to me that it would perhaps be better to try to reduce the
number of error
cases where the user would get notified first. After that is done, it
might make
more sense to have some applications that would do something in the
background, do
something like you propose, by possibly adding an "alert" to the
notification area.
Another issue to deal with, is that we need to differentiate between
user-requested
actions and actions that occur in the background automatically. So, if
for instance,
Evolution is set to check my mail every 10 minutes, and an error occurs,
and the
Evolution window is on another desktop, I might get a notification area
alert that
will show me the error(s). However, if I switch to the Evolution window,
and then
manually press Send/Receive, and switch back to another desktop to wait
for my mail
to download, and an error occurs, I probably want to just see the error
message right
now. BTW, your last sentence here sounds like a metaphor for you being
Ahab and trying
to kill the white whale of Evolution error messages. :)

>  Note that this API proposal is based on the average simple needs of
> most error dialogs.  There may be specific situations where the below
> won't work as desired.  I'd like to identify any that we can, and make
> any needed API changes to retain the simplicity and ease of use while
> allowing more complex situations.  Honestly, tho, I can't think of a
> situation off hand that the below doesn't cover.  Unless we want to add
> priorities or alert types (i.e., just an icon, or also a non-intrusive
> mini-popup?)  A lot of that can be hidden behind the below API, and
> things like priorites can be done with API additions without even the
> need to deprecate what we already have (since they would just use
> defaults).

Rather, I think I would say that most error dialogs probably shouldn't
be. You are
also seemingly only targeting error dialogs in this mail, yet you say
"alert" many
times. There are a lot more alert cases, than just errors. What we
really need, is
working balloon messages for the notification area. Another thing we
need to do, is
probably replace GtkMessageDialog for GTK+ 2.6 with a more robust alert
dialog API.
GtkMessageDialog really is t3h suck as it were. This is one thing I have
already
started a little work on.

I know a lot of people abuse the notification area currently. That is
bad. However,
I think we should really define how it should be used, before adding
more ways to
easily abuse it with error dialogs and the like. I also don't think the
notification
area, as is, is very good for notifying users of much, especially
important things,
like error dialogs very well may be. I have had gaim crash several times
recently
when trying to reconnect to a service, and it has taken me 30+ minutes
every time to
notice that the tray icon was missing. And, having a bunch of icons
blinking in
different rhythms may also be just as bad. While blinking can help grab
the attention
of the user, it can also be very overused many times. Fixing the sound
events system
in gnome is something else that needs to be done, and could help with
our cause of
telling the user something has happened, by not being overly intrusive
to their work.

I applaud your enthusiasm and efforts, but I'm not sure that your
proposal is the
right way to go about the error dialogs or alert dialogs in general, and
the use of
the notification area. I really think we need to define more of what to
do with
certain pieces of technology that we possess, first, and then deal with
writing the
policy for how those various pieces should interact on a higher level.
Unfortunately,
I suck at writing. However, if you and someone with more pronounced
technical writing
skills than it seems either of us have, want to discuss how the
notification area
or other pieces of the various APIs, like sound events, should be used,
let me know.
I'd be glad to get some of these higher-level issues solved, so that it
will be easier
for both developers to write nicely integrated pieces of software, and
users to use
that software.

-- dobey