Goal
In our current exploration, we are aiming to embed responsiveness into Codex components by making them react to breakpoints. The internal spacing of said components will increase to make them touch-friendly in smaller viewports. This will mean that, most frequently, components will take two shapes/dimensions: a desktop-oriented one, and a touch-friendly (responsive) one.
There's a set of elements that should display a discrete, consistent height when becoming touch-friendly. These are the same ones that now share the base height of 32px on desktop: buttons and form elements such as text input, select, combobox. These are components that are often combined or used in alignment compositions, and that thus should keep homogenous proportions.
In the name of consistency, all other system elements will be impacted by this decision too. For example, we should apply the same or a similar vertical spacing to them.
Current exploration
We've been evaluating 3 different responsive sizes:
| Option | Description | Example |
|---|---|---|
| Option 1: System scale-based responsiveness and sizing | Values from the system’s spacing scale are used to create size increments for the responsive version of components, and size variants for sized components. This results on buttons and fields being 32px on desktop and 40px on mobile. ⚠ We would have to apply a touch area around certain elements (e.g. icon-only button) in order to keep them accessible |  |
| Option 2: Accessible by default sizing | Applying accessibility recommendations to obtain a touch-friendly version of all elements (even if it involves applying spacing values that are not part of the scale). This results on buttons and fields being 32px on desktop and 44px on mobile. |  |
| Option 3: Accessible by default + scale-based sizing | Applying size scale values to create touch-friendly version of components that also makes them accessible. This results on buttons and fields being 32px on desktop and 48px on mobile. |  |
Considerations
There are several criteria to factor in when trying to define the responsive properties of Codex components:
- Ideally, responsive sizing should be applied to all components that need scaling holistically, and the dimensions should be based on our system spacing and sizing scale.
- Accessibility: We need to observe accessibility recommendations and standards that will make components touch-friendly: keeping in mind the minimum recommended target size (44x44px), but understanding that we might need to cover for interfaces with higher density
- Consistency with current state: Ideally (but not necessarily), the responsive version of Codex components should be visually “compatible” with the current mobile version of components in order to minimize temporary inconsistencies.
- Information density: We should go for a size that minimizes impact for the community by limiting the spacing and sizing of elements in order to maintain our visual identity as much as possible.
Acceptance criteria
- We explore/represent versions of the responsive properties of Codex components and gather feedback on these
- We define the design of the responsive version of Codex components