Row selection behavior in grid when going up/down with arrow keys and checkbox select

[martintaal]

Hi,
I see the following behavior when I have a listgrid with selectionAppearance: checkbox:
1) I select one row with the mouse
2) then I walk up and down using the arrow keys
3) each row I visit gets selected, without the previous row being deselected
4) when I get to the top or end of the list then pressing up resp. down deselects the row and then selects it again, press up a few times when at the top, then it can be seen.

To me both 3 and 4 are incorrect. However, issue 3 does not occur in my code, issue 4 is the real problem for me and has been reported as a bug on my side.

You can reproduce in the columnSize example in the smart client explorer, after adding this line in the js code:

selectionAppearance: 'checkbox',

I tested it in 8.3 (chrome) a build from a week ago, but afaik it also happens in other cases.

gr. Martin

[Isomorphic]

I think the issue here is that the selectionType for the ListGrid is inadvertently being changed from "multiple" to "simple" by the fact that the selectionAppearance property has been set to "checkbox". The "simple" selectionType behaves as you describe in #3 and #4 but it's by design.

So, you're final code will have the properties:

selectionAppearance: 'checkbox',
selectionType: 'multiple',

This will give you the behavior that I sense you want
- a single row is selected at a time by keyboard navigation up and down
- no bounce occurs when you reach the top or bottom

Details about how these two properties affect each other are provided in the SC reference documentation under ListGrid.selectionType.

[martintaal]

The problem is that in our instance we need the
selectionType: 'simple'

We don't care about point #3, but point #4 is important for us.
Just to understand, what is the logic behind point #4 to consider it as a desired design? It seems very strange, since the bounce doesn't happen in any other case (without the "selectionAppearance: 'checkbox'" and/or without the "selectionType: 'multiple'")

gr. Martin

[Isomorphic]

It sounds like the best option in your case is to use the arrowKeyAction property of ListGrid to set the default action to "focus". Now, when you navigate up and down by arrow key, the current row is highlighted, but there is no selection change unless you tap space. This also avoids the "bounce".

So:

selectionAppearance: 'checkbox',
arrowKeyAction: 'focus',

We're going to make a change in the latest code stream to have arrowKeyAction default to null (rather than "select") and then be configured automatically in such a case to "focus" if selectionAppearance has been set to "checkbox"...otherwise it will be configured to "select".

-

[The following provides some answers to your questions about keyboard navigation in "simple" mode with arrowKeyAction set to "select" (our current default).]

With the simple selection mode, as you move to a new record via keyboard navigation, the new record is highlighted as you arrive on it, without changing the state of the old record. So without a "bounce," if you navigated to the top (or bottom), and then navigated away, you'd leave the record closest to the top (or bottom) highlighted--unless you tapped space on it before navigating away. So the behavior provides a way to maintain a contiguous selection region in that situation.

The reason for #3 is basically that keyboard navigation is designed to emulate mouse clicking (without any modifier keys) on the records. In "multiple" mode, mouse clicking without any modifier keys deselects everything else, selecting one new record; in "simple" mode, doing the same flips the state of the record being clicked on, not changing the state of anything else selected (or not selected).

[martintaal]

Originally Posted by Isomorphic

With the simple selection mode, as you move to a new record via keyboard navigation, the new record is highlighted as you arrive on it, without changing the state of the old record. So without a "bounce," if you navigated to the top (or bottom), and then navigated away, you'd leave the record closest to the top (or bottom) highlighted--unless you tapped space on it before navigating away. So the behavior provides a way to maintain a contiguous selection region in that situation.

I still don't understand it.
As it is right now (forgetting about your mentioned incoming change),
* I am in record 4, with it selected, I press up-cursor-key: now 4 and 3 are selected so:
* Now I am in record 3, I press up-cursor-key: now 4, 3 and 2 are selected so:
* Now I am in record 2, I press up-cursor-key: now, 4, 3, 2 and 1 are selected so:
* Now I am in record 1:
- if I want to unselect it again, I just should press down-cursor-key to go back to record 2 (and the state before).
- if I press up-cursor-key I lose first record selection and I am in no-man's-land (this is what I say it's wrong, any new up-cursor-key press should not have any effect at all). Even more, if I press down-cursor-key again, I have a strange/unpredictable selection state, since when I go back to record 4, I see 1, 2 and 3 deactivated, but once I press down-cursor-key again, I see 4 and 5 selected... If I continue pressing down several times, and then up again, the result is even more unpredictable

I don't understand. Pressing up/down cursor-key there is no way to leave the grid, the only way to do it is press tab-key (nothing to see with the previous up/down cursor-key sequence), so I don't understand your assessment: "So without a "bounce," if you navigated to the top (or bottom), and then navigated away, you'd leave the record closest to the top (or bottom) highlighted"

Could you provide an scenario/example with a desired selection state that only is possible with the bounce? This maybe makes me understand it better.

gr. Martin

[Isomorphic]

Let me ask first; will focus navigation work for you? It's available right now if you use the code snippet provided in the previous post, and should not have any complicated behavior.

Originally Posted by martintaal

I still don't understand it.
As it is right now (forgetting about your mentioned incoming change),
* I am in record 4, with it selected, I press up-cursor-key: now 4 and 3 are selected so:
* Now I am in record 3, I press up-cursor-key: now 4, 3 and 2 are selected so:
* Now I am in record 2, I press up-cursor-key: now, 4, 3, 2 and 1 are selected so:

