Design a responsive type scale/ramp
Problem
In https://gitlab.com/gitlab-org/gitlab-ce/issues/24310 we took the first stab at defining our type scale/ramp and vertical rhythm. Later, in #130 (closed), we updated some details and added a new compact markdown style.
But right now our type scale is only intended for viewing in mid-sized desktops. We should create variations for not only smaller viewport sizes, but also larger (to be address in a separate issue).
Solution
Keep the 16px base size and only resize the 3 largest font sizes across our breakpoints. Other font sizes stay the same (h4, h5, h6), including paragraphs. The logic behind the scaling comes from musical interval ratios (e.g. minor third, major third, perfect fourth, …):
-
>0px
- Minor third 1.2 -
>768px
- Major third 1.25 -
>992px
- Perfect fourth 1.333 -
>1200px
- Augmented fourth 1.414
View prototype and design specs.
Rationale
As with our current type scale, the 4th largest font size uses the base size (16px). Because we have 3 type scale subsets (Documentation Markdown, Compact Markdown, and UI), it means this 4th font size maps to: Documentation MD h4 / UI h3 / Compact MD h2
. The reason for keeping it at 16px
is because of the common use of headings in each of those subsets: in documentation, it's unusual to have more than 3–4 headings; in descriptions/comments (compact markdown), it's unusual to have more than 1–2 headings; in the UI, it's unusual to have more than 2–3 headings. So trying hard to have more font size variations at and below the 4th largest is not going to have much impact on the final UX.
The logic behind the scaling comes from musical interval ratios (e.g. minor third, major third, perfect fourth, …) — interestingly, most of our current type sizes already match a perfect fourth scale, which wasn't deliberate. Using the Type Scale tool, I assigned a different ratio to each of Bootstrap's breakpoints, all while testing on different devices that matched each breakpoint. This is the result:
-
>0px
- Minor third 1.2 -
>768px
- Major third 1.25 -
>992px
- Perfect fourth 1.333 -
>1200px
- Augmented fourth 1.414
The ratio increases as the breakpoint sizes increase, which results in a more and more contrasting type scale (i.e. larger breakpoints have larger font sizes).
As an alternative to the ratio's approach, I also explored resizing fonts based on the viewport size (an example implementation of this is Bootstrap's RFS) but decided that it should be a separate exploration, a possible improvement of this work.
Per @matejlatin's suggestion, our 14px
paragraphs now use a 20px
line-height (instead of 24px
) making them more legible.
Despite of having confirmed that we can use Boostrap's SM
breakpoint (576px
), on my explorations it wasn't an advantage for increasing the heading sizes.
To be solved in separate issues
- #585 (moved): Larger breakpoint(s) for bigger screen sizes that allow us to increase the base font size (documentation and compact markdown only)
- #586 (closed): Test one (or two) sizes smaller than 12px for smaller typography to be used in the smallest breakpoints
Example
Related patterns
Links / references
- Boostrap 4 Breakpoints
- Apple iOS
- Material Design
- Microsoft UWP: They use a scaling algorithm to ensure the same font size looks legible no matter the screen size.
- BBC GEL
- Buzzfeed Solid
- FutureLearn
- Shopify Polaris
Pattern checklist
Make sure these are completed before closing the issue, with a link to the relevant commit, if applicable.
-
Read our contribution guidelines, especially the For GitLabbers section. -
Create a Sketch file in your progress folder just for this pattern and make sure that: -
You have not created a duplicate of an existing pattern, symbol, layer style, or text style. -
You have used the proper method for creating the pattern depending on the complexity. Atoms and molecules are symbols, organisms are groups. -
Typography uses text styles. When applicable, colors use shared styles.
-
-
Ask a UXer to review your Sketch file, linking them to your latest commit so they know where to find it. If they have the capacity, they should assign themselves to this issue. -
QA of your Sketch file by the reviewer. -
Add your changes to the pattern library. When copying things over, watch out for duplicated symbols, layer styles, and text styles. Some of our recommended plugins can help you find and remove duplicates. -
QA of pattern library by the reviewer. -
Create an issue in the Design System to add the pattern documentation. Mark it as related to this issue. - Link to Sass map method
-
Add an agenda item to the next UX weekly call to inform everyone (if it's a new pattern, not yet used in the application).