A few weeks ago we added our first wearable to the Bearded device lab, and it was an eye-opening experience. The same day that Apple showcased the soon-to-arrive Apple Watch, a Samsung Gear S showed up at our door. This device is a large smartwatch with pixel dimensions slightly greater than the iPhone 3GS. It has Opera Mini and its own cellular and wifi connections, so it functions as a standalone web interface.
Article Continues Below
So will people use their watch-like devices for browsing the web? Though some may scoff at the idea (and believe me, there’s been plenty of scoffing), stranger things have happened. And if the last few years have taught us anything, it’s that if you can use something to get on the web, people will get on the web with that thing.
After some personal use, it seems to me that these watch-sized screens are a totally reasonable way to access web content. And it’s equally reasonable for us to present our content in readable ways on these screens.
As Brad Frost recently wrote, responsive design and future-friendly strategies go a long way to making sure our websites work and display the best they can on devices that haven’t even been invented yet. And it’s true that my first reaction to seeing the sites we’ve built displayed on the Gear was “not bad.” But, as I began to look closely and interact with these familiar sites via a tiny curved screen on my wrist, my perspective began to subtly, but significantly, shift.
My gut reaction to these new smallest-of-screens: I’ve been starting with too big of a browser window. Lucky for us, if we’ve been prescient enough to be writing our CSS in extensible ways (and goodness knows mobile has given us plenty of reasons to do this already), there’s some pretty great low-hanging fruit for us to grab.
The current Bearded site is super simple; a static two-pager with no navigation and very little in the way of bells and whistles. It struck me as a perfect candidate to try out some wearable-friendly optimizations without a lot of distractions. So let’s have a look at what could be done in an afternoon to make it more pleasurable to read on a watch.
The Samsung Gear S, according to my tests, registers with media queries as a 213px-wide viewport. This is a far cry from the 300px-wide starting point I’ve become accustomed to when styling.
On this new screen size, the range of acceptable type sizes is tighter than what I’ve been used to. My type was mostly either huge and unwieldy or eye-strainingly small. The original site styles utilized headings set in Quadon Regular, which range from 0.875em to 2.5em. But a 213px-wide viewport, to my sensibilities, only tolerates type sizes from 1.1em to 1.6em with that same typeface.
A closing of the typographic aperture seemed called for, but how to do that without reworking a ton of CSS? Enter Past Bearded being kind to Future Bearded. Here’s how, thanks to Sass, we’ve been writing our heading styles for years. First we define the font stack:
@mixin title-face {
font-family: Quadon-Regular, arial, “helvetica neue”, helvetica, sans-serif;
font-weight: normal;
}
Then we roll that mixin into our general heading mixin, where we add margin-bottom, line-height, and color:
@mixin heading {
@include title-face;
margin-bottom: 0.35em;
line-height: 1.2;
color: $heading-color;
}
Next, we snowball all of that into the various specific heading mixins, and add font-size:
@mixin heading-1 {
@include heading;
font-size: 2.5em;
}
@mixin heading-2 {
@include heading;
font-size: 1.8em;
}
...
Which we can apply to all our headings by default:
h1 {
@include heading-1;
}
h2 {
@include heading-2;
}
...
This approach may at first seem a little overwrought, but it provides some terrific practical benefits over time. For instance, should you have something that semantically deserves to be lower down the chain from an h1 (say a paragraph or an h2), but you want it to have the visual appearance of an h1, you can just apply the heading-1 mixin:
h2 {
@include heading-2;
&.title {
@include heading-1;
}
Best of both worlds, right?
As is often only possible with Sass, this approach also abstracts major styling decisions away from the low-level CSS implementations. This allows for us to be more agile with changes, even later in the project when our CSS files have grown more unwieldy.
For our wearable type hierarchy issue, I was able to easily make adjustments to my heading sizes by adding media queries to those mixins, like so:
@mixin heading-1 {
@include heading;
font-size: 1.6em;
@include breakpoint($breakpoint-s) {
font-size: 2.5em;
}
}
Then I got to sit back, refresh my browser, and watch my sitewide heading typography do its thing. Past Bearded, thank you for being awesome.
Limitations breed innovation#section3
The tiny screens of wearables further restrict the design options we have at our disposal, even more so than mobile screens did before them. But working within this more limited palette is not necessarily a bad thing.
In the letterpress world, for example, we’re restricted to the type we have physically sitting in our cabinets. The weights, sizes, typefaces, and variations we have to work with are extremely limited. And this can lead to some very exciting design work that otherwise we’d never be forced to do.
When we work to come up with a sensible typographic hierarchy for any size screen, we must first consider what we have to work with:
font-familyfont-sizefont-weightfont-stylefont-variantfont-weighttext-transformcolor
The most obvious things (aside from size) that you can use to accentuate your headings are uppercase and bold. Small caps, italics, a new font-family, or color changes may be reasonable options for you, as well.
Though you may not have enough variations in font-size between 1.6em and 1.1em to effectively distinguish six heading sizes from each other, you can mix up font size changes with other type qualities to have that effect, then shift back to your size-based hierarchy as screen size allows for it.
For instance, with the Bearded site headings I chose to use uppercase as a differentiator for two headings with the same font-family and font-size. Then, when the screen is wide enough, I can use media queries inside the mixins to return to my font-size based hierarchy, like so:
@mixin heading-3 {
@include heading;
font-size: 1.1em;
text-transform: uppercase;
@include breakpoint($breakpoint-xs) {
font-size: 1.4em;
text-transform: none;
}
}
@mixin heading-4 {
@include heading;
font-size: 1.1em;
@include breakpoint($breakpoint-xs) {
font-size: 1.2em;
}
}
Where’s that breakpoint gonna go?#section4
Speaking of which, at what point should one add this no-longer-wearable breakpoint? The answer: at a width at which your larger screen design decisions start making sense again. The Gear clocked in at 213px, but it seems like those smallest-screen decisions would be beneficial for widths wider than that. When enlarging my browser up from 213px, my wearable-focused design decisions applied for the most part up until 290px, at which point typography could stretch out a little more, and some multi-column grid layouts could comfortably be put to use.
But not all of the layout decisions from the existing mobile-centric site design made sense at 290px. What’s interesting is that, working at that scale, I actually needed an extra breakpoint. Previously I’d been working with these breakpoints:
- < 400px
- 400px
- 550px
- 700px
Now, starting with smaller widths, I’d arrived at:
- < 290px
- 290px
- 350px
- 550px
- 700px
Not surprisingly, the smaller the screen, the greater the impact that a few pixels has. The difference between 1000px and 1050px may not warrant any design changes at all, whereas the difference between 250px and 300px almost certainly does.
Too small for small#section5
The last thing I addressed was a bit surprising to me: my 1em (16px) body copy type was too small to comfortably read. I’ve always thought of 1em as a font size that was great for web reading. It feels almost clunky, in fact, when compared to the 8pt reversed type I frequently saw in the world of print design. But on this tiny screen on my wrist, there seemed to be a huge difference, at least with this font-family, between the 1em body type and the 1.1em intro paragraph copy.
On this site, fixing that was a breeze—I could just increase the font-size of all paragraphs to 1.1em. There was no need to worry about accidentally missing anything, because there was no non-paragraph body copy (i.e. lists or tables). But for a bigger site, this would be too specific of a solution. I could easily end up with well-sized paragraphs and—on some forgotten page—a tiny definition list or errant span. So what might a more extensible solution look like?
Easy—we can just bump up the site-wide font-size for everything below a certain breakpoint! Something like:
html {
font-size: 110%;
@include breakpoint($breakpoint-s) {
font-size: 100%;
}
}
Of course, now our small screen heading sizes are 10 percent too big. Oh man! Good thing we used those mixins, huh?
Thanks to the Sass-based typographic system we established earlier, adjusting those values a second time won’t be so bad. Who knows, we might even be in pretty good shape when those web-enabled holographic refrigerators finally hit the market in 2016.
