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

[Jacob Beauregard <jake13jake comcast net>]

On Tuesday 22 May 2007 11:33:55 Matthew Paul Thomas wrote:
> 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?

Well, I mean opening on right-click, but that's a thought. In my experience, 
moving the mouse, especially without any visual cues and delaying the users 
motion, will almost always lead to some amount of error on the part of the 
user (this behavior is in winXP for certain things like shutting the computer 
down).

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

For two and three, you're forgetting it's beneficial for users to know what 
files are causing collisions. You're also forgetting that the user may want 
to rename the items from either the source or 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.

That's a good point (5).

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

Okay, let's first agree on the ordering of what's most likely to be the case, 
and what's least like to be the case.

1. The user wants to move the files without collisions
2. The user wants to move the files to replace other files
3. The user doesn't want to move the files.

Do you agree with this?