Row selection has no keyboard support

[les2]

One idea is to allow tab to focus on each row. While focused, an enter (or space) press would select that row. If the ctrl / cmd modifier is used when selecting, it would add/remove the row to the existing selection. If shift modifier is used, it would select a range of rows.

While a row is selected, the up and down arrows could move from one row to another (without activating them) -- this is where the shift modifier would be useful.

Row states:

• focused (user used tab to focus the row); with a mouse, this is achieve via a click
• selected (user hit enter while row was focused; with a mouse, this is achieved a click
• highlighted (user uses up or down to move between rows without focusing the row); with a mouse, this is achieve via hovering

I've built something like this before with angular and it wasn't too bad to implement (but I wasn't working with a general purpose table widget so I could use more hacks and dirty tricks that would be acceptable for a large project).

Would PRs implementing something like this be accepted? I don't really have a ton of time to focus on this right now but perhaps with a little guidance on implementation strategy me or someone else could take a stab at this.

[offirgolan]

Hi there,

I think this will be a solid addition to the table selection features. I'm not really too sure I understand the exact use case for the tab stuff. I feel like the up and down keys should handle that no?

[ScottSmix]

In my experience, the following work bests (with slight changes for Mac like Cmd-A selects all in multiple selection). I would love to have keyboard features. I think there should be a default mapping of keys to events but the default mapping should be configurable.

Navigation (changes the focused row with a visual clue often highlighting):

• Up: Move selection focus up one row. If scrolling enabled and at top row, scroll.
• Down: Move selection focus down one row. If scrolling enabled and at bottom row, scroll.
• Page-down: If scrolling enabled: If not at bottom visible row, move selection focus to bottom row. If at bottom visible row, scroll up one scroll viewport. If scrolling is not enabled: Do nothing special (let the browser do it's thing).
• Page-up: Opposite of page-down when scrolling is enabled. If scrolling is not enabled: Do nothing special (let the browser do it's thing).
• Home: Set selection focus to top most row (of full dataset).
• End: Set selection focus to bottom most row (of full dataset). This should be optional because sometimes going to the end of a dataset directly cannot be easily/quickly done.
• Ctrl-Right: Pan right if scrolling enabled (future when horizontal scroll is implemented)
• Ctrl-Left: Pan left if scrolling enabled (future when horizontal scroll is implemented)
• Tab and Shift-Tab should NOT be used inside the table. In my opinion, those should go to the next or previous component/control.

Multiple selection:

• Spacebar: Add focused row to the selected list of rows if not selected. If the row is already selected, remove it from the selected. So, space bar is a toggle. Would be nice if spacebar also navigated down one row (often you are selecting multiple rows together).
• Click: Select clicked row if the row is unselected. If the row is already selected, unselect it. Either way, unselect all other rows.
• Ctrl-Click: Same as spacebar.
• Shift-Click: Selects all rows from the row that was last selected to the current row (under click).
• Alt-A: Selects all rows.

Single selection:

• Navigation auto selects the focused row and unselects all other rows. For example, the Up key would bring into focus and select the next row up.
• Click: Toggle whether the current row (under the mouse cursor) is selected. Regardless unselect all other rows.

Notes:

• Single selection and Multiple selection are mutually exclusive.
• In multiple selection, the visual clue for the currently focused row should be different from the selection status visual clue. For example, a check mark could be used to show if the row is selected and a row highlight could be used to show the currently focused row.

[les2]

update from a recent feature.

i disabled the built in ELT row selection in favor of a checkbox column with a header column with toggle select all checkbox for the following reasons:

• the row highlight color needs to be accompanied by a visual indicator for a11y reasons. if contrast of highlight/text color is not high, then it's hard to see that rows were selected. designer picked a light bg color for selection.
• i tested on two users and they were confused by the need to cmd + click initially. when a visual indicator is added to indicate selected status of row, the user expectation of the behavior became checkbox semantics. my wife flat out told me it was stupid. lol.
• if other components are clickable in the cells, the row click is confusing.
• checkboxes natively support keyboard navigation and have none of the other problems. the only thing they natively lack is the ability to extend selections using shift modifier, but that could be implemented quite easily, i believe.

note: it was not difficult to implement this. took about an hour, including updating tests, etc.

so an alternative to the current selection method is the checkbox column (assume it has extend selection enhancement i mentioned above and the up/down navigation system proposed by Scott).

thoughts? i can throw up example of this if it would aid the discussion - let me know.

[plcarmel]

I have the same need for keyboard support. However, I thought, too, about the checkboxes idea but they are a little old school for my taste (i.e. they were needed before the AJAX era but not anymore). Beside, they are slower than an "Excel style" selection where you can quickly select a large range of rows with the mouse. I like the suggestions of @ScottSmix for the navigation and selection.

Anyway, I will implement my thing, put up a demo and you guys tell me what you think.

[ScottSmix]

Excellent! I am glad you are going to tackle this!

[les2]

I agree that the checkboxes feel a little retro.

I too look forward to seeing your demo with keyboard support.

On Tue, Nov 22, 2016, 8:08 PM Pierre-Luc Carmel Biron < notifications@github.com> wrote:

I have the same need for keyboard support. However, I thought, too, about the checkboxes idea but they are a little old school for my taste (i.e. they were needed before the AJAX era but not anymore). Beside, they are slower than an "Excel style" selection where you can quickly select a large range of rows with the mouse. I like the suggestions of @ScottSmix https://github.com/ScottSmix for the navigation and selection.

Anyway, I will implement my thing, put up a demo and you guys tell me what you think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/offirgolan/ember-light-table/issues/236#issuecomment-262412354, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBEYHwzORtn8_G_F9DCRi6CaPb-YCudks5rA5H9gaJpZM4KeYIW .

[plcarmel]

Sorry it has been a long time. I am working on it full time now. Should be ready anytime soon.

[plcarmel]

Demo: https://plcarmel.github.io/ember-light-table/#/rows/spreadsheet

I will prepare a PR soon.

[ScottSmix]

Demo looking good! It is very much appreciated. A few notes from my perspective (based on my original suggestions):

Using keyboard navigation on a multiple row selection table, shouldn't the spacebar toggle row selection?

In the demo using the navigation keys (like cursor up or down) un-selects a row. I think that should only be the behavior on single row selection. In multiple row selection, the navigation keys should not automatically un-select a selected row (only spacebar should toggle).

[plcarmel]

I was trying to replicate the behavior of a spreadsheet because it is the behavior that I wanted to have in my app. However, I also did a heavy refactoring (but 100% backward compatible) to allow complete customization of the behavior of the keyboard and mouse. This way, we will be able to provide a large number of different behaviors to the users and they will be able to provide their own if the proposed behaviors do not suit them.

So, if you don't like the way it works, don't worry, it can be just one of many possible options.