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

[Matthew Paul Thomas <mpt myrealbox com>]

On May 22, 2007, at 1:14 PM, Jacob Beauregard wrote:
> ...
> 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.

Depends what you mean by "useful". There are several factors involved, 
including time to find an item when you don't know where it is, time to 
access an item when you do know where it is, time to recover from 
mistakes, and time and willingness of people who've been using any 
other system (including previous versions of Gnome) to learn the new 
system.

As Thorsten said, it would mean opening a submenu would require a click 
rather than a mouseover. But that wouldn't *necessarily* be a bad 
thing, because menus currently have a delay before opening just in case 
you're mousing over the submenu title on your way to another menu item, 
and with an explicit click that delay would no longer be necessary.

> ...
> I'm starting to think more and more that you're the person who bugged 
> the combo boxes.

I have no idea what you mean. What combo boxes? Bugged how?

> Context menus are generally used by more novice users that haven't 
> learned keyboard shortcuts.

As with Calum, that's pretty much the opposite of my observations.

> Keyboard shortcuts are usually where users rely on muscle memory.

That's usually not true either, though people *think* it is, because 
they're thinking so hard about what the keyboard shortcut is that they 
don't realize how long they're taking to think about it. (Apparently vi 
users are an exception to this rule, though, so I need to research that 
more.;-)

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

Ah, horizontal centering! I thought you meant vertical centering, but I 
should have realized that wasn't mentioned in the paper you linked to. 
Sorry for the diversion.

So do you mean that when you hover over a submenu title for long 
enough, not only should the submenu open, the mouse pointer should also 
jump across to the horizontal center of the submenu, to make moving 
through the submenu easier?

If so, what if the submenu opened only because you hovered a little too 
long on its title, on the way to the next item down? Normally, that 
doesn't matter. Here, it would.

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

But *I* have already suggested that would be too complicated to save 
most people from dataloss. :-) So we may just have to agree to 
disagree, at least until one of us is rich enough to do a usability 
test.

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

No, because the alert has to cater for *everybody* who uses Nautilus at 
all, not just those few who haven't yet gotten into the habit of 
ignoring alerts.

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

Agreed with your identification of the problem, just not with your 
proposed solution.

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

I agree that "Skip" is a silly idea, but I'd rather it was changed to 
"Cancel", such that it stopped the move/copy before it even began.

This is because renaming the clashing items at the source is not the 
only method by which you might want to resolve a clash. Other methods 
include (2) renaming the clashing items at the destination, (3) moving 
the clashing items (and maybe even other items) out of the destination, 
(4) creating a subfolder in the destination, or most importantly, (5) 
*realizing that you were moving/copying into the wrong folder in the 
first place*. In case 5 especially, even "Skip All" is not good enough; 
you still have to go clean up the mess that the file manager made 
before it bothered to discover the first clash.

Choosing the appropriate method *outside* of the alert has two 
benefits. First, the alert is no longer open, so you're no longer 
itching to blat it away as fast as possible. Second, you can use 
exactly the same file manager UI as you would if you'd handled the 
problem before trying the move/copy. You don't need to learn a whole 
different UI for creating subfolders, renaming items, etc. (I think 
Nautilus should have a mass-rename function available all the time, not 
one that's available only in replace confirmation alerts.)

Now there may still be benefits of presenting such an alternative UI 
for those operations in a combined dialog, for ease of choosing which 
methods should be used on which clashing items. That's why I suggest a 
separate "Merge" dialog. But I don't think the replace confirmation 
alert itself is the right place for that alternative UI, because the 
extra complexity would just blind more people to the alert as a whole, 
leading to more dataloss overall.

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