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

[Jacob Beauregard <jake13jake comcast net>]

On Monday 21 May 2007 15:50:08 Matthew Paul Thomas wrote:
> 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>
>

Do you think that if context submenus were presented in the fashion of a tree 
rather than cascading that it would be more useful? I think it would, but I 
can't quite imagine how it would look.

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

Visibility would be, by far, more important than centering. Visibility is 
expected behavior. A menu is practically rendered useless and is much more 
difficult to learn if a user can't see what's in it.

> (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 resitioning of
> submenus would be inconsistent enough that people might never discern
> any pattern in it. It would be a repeated subtle distraction.

The fact is that there's already positioning for context menus. I wouldn't be 
so much worried about menu bars right now. Positioning at screen borders 
wouldn't have to change at all.

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

I'm starting to think more and more that you're the person who bugged the 
combo boxes. Context menus are generally used by more novice users that 
haven't learned keyboard shortcuts. Keyboard shortcuts are usually where 
users rely on muscle memory. Novice users, on the other hand, are more 
inclined to rely on the context menus. In addition, if the user doesn't have 
many degrees of freedom in which to reference the context menu, desirable 
operations would require MUCH more cost by the behavior you describe. I, as 
well as many other users have experienced this first hand with the combo box 
mess. It also interfered a great deal with my window grouping strategies.

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

I'm confused as to how this applies to anything.

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

Once again, I have no idea what you're talking about.


Okay, now that I'm reading this again, I think you just entirely 
misinterpreted what I meant by centering the context menu under the mouse. I 
meant centering the mouse along the top border (or the bottom border if on 
the bottom of the screen) with some kind of offset, not the central item. 
Centering the context menu as a whole wouldn't be useful for a number of 
reasons.

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

She didn't really know what GNOME was, but she said that it was the system and 
that she would have been able to do it in Windows (for a task that's 
practically identical using windows). That implies GNOME.

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

It doesn't have to make choosing the first menu item in the menu slower. That 
would be specific to the positional rendering in most cases, and in the cases 
for which your argument would apply more strongly (the panels), it's 
definitely proven itself as useful for KDE.

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

I would argue for overriding sibling context menus with the selection context 
menu, and also adding "clear selection" to the context menu, meanwhile 
maintaining the current selection.

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

Or possibly drawing the item to be dropped with an arrow pointing into the 
folder/media it will be dropped into. Actually, it's possible that I've filed 
a bug report for this multiple times. Everyone go find this on Bugzilla and 
comment the hell out of it.

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

Yea, it's definitely one of those adaptations people would have to make 
because they're actually misapplying the context.

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

Yea, it would be useful.

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

Once again, you're forgetting that things can be adapted. When moving files, I 
have already suggested that collisions prompt the user for a new file name, 
or in essence, the suggested modifications to the collisions dialog when 
moving files.

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

Are you forgetting that this is a use case for someone that doesn't use the 
computer all that often? The ability to view the files and the existence of 
text fields for renaming either file, are in my opinion, a feature that 
should just be there. Otherwise the dialog is simply useless to completing 
the job of moving the files.

All the collision dialog does right now:
Slow down users that are expecting to overwrite files.
Offer no functionality for the people who weren't expecting it.

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

Still, choosing "skip" doesn't help the user accomplish the task, it simply 
puts it off. It would be easier to change a filename upon a collision as 
opposed to moving to the files original location which may or may not be 
obscure, and renaming them all one at a time. Though there are some 
applications that can help with this, there would also be extra costs of 
operating those applications. For a novice user this would amount to right 
clicking every icon, choosing rename, and typing a new filename for every 
one. Meanwhile, replacing, though sometimes applicable, has major 
recoverability issues. Allowing for the user to see what they're changing 
(and it doesn't have to be thumbnails) in an environment with filenames that 
aren't necessarily descriptive adds a lot of utility, and an option for 
renaming would also keep the issue at hand. 

Meanwhile, when there are collisions, users can either expect it (replace), or 
don't expect it (skip). Not providing useful options for a collision that was 
clearly not expected is a travesty.

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

I don't find the name you have for that behavior very descriptive.

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

This is wrong because you're offloading the work into a separate task for 
people that just wanted to keep both of the files. I've already outlined how 
offloading is extraordinarily inefficient for users that didn't expect this 
behavior.

>
> Cheers