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

["Jimmy Clarke" <james clarke gmail com>]

There's definitely an inconsistency here - 

Nautilus (2.16.1) "Places" side pane: 
clicking in white space does not clear selection, brings up context menu for selection

Nautilus main view: 
clicking in white space clears selection, brings up context menu for folder

Epiphany (2.16.1):
clicking on whitespace does not
clear selection, brings up the context menu for selection

Epiphany History window;
clicking on whitespace clears the selection, does not bring up context menu

There are different behaviours elsewhere - 

Totem (2.16.2) "Playlist" side pane: 
clicking on whitespace does nothing at all (does not clear selection, does not bring up context menu)

Totem main window: 
clicking on the part of the window with the playing movie/visualization in brings up a kind of context menu (though I couldn't really say what object the context menu is referring to); clicking anywhere else on the window does nothing at all

Anyone who has used these three apps could not be expected to know what would happen when they right clicked.

James

On 5/20/07, Jacob Beauregard <jake13jake comcast net> wrote:

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


_______________________________________________
Usability mailing list
Usability gnome org
http://mail.gnome.org/mailman/listinfo/usability