Readable Wearables

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.

Let’s get small#section2

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.

Boldly oversize type loses its appeal on the very small screen. (Left: before; right: after.)

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-family
  • font-size
  • font-weight
  • font-style
  • font-variant
  • font-weight
  • text-transform
  • color

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:

  1. < 400px
  2. 400px
  3. 550px
  4. 700px

Now, starting with smaller widths, I’d arrived at:

  1. < 290px
  2. 290px
  3. 350px
  4. 550px
  5. 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.

Increasing the font-size from 1em to 1.1em helped readability. (Left: before; right: after.)

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.

15 Reader Comments

  1. Maybe it’s just the coffee not kicking in yet, but why 350 for the one media query breakpoint? I’ve had a few Android phones where 360 is the portrait width.

    Also, not yet owning a smartwatch (I’m waiting for one that can do continuous heartrate monitoring at the very least) I have to ask has anyone yet compiled the dimensions for them yet? I appreciate the article giving the width for the Gear S, but has anyone seen it for other devices? My Google-fu isn’t finding them yet.

  2. PS,

    Thanks for the good question! I chose 350px, because that’s where those design decisions started to feel bad, and could benefit from adjustment. Up until that point, the type and grid changes still seemed to benefit the overall viewing experience.

    I’m trying not to make breakpoint decisions based on device widths. There are far too many in the present and near future to wrangle.

    My motto about when to add a breakpoint? When the design breaks: breakpoint.

    As for your other question, this is not up to the minute, but I did find it helpful:


  3. @powrsurg I would assume that the 350px breakpoint came about simply because he felt the design needed to be tweaked at that width rather than tying it to a specific device viewport.

    In general, when writing responsive CSS, you really shouldn’t worry very much about a specific device’s pixel width, but instead adjust your designs based upon when you see issues as you expand/contract the browser window.

  4. When you say “my 1em (16px) body copy type was too small to comfortably read”, and go on to increase the font size to 1.1em.

    Is this possibly a device specific problem, and that another device might use a lower resolution display (or use more pixels per CSS pixel)?

  5. @CraigFrancis Yes, it’s device-specific. It’s up to the device to determine what its “ideal viewport” is. Smartwatch vendors should test if standard 16px text is readable and if not, set a lower ideal viewport to accommodate for that.

  6. Great reading! Yet another example of how handy SASS can be, especially when maintaining and experimenting on readability on this kind of device. Hope there’s not too much difference in the screen resolutions.
    I work at Stibo, where we have an accelerator currently working on news on smartwatches, an area where typography definitely becomes an issue. Very interesting stuff! Check it out if you’d like:

  7. Craig,

    My impression resulted from two things: the screen is very tiny, yes (so big type doesn’t fit), but also one tends to hold a watch (if you’ll forgive the expression) at arm’s length. Being that it’s not right in front of your face, the 1em font size did feel too small. I did find this effect to also be true on the Moto 360’s very different screen.

    This effect is also a factor of the typeface design, so I encourage you to try things for yourself on your own devices, and use your best judgement.

  8. So here’s the question – does technology drive behaviour or does behaviour drive technology? My answer would be that technology has to be compatible with some underlying behaviour. Putting a camera onto a phone fitted with an underlying human need to simplify things. One device is easier than two. Maintaining two devices goes in the opposite direction – it complicates life. I wonder.

  9. Edge,

    In the best possible world: both. It becomes (hot new phrase) a virtuous cycle.

    How will people use these things? We’ve yet to find out. But this is why I ordered a couple and tried to start living with them, regardless of the potential for silliness.


  10. It occurs to me that I should really clarify my “arm’s length” comment, as a phone is clearly at the end of the same arm as a watch.

    The thing I noticed is that when one has a watch to look at, and its display is on the back of the wrist, it suggests a very different arm posture to use close to your face.

    As a test, try holding your hand in the phone position (elbow down, palm towards your face) for 30 seconds. Then do the same in the watch position (elbow up, back of wrist towards your face) for the same period of time.

    How comfortable is the second pose, in comparison? Not so good, right? My tendency was to leave my elbow (and my wrist) in the down positioning, making the tiny screen more tiny, thus leading me to desire slightly larger smallest font sizes than on my phone.

  11. This, is a great article. Another example of how break points should be used. Rather than base them on devices, use them when your content starts to misbehave.

    Bumping up body copy font size is also beneficial for people reading in the bus for example. With the bumps in the road, you need larger text size so you don’t loose focus on the line you were trying to read. I use larger font size even on my tablet when reading an e-book in the bus, but I lower it when I get home.

  12. Has anyone got further updated information on the Samsung Gear S. 213px-point is small when styling. Our team are having fun with function and form with this. I am not so sure about these devices from a browsing perspective. Might stick with the Gold apple watch (kidding!)

  13. Excellent articles. There has been many wearables that has transformed the way users use certain applications. These wearables directly compete with Mobile applications and are expected to replace mobile apps as well. What is important is to understand the dimensions of the device and search for the techniques that help a company to develop an attractive wearable. Navigation and clarity of text are crucial elements in wearable apps.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA