[DataTable] with selection, missing possibility to select multiple subsequent rows with Shift key

[tomkdgun]

Description

Missing possibility to select and unselect multiple subsequent rows with Shift key, which brakes UX. You can check expected behaviour using Chrome - History page, where this works as expected.

Justification

IBM application would like to use paginated DataTable with Search input, for tables with 1000+ rows, Example:

For items per page 20:

• search for rows which contain some text e.g. salary, result (salary_1, salary_2, salary_3, etc.)
• select multiple subsequent rows, e.g. from salary_3 to salary_11, by selecting salary_3, hold Shift, selecting salary_11

Steps to reproduce the issue

Try on: http://react.carbondesignsystem.com/?path=/story/datatable--with-selection

1. Select one row e.g. 1st
2. Press Shift key and hold
3. Select any row below/above selected row e.g. 4th Expected: rows from 1-4 are selected Result: only row 1 and 4 are selected

Fix should work also for unselecting, see Chrome -> History page.

What version of the Carbon Design System are you using?

"carbon-components": "10.5.0",
"carbon-components-react": "7.5.0",
"carbon-icons": "7.0.7",

### Tasks
- [ ] https://github.com/carbon-design-system/carbon/issues/13479
- [ ] https://github.com/carbon-design-system/carbon/issues/13480
- [ ] https://github.com/carbon-design-system/carbon/issues/13481

[tomkdgun]

It seems point 4) from this slack post also mention that https://ibm-analytics.slack.com/archives/C2K6RFJ1G/p1530819362000214?thread_ts=1530800070.000147

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[tomkdgun]

Hi, Any update on this issue ? It's very important from User Experience point of view.

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[tomkdgun]

@dakahn Selection with shift key, is very important from accessibility and usability point of view.

[dakahn]

Just getting to this now. My apologies.

I assume the specific situation we're talking about here is a user has narrowed their search through filtering as much as they can and still have too many table items to select manually without frustration (greater than 10? 20?).

Selecting rows on our DataTable is done by ticking a checkbox component. If you think about the expected keyboard interaction pattern there it goes something like this:

1, with keyboard the user focuses the checkbox

2. user hits enter or space to change the checkbox's state to selected

For anyone unfamiliar with the referenced functionality found in Google Chrome's History menu. When the user enters a fieldset of checkboxes and focuses the first checkbox they can hold down shift and use the down (or up) arrows to move through the table's items. Then when they get to the desired item with the shift key still held down they can hit space or enter to select or deselect all the checkboxes they've just moved through while holding shift.

In my brief testing using NVDA Chrome's History datatable has VERY poor screen reader accessibility. An interaction we'd need to fully flesh out if we were to consider this feature. The user would need to know:

1. that they can do this keyboard command in the first place (some instruction when entering the fieldset I'd assume)
2. that they'd readied X number of data table items for selection/deselection (readied state persists while shift is held down?)
3. upon selection/deselection they would need to know what items that action had been performed on

I expect (based on experience) for this feature to conflict with JAWS's arrow key movement peculiarities when dealing with form fields specifically.

[tomkdgun]

I think more common pattern used here is:

• mouse click on one checkbox e.g. second row on table/list element
• press Shift
• mouse click on other element from group e.g. 10th row on table/list element

Result: rows/elements from 2-10 are selected.

[dakahn]

We build for everyone not just the most common user and so any speculative discussions about new features or enhancements will consider mouse users, keyboard users, screen reader users (etc).

To your point -- some sort of visual messaging signalling this keyboard control should be given to sighted users as well. Unless like in Chrome we expect them to somehow stumble upon this functionality -- which may be fine for removing the last three sites you visited from your browser history, but is certainly not fine when the expectation is our user should be selecting dozens of checkboxes at a time.

[tomkdgun]

@dakahn in Chrome browser history, I can filter by e.g. by "youtube", I can click on first checkbox, scroll down e.g. to row 150, press Shift and hold, click on this 150 element, and all elements between 1-150 will be selected. My intention was to mention commonly used multiple checkboxes selection pattern, across web and other applications, which is currently missing in DataTable, and forces user to click or use keyboard 150 times.

[janhassel]

Looking at how Apple does it in the finder seems pretty intuitive imo. In this screen recording I press ⇧ Shift ▼ Arrow Down until I have the postmortems folder selected. Then I simply press ▼ Arrow Down to remove my selection and go to the next item.

[tomkdgun]

@mattrosno @asudoh @dakahn When we can expect this, to be implemented ? We are receiving multiple negative user feedback regarding exactly this issue. I think this item should have high priority. Example below.

"I might have 35 or more "variables" as rows. So, having to individually click a little box to select a variable is tedious. It would be a big improvement to be able to select a variable by clicking on the row of the variable and being able to hold down the shift key, scroll down, and select all the other 34 variables with a click on the bottom in the order.""

[curtis-browning]

I completely agree. This is a glaring omission in the current control.

[sstrubberg]

From DataTable Backlog Grooming call:

Core carbon should eventually take this on.

[AustinGitHub]

Hi @sstrubberg do you know if there is any movement on this any time soon? We have an issue open on DataStage IBM issue tracker about a feature like this where you can shift click the rows and have them multi-selected through this type of method and was wondering where this is at so I can report back. If you need further info, we can discuss over slack. Thanks! Behavior would follow like original issue mentions

Select one row e.g. 1st Press Shift key and hold Select any row below/above selected row e.g. 4th Expected: rows from 1-4 are selected Result: only row 1 and 4 are selected

Thanks!

[sstrubberg]

Hey @AustinGitHub, no news yet, but after the call we had looking over Data Table enhancements, this one definitely got people excited. Good to know that your product is in need. This helps our business case for taking it on. I'll be sure to update you accordingly!

[sstrubberg]

Ref https://github.com/carbon-design-system/carbon/pull/6942 PR that didn't get finished, got de-prioritized bc of v11

[mbgower]

I'd like to take a moment to set a baseline on this discussion.

In a select element, with the "multiple" attribute set, once an option is selected, users have the ability to hold down the Shift key, then arrow down, which selects each option in turn -- or with a mouse hold the Shift and then click on any option to select all the options between inclusively. On a Windows system users can also select non-contiguous options using the Ctrl key in combination with the Space key. It's possible to do on a Mac with the Cmd key, but it's flaky. This is native HTML behaviour.

A group of checkboxes have no such option natively. Each separately takes focus with the Tab key, and is activated separately with the spacebar.

Carbon's multi-select dropdown, which uses checkboxes, follows the same basic behaviour as a group of checkboxes. You select each one individually.

There are some implementations of multiselect dropdowns that do not use checkboxes. The video Jan provides shows one of these on a Mac OS. But there can be real challenges with these on the web (beyond both the Mac conflicts mentioned earlier for non-contiguous selection, as well as the fact there tends to be no visual difference between single and mutli-select versions). It's one of the reasons Carbon's has been so long in development.

So, that's the slightly rocky terrain when we're just talking about an interaction where the main thing we're doing is selecting items. However, looking at the Chrome history described in this issue, there are a whole lot more moving pieces:

1. the user has multiple interaction points on every row
2. the rows themselves are selectable
3. the rows may also be actionable
4. the rows, while also having embedded actions, are also treated as discrete elements that can be selected contiguously
5. most bizarrely of all, the row selection is sticky -- clicking a checkbox with no Shift or Ctrl/Cmd key selected does not reset the selection for the entire group. I'm not actually clear on how a user does that. Oh, I just saw that there is a completely separately indicator above the 'table' indicating the number of rows selected, that offers an ability to clear the selections.

Chrome is not following any pattern I'm aware of there, and it's not consistently implemented across OSes. For instance, on my Mac, Chrome's history treats each checkbox as a separate checkbox, whether I hold down my Shift key or not. It supports contiguous mouse clicks but fails with a keyboard. It works as described in Windows. That inability of chrome to do this consistently (even where it owns the user agent) hints at how difficult this is to implement properly. Keep that in mind.

---

When this interaction was described to me initially, my reaction was 'that's not checkbox behaviour; it sounds like they've implemented a grid or something', and sure enough, when I turn JAWS on in Windows, it announces the entire construct in the Google history is a grid.

There's some decent ARIA authoring guidance on grids. They can be tricky beasts to implement and maintain well, and as DA mentioned, they are difficult to make work programmatically in regards to accessiblity output, even when one gets the UX for keyboard and mouse working well. I'm not sure a JAWS user would discover interaction on that history page. (The output doesn't let them know what's been selected, etc) It's something I definitely would expect to document to meet US Section 508.

With those cautions, is it possible to get a better understanding of the use cases? I'd like to establish that grid behaviour is really warranted, especially given the effort.

For instance, thinking of that Chrome history example, the only thing you can do with the functionality is delete rows. Given the amount of filtering available, I find it a little odd that it provides all that granular selection but seems to lack a Select All (beyond the indiscriminate 'Clear browser data', not even part of the construct).

[tay1orjones]

I agree, we have to provide solid reasonable parity for a keyboard-only interaction of this behavior. If we can't (even with role="grid", then this is a non-starter.

With those cautions, is it possible to get a better understanding of the use cases? I'd like to establish that grid behaviour is really warranted, especially given the effort.

Going to mark this as blocked for now. If anyone has more use cases to share, please do so.

[sstrubberg]

REF Should our DataTable become a DataGrid?

[jjennings7]

@sstrubberg @tay1orjones @mbgower In DataStage and CPD we now have multiple issues of customer feedback regarding the lack of Shift+click functionality. Yong Li, the director of MultiCloud Data Integration in Data and AI, has asked me to follow up on this. Is the table in Carbon for IBM Products actually a grid since we're calling it "Datagrid", and if so, can we work on implementing a solution there? Is there anything DataStage or CPD team do to help get this rolling?

[sstrubberg]

@elycheea @matthewgallo

[elycheea]

@jjennings7 Super late response, but wanted to followup on the Datagrid as well. The Datagrid is still a table (role="table") despite its name that suggests perhaps it’s something else. The DataSpreadsheet is a grid currently, but I think its usage is a bit different than the Datagrid itself.

I think we’d be open to prototyping and exploring the behaviors, but I’d be cautious about simply changing the role here since there could be other implications and impact existing usage.

Also want to add this bit from @tay1orjones — this would still apply for us as well.

we have to provide solid reasonable parity for a keyboard-only interaction of this behavior

[mbgower]

I'm pulling @tombrunet in on this, in case he's encountered anything like the interaction in Chrome's history, with multi-select checkboxes using arrow key navigation AND the mutliple selection they've implemented.