Updates made: increased the height to better match what Bootstrap offers us, darkened the border so that it has a 3:1 contrast, dark version (same colors)
Any color change that needs documenting?
Primary, brand, success, warning
Not sure on the use case of needing these colors, but we can keep for now in case we need them
Removed stripes entirely? Yes
Have we addressed what happens when the bar gets shorter than the text if we’re displaying text on top?
React’s current implementation: it will trim it
@Adam Butterworth (Deactivated) introduce exclusion here
Updates made: used bold instead of medium on the active pages, and gave visible bg (not 3:1 on the active state) - the goal here is the reduce the amount of the visual noise there is. Added a reduced version
a11y: Can you use bold alone to indicate selection?
Yes, you can do. It will be technically WCAG conformant that but not 100% ideal
Do we want to move forward with elm (better a11y) or grey (better hierarchy) for selection?
Decision: We’ll move forward with the grey version for selection unless Jeff has blocking concerns
We’ll use ellipsis when there are a lot of pages
Room for other explorations:
Adding in a caret to the selection. @Adam Butterworth (Deactivated) to explore the exact look and feel
Button sizes: Is there a need for a small variant for pagination?
Probably yes, esp. in ENT. @Adam Butterworth (Deactivated) to add in a small variant
Any other variant that we want to support other than the default and small variants?
Large may be needed in Marketing
Will there be additional styling constraints? We can chat further when we have a specific use case in the future
Updates made: All based on the tertiary button, and the last one based on the tertiary button (i.e. logistration work). Current hover maps to our primary button style. Dark version and states (hover states map to our tertiary button states) were added
Jeff: In addition to the light bg, do we also want to darken the text on hover?
If we want to update that, we’ll want to update that at the button-level. Should we update the tertiary hover button state? @Adam Butterworth (Deactivated) to explore
Folder pattern: The differentiation between the two options are not as visible (does not have a 3:1 contrast) in the logistration tabs
What’s the reason not to use the underlined tab in the logistration work?
There’s a version with an underline
Underline feels more consistent across different element types
Pills feels like radio button. Intention of the pills: showing a pane of content. It looks like a button group
a11y: If we want to accessibly show selection, do we want to consider adding a caret on selection (from the pagination convo)?
Darkness of the text and darkness of the bg alone wont' make it a11y conformant, but bolding will.
Jeff: Bolding alone is technically WCAG conformant but doesn’t feel as strong
Decision: Let’s bold the selection. @Adam Butterworth (Deactivated) to rework.
Manila folder pattern:
We’re trying to avoid the folder pattern because it adds visual noise.
It’s been around forever because the affordance is crystal clear, but it is visually too heavy.
The underline treatment gets the same job done. Looks more like a nav than a tab.
Definition of tab: It’s a nav that’s physically connected to the content that it is controlling.
It’s more important for sub tabs than top level-tabs to look like they’re connect to the content that they’re controlling.
Top level tabs: doesn’t need to be indicative it’s not bound
Sub tabs: more important to be indicative that it’s bound
Jeff: If you’ll have tabs in tabs, a secondary tab set should have a tinted treatment. But we’d only be using darkness so it’s technically not accessible. It also will need to be bolded.
This might get into a level of skeuomorphism that doesn’t work with our brand
Downward caret? Probably won’t work - it’s indicative of what is selected but it doesn’t show what it is affecting
@Adam Butterworth (Deactivated) to iterate more on tabs in tabs use cases. Can also iterate more on elevations and shadows
@Adam Butterworth (Deactivated)
Discussion future of this meeting
Remaining items:
Update to pagination and tab
Toast: already reviewed, needs minor updates (new shadows and elevation) but won’t need to be reviewed again in this group
We can end this meeting and merge with the PWG mtg. Thoughts?
Worried that the PWG mtg is too short to get done what we need to get done.
How can we leverage Slack? Is there perhaps a step that happens async to track and discern post-exploration decisions?
Problem with Slack so far has been that we don’t get a ton of interaction
Maybe we can: extend the PWG to an hour, but capping discussions at 10 min per component. And in the PWG group, we won’t do verbal questions and instead we can create a Slack thread with the questions (during or ahead of the meeting)
@Adam Butterworth (Deactivated) to think more on this and follow up with a proposal