Re: [Usability] Selection problems in List view



On 12/05/05, Christian Neumair <chris gnome-de org> wrote:
> Hi Turing,
> 
> Am Donnerstag, den 12.05.2005, 15:48 +0200 schrieb Turing Test:
> > In this mode, control-click on a selected item doesn't unselect it. So
> > it's impossible to unselect all files, and very difficult to start a
> > fresh new selection from scratch.
> 
> Sounds like a bug. You would expect that in both modes, ctrl-click
> unselects the item under the mouse if it is selected, right? If so, I
> can't reproduce it with Nautilus HEAD (which will eventually become
> Nautilus 2.12). What Nautilus version are you on?

Nautilus 2.10.0 on a Ubuntu Hoary distro. Maybe this has just been
fixed recently; it has been there since the first Spatial Nautilus in
2.6 (or sooner).
  
> > There is only one workaround for this: right-click an item and press
> > ESC to close the menu.
> > What would you think of having a "Select" action in the command menu
> > to alleviate this problem?
> 
> Sounds horrible, really. Why would we place something in the context
> menu one can be achieved easily by left-clicking?

Because in single-click mode, you can't easily select by
left-clicking! It's always a pain. At least in Icon View you can drag
a box around the item, but you can't do it in List View in Nautilus
(although you can do it in Konqueror and Windows Explorer).

By having a Select command in the context menu (only needed when in
single-click mode), I could press the right button, move mouse to
Select, and release the button.

I would go further and propose a second menu item called "Extend
selection" or  "Select list", to emulate the Shift+Click that extends
the current selection with all the items between the previous one and
the clicked one. That way I could do list selections without having to
reach the keyboard with the other hand.

 
> > Also, in List view the "folder background" is inaccessible.
> > The only possible place to access it is past the bottom of the list,
> > but when the list is longer than the window, there isn't any empty
> > space there.
> 
> Yes, this is a known issue. I'll try to work on it. It's been filed in
> bugzilla, although I can't find it at the moment.
> The proposed solution is to add an empty dummy row at the end of the
> list. Maybe we should even get a consistent solution into GTK+.

I don't think that really is a  good solution; you have to scroll the
whole list down in order to do just a "click to unselect all". What if
you have 1000 files in the list?

Konqueror and Explorer do this by handling a click on any whitespace
as if this where the background, but I don't know if it's possible to
program this in Nautilus.


> 
> > I would also ask your opinions on the validity of a "single-click
> > actions" mode. In a perfect world, mouses would have two buttons
> > (ha!): one for selecting items and the other for performing actions on
> > them. Overloading the left button with both "actions" and "selections"
> > brings to the must hated "double-click" syndrome
> 
> We don't (yet) live in a perfect world, and people tend to do what they
> did before, so they will flame us to death if we remove double-click ;).

With a semantics of "left button for selection", double-click could be
used like a Shift-click or Ctrl-click. List widgets already work that
way in many systems. It's just that the "default" action would never
be "Open", but always "extend the selection".


> 
> > (have you ever seen users double-clicking a link in the browser?).
> 
> Gosh, my mum does it all the time :D.
> 

That's because in everything but Web browsers, one click Selects and
two clicks Opens.

I prefer the more consistent *one click* for everything (even with the
selection problems), but then my significant other has problems when
using my desktop because of this. Since I have Nautilus configured to
single click, he always opens the document when trying to select it,
and launches *two* instances when trying to open it.


> Let me thank you again for your closer look at the list view.
> We're working hard to improve the user experience :).

That's why I prefer Gnome over KDE ;-)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]