Re: [Usability] rubberbanding in gtktreeview



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

It is!! :)

Exactly as you said, currently it's all about microbehaviour in
gtk/gnome, so each app has its own way of selecting objects or better -
rows.

I checked the HiG on this topic, it's horrid, no offense intended, the
HiG is a great piece of work :)
The HiG isn't guidelining here at all, just briefly describing what RB
is. 

What's missing:
1. First of all, HiG should mention that 'a bounding box is also refered
to as rubberbanding', to make it clear for other people who might use
one or another term for the same thing.
2. The reason it was called rubberbanding was
probably the behaviour of a real rubberband if you stretch and release
it(it jumps back immidiatelly, restoring it's previous shape). This is
very similar to rubberband selections, where by dragging a rectangle you
actually stretch a virtual rubberband, the rectangle disappears by
releasing a button(= releasing a stretched rubberband in real world).
The reason why it disappears is that the virtual 'shape' of the virtual
rubberband is actually just an invisible point(place where you clicked
with the mouse) hence it restores back it's previous shape. :)

"WordNet (r) 2.0"
rubber band
     n : a narrow band of elastic rubber used to hold things (such as
         papers) together syn: elastic band, elastic

Now if you replace 'things' with 'entire objects' you get object
rubberband selection.
Here again the behaviour is similar, by dragging the virtual rubberband,
entire objects which lie even partially underneath get marked for
selection(visually they just get selected), otoh if you shrink the
rubberband(moving the cursor closer to the point where you clicked),
those objects which lied underneath the selection and now don't, get
unmarked (visually they get deselected). Releasing the mousebutton
confirms the selection. 

3. The HiG doesn't mention that RB actually happens *only* by clicking
on and dragging from empty space.

What's wrong:

the HiG mentions only 3 points! And the topic is rather extensive imho
:)

1. In the first point HiG mentions that 'By default, select only objects
that are completely enclosed by the bounding box when the mouse button
is released.'
This is wrong, and nautilus doesn't do that by default(unless there's a
hidden setting somewhere), nor do other RB systems that i know of (note
that all GUIs had implemented this except gtk/gnome, win/mac and kde)
The right behaviour is, if you only *touch* an object with RB rectangle,
it gets hilighted for selection.

---
(points 2,3 - very ok.)
---

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

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.

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. 

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

The best example for this is nautilus - 1 app, 2 modes with 2 different
types of selections, only one of which allows RB.

This is why we can't underestimate this issue at all, and not view it as
microbehaviour. The HiG doesn't "enforce" *one* type of selection
throughout the entire GUI, but there clearly is just one type of
selection system that works/would work.

Marek




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