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

[Jacob Beauregard <jake13jake comcast net>]

On Saturday 19 May 2007 14:13:36 Thorsten Wilms wrote:
> On Sat, May 19, 2007 at 01:25:00PM -0400, Jacob Beauregard wrote:
> > 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.
>
> So right-click single file: context menu header contains filename?
> The names can't be listed for multiple selected files (it could be 20, 200,
> 2000). Just use "Selection" as header?
>
> > 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.
>
> My first impulse was: why does right-clicking on white space clear the
> selection, it should not do that. But the context menu always works on
> the selection ...
>
> Maybe the target areas are too small or just not obvious enough?
>

Well, to my mother, she expected that a right click on anywhere in the 
whitespace when files were selected would bring up a context menu for the 
selection. On the contrary, this action not only didn't do what she expected 
(bring up the context menu for selection), it cleared the selection. 

I think a possible solution might be to have the selection context menu either 
coupled with the whitespace context menu (as is common with apps used in 
document editing), or to have the selection context menu override the 
whitespace context menu (as is common with apps used in document viewing).

Also to note, that this is a bit on the edge because almost every other 
desktop I've used behaves exactly the same way as GNOME does in this regard. 
This one needs to be well thought out.

> > 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, and I wouldn't know if its
> > fixed because I don't know if Ubuntu, the distribution that I use for her
> > computer, has the latest GNOME packages.
>
> Ah yes, this one has been bugging me, too.
>
> > 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.
>
> Agreed. I tend to feel uneasy about deleting folders that should be empty
> :)
>
> > 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.
>
> This would be no problem at all if filenames in a folder wouldn't have to
> be unique. It happened that I renamed images just so they could exist in
> one folder, not caring one bit about the actual filenames otherwise.
>
> > 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.
> >
> > 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.
>
> I mean to remember that at least one of Gthumb and GQView show thumbnails,
> date, size and allow overwriting, skipping, renaming. Might be that
> renaming even defaults to a scheme like yours.

Well actually, you know how when you create a new folder when there's already 
one with the default folder name ("untitled folder"), It will just make the 
it "untitled folder 1" and so on.

Auto-Renaming would probably work out well for casual users, but if you 
actually need a pathname for something, Only doing auto-renaming could be a 
pain in the ass. 

I could try to make a mockup in GIMP or something.

Another thing I can note that would be useful, moving collisions into a 
separate queue. I mean, if the intent is to move all the files, then do 
everything you can to move the files without needing user input while waiting 
for user input on the collision. If there are a ton of files to be moved, and 
the user decides they will watch a movie while waiting for all the files to 
move, and a collision happens like a quarter of the way through the way it 
is... Lets just say that would be frustrating.