Selectable refactor: selection modes

[Richard D. Worth]

Paul and I had a good chat and cleared up a couple issues that have been bothering me a bit with the current spec and implementation. Currently there's a closest option, which is a boolean. First, I think if there's an option, really any variable, that's a boolean, it should be *obvious* from it's name alone, what it means when that boolean holds true vs. false. Unfortunately, this fails both tests. So, I think the name could use some help. Anyway, currently when closest is false, the default, you select in DOM order when using the arrow keys. When closest is true, you select in position order when using the arrow keys. The thing that's weird is when closest is true and you press for example (while holding shift), down+down+right+right, it adds to the selection each item it passes the focus over, creating an L. I call this a snake. You can arrow all around the place (while holding shift) and draw a really long snake. It will even erase portions of itself that it crosses. Fun game. But it's inconsistent. Selection with keyboard arrows should be the same as mouse selection. So if you shift+down+down+right+right, it should draw a lasso from the item you started on, to the one you ended on, selecting all 9 items, not just the 5 the arrow keys navigated the focus over. The other thing that's really odd about the current implementation is that when closest is set to false, the down and up arrow keys act the same as the left and right arrow keys, going next and prev (in dom order), instead of to the items below and above (in layout order).

So, there's two separate things here. I propose:

1. arrow keys should always move the focus up, down, left, right. That is, it should always be location/position based, never dom based.

2. selection mode can either be dom mode or position/lasso/rectangle mode. Whether you're using the mouse or the keyboard, should be the same

So the first point can be handled by taking the current arrow nav logic from closest:true and applying it always.

The second point can be handled by removing the 'closest' option, and adding a 'mode' option, with two possible values: 'dom' | 'box'. Dom mode would select all items between the first selected item and the currently focused item, in dom order. Box mode would draw a rectangle between the first selected item and the currently focused item, selecting all items the box touches, based on tolerance.

This will handle the most common selection scenarios. For example:

text selection, windows explorer = mode: 'dom'

grid, spreadsheet, graphics program = mode: 'box'

As for the snake, if people think it's valuable, it could be mode:'pen', or maybe mode:'cursor'. And it should support keyboard as well as mouse. This would allow you to "draw" a selection of any shape. I don't see this as being nearly as fundamental as 'dom' and 'box' modes, so if it doesn't happen until a later version, I think that's fine.

Thoughts?

- Richard

[Todd Parker]

+ 1. I like the idea of these very clear modes because different apps
handle selections different ways. I think all 3 are valid, and we'll
probably add mor later.

Todd Parker
to...@filamentgroup.com

On Sep 3, 2009, at 8:41 AM, "Richard D. Worth" <rdw...@gmail.com>
wrote:

[Scott González]

+1

[Paul Bakaus]

+1 (can someone get this back on the spec? Let's try to implement it Thursday/Friday).

2009/9/6 Scott González <scott.g...@gmail.com>

+1

--
Paul Bakaus
UI Architect @ smart.fm
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus