carbon
carbon copied to clipboard
feat(TreeView): implement keyboard shortcut modal
Refs https://github.com/carbon-design-system/carbon/issues/6792
draft PR to collect design feedback
notification
- can app developers opt out of showing the notification?
- is the notification persistent or should it have a timeout?
- if the notification is dismissible, what conditions are required to bring the notification back (if any)?
- notification location/positioning options?
- finalize notification content
modal
- finalize appearance
shortcut list
- finalize appearance/formatting
Deploy Preview for carbon-components-react ready!
Name | Link |
---|---|
Latest commit | c074a1666de79ef0ff2d7eb638eb6512ad2a2e4a |
Latest deploy log | https://app.netlify.com/sites/carbon-components-react/deploys/62d092e699a2380008c9e0c6 |
Deploy Preview | https://deploy-preview-11724--carbon-components-react.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Deploy Preview for carbon-elements ready!
Name | Link |
---|---|
Latest commit | fee5ee16f6ee9cf53ae76b35a5d60c3c7adf923f |
Latest deploy log | https://app.netlify.com/sites/carbon-elements/deploys/62bdef9c545058000879ae74 |
Deploy Preview | https://deploy-preview-11724--carbon-elements.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Deploy Preview for carbon-elements ready!
Name | Link |
---|---|
Latest commit | c074a1666de79ef0ff2d7eb638eb6512ad2a2e4a |
Latest deploy log | https://app.netlify.com/sites/carbon-elements/deploys/62d092e6409cce000934bd22 |
Deploy Preview | https://deploy-preview-11724--carbon-elements.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Not sure if it would be easier to have another review with @oliviaflory and @mbgower or if we just try to hash this out here. I think michael will have a more informed answer to some of your questions. After reading these questions, I tried to do a little bit of quick visual research around this pattern and I'm coming up empty handed. Below I mentioned a few images Michael showed on our last call... it would probably help to post those and any relevant links here... this might require a bit more visual research to get Andrew over the finish line.
can app developers opt out of showing the notification?
I would defer to Michael on this, but wouldn't this kind of be like opting out of an accessibility best practice? Seems like they shouldn't be able to opt out.
is the notification persistent or should it have a timeout? if the notification is dismissible, what conditions are required to bring the notification back (if any)?
This is a good question. Gut instinct, it seems intuitive that a user would be able to close the notification (rather than having it time out) — but then what do users do if they want a notification to return... would they refresh the page? Or would we need to have some kind of persistent collapsed state of the notification (which also might be a little weird)? I'm not sure what best practice would be on this.
notification location/positioning options?
So it looks like you've just defaulted it to the upper right hand corner, again, in a normal situation, i.e. in a web app with a notification center, this would make sense... but this is a very specific situation where we're telling the user a key command to operate a specific component on the page... So it seems like proximity to that component would be important. I know Michael had some visual examples that he showed us on the previous call @mbgower I'm wondering if you can post some of those visual examples here because I'm having trouble finding anything similar.
finalize notification content
I guess I wasn't necessarily thinking that the notification had to trigger a modal... I was thinking that the notification would just tell you the specific key command that you needed to multi-select with the tree component... i.e. in this case, I'm not sure a modal would be required. What's odd in the example is that, you're giving the user a notification with a key command to trigger a modal that then displays key commands...
-
If you had enough key commands on a page to warrant a dialog, I think the notification would say something like (SUPER stupid example) "View the key commands you need to navigate this experience"
-
But if the purpose of the notification is JUST to tell people the key command they'd need to multi-select with tree, I don't think you'd need the dialog... you'd just say something like "To select multiple items in this tree component, Command click..." or whatever
Modal / shortcut list formatting
First let's see if we need a modal... If we did do a key command modal something really straight like this would be nice

