Closed mcarrano closed 1 year ago
mcarrano
commented
1 year ago @pankajshivpuje @tiyiprh I have opened this new issue and assigned to both of you to work together on a more consistent approach that spans components. I will close the existing issues assigned to you. Let me know if you have any questions.
mcarrano
commented
1 year ago @pankajshivpuje @tiyiprh I was having some conversation with @mceledonia @mmenestr and @jessiehuff to try to clarify what our next steps should be regarding this issue. We reached a few conclusions that I wanted to share with you.
First to help clarify the difference between card actions, we should differentiate "clickable" cards from "selectable" cards. In a bit of research I've done, looks like this is what some other design systems do. See https://carbondesignsystem.com/components/tile/usage/#tile-variants and https://clarity.design/documentation/cards#top. Going forward let's refer to a card that has an associated link or action when you click it a "clickable" card and cards with selection (either single or multiple) as selectable cards. I will propose this naming change to the component library as part of our PatternFly 5 release. Does this make sense to you also? Hopefully it helps to claify some things.
We currently have multi-selectable cards that use checkbox select, but we should also add single (radio) select cards. This will roughly give us consistency with what Carbon supports.
You are probably noticing that tiles and cards are used interchangeably by other design systems. Perhaps to simplify things we should drop Tiles and incorporate everything into the Card component? If so, we should make sure that layout variants for Tiles are incorporated into Cards (i.e. a simple/compact card that could be used on a form, for example).
Let me know if these proposals make sense and we can proceed forward with working through some details. Hopefully this clarifies the problem a bit. Whatever we design for Cards should also be made consistent across Data Lists and Tables with clickable and selectable. Let's discuss more at our next meeting.
tiyiprh
commented
1 year ago @lboehling @mceledonia Wanted to get some feedback! From our discussion today, I doubled the width of the blue on the "click" state on the table row with a primary detail and I think that does help make it more apparent, especially on a full-width table. cc @mcarrano
tiyiprh
commented
1 year ago @mcarrano Per our conversation yesterday, see updates below. We can also review this in tomorrow's design share.
Selectable table rows: (same behavior/interaction as current) There is a hover on the checkbox via mouse and keyboard. Selection is done by clicking the checkbox and the visual affordance is the checkbox appears to show the row is selected. There is no hover on the row itself.
Expanding table rows:
There is a hover on the caret via mouse and keyboard. Expansion is done by clicking the caret. There is no hover on the row itself. Updates: Once the row expands, the visual affordance will no longer be the left blue border to indicate expansion, instead it will be the removal of the bottom border of the parent row and the growing of the row into the expanded row content. The expanded row content will also be indented to be in line with the first column content.
Clickable table rows [primary-detail view only]:
There is a hover on the row via mouse and keyboard (drop shadow and blue border). The row can be clicked to produce the action of opening the primary-detail drawer. Updates: Once the primary-detail drawer opens, the visual affordance will be updated to be a thicker left blue border (double the width of current) so it can be clearly seen in both cases where the table has content padding and where it doesn't. (same images as the above comment)
Selectable cards:
Updates: There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would select the card and there is now more visual affordance to the selected state of the card with the addition of the background color and blue border around the body of the card. This mirrors Carbon's interaction for tiles.
Single-selectable cards (new):
There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would select the card and there is now more visual affordance to the selected state of the card with the addition of the background color and blue border around the body of the card.
Clickable cards:
There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would open the primary-detail drawer. Updates: There is now more visual affordance to the "clicked" state of the card with the addition of the background color and blue border around the body of the card.
Selectable & clickable cards:
There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected/clicked state. Clicking anywhere on the card would open the primary-detail drawer. To select the card, you would need to click the checkbox. The clicking action would supersede the selecting action when both actions are available.
mcarrano
commented
1 year ago @jessiehuff please take a look at this latest proposal. Do you see any a11y issues with this?
jessiehuff
commented
1 year ago I really like the updates, particularly for the different selectable options! I think that the checkboxes and radio buttons make it clearer what the selectable interaction is. I think the only one that I have concerns with is the clickable examples. The hover styling probably makes it clear enough for sighted users, but I wonder what would tell a screen reader that it is clickable? Do we expect these cards or table rows to semantically be buttons or links? If they're buttons or links, the screen reader user will know that they're interactive/clickable. So if that's our intention, I think this will work. But if we don't want to semantically make them something like a button or link, I would just pose the question of how we'll let the users know that they can click on the item. That being said, I don't think that concern inherently holds this back (as long as we have a path forward for that question), and I really like the updates!
mcarrano
commented
1 year ago Based on discussion from meeting today with @tiyiprh @mceledonia @mcoker @jessiehuff @nicolethoen we will modify no.4 above (clickable and selectable cards) to require explicit and separate affordances for multiple actions, i.e. if the card is both clickable and selectable, selaction will be using a checkbox, but there must be another element on the card to fire the click action. This could be as simple as linking the card title or adding a "View more" button. Multiple actions could be added inside of a card in this way. The body of a card will only be used to trigger an action when there is a single, unambiguous action within the card.
tiyiprh
commented
1 year ago Updated comment with the most up-to-date info. Sketch file: https://www.sketch.com/s/24c4707b-3dc6-49c2-b3b5-2a42718b74ba
Selectable table rows: (same behavior/interaction as current) There is a hover on the checkbox via mouse and keyboard. Selection is done by clicking the checkbox and the visual affordance is the checkbox appears to show the row is selected. There is no hover on the row itself.
Expanding table rows:
There is a hover on the caret via mouse and keyboard. Expansion is done by clicking the caret. There is no hover on the row itself. Updates: Once the row expands, the visual affordance will no longer be the left blue border to indicate expansion, instead it will be the removal of the bottom border of the parent row and the growing of the row into the expanded row content. The expanded row content will also be indented to be in line with the first column content.
Clickable table rows [primary-detail view only]:
There is a hover on the row via mouse and keyboard (drop shadow and blue border). The row can be clicked to produce the action of opening the primary-detail drawer. Updates: Once the primary-detail drawer opens, the visual affordance will be updated to be a thicker left blue border (double the width of current) so it can be clearly seen in both cases where the table has content padding and where it doesn't.
Selectable cards:
Updates: There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would select the card and there is now more visual affordance to the selected state of the card with the addition of the background color and blue border around the body of the card. This mirrors Carbon's interaction for tiles.
Single-selectable cards (new):
There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would select the card and there is now more visual affordance to the selected state of the card with the addition of the background color and blue border around the body of the card.
Clickable cards:
There is a hover on the entire body of the card via mouse and keyboard. We are introducing a background color for more visual affordance on the hover, focus, and selected state. Clicking anywhere on the card would trigger the action: ex. opening the primary-detail drawer, navigating to a new page, etc. Updates: There is now more visual affordance to the "clicked" state of the card with the addition of the background color and blue border around the body of the card.
Selectable & clickable cards:
Moving away from nested interactions and requiring separate affordances when there are multiple actions within a card. The body of the card being a trigger to an action will be reserved for when there is a single action within the card, like the above examples.
There is a hover on the card title and checkbox via mouse and keyboard. Clicking on the title will trigger the action of either opening a primary-detail drawer, navigating to a new page, etc. If opening a primary-detail drawer, the card will appear with a blue border to indicate that the card has been clicked. To select the card for a global action, the user would need to click the checkbox. Below are examples of the different states in a white and gray background.
Default card state uses default card component
Hover card state:
Focus card state uses PF Focus State layer
Select card state:
Disabled card state:
Default card state uses default card component
Hover card state uses the default card component with text: 08. Link (RHT rg 16) 2.pf-global--link--Color--hover.
Select card state uses default card component
Click card state:
Disabled card state:
mcarrano
commented
1 year ago Thanks @tiyiprh ! I've added this design detail to https://github.com/patternfly/patternfly/issues/5264 and https://github.com/patternfly/patternfly/issues/5347 to begin development.
mmenestr
commented
1 year ago Created this design doc issue for it: https://github.com/patternfly/patternfly-org/issues/3409
lboehling
commented
1 year ago Created design kit issue here: https://github.com/patternfly/patternfly-design-kit/issues/608
The current PatternFly 4 visual affordances for indicating selection and expansion for cards, lists, tiles, and tables have been problematic. Some current issues include:
Current designs are not always accessible to screen readers. See https://github.com/patternfly/patternfly-design/issues/1142
The blue border feels overused. It has been used in places to indicate selection as well as expansion. It has also been problematic when a component like a table is adjacent to another element (like navigation).
It is unclear how to differentiate single and multiple selection for global actions vs examination of details (e.g. primary-detail views).
The PatternFly v5 release presents an opportunity to rethink these designs and come up with an approach across components that is more consistent, usable, and accessible. The solution should consider hover as well as active/selected states for all of these components.