|
|
|
|
Issue 14 \\ Rhythm & Grid
Rhythm, the pattern of movement in space and time, is fundamental to any design system. Grids define the proportions of space and elements in a layout, making an orderly rhythm possible.
Vertical rhythm, the alignment of elements on the Y axis of a page, is relatively easy to achieve in print, but on the Web it gets tricky quick.
In this issue, UI designer Tyrick Christian explains how he collaborated with front-end developers to bridge the gap between typographic baselines in Photoshop and browsers to create a rhythm that brings subtle beauty to the MailChimp UI. Front-end developer Mardav Wala carries the story further, explaining how he translates a vertical grid into CSS with a little math wizardry.
|
|
Hey, did you miss our last issue?
On Twitter: @MailChimpUX
|
|
In the past year we’ve redesigned our web and mobile apps, and designed some new tablet apps. Big projects haven’t slowed down our development of new features either. Clear communication was critical for all of this to happen in a short amount of time, and maintain the feeling that these products are part of a family.
Simply moving people into shared spaces in the office helped ideas flow. For example, before the redesign our UX team worked in a small office; over the past year, we’ve moved around the MailChimp campus several times to be near the marketing, mobile, engineering, and support teams. We’re nomadic. This was a great experience because it forced us to communicate with other teams, learn how and why certain decisions were being made, and discover flaws in our own design and development processes.
One major design flaw we discovered was the inconsistency in measurements between design and development. Although we established rules early in our design process for fonts, grids, and colors, and later established styles for basic components like buttons, tables, and lists, the final product simply didn't look like the initial design that was created in Photoshop.
To solve the problem, we revisited an idea we’d discussed early in the design process: use a baseline grid to establish each component in our pattern library. We started by evaluating pages in the app and breaking them down into atomic elements. Because the MailChimp UI is mostly type, it seemed logical to start aligning to the baseline and slowly build larger elements from that point. After the design and front-end development teams reached a consensus that the styles for typography in Photoshop documents could be matched in markup, we moved on to revise buttons, tables, lists, slats, and more until each component rested upon a common baseline.
For the most part, each piece of our pattern library was very close to proper alignment because we’d been working in six pixel increments from the beginning. We found that there were small inconsistencies that eventually added up to larger inconsistencies. For example, a designer may measure the distance between stacked type from the baseline of the top word to the ascender of the bottom word, while a developer may measure the line-height of each word and the amount of space between them. The difference might only be two pixels, but when repeated multiple times on a page the rhythm becomes noticeably different.
|
|
|
Photoshop, Illustrator and other print-centric apps set type on a traditional baseline, but CSS sets type inside a container creating confusion and miscommunication between designers and developers.
|
|
|
Now that everyone is working with the same elements, both in mark-up and Photoshop, and all of those pieces align to the same grid, we’re finding that communication is much smoother from the beginning of a project to the end. Because MailChimp is responsive, we created two versions of our pattern library in Photoshop: one for desktop and one for mobile phones. This let the UX team form a closer relationship with the mobile and marketing teams. We're finding ways to share patterns across multiple projects, all of which share similar grids, baselines, and styles.
|
|
|
The same baseline is applied to our mobile views, bringing consistency across devices and screen sizes.
|
|
|
Looking back at this process it’s clear that, like any new process, responsive design has a steep learning curve. Am I confident that this baseline solves all of our problems? No. Our tools aren’t perfect for this medium yet and we’re continuing to explore new techniques and applications. In the meantime, this simple visual tool has helped us create a language that both designers and developers can use to create something beautiful and useful. In the end, that’s our goal.
|
|
By the way, we're looking for a talented UI designer to join the MailChimp UX team.
Is this you?
|
|
|
The recent MailChimp redesign gave us the opportunity to carefully consider our typography in the app. Laying out content in a grid is a piece of cake these days, but attaining vertical rhythm on the Web—aligning content to a baseline grid—is still nothing short of harrowing, especially when the content varies wildly as is true in most web apps. After addressing the initial inconsistencies between design and code Tyrick described above—mainly due to the differences in how the line height and leading is perceived (or not) in print and Web media—the front-end and design teams are finally speaking the same language (Hello, Tyrick!).
As Richard Rutter notes in his 2006 article on 24 Ways, the vertical rhythm on any web page can be achieved by carefully applying line height, margin and padding to the content. The trick lies in finding a suitable line height, which forms the basis of calculating margins and paddings.
Although the MailChimp app is content-heavy, very little of this content consists of paragraphs of text; almost all of the information is displayed as either lists, forms, tables, charts or data blocks. Therefore, instead of starting with a large value for a line height, which would translate to large margins and paddings, we started with the smallest possible margin value of 6px for any element in the app. Our 6px baseline grid is derived from this value.
You might be wondering why we chose 6px as our base unit for our grids and typography. We experimented with a number of base units, but found that 6px multiplied elegantly to 12px, 18px, 24px, etc to give us a nice range of type sizes and margins. It also worked well when applied to small elements like buttons and form fields. It offered us the flexibility and elegance we needed to construct any UI.
Early in our design process we decided to apply margin spacing only to the bottom of elements to make maintaining the vertical rhythm easier. Change is a constant in MailChimp. We release new features and refinements the UI every four weeks. In our quest for vertical rhythm we had to design flexibility into our system so new modules could be accommodated without disrupting the visual hierarchy on a page. Single-direction margins helped us achieve this goal.
|
|
|
We use a special "baseline" class to display the baseline in the browser. Here is one of the first pages we redesigned.
|
|
Simple Maths
Because our UI is designed on a 6px baseline grid, all line heights, margins, and padding had to be applied in multiples of 6 to maintain vertical rhythm. So long as this is true, a consistent vertical rhythm is guaranteed. Always.
Fonts, however, can be set to any size without breaking rhythm. Our base font size is 15px, a value that we found to be legible in all situations without making UIs feel oversized. Best practices suggest setting the line height of type at one and a half times the size of the type to improve legibility. With our base font size set at 15px, that would result in line height at 22.5px (15px × 1.5). But because our baseline grid is set on a 6px base, we tweaked the line height to 24px, creating a relationship between the padding, margin, and line height in all layouts. With the math sorted, we began applying these proportions to the various elements in our app.
For all headers and other font sizes, the line height is again a multiple of 6 and is calculated based on the font size itself. The examples below use pixel units for the sake of simplicity.
|
|
h1 {
font-size: 40px;
line-height: 48px;
}
.small-meta {
font-size: 13px;
line-height: 18px;
}
|
|
Exceptions to the Rule
Images and charts march to their own drummer, often breaking the baseline grid. Their heights are unpredictable, and can’t easily be made to fall in step with a baseline. However, the vertical rhythm remains unaffected because the vertical spacing defined by the margins and padding don't change.
Elements with borders can also throw off the baseline grid because they're by default not included in line height calculations; they’re added to it. But there’s an easy workaround: simply include the border as part of the overall element height. This may require reducing the top or bottom padding based on the border height. Purists may argue that this results in visual imbalance if the border height is more than 1px and they are absolutely right. Striving to align horizontal rules and elements with borders to the baseline grid is not always the right thing to do because the vertical rhythm is never affected with borders and horizontal rules as long as the margins, line heights and paddings are correct.
Here’s an example of how we trimmed padding in list items to account for a 1px border separating elements:
|
|
@base-unit: 6px;
.dotted-list {
margin-bottom: (@base-unit * 2);
li {
padding-top: (@base-unit * 2)
padding-right: 0;
// 1px less padding bottom
padding-bottom: ((@base-unit * 2) - 1);
padding-left: 0;
border-bottom: 1px dotted #c0ffee;
}
}
|
|
|
Here we show some elements and their respective paddings to ensure that they align properly to the baseline, even with borders.
|
|
Charts can also be adjusted to follow your baseline proportions. If the chart maintains the aspect ratio on resizing the browser window, set the chart height and vertical margins to be a multiple of your base unit. If not, only set the vertical margins and leave the height unchanged.
Because an image’s height will scale as the width changes we can't depend on the height aligning to the baseline grid. In these cases, we ensure that the margins surrounding the image are specified to maintain the vertical rhythm.
Maintaining code with such special rules and exceptions could potentially get messy. A quick word with the team and a simple comment in the code might alleviate some difficulties. Documenting the change in a live pattern library also goes a long way and helps everyone involved.
We’ve also found that tweaking the vertical spacing at a modular level makes more sense—designing from the "content out" as Mark Boulton recommends—than making refinements on a global, per-page basis. If the individual modules adhere to the baseline grid then no matter where they’re placed on the page, the vertical rhythm and the visual hierarchy will automatically be maintained.
|
|
Are you an analytics and data nerd looking for new challenges? We have an amazing gig for you.
|
|
|
Dig Deeper Into Typography
|
|
|
You've made it this far in the newsletter, and you deserve a reward. The next time you log in to your MailChimp account, right click on Freddie in the top left of the screen for a "surprise".
|
|
Ask Us Anything
We want this newsletter to be a dialogue. If you have any questions for our team about workflows, interview techniques, or even Laurissa's thoughts on surviving a PhD dissertation, send them in. Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.
|
|
|
|
|
|
|
