Maturity
FYQ2 target
Repository
Overview
When it comes to establishing a hierarchy, size is critical. More prominent elements naturally draw more attention and are seen as more important. We use predefined size sets to ensure balance and coherence in each context and align with the hierarchy and information density.
Related content
Scale
Our predefined base eight sizing scale helps makers layout elements consistently, allowing flexibility.
When creating any component or designing a screen, make sure you use one of the values below:
Usage
Information density and size
High-density components can improve the experience when people are presented with and interact with large amounts of data.
Dense density (default)
Increasing the density of lists, tables, or toolbars can make viewing and interacting with screen content easier. For this, we have the Dense density, which uses the size-md size.
Loose density
However, when a person performs or finishes a specific main task, like filling out a simple form, editing large amounts of data, or confirming an action, we'll use the Loose density, which uses the size-lg size.
Minimum target sizes
Enhancing the clickable area size allows people to complete actions faster and prevents triggering accidental interactions for people with motor disabilities. Our interactive controls follow the WCAG 2.1 success criterion for target sizes, establishing a 48x48px target area for interactive elements, regardless of their contents.
But to prevent accidents and be forgiving with people, we must also ensure that our controls are not too close to each other by adequately spacing controls.
Related content
Maximum and minimum sizes
Defining maximum and minimum sizes is an excellent way to create adaptive components that remain understandable and accessible.
Sometimes—as in our Buttons—we might need a component with a minimum width regardless of its content, ensuring the clickable area meets our usability and accessibility requirements.
And sometimes, we need components to do the opposite: stop growing even if the content is very dense or the viewport/container size increases, as in our Tooltips.
Fixed sizes
Defining fixed sizes for containers can cause issues with overflowing content and a broken/non-accessible user interface, so it's generally not recommended. However, in certain cases, specific element measures may be necessary.
Navigation
Our TopNav and MainNav use fixed height and width to keep the Application Frame consistent throughout the app experience.
Quality checklist
This element passes the following requirements described in our Component lifecycle.
Maturity
α · Design tokens
It uses Ariane design tokens.
α · Naming agreement
Its name is agreed upon and shared between design and development.
α · Responsive L1
Is responsive to different viewport sizes.
β · Responsive L2
The responsive behavior has been reviewed and validated by the team.
β · Docs L1
It has essential documentation with at least primary usage.
β · Use cases
All the uses are audited and refined.
Acknowledgements
- Applying density — Material Design