Re: [Usability] notification - design proposal

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2004-04-07 at 00:32, Rodney Dawes wrote:
> On Mar , 2004-04-06 at 15:53 -0400, Sean Middleditch wrote:
> >  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,

Ideally, there won't be that many error dialogs.  If the desktop is
generating that many error dialogs, there's a problem somewhere else
than the UI...

> 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.

Any examples of such errors that actually occur?

> 
> >  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.

I'd personally like to see the window in the window list colored
differently for these windows.  In regards to the notification area,
tho, that *is* what it's for - notification.

> 
> >  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

I agree.  I was thinking about that very issue, but couldn't come up
with a good solution.  Perhaps add another function to see the error
icon, with recommendations on how those should be colored and/or related
to the document icons?  (i.e., red-tinted version of the dialog with an
exclamation point over it?)

> 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,

Again, you should't be "bombarded."  Most apps should only really ever
have one error occuring at a time, ever.  (if an error occurs, it won't
continue its task until the error is resolved.)  Perhaps the proposal
should be reworded to emphasize the "only one error dialog" model, with
provision for exceptional circumstances (none of which I can actually
think of, to be honest).

> 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?

First off, errors are *document* centric.  Epiphany doesn't have errors
loading a page.  The window with the page itself has the error.  Error
dialogs under this model *must* be associated with a document window.

For tabs, I again think of Safari.  In Safari, when you have a window
with tabs, and a document in a tab has an error, the tab becomes colored
special (and gets an alert icon).  When opening the tab the error dialog
(only ever one, again) appears.  If that window isn't focused, then the
alert notifier in the dock occurs (the icon bounces) allowing you to
click on that and re-focus the relevant window.  Thus, again, the error
dialog doesn't interrupt your work.

> 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.

Then that's a bug with the error dialogs.  They should be fixed so as
not to be so brain-dead.  I recall seeing that problem before, and it's
incredibly irritating, and a *perfect* example of why my method is
better.  I'm on workspace A and click a link in an Epiphany window, then
switch to workspace B and start working in another Epiphany window.  The
second window suddenly locks up, and to me it looks like the whole app
locked.  I don't even remember the window on workspace A usually because
that's not the task/document I'm working on, and it's thus naturally out
of my mind entirely.

> 
> >  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. 

Yes.  ^^;

> 
> >  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

I mention that problem below.  Read the mail first, write reply after. 
;-)

> 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?

Why does the application have so many error dialogs?  The application is
doing something wrong if it has that many.  And, aside, that problem
already exists.  If Epiphany starts popping up tons of errors because a
whole group of tabs fails to load, you have to get rid of all of them. 
Quite annoying.  It's even more annoying that it's popping up these
irritating dialogs even tho the tabs they relate to aren't what you're
looking at or working on at the moment.

> 
> >  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

That's a separate issue.  I'm not trying to concern myself with why apps
are showing errors (I'm not the app author, I can't claim to know what
causes an error in their case), just trying to make it so when errors
occur, the user doesn't get interrupted by alerts from tasks that are
completely out of their mind at the moment.

I do agree that the number of error dialogs created should be at a
minimum.  If it's not something the user needs to know about or correct,
don't bother telling them.  Condense multiple errors where possible. 
etc.  Perhaps something else to be added to the HIG?

> 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. :)

I don't ever see Evolution error messages often, actually, so that's not
the best app for me to discuss.  probably should have avoided it to
begin with.  ;-)

In regards to "seeing the error message right now" after explicitly
askign to check mail... *why* do you need that dialog to pop up so
badly?  You'll know about it the second happens because of the
notification area.  If you just keep error dialogs on the workspace they
occur, as some apps do now, then you won't have that knowledge.  You
won't have your work interrupted by the dialog, which is good, but if
you did care about resolving it quickly, you'd have to constantly check
back.  The notification area solution solves *both* problems.

> 
> >  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

Sorry.  I tend to abuse terminology a lot.  ;-)  When I say "alert" I
generally mean "something has gone wrong and you need to know" which
pretty much means "error."  Warning dialogs, if they are actually needed
(again, its a separate issue about what users need to know or not - that
isn't this documents goal), should be handled just the same.  Don't
popup the warning dialog and interrupt your work if the warning doesn't
have anythign to do with what you're working on, but at the same time
make sure the user knows there is a problem that they may need to review
or deal with.

Popup balloons would work as well.  Since there is no consensus on what
should be *in* said balloons (just text?  other widgets?  are they a
replacement for error dialogs or just enhance them) and since I really
don't know the asnwers to those questions, i avoided them.  If we want
to start a discussion on what popup balloon alerts should do, what cases
they should be used in, etc. then I'm perfectly alright with that.  ^,^

> 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.

Sounds like somethign that should be done before thinking about this
stuff, then, doesn't it?

> 
> 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

The style issues of icons should then also be address in the HIG. 
Things like coloration, usage, animations/blinking, etc.  I.e., *if* we
decide blinking is good, then perhaps we should specify the rate and
beat they blink on.  (Once every other second, on the second.)

> 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.

Agreed.  Altho sounds alone won't solve the problem.  They can't tell
you who had the error and where; just that one occurred.  Don't want the
user to have to hunt all over their workspaces to figure it out.

> 
> 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.

Perhaps.  I started from the perspective of the user (the problems with
error dialogs as things are now, how I think they could be improved) and
then specified with technologies we should use.  Which is the right way
to do the design, I believe.  I may have just chosen the wrong set of
technologies.  ~,^  I'll admit now that I'm *not* very familiar with
GNOME/GTK internals; I don't develop GUI-based apps very often at all.

> 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

(that's a bit funny; I write technical specs for contract jobs a lot. 
my original mail was more of a "brain storm" mail/proposal than a real
technical spec.  ~,^ )

> 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.

I suppose perhaps we should start over, again thinking about what we
want/need in errors/alerts.  When should they be used?  When should they
or should they not interrupt the user?  How do we want to convey to the
user that there is an error in different task/workspace?  Figure out
what we want to do, *then* figure out how to do it.

Sounds events are definitely something we should add.  The lack of sound
events is actually rather irritating in GNOME; I've just gotten so used
to it that I forgot it was a problem.  ~,^  I'm not entirely sold on the
popup balloons until we decide what they should do.  If all they are
going to be is an alternative error dialog (they have all the
information, widgets, etc dialogs normally have) that simply doesn't
steal focus, I wonder whether they are really an improvement worth the
effort.

> 
> -- dobey
> 
> 
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://lists.gnome.org/mailman/listinfo/usability
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.