OK, correct, you have 1-4 selected and your position (from the point of view of further navigation) is at the top row.

Originally Posted by martintaal

* Now I am in record 1:
- if I want to unselect it again, I just should press down-cursor-key to go back to record 2 (and the state before).

The down arrow key doesn't unroll the state to a previous value; instead it simply:
- increments the current row position
- toggles the selection state of the new current row (for "simple" mode)

So if you press down arrow as soon as you get to the top row, the top row is left selected, you're sitting at the 2nd row, and you've just unselected it.

Originally Posted by martintaal

- if I press up-cursor-key I lose first record selection and I am in no-man's-land (this is what I say it's wrong, any new up-cursor-key press should not have any effect at all).

At the top row, the effect of hitting up arrow again is really the same as tapping space. It doesn't move your row position, but toggles the record selection state.

Originally Posted by martintaal

Even more, if I press down-cursor-key again, I have a strange/unpredictable selection state, since when I go back to record 4, I see 1, 2 and 3 deactivated, but once I press down-cursor-key again, I see 4 and 5 selected... If I continue pressing down several times, and then up again, the result is even more unpredictable

Remember, the "select" action of key navigation in "simple" mode simply toggles the current selection state of each record after you arrive at that position. So navigating up and down can indeed create patterns, but they're completely deterministic.

Originally Posted by martintaal

I don't understand. Pressing up/down cursor-key there is no way to leave the grid, the only way to do it is press tab-key (nothing to see with the previous up/down cursor-key sequence), so I don't understand your assessment: "So without a "bounce," if you navigated to the top (or bottom), and then navigated away, you'd leave the record closest to the top (or bottom) highlighted"

By "navigated away," I meant moving back within the grid in the opposite direction. So if you start at row 4 with it selected, you can hit up arrow 3 times and rows 1-4 are selected. Hit it once more; row 1's selection state is toggled. Now you can hit down arrow 3 times and there should be no selected records left.

Originally Posted by martintaal

Could you provide an scenario/example with a desired selection state that only is possible with the bounce? This maybe makes me understand it better.

gr. Martin

The example in the previous paragraph is such a case. Let's say you reach the top row and records 1-4 are selected. Now without the "bounce," you have to tap space to unselect the first record before you hit down arrow 3 times to unselect records 2-4. (Otherwise, record 1 will remain selected.)

[Isomorphic]

Just to be clear - we agree that the default behavior you're seeing isn't intuitive for checkbox selection.

If you set arrowKeyAction to "focus", the behavior will be as follows:
- pressing the Up or Down arrow key will show a highlight around the row in the appropriate direction but will not select or deselect anything. You can then use the spacebar to toggle selection.

This is a much more intuitive user experience coupled with checkbox based selection, so we're changing to this default in future builds (as described above).

Please let us know if this behavior won't work for you for any reason.

(We will still be supporting the existing behavior as well but it will no longer be the default for this mode.)

[martintaal]

Thanks for the clarification.

The point is that our behavior is slightly different from the Smartclient standards.

Our behavior is:
1) The checkbox is in the left (selectionAppearance: 'checkbox')
2) If you click in any row in any place (but not in the checkbox column) ONLY the clicked row is selected, no matter the previous state of the other rows (if someone was selected, now is unselected)
3) If you move up/down cursor keys, ONLY the previous/next row is selected, no matter the previous state of the other rows (if someone was selected, now is unselected)
4) If you click in any row checkbox, now this row is selected too

So as you can see, it doesn't fit with any of your cases. We are doing it as:
selectionAppearance: 'checkbox'
selectionType: 'simple'
arrowKeyAction: 'select'

And then some click logic to allow #2, and some key logic to allow #3
So, with this in place, the bounce is a strange effect for us, and we thought that also for the standard case, but it seems that we are wrong.
Since the solution it seems is not easy for both of us, I think the best thing we can do is override also key up/down presses when the first/last row is selected.

So, I think we can close the topic. Anyway, thank you very much for the arrowKeyAction benefits, I think we could use it in other special grids we have.

gr. Martin

[testsdk]

Looks like your ideal mode is a hybrid that behaves like "multiple" mode for clicks on the grid other than in the checkboxes and for keyboard navigation, and like "simple" mode for clicks on the checkboxes.

One simple solution, which can be tested using the to the "Grids >> Interaction >> Checkbox Select" Showcase Example (by adding the snippet at the bottom of the ListGrid's properties) is the code snippet:

selectionType: "multiple",
arrowKeyAction: "select",

rowMouseDown : function (record, rowNum, colNum) { if (colNum == 0) this.body.selectionType = "simple"; },
rowMouseUp:    function (record, rowNum, colNum) { if (colNum == 0) this.body.selectionType = "multiple"; },


recordClick: function (viewer, record, recordNum, field, fieldNum) { 
    if (fieldNum > 0) this.selectSingleRecord(record); 
    return true;
}

The switching of the property in the mouseDown/mouseUp tricks clicks on checkboxes into performing a "simple" select, allowing for multiple click selections.

The recordClick() function adds the selection behavior you want for clicking on a row, but not over the checkbox, where you just need the default ("multiple") selection. Keyboard navigation works as you need because the default mode is "multiple".

Obviously, this is just prototype code as it assumes the checkbox is fixed at position 0.