[umbrella] New design system components

[alecdanz]

Simple components

Simple components are thought of as components that just reference foundational design system elements such as colors and type.

• [x] Avatar – Spec
• [ ] Breadcrumb – Spec
• [x] Button – Spec
• [x] Checkbox – Spec
• [ ] Date picker – Spec
• [ ] Flag – Spec
• [x] Input – Spec
• [x] Link – Spec
• [ ] Pagination – Spec
• [x] Radio – Spec
• [ ] Steps – Spec
• [ ] Switch – Spec
• [ ] Tabs – Spec
• [x] Tag
• [ ] Tooltip – Spec
• [ ] Top bar – Spec

Complex components

Complex components are thought of as components that will reference other components inside of them.

• [ ] Banner – Spec
• [ ] Dropdown – Spec
• [ ] Modal – Spec
• [ ] Menu – Spec
• [x] Section message – Spec
• [x] Select field – Spec

[WilliamKelley]

Hijacking this thread for a feedback cycle on the new "Foundations - typography" spec as well.

1. Specification for "Code" variants have been removed in PDS v2. Was this intentional? From the deprecated file / old mapping, it is not clear. I would advocate for keeping at least one variant: "code-md" -> code.
2. The "T32" variant is described for use as "top level headers", and "T28" for "main titles...typically h1". Can you clarify the difference between a "top level header" and a "main title / h1"? My intuition says they're identical.

[WilliamKelley]

Component design feedback:

Preface

Several feedback items come back to defining "states" for a component too liberally. "States" should correspond either to a valid pseudo-class for the component role or a some ARIA-based, stateful attribute (see ARIA guidance for "button" role).

To make this clear in component specs, I believe the "state" should details its corresponding pseudo-class or ARIA attribute that it's targeting. If one cannot be given, then it will probably not lead to a valid implementation, but there's exceptions for everything. For example: "Hovered (:hover), Focused (:focus-visible), Pressed (:active), Disabled (disabled), "Expanded" (aria-expanded).

Several component specs reference "icons" or other elements like they'll be interact-able by default, but this is not the case. A close icon needs to be an instance of an IconButton, referencing the full specification, or else it won't have the full styling and implementation as needed.

• Avatar (fine)
• Banner (fine)
• Breadcrumb (fine)
• Button
  1. States
     • Missing "Focus (:focus-visible)"
     • Clarify "Pressed" to "Pressed (:active)"
     • Rename "Active" state: "Expanded (aria-expanded or aria-pressed)
     • this styling will only be seen in buttons that are "triggers" for specific composite components.
     • aria-expanded maps to use of <button> as a controlling a group of elements, like a menu of items ("Dropdown")
     • aria-pressed maps to use of <button> as a "toggle button"
     • see more here
  2. Missing specs
     • "leadingIcon" / "trailingIcon" on sizes other than medium.
     • "leadingAvatar"
     • See Dropdown feedback item
     • different than "leadingIcon" because "Icon" /= "Avatar"
     • "AvatarButton"
     • See TopBar feedback item.
• Checkbox
  1. Separation suggestion
     • Checkbox
     • LabeledCheckbox (in implementation this is really "FormControlLabel" with "Checkbox" as the "control" because the label's implementation is identical when given "Radio" as the control)
     • CheckboxGroup
  2. Missing helpful spacing specs
     • horizontal spacing offset of child checkbox's of indeterminate checkbox (see "Vertical Orientation").
     • horizontal spacing offsets of elements (group label, checkbox, helper text) in Checkbox Group from a left baseline (see "Vertical Orientation").
  3. States
     • Rename "Unselected" / "Selected" row labels to "Unchecked" "Checked"
     • Add "error" styling for "checked" and "indeterminate" states
     • A checkbox group is different from a radio group, in that multiple selections can be required. Thus an error state is valid for a group that has one box checked, but needs at least one other checked as well.
• DatePicker
  1. Anatomy
     • pretty much all ill-spec'd, suggest replacing with
     • 0. Trigger
     • 1. Calendar navigation
          • 1a. buttons ("<, >" month navigation; "<<, >>" year navigation)
          • 1b. heading ("April 2021")
     • 2. Date grid
          • 2a. column heading ("Mon", etc.)
          • 2b. cell button ("1", etc.)
     • 3. Buttons
          • 3a. Cancel
          • 3b. Clear
          • 3c. OK
     • Calendar navigation should be an IconButton instances, not icons (icons are not interactable by themselves)!
     • the "year" options can be optional
       • it's often necessary: birth dates (for age), start date, end date, etc.
       • but sometimes it's unnecessary: birthdays (recurring every year), favorite day of the year, etc.
     • Dialog buttons like "Cancel", "Clear", and "Okay" can prove useful, but aren't strictly necessary
     • Missing its "Trigger" element, and/or clarification that the calendar view is a "dialog"
     • the calendar UI is a "Dialog" that is shown when something like a calendar icon or "choose date" button is pressed.
     • see W3 WAI-ARIA example
  2. States
     • Calendar navigation button
     • IF desired to be different than the already spec'd IconButton, then it needs a complete specification like any other button type
     • Date grid cell button
     • Missing "Focus (:focus-visible)"
     • Rename "Active" to "Selected (aria-selected)"
• Dropdown
  1. Anatomy
     • Condense "1. Container", "2. Label" and "3. Icon" into "1. Trigger". i.e., the element (component) that controls the appearance of another set of elements (e.g. Menu (component) (containing Menu Items by its own spec)).
     • Then, the burden of a complete spec for the "trigger" element falls to whatever is used.
     • The only exception to this would be specifying a trigger that's meant to have different styles than any existing button. In that case, it still needs an equivalent full specification. You probably won't want that complexity and restriction.
     • Remove "5. Menu item" as that anatomy should be specified by Menu's spec. Dropdown is only using it as the appearing object/element.
  2. Activation
     • Rename to Anchors
     • "Dropdown Button" is a superfluous anchor, it's covered by "Button" since that includes a "leadingIcon".
     • If you desire to put some type of descriptive restraint on the anchor, like you should default to using a "DownChevron" "trailingIcon", then it's best to describe that separately, not make it seem like an independent element.
     • An Avatar is being used as an anchor element, but an avatar is not an interact-able element. An "AvatarButton" would be, but that needs it's "states" spec'd (see Button feedback).
  3. Appearance; Behavior; Sizes
     • Remove, this should be specified by the "Trigger" element's spec, not independently.
• Flag
  1. Anatomy
     • Rename "1. Flag" to "1. Text" or similar. Flag is the component, not the content.
  2. Missing specs
     • Needs to illustrate placement on the page. I'm guessing this takes the purpose of an Alert Dialog under WAI-ARIA specs, but the spec doesn't make that clear.
• Input
  1. Anatomy
     • Rename "4. Optional text" to "4. Helper text (optional)". This is a much more common name for it.
     • Correct "3. Container" to point to container
     • Add "Inputted text"
  2. States
     • Rename "Standard" to "Default"
     • Rename "Active" to "Focused (:focus-visible)
     • Is "Success" really a desired state?
     • In the past its usefulness was questioned. We can implement, but I would like to clarify.
     • There's also no success state defined for any other form input.
     • Missing "Required (:required) (usually adds an asterisk to the FormLabel)
     • All states should include "Inputted text" in them so there's a spec of what happens to it given that state.
     • All states should include "Helper text" so there's a spec of what happens to it in that state
• Link
  1. "Component"
     • I don't get why this block is called component, or what it's for
  2. States
     • Missing spec specs for "inline", only does "standalone"
• Modal
  1. Calling this spec "Modal" is largely a misnomer (see explanation from our underlying UI library) (see WAI-ARIA attribute explanation). Most of this spec details a "Dialog".
     • For example, a "Select Menu" or "Date picker calendar" is also "modal" since it will block interactivity with the rest of the page.
     • The only applicability of this spec to general "modal" styling is the "blueing" of the background behind the modal, that is blocked from interactivity. But the rest of the spec should be separated.
• Menu
  1. Separation suggestion
     • Extract "MenuItem" to its own spec. It's crowding and hurts clarity of what a "Menu" is responsible for.
  2. States
     • Missing "Focused (:focus-visible)".
     • Clarify "Active" to "Selected (aria-selected)".
  3. "Menu Item" (separated feedback)
     • There's an idea of a "leadingElement", and an icon/checkbox seem to take on their default sizing, but the Avatar example does not. Either this needs to be a valid "size" of "Avatar" so it's fully defined for "icon" and "initials" variants, or it needs to be separated as "MenuItemAvatar" to be an independent full specification.
     • "Active" should be "Selected (aria-selected)"
• Pagination
  1. States
     • Rename "Active" to "Selected (aria-selected)"
  2. Variations
     • Suggest different names: "Previous", "Page", "Ellipsis" (not "More" because that implies click to see more, but that's not what it's used for), "Next"
     • Suggest spec'ing "First" and "Last" (usually double chevrons)
• Radio
  1. States
     • Rename "Unselected" / "Selected" row labels to "Unchecked" "Checked"
  2. Appearance
     • Add spacing specs for distance between group label and group helper text.
• Section message
  1. Anatomy
     • Change "Close" to "Close button" and it should be some button instance, not just an icon.
  2. Variations
     • Should showcase an instance without "Title" since it's described as optional in the anatomy.
• Select
  1. Anatomy
     • Remove "Placeholder". Why is this spec'd for Select but not Input? Also, doesn't seem to carry through to actual designs below, so I assume it's a mistake.
  2. Generally, feedback to Input also applies to Select
• Steps
  1. Anatomy
     • Rename "Stem" to "Connector"
  2. States
     • Missing several states, this should be a table with columns "Default", "Hover", "Focus", "Disabled" and rows: "Default", "Selected" (or "Expanded"), "Completed"
• Switch (fine)
• Tabs
  1. States
     • Missing several states, should be a table with columns "Default", "Hover", "Focus", "Disabled" and rows "Default", "Selected"
• Tag
  1. Anatomy
     • Change "Icon" to "Remove icon button" -- again, icons are not interact-able, buttons are.
  2. Behavior
     • Add "Focus" behavior (see outstanding issue), where the whole tag is focused.
     • Necessary since the tag is inter-actable. Pressing "Backspace" while focused will mimic clicking the remove button.
• Tooltip (fine)
• Top bar
  1. Anatomy / Avatar menu
     • Same feedback as in dropdown. An avatar is not interact-able, but an AvatarButton would be, thus that needs to be referencing a full component spec for that.
  2. The full spec for the "buttons" / "nav links" / "nav menu items" seems to have disappeared, that needs to be returned.

[alecdanz]

Thanks for the thorough work William! Meeting with Spence today and we're going to start addressing these inside figma. I'll drop a comment in here if there is anything that needs more discussion.

I added a type for code as suggested to the foundations file - just one size as suggested 👍

For the T28 and T32 example T28 is a more traditional page header and T32 would be used more for the empty state and as an optional emphasis header. It's a little hard to describe but that's the best that I can do.

[WilliamKelley]

Great, thanks y'all 👍🏼

[WilliamKelley]

I'll be working on Typography today.

@shadoath is working on the Button (+ IconButton ?).

[WilliamKelley]

• [x] Typography #366

Working on Link next.

[WilliamKelley]

• [x] Link ~in review~ #371
• [x] SvgIcon ~in review~ #374

Beginning work on Input (+ InputLabel, InputBase, InputAdornment)

[WilliamKelley]

• [x] InputAdornment ~in review~, #385
• [x] InputLabel ~in review~, #386
• [x] FormHelperText ~in review~, #387
• [x] Input ~in review~, #388
• [x] Select ~in review~, #389
• [x] TextField ~in review~, #390
• [x] [Skylar] Button #375
• [x] [Scott] SectionMessage ~in review,~ #383

[WilliamKelley]

@alecdanz @ssbittle For components like the Tag that have a custom SVG icon in their design spec, we should isolate that element in the spec and treat it as a component. (doesn't have to have its own page, I mean a Figma component -- something we can iterate on in isolation and have all its copies update in sync)

I noticed when exporting the Tag's cross that it was weirdly large in file size. I'm amateur at best at Figma SVG manipulation, so I couldn't figure how to fix it, so instead I copied the cross from Anron Icons, and adjusted it to match the Tag's cross exactly. It amounts to a 76% size reduction. I can't seem to upload the file here, but you can copy-paste this into a .svg file in text pad and upload it to Figma.

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" fill="none" viewBox="0 0 24 24">
  <path fill="#253858" d="M7.293 7.293a1 1 0 0 1 1.414 0L12 10.586l3.293-3.293a1 1 0 1 1 1.414 1.414L13.414 12l3.293 3.293a1 1 0 0 1-1.414 1.414L12 13.414l-3.293 3.293a1 1 0 0 1-1.414-1.414L10.586 12 7.293 8.707a1 1 0 0 1 0-1.414Z"/>
</svg>

[alecdanz]

Hmm. Getting an error when trying to upload that as well.

Want to hop on a call to review?

[WilliamKelley]

@alecdanz Now that I think of it that's actually the optimized export as well. Maybe it's best if i just get edit access to the file to copy-paste the figma asset.

[alecdanz]

Sure. What file specifically? Components?

[WilliamKelley]

Yes components