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

[Jacob Beauregard <jake13jake comcast net>]

To reconsider the drag+drop nature where you can't necessarily see the folder 
the file is going into, I have an idea for addressing that.

When a file is dragged over a folder, why not modify the icon into the file 
with an arrow pointing into the folder?

(more under Clarke's comments)

On Sunday 20 May 2007 05:33:16 Jimmy Clarke wrote:
> 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

It might seem inconsistent between applications at first. However, I've 
noticed a few patterns.

When you right click whitespace in an application that's primarily used for 
document viewing, it generally does not clear the selection. In fact, it 
generally just uses one context menu for right clicking anywhere on the 
document (the document is the context, and if the document has a selection it 
enables some extra functionality). I can see this behavior as useful in the 
context.

When you right click whitespace in an application that's primarily used for 
document editing, it will generally clear the selection and show you a 
different context menu (the white space has its own context). Because 
document editing can involve many different types of elements, coupling the 
selection's context menu with every other context menu would make the context 
menu quite a bit confusing.

Meanwhile, Nautilus doesn't really fit into the categories of document viewing 
or document editing, but let's just assume we're using it as a document 
editing utility since having multiple contexts is useful.

The question is, should any selection context override any sibling contexts? 
If right clicking didn't clear a selection, a user would most likely assume 
that the context menu is for the selection. Is this because displaying a 
context menu for the selection is the expected behavior? If so, I would say 
that selection context menus in an environment with multiple contexts should 
override any sibling context menus.

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