Re: [Usability] rubberbanding in gtktreeview



On Wed, 2003-11-12 at 12:52, Carlos Morgado wrote:
> On 2003.11.12 08:23, Jeff Waugh wrote:
> > <quote who="Carlos Morgado">
> > 
> > > Look at the message list on your Evolution. You loose. Game over.
> > 
> > Please keep discussions on usability list polite, you've been fairly
> > venomous throughout this thread. Explaining yourself is a far better
> > strategy than flaming the other person willy-nilly.
> >
> 

Thanks Jeff.

> In my opinion it's fairly obvious the purposed idea simply doesn't work for  
> complex tree like a mailbox index. It might work for simplistic trees like  
> the example the author used but it breaks apart for a number of applications.

IMO it does work for gtktrees with arbitrary complexity.

> 
> Also, the purposed behaviour is nice for a class of applications where the  
> most common is action is multiple selections but is a nuissance for  
> applications where drag'n'drop of single items is the norm.

The RB proposal doesn't remove the drag'n'drop functionality at all.

> Also, the author doesn't explain how the mechanism would work visually for  
> compact trees with little free space. 

You simply haven't read my previous mails.

> He then goes on to  
> use keybindings he previously claimed are to complex for normal users.

Where? What i proposed is to *unify* the keybindings for the selection,
proposing ctrl for adding *both* single or multiple selections to
extisting selections *everywhere*.

> 
> The new scheme would also break expected behaviours of existing applications  
> and disrupt usage paterns for users.

No. The scheme would unify the selection behaviour throughout the entire
desktop which is one of the most important things in a well designed UI.
If a user learns RB for icons, he doesn't have to learn another type of
hidden keybinding style selection for gtktrees. I'm using gnome for
3,5yrs and i didn't know about shift until recently. Besides what it
does is simply to make a continuous block of selected rows in both
directions on the Y axis, that's up or down. It *never* deselects. It
*can't* handle discontinous blocks. It doesn't *pre-select/hilight* for
selection. And it's accessible only through a keybinding. I think a
keybinding is unacceptable for an easy to use environment. But note that
ctrl has been adopted by every desktop available for adding selections.
So it's kind of an exception and a keybinding seems not avoidable in
this case.

> 
> I finally claim the Box concept doesn't make sense for unidimentional  
> objects. 

As i stated in my previous emails, i don't think they are
one-dimensional. You've got rows which can be considered as 1D if you
don't count their height which is always the same size so i understand
how this theory came to be, but you're not selecting horizontally nor
are the rows placed one after another horizontally. They're placed
vertically, and if you have more than one column, the playground clearly
becomes two-dimensional.

As you can see, stating that a list is one-dimensional just isn't right.
As long as there's a 2D display unit, there'll always be just 2D. No
need to speculate about 1D vs. 2D IMO.

> Drawing a rectangle around a line segment isn't a familiar concept  
> anywhere.

How about every other OS(win, macosx, kde)?

> Clear enough ?

No comment.





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