Re: [Usability] Cascading Menus, Context Menus, and Moving Files
- From: Matthew Paul Thomas <mpt myrealbox com>
- To: GNOME Usability List <usability gnome org>
- Subject: Re: [Usability] Cascading Menus, Context Menus, and Moving Files
- Date: Tue, 22 May 2007 07:50:08 +1200
On May 20, 2007, at 5:25 AM, Jacob Beauregard wrote:
I was browsing looking for some usability studies on cascading menus
the other day (If you didn't know, I hate cascading menus). I found
Ah, Andy Edmonds! He and I used to chat about Mozilla usability back in
the day. Unfortunately he went to work for Microsoft. :-)
The information that's on this page, and the visualization of it, could
probably bring someone who's mind is on usability, into
It reminds me of a picture I drew long ago to demonstrate why shortcut
menu (aka context menu) submenus suck.
For instance, in the diagrams, the users almost always move the mouse
toward the center of a menu before continuing. This is a strategy in
menu browsing, and eliminating the need for it could subconsciously
make the interface feel more usable. Why not center menus under the
mouse rather than the traditional method of drawing it right of the
mouse? The one exception for this of course, would be if centering a
menu under a mouse would interfere with the visibility of the menu.
Well, that's right. More precisely, what do you do in cases where
(height of submenu) > 2 * (distance from screen top to submenu title),
such that you don't have room to center it? You have two choices:
(1) Give the menu an upward auto-scroll arrow (even when it would easily
fit on the screen without auto-scrolling at all), so as to preserve
that center positioning.
(2) Temporarily abandon the center positioning.
With a menu bar this issue would come up fairly often, because menu
bars are usually close to the top of the screen, so (distance from the
screen top to the submenu title) is relatively small. If you chose (1),
that would likely make those submenus more difficult to understand --
because submenus, like menus, tend to be designed so their structure
can be scanned top-to-bottom. If you chose (2), the positioning of
submenus would be inconsistent enough that people might never discern
any pattern in it. It would be a repeated subtle distraction.
(A related problem occurs with shortcut menus near the screen bottom.
If you get used to using shortcut menus rapidly (in the way that every
OS except Windows allows, because Windows opens them on mouseup rather
than mousedown), you can memorize at least the first item as a gesture,
rather than looking at it each time. The canonical example is "Back" in
a Web browser's shortcut menu. But if you happen to open the menu near
the bottom of the screen, and the menu is as long as it is in Firefox
or Internet Explorer, the menu opens upward instead of downward and
your gesture memory is useless. Netscape versions 2~4 for Mac are the
only software, on any platform, that I've ever seen get this right: the
menu still opens such that the first item is immediately southeast of
the cursor, and there is an auto-scroll arrow at the bottom, even
though the menu would fit on screen completely if it started higher up.
That way your muscle memory is preserved for as many items as still fit
between the cursor and the bottom of the screen. And preserving muscle
memory is more important than all the items being visible to start
Another problem with centering submenus would be when the submenus were
dynamic, with items added or removed over time. (An example of this is
the "Edit" > "Remove Tag" submenu in F-Spot. I'm not suggesting it's a
*good* example, but there it is.) When a submenu opens with its top
aligned to the submenu title, only those items *below* an added/removed
item will have changed position relative to the submenu title. But if
the submenu was centered relative to its title, *every* time an item
was added or removed, *every* other item would change position relative
to the submenu title, which would be more disruptive to your muscle
If you have a long first-level submenu, though, you can give your users
some of that centering goodness by placing the submenu item near the
bottom of the main menu. This is, I assume, partly why the Encoding
submenu is so low down in the "View" menus of Evolution, Firefox, and
Konqueror. Their respective toolkits (correctly) don't align the top of
the submenu with the top of its title if that would mean the menu never
fits fully on-screen; they start it higher instead. So you get
something close to centering.
When my mom's digital camera wouldn't connect to Windows 98, I gave
her my desktop computer that uses GNOME. So I have to mention a few
more things about context menus that she gave her a hard time. Mostly,
she wants to be able to easily organize her photos in the file system.
She blames her problems on GNOME even though she obviously had never
done the same thing on Windows.
This may not be a popular opinion around here, but IMO it's unfortunate
that she ever had to know what "GNOME" was at all. Ubuntu, Suse,
Fedora, fine -- but GNOME? That's like someone with an iPod having to
know what Wolfson Microelectronics is.
Please keep in mind that all of the following is based on the Ubuntu
Feisty packages, so if you can't duplicate it with the latest GNOME,
don't shoot me.
Ubuntu's release schedule is designed such that, except for a week or
two each year, the latest release includes the latest Gnome.
1. She was confused about what the context menus were referring to. One
solution would be to give context menus a header as to what they are
referring to. KDE does this for many panel applets and the system tray
already, but nothing else. GNOME doesn't have any similar behavior. It
could also be considered whether sub-headers would be useful, but at
this point I'm only recommending a header that states what the context
menu is for.
Netscape 3 for Unix did this. One drawback is that it makes choosing
the first item in the menu much slower -- you can't just mouse down,
flick the mouse a pixel or two to the southeast, and let go. (I suppose
you could make the header appear to the northeast, while the first menu
item was still immediately to the southeast, but ... meh.) Another
drawback is that shortcut menus often contain a grab-bag of whichever
menu items happen to be used most often (hence the name), and/or items
that apply to successively wider contexts, and in either case there
won't be a coherent title you could give the menu anyway. (I can't
remember what the Netscape 3 shortcut menu title was, but I'm pretty
sure it was always the same regardless of where you opened it.)
2. When I was trying to show her how to copy/cut/paste multiple files
at the same time, she continuously made the error of right clicking on
whitespace and therefore lost the selection she had made. Considering
how many files she was copying, this wasted a lot of time. I wouldn't
immediately be able to think of a solution for this.
Jimmy Clarke addressed this. I don't have an opinion on whether the
correct behavior should be to open the menu that's relevant to the
selection, or the menu that's relevant to the position of the mouse,
but I'd be interested in reading arguments for either.
3. When she tried dragging photos into a folder, the size of the
thumbnail made it impossible to see whether or not the folder was
highlighted. I would categorize this as a bug,
Yes, please report it as a bug if it hasn't been already. Items being
dragged should never obscure drop targets, that's defeating the point.
They should be either nearly transparent, or (if that's impossible with
current technology) drawn just as an outline.
4. "Move to Trash" in the context menu confused her, because she is
familiar with calling it delete. She was especially confused because I
told her to "delete" the folders she had successfully moved all of the
files out of because they were now empty and useless. I'm not saying
this should change, though someone might have a bright idea of how to
end this confusion.
There probably isn't a good way to solve this confusion, unless we
somehow change the English language such that "delete" means what
Windows claims it means, even though Microsoft knows it doesn't really.
"When you delete a file or folder, the file or folder is not deleted
right away", they say <http://urlx.org/microsoft.com/0cf03>. Wackos.
I can say though, it would have been beneficial for there to have been
a visual cue to whether or not the folder was empty, as the folder she
was moving to the trash was quite similarly named to another folder.
Folder icons in Nautilus are depressingly unexpressive. How much do the
folders have in them? What kind of files are they, mostly? How old are
they? How often do you use them? You can't tell any of this by looking
at the icon.
5. When getting the message that moving files to a folder would
overwrite already existing files, she didn't know what to do. If I
hadn't told her to say skip and rename the files, she would have
overwritten the files with the same name. This presents a problem with
recoverability in moving files. I would suggest possibly making a
section in the trash for files that were overwritten from the
clipboard and from drag & drop behavior.
The last time I read this suggestion was four years ago, from John
I e-mailed him and said, in essence: "That wouldn't work, because what
if you later went into the Trash, and selected the item that just got
replaced, and chose 'Put Away'? [That's basically the classic Mac OS
equivalent to 'Restore' in the Windows Recycle Bin, in case you're
wondering.] The item in the Trash would replace the item you'd moved in
the first place, so by the same rules, that item you'd moved originally
would end up in the Trash, so the two items would swap places, it would
look like nothing had happened, and would just be really strange."
John replied with words to the effect of: "That's no problem, because
as of Mac OS X, the Finder doesn't *have* a Put Away command any more."
And I replied with words to the effect of: "What the hell?!?"
Alas, Nautilus's Trash doesn't have a Restore command either. :-] And
the problem I raised with John was an edge case which probably could be
solved somehow, though I still don't know how.
The other problem with the overwrite dialog. It does not guide the user
through what they can do to move the file successfully. The user is
presented with: Skip All, Replace All, Skip, Replace. Even worse, the
user is presented with the question in BOLD, "Do you want to replace
it?" which may have lead her to click "Replace" and permanently lose a
large number of her photos. The mentioning of overwriting the
contents, even if she knew what that meant, wasn't in bold.
I would suggest displaying thumbnails for both files in the dialog
that the user can open so that the user can see the difference between
the files. I would also STRONGLY suggest giving the option to rename
the file. This option should be failsafe, as it should not allow the
user to choose another filename that already exists, and should inform
them if they do so.
I think everyone, when trying to design this alert, falls into the trap
of thinking that people will look at it for any more than about half a
second before making a choice. A few people may, but many won't.
So you need to be *really really sparing*, choosing the elements that
are *most likely* to help people. You want more than two buttons? Okay,
that's your half second used up, no reading time left for thumbnails.
You want to include thumbnails? Okay, that's your half second used up,
no reading time left for more than two buttons. You want to include the
files' modification dates? Okay, that's your half second used up, no
reading time left for thumbnails *or* more than two buttons.
Another option would be to automatically rename all files, such that
on a collision with 00002.jpg, it will just name the file 00002_2.jpg,
and on collision 00003.jpg, it will just name the file 00003_2.jpg.
That option would be great for a separate "Merge" dialog, opened from
an extra button in the replace confirmation alert. So of all the extra
things *I* could choose to put in the replace confirmation alert, a
"Merge..." button would be it. That way the alert itself could be kept
really simple, but people who wanted to do complex selective
replacements or renames could do it with an interface much less
ridiculous than choosing "Skip" vs. "Replace" one item at a time no
matter how many hundreds of items there are.
But on the other hand, once Restore is implemented for the Trash, and
Undo is implemented for moves/copies, we could just about get rid of
the replace confirmation alert altogether, and use a notification
bubble instead. "12 items in “Destination” were replaced by items you
moved, and are now in the Trash. To reverse this, choose “Edit” > “Undo
Matthew Paul Thomas
] [Thread Prev