Re: [Usability] Disclosure triangles

[Matthew Thomas <mpt mailandnews com>]

Liam Quin wrote:
> 
> On Sat, Dec 29, 2001 at 04:12:49PM +1100, Jeff Waugh wrote:
> > Here is a pic of Jim Cape's most excellent GnomeChat dialogues:
> >   http://jimbob.myip.org/sshots/2001_10_08_171943_shot.jpg
> >
> > Lumpy arrow, good labels. Thoughts?

First, it's not a dialog, it's a progress window. Its primary purpose is
not for the user to enter information about how the computer should
carry out a task (which a dialog is for); it's to show progress of a
task which the computer already knows how to carry out.

Yeah, this sounds rather anal. But being anal about this sort of
distinction (progress windows vs. dialogs, alerts vs. dialogs, utility
windows vs. dialogs) will actually make your software more usable in
most cases, in the same way that being anal about grammar (adverbs vs.
verbs, interjections vs. verbs, adjectives vs. verbs) will make your
English more understandable in most cases. You can sometimes get away
with muddying these distinctions if you're the UI design equivalent of a
poet, but most people aren't. :-)

Now, maintaining distinctions between different types of window shows
the first small problem in Jimbob's design: the icon in the top left
corner of the window, combined with the wide-and-short window
proportions, makes the window look unnecessarily similar to an alert.
So, I predict usability testing would find at least a few people blindly
clicking the `Stop' button because they thought the window was an alert,
and `Stop' was the only button in the window. To fix this problem, I'd
just remove the icon, which isn't adding much anyway.

The second problem is that having the words `More Information'
duplicated in several different windows on the screen (if you had
several transfers running) would be rather tiresome. Where possible, the
text for an expander should be a meaningful summary of what the expander
is hiding, rather than a generic label like `More Information'.

In this case, the expander is hiding stuff which is mostly about the
speed of the download -- amount left, amount remaining, transfer rate.
The time remaining is, itself, a reasonable summary of that stuff, so it
can be the label for the expander.

,--------------------------------------------.
|:::::::::::: Sending to Dekar :::::::::::(v)|
|--------------------------------------------|
| Sending MyDoc.txt ...                      |
| [###):::::::::::::::::::::::::] (  Stop  ) |
| __                                         |
| \/ Time remaining: 3 hours, 2 minutes      |
|                                            |
|     Total to send: 4.5 MB                  |
|       Sent so far: 2.0 MB                  |
|              Rate: 2.5 kB/second           |
`--------------------------------------------'

(The order of the expanded fields probably isn't optimal, but you get
the idea.)

> I would like to be able to click anywhere on "more information".
> Actually I'd prefer a button that said "more information..."
> Why should I have to fiddle around trying to click on some tiny
> triangle when there's all that space used for the label?

You could say exactly the same thing about checkboxes and radio buttons.
Do you want to make their labels look like buttons, too?

> The tree triangles in Mozilla, I hate with a passion -- I am never
> sure what, if anything, clicking on one will do, and I don't remember
> whether I need to single or double click,

I am sorry about that. I think that is the fault of their inconsistent
usage -- they should always open with a single click, and we have a
number of bug reports open on making them consistent. I don't think it's
a problem with the original idea of the control itself.

>                                           and there's no feedback
> (busy cursor, etc) to show I've clicked.

The triangle, like any non-field control, should go darker when you
click it. If it doesn't, please file a bug.

>                                           Tree triangles on the mac I
> can usally deal with, although it's not obvious which shape means
> "click to expand more" and which means" things are hidden" and which
> means "nothing more here".
                                                   __
|> always means you can click to show extra items. \/ always means you
can click to hide the extra items. The only case when |> *won't* show
extra items is the case where a folder contains zero items, and having a
special symbol for that (relatively) rare case would probably be more
confusing than useful.

> But if I can click on the label next to the triangle, it's no longer a
> nightmare in clicking a tenth-of-an-inch-across control that doesn't
> even look pressed or highlight when the mouse is over it.

You should be able to click the label, but (as with checkboxes and radio
buttons) that doesn't require that the label have a bevel as well as the
control itself.

> The "Less information" triangle is odd in the screenshot referenced
> above. The triangle should point upwards, to sho that the extra info
> will be hidden.

That's how expanders used to work on the Mac, back in the days when they
looked like a flag on a rural mailbox, before they were fixed to use
triangles instead. I guess it's more intuitive that the triangle points
to where the expanded items are, rather than to where they will be if
you click it -- in the same way that a checkbox shows you what the
current state is, not what the state will be if you click it. (When an
expander is unexpanded, the stuff it hides is conceptually `inside' the
label, just as in a file manager's list view the items in an unexpanded
folder are inside the folder.)

>...
> KDE's ppp dialer has a "details" button that brings up a new window,
> but that window hasa "close" button, worrying becuse you are not sure
> if it means close the window or close the connection!
>...

Quite. Any time you feel the need to implement a `Close' button, you can
be sure you're doing something wrong.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>