Re: [Usability] Cascading Menus, Context Menus, and Moving Files

[Matthew Paul Thomas <mpt myrealbox com>]

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 
> this link.
>
> http://surfmind.com/masters/screens/the_making_of_a_visualization.html

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

It reminds me of a picture I drew long ago to demonstrate why shortcut 
menu (aka context menu) submenus suck.
<https://bugzilla.mozilla.org/show_bug.cgi?id=70830#c35>

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

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

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 
Gruber. <http://daringfireball.net/2003/03/i_love_it_because_its_trash> 
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 
Move”."

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/