I'm wondering if you can post some of those visual examples here because I'm having trouble finding anything similar.
On this page, the visual cue for arrow navigation doesn't appear until a user tries hitting an arrow key, which I wouldn't regard as a really great implementation (i also don't find the position BELOW the table instead of beside it a great feature), but this is one of the ones I just pointed out as an example of surfacing keyboard cues in the gutter.
can app developers opt out of showing the notification?
As @jeanservaas says, if you allow folks to opt out of an accessibility, we seem to be setting ourselves up for other failures. This is like the example of letting folks remove underlines from links. Suddenly you need to create a bunch of secondary designs to prevent authors from failing when they decide to ditch the establish (accessible) convention.
If the keyboard assistance is done properly, I don't see it as something that would fall into the 'distraction' category (i.e., making another problem while trying to solve this).
is the notification persistent or should it have a timeout? if the notification is dismissible, what conditions are required to bring the notification back (if any)?
the challenge with non-persistent information is that it becomes a timed event, which can itself be a challenge. What if someone with magnification takes a while to happen to see that guidance in their viewport, and by that point it's gone?
I don't think this was intended to be interactive, so making it dismissible raises the question 'how does a keyboard user (the only people who will actually SEE this) dismiss it?' It's hard to dismiss something that doesn't take focus. This could be solvable, but would take some work to figure out (ie., how do you expose the key to dismiss).
One creative option would be to remove it as soon as the user uses one of the keystrokes provided (i.e., they press an arrow key, and it disappears). That makes the assumption that the user has seen the guidance to do the action. As Jean says, it raises the question 'how do I bring it back?' If it's just a simple text string to 'Press __ for keyboard help', then I think it likely needs to persist until the keyboard help as been activated. I'm 'okay' with the idea that once the user dismisses that prompt, it never comes back until a hard-refresh of the page (ie., store as a cookie)
notification location/positioning options?
I agree with Jean that proximity is pretty key here. I like the gutter beside the focus, or the top or bottom of the tree.
Apologies, I posted before finishing my thoughts. Updates below
finalize notification content
I guess I wasn't necessarily thinking that the notification had to trigger a modal... I was thinking that the notification would just tell you the specific key command that you needed to multi-select with the tree component... i.e. in this case, I'm not sure a modal would be required. What's odd in the example is that, you're giving the user a notification with a key command to trigger a modal that then displays key commands...
- If you had enough key commands on a page to warrant a dialog, I think the notification would say something like (SUPER stupid example) "View the key commands you need to navigate this experience"
- But if the purpose of the notification is JUST to tell people the key command they'd need to multi-select with tree, I don't think you'd need the dialog... you'd just say something like "To select multiple items in this tree component, Command click..." or whatever
I agree we might want to look at just the key command instructions for multi select. If I'm remembering correctly from our previous reviews, all the other key commands are pretty standardized?
If we do need to show all key commands a simplified message would be nice!
I've also seen patterns that show the user a modal or dialogue with key commands or instructions for something that are either dismissible with "don't show me this again" option, OR have messaging within the dialogue/modal with the key command to bring up the dialogue again "to view the keyboard shortcuts again press Shift
+ /
"
keyboard position
This is quite tricky! I am concerned that tree view has so many different use cases, that no single position for the notification is going to work for all use cases, especially if the notification is persistent. Depending on the application, a persistent notification could be covering necessary content. I wonder if we should be giving the author options for positioning?
Styling
Last bit...if it is not really a notification, and more of an instruction, would styling similarly to a tool tip (without the caret) make sense?
(Not my best example, but something like this if it was top positioned)


@emyarod a few alignment things I noticed while looking at this PR:
1. Caret alignment
The caret looks like it might have some extra bottom padding, or something that makes it sit higher in the container in comparison with the folder icon. Both caret and folder icon should be vertically centered with the text label, see last image with spec



2. Text wrap
In the With icon version, we see text wrap happening under the "Business automation" folder. This causes the icon to not be aligned with the text.
However, in the original spec file I found the example below that shows the tree view should utilize ...
to maintain the height of a single item, and not wrap the text. I think this is the desired design approach. cc @mbgower I want to double check with you that there is no a11y issue with truncation of the label utilizing ellipse?

@emyarod @mbgower
There is A LOT of good discussion here but in order to unblock/ship tree view... I'm wondering if we can:
-
focus solely on exposing the hot key to operate the multi-select modal, rather than triggering a modal with a list of command keys to navigate through the tree
-
Open an issue to carry over some of this discovery on a larger persistent global pattern for a keyboard interaction dialog (maybe in the footer as Michael suggested)
If we can agree on that... we'd like to explore Andrew's idea of the help (question mark) icon next to the tree's label, that triggers a tooltip describing the hot key interaction for multi-select).
I know this is not a dynamic solution, so it has some limitations when the user scrolls — but it's a very simple one that we can proceed with and test. That way we can get tree out there...
Opinions on this?
Yeah, that works. Untimately, there a number of components that have documentation challenges for keyboard accessibility. I don't think we have to solve them all with the tree interaction
closing until we revisit multiselect tree