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

[Jacob Beauregard <jake13jake comcast net>]

Wow, I've never even come across the collision dialog in KDE until now just 
because I wanted to see what it was.

An older item named '/blah' already exists.
[icon] size XXX B 
--------- created on XXXX-XX-XX XX:XX
--------- modified on XXXX-XX-XX XX:XX

The source file is '/folder/blah'
[icon] size XXX B
--------- created on XXXX-XX-XX XX:XX
--------- modified on XXXX-XX-XX XX:XX

[text input defaults to filename] [Suggest New Name]
[Rename] [Skip] [Auto Skip] [Overwrite] [Overwrite All] [Cancel]

Also has the utility of recognizing if your moving/pasting duplicates, but for 
some reason will ask you for a new name because it would "overwrite."

These icons are just there, one cannot click them and open the file in 
question. This is just KDE though, and that's quite useful, imho, though it 
could be a bit better (in a sense that one would possibly be able to view the 
files from the dialog via clicking the icon). "Suggest New Name" doesn't seem 
like it would offer much utility unless it applied to all the files.

Whoever suggested that not being able to rename by default isn't such a bad 
idea, here is my argument for you.

Under the assumption that the user usually wants to move all of their files 
without collisions. It would be most efficient to do the work while moving 
the files than doing guess work before and after.

One could compare it to the statements: 

while (not everything moved without collisions) {
  for (int i=0; i < n; i++) try moving thing[i]; 
  for (int i=0; i < n; i++) fix problems;
}

vs.
 
while (not everything moved without collisions)
  for (int i=0; i < n; i++) {try moving thing[i]; fix problems;}

The fact is, doing nothing about a collision when it happens will inevitably 
lead to redundant actions by the user (i.e. more work). I wouldn't be 
suggesting a feature-obese and ugly dialog, just added functionality for 
renaming in SOME sense, as well as the ability to view the files of interest.

Perhaps something like:

The file with the name '[name]' already exists. Please make the appropriate 
changes to either filename.

[------------------] File in [moving file's current location]
[icon button] [input text defaults to filename] [Reset] [OK]
[------------------]
[icon button] File in [collided file's location]
[------------------] [input text defaults to filename] [Reset] [OK]

[Skip*] [Skip All*] [Replace] [Replace All*] [Auto Rename*] [Cancel]

*not needed for single collision

I don't know if that would be the best way to design it for multiple 
collisions. It might be beneficial to some to have some sort of extremely 
cheap access to the properties of the files to see things like date 
created/modified rather than including them directly (though as a button, I 
don't know how a context menu would even be expected).

I also think it's wise to use the OK buttons on the filename part, because 
that will not lead to interference with the people who know they want to skip 
or replace files (skipping/replacing requires more knowledge of what you're 
doing, and OK is more reassuring).

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