Re: [Usability] rubberbanding in gtktreeview



On Mon, 2003-11-03 at 07:00, Marek Peteraj wrote:
> Hi Calum & all,
> 
> On Mon, 2003-11-03 at 12:04, Calum Benson wrote:
> > On Mon, 2003-11-03 at 11:24, Marek Peteraj wrote:
> > 
> > > Moreover RB is the most efficient way for doing multiple selections.
> > > Any chance it would be included in HiG?
> > 
> > There's already a section in the HIG about rubber-banding (aka "Bounding
> > Box Selection":
> > http://developer.gnome.org/projects/gup/hig/1.0/userinput.html#selection
> > 
> > There's no doubt it could be improved, but in general I'm not sure it's
> > really the HIG's place to talk about the micro-behaviour of specific gtk
> > widgets... 

[snip]

> 2. In the beginning, the HiG states that 'For a container whose objects
> may be arranged in two dimensions (e.g. Nautilus "View as Icons"), allow
> multiple selection by dragging a bounding box around one or more
> objects. '
> 
> User joe - "objects arranged in two dimensions huh?" you get the idea :)

User Joe might be confused by that terminology.  Maybe.  But we don't
use that terminology in the interface anywhere.  I think most adults
have the mental capacity to comprehend the difference between a grid and
a list. 

> The strength of a UI is in its simplicity and efficiency, thus focus
> should be on unifying operations that share the same or similar
> principle(s). One such operation, and a very important one is selection.
> (overall i think that the HiG is following that goal, but it missed that
> goal completely in this topic)
> 
> So Joe would only learn RB once, and he should be allowed to use it
> everywhere where he needs to select objects. Simple rule - learn once,
> use everywhere. As you can see, microbehaviour vanishes rapidly, which
> makes things much more simple for everyone.

The way I see it, clicking is the One True Selection Technique.  It
works everywhere, for selecting everything.  Rubberbanding is a cute
extra feature you get with a grid layout of icons.

When icons are layed out in a grid, you naturally have empty space.  In
a list view, we'd have to invent empty space, which will certainly lead
to problems.

When icons are layed out in a grid, having a two-dimensional selection
mechanism is useful.  It's not nearly as useful for list selection.

> Another problem arises. It becomes clear that rows won't fit this model.
> Currently it's possible to drag whole rows, which isn't a good thing
> either.
> 
> Consider the following row: foo.jpg | JPEG image | sat 21 june 2002
> Curently it's possible to start dragging on (say) 'sat 21...' because
> we're allowed to drag an entire row. But this is a misconception really
> because it's not the date we want to drag, it's not the object, the
> object is foo.jpg. 

But it's nonetheless useful to be able to select on the other columns. 
They're there because they're useful things to see.  And generally,
anything that's useful to see is useful to click on.  If I'm scanning
the file types primarily, it's nice to be able to click that column,
because that's what I am immediately looking at.

Of course, I can shift my attention and click the filename, but I've
always found that generally annoying.  In fact, every time I've had to
use a file manager that does rubberbanding in a list view, I've been
annoyed because my clicks don't work.

Since the big argument for rubberbanding in list view is consistency,
how about the icon captions in an icon view?  Nautilus will gladly put
the file type and size and whatever else in the caption under the icon. 
Should I not be able to select on those?

> If you selected each such object as text(selected text) you'd see that
> they very much resemble objects. The rest should be inactive area
> reserved for RB. It's the way it's done in every GUI and it's a clever
> system because, from the general gtk/gnome(each app) point of view, we
> get *one* type of selection which we apply on *objects*.

It's not the way it's done in every other GUI.  It's the way it's done
in Windows, IIRC.  For reference:

Windows (IIRC): Only the filename and icon are selectable.  Everything
else is empty space.  Alternating-color rules are not used.

Konqueror: The column containing the filename and icon is selectable,
even if you click on "white space" in this column.  Alternating-color
rules are not used.

OS X Panther: No rubberbanding in list view.  The entire row can be
selected.  Alternating-color rules are not used.

OS X pre-Panther (IIRC): Filename, icon, date, and any other visual
element of the row can be selected, but white space is empty space. 
Alternating-color rules are not used.

Nautilus: No rubberbanding in list view.  The entire row can be
selected.  Alternating-color rules are used.


In the Windows and pre-Panther cases (which are both IIRC, as I don't
have a machine around to verify at the moment), you effectively reduce
the clickable area for a file, because I have to get the click on the
text, rather than just in the right vertical range.  This means I have
to be more careful with my clicks.

Nautilus is the only one listed that uses alternating-color rules.  The
rules give a very strong visual row-delineation, and I think it would be
a mistake to consider anything to be white space while using them.  But
I always find the lack of them annoying.  They do exist for a reason.

Once you introduce empty space in a list view, the user has to figure
out what is and is not empty space.  This is not at all obvious.

There are certainly advantages to having rubberbanding in list view. 
But it's not an open-and-shut case.  There are disadvantages as well.

--
Shaun





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