Re: [Usability] rubberbanding in gtktreeview

On Mon, 2003-11-03 at 13:08, Shaun McCance wrote:
> 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":
> > >
> > > 
> > > 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. 

The terminology is implying that the UI is more complicated than it
should be.

>  I think most adults
> have the mental capacity to comprehend the difference between a grid and
> a list. 

This isn't about mental capacity, if you have to use your mental
capacity to use a UI, then it means the design is wrong.
The desktop or iconview doesn't look like a grid at all, no grid lines.
You can place the icon anywhere, you can have a total mess on your
desktop :)) (from Joes perspective)

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

You're forgeting about something. You've got single selections and
multiple selections. Of course with simple leftclick you can add to
selection, note - you're *always* adding *single* object. 

>   Rubberbanding is a cute
> extra feature you get with a grid layout of icons.

Not at all. RB is a *vital* function for multiple selections.

> When icons are layed out in a grid, you naturally have empty space.  In
> a list view, we'd have to invent empty space,

there's plenty of empty space, see "inactive area" in my previous email.

>  which will certainly lead
> to problems.

Let's discuss those.

> When icons are layed out in a grid, having a two-dimensional selection
> mechanism is useful.  

I understand why you would consider a row as 1-dimensional, but you
never have case where there's 1 row in a list(rare cases where there's
one item in list but no exception here, lots on empty space to start a
RB, or just singleclick).
So it's always 2D.

> It's not nearly as useful for list selection.

Ok. Try to select 18 files in gtkfileselector or 18 songs out of 25 in
totems playlist. You'll end up clicking like an <insert your favourite
swearword here> ;)

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

Doesn't mean they should be clickable to select an object.

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

Could you give a brief practical example? This never happened to me.
Why would you want to click on a JPEG file, if you want to select JPEGs
just either single click on object or rubberband all JPEGs, same for
Oggs for example, if you're not sure what(kind of music) an Ogg is you
just click the name.

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

But you don't bother shift+single-clicking on 200 items you want to
select? :) 
> 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?

The question is - how much information does nautilus allow in caption?
The list offers a ton more.

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

Not only that, the whole row is selected in my copy, one column is left
blank meant as empty space. 
What about the file selector in KDE? AFAIK it's the same as with win.

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

Step backwards, great :)

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

Doesn't seem like a bad idea.

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

It's not a real problem at all to click on text for anybody, everybody
is doing that with selecting text anyway.Besides it's just like a 2px
border, hard to miss.

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

RB does for a better reason IMHO.

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

It is. I've taught RB to persons which first used it.
Not at all obvious is that App A mode 1 allows RB while mode 2 doesn't,
that App B allows *multiple selections* by *dragging* rows, while in App
C dragging row means drag'n'drop. That is a lot *more* confusing even
for experienced users.    

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

It is ...almost. :)

> There are disadvantages as well.

Agreed, let's discuss them.


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