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

[Jacob Beauregard <jake13jake comcast net>]

On Saturday 19 May 2007 18:48:54 Jacob Beauregard wrote:
> 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.

Ugh... too much trouble. Essentially, with contextual abbreviation and 
suggesting some possible extra options:

Something describing why this this alert came up.
Something showing the thumbnails of the collision and/or the ability to view 
them.

Options:
Don't (move new/keep old) file(s) (always/this instance)
Rename (new/old) file(s) (automatically/manually)

? Move (all/this) (new/old) file(s) to a different folder ?
? Save collision log ?

>
> 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.
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability