Prototyping Responsive Typography

The history of typography dates back about 5,000 years. It starts from a series of pictograms, which then evolved to hieroglyphs in Egypt and later around 1,200BC to Phoenician alphabets. Almost 2,500 years later the Chinese invented first movable type which later revolutionized everything in the west when Gutenberg invented latin movable type. Many of the basic concepts of typesetting are still the same as 500 years ago.

Web typography, and digital typography in general, is a huge step forward in this history. It has made setting type fast and easy compared with hand-setting metal type. Responsiveness, when added on top of this, makes this period of change we are living very fascinating. Not only is centuries old design theory being rewritten, but the process of how design happens is now changing too (as Mark Boulton states it).

Universality, as a design principle, should guide us when choosing fonts and when testing how our type works on various devices and platforms.

When talking about “responsive typography,” I don’t just mean flexible body text, but also that all our decisions should be based on universality. Universality, as a design principle, should guide us when choosing web fonts and when testing how our type works on various devices and platforms. It should be the core principle behind all the work we do.

Movable Type

New Process

About a year ago I wrote Responsive Workflow article describing my responsive design process. It was an article that gathered a lot of buzz, but I think it just scratched the surface a bit and never really tried to fully describe what’s happening behind the curtains. In this article I’m going to open the curtain and explain a new phase which I would today add to my year old workflow drawing. The new design phase is somewhere between prototyping and visual design phases, and I call it the “Typography Prototyping Phase.”

As I earlier in that article wrote, typography for the Web is really hard to design anywhere else than inside the browser. This is today even more true than it was a year ago. Typography prototype tries to solve this by doing the hard choices before jumping to other tools like Photoshop.

Basically, a typography prototype is a single web page that consists of the project’s actual content. It’s designed in the browser using real web fonts and tools like Typecast. A typography prototype includes font choices, styles for the basic text content and a typographic scale, but nothing else.

Content precedes design. Design in the absence of content is not design, it’s decoration.”

– Jeffrey Zeldman

Planting the seed

All our decisions should start from the content out, not canvas in. This means we shouldn’t start doing any design work before having the project’s actual content on hand (or something that is very near the actual content). That’s because the content and the language used has a big impact on how our typography will work. This is especially true with display type and headers, but also with paragraphs and line-lengths. Having the real content also helps to judge if the font choices fit the mood correctly.

Below is an example of what the typography prototype looks like before any styles have been applied. This basic HTML page is already responsive on its own—by default, like Andy Hume states it, so you can immediately start testing how it works on various devices:

Typography prototype, example 1

Choosing typefaces

Choosing type combinations, which are legible and readable across multiple devices and operating systems isn’t easy. Windows XP, which still has relatively high usage percent globally (24.29% at the moment of writing), is notorious for its poor font rendering. By default it doesn’t have ClearType antialiasing on at all, except in IE8. Fonts which haven’t been properly hinted for use on screen, tend to look like this when viewed there:

Windows XP rendering

When choosing typefaces for the Web you should look out for the following qualities: Style and form, How easy it is to read, typeface’s intended usage—is it meant for longform reading or is it a display type, it’s character set, file size, OpenType font features, how it renders on different screens and if it is hinted for screen or not. Some good tools which can help with the process are Web Font Specimen, Typecast app and Typekit’s font browser.

It’s important that we choose the typefaces before making any other decisions about the layout. This way we can later on determine what the optimal font sizes are for the project, based on how the selected typefaces render at different sizes. Below is an example of what the typography prototype looks like on various platforms after the typefaces have been picked and we start testing how they actually render:

Typography prototype, example 2

Useful Resources:

Choosing a scale

A scale, or more precisely, a modular scale, is a sequence of numbers that relate to one another in a meaningful way. A modular scale helps us to choose font sizes, line heights, margins, and more. Modular scales also make it easier to achieve a visual harmony in the whole design.

I recommend calculating typographic scales using the ideal text size of the chosen body typeface + a ratio, which could for example be the Golden Ratio 1:1.618. I tend to use either Tim Brown’s Modular Scale Calculator to build a custom scale, or, if the sizes match, the scale described in my previous typography article:

Typographic scale

Tim, who also made the calculator I just mentioned, has written an in-depth guide about modular scales and how to use them on the Web. Tim’s methods are very similar to the ones I use myself too, and this is a short excerpt from his article:

Sizing type on the web is tricky because of the limited resolution involved. One pixel of font-size up or down can completely change how a typeface—and thus a whole text—looks. But once I found the size I liked, 18px, I had a number upon which to base my modular scale.”

Sizing type

There are no absolute sizes when it comes to measuring web type. Everything is relative. That’s why you should avoid using absolute values like pixels and instead embrace the fluid nature of the Web using units like percents and EMs. The size of the type you should use depends on the reading distance, device’s resolution and the typeface used. Reading distance also varies depending on the device used—is it a device held in hand, is it a tablet or is it a desktop device? Or maybe it’s something in between these?

A good starting point is to set the body font-size initially to 100%, which zeroes our scales to the “normal” of a given environment and then design and build for larger screens from that point upwards by using the modular scale we calculated earlier.

I do this by using a function in Sass which automatically converts pixels to EMs so that I don’t have to manually calculate them. The function below works by taking two arguments, pixels and context. You can either use the default context and specify only the pixels you want to convert—or you can specify pixels and a context for the conversion:

1
2
3
4
5
$browser-context: 16; // Default

@function em($pixels, $context: $browser-context) {
  @return #{$pixels/$context}em
}

…and then later in the CSS we can just pick numbers from the scale, 16/24/72, and they get automatically converted to EMs:

1
2
3
4
5
6
7
8
9
10
11
body {
  font-size: em(16);
}

p.intro {
  font-size: em(24);
}

h1 {
  font-size: em(72);
}

Below is an example of what the typography prototype looks like now, when we have our scale and have applied some base font sizes from that, but haven’t really tweaked the leading or margins at all:

Typography prototype, example 3

Leading and white space

Leading (line-height in CSS) is the vertical distance between baselines of two lines of text. Leading has a big impact on the readability of a paragraph, so we should be careful when adjusting it. We should use tighter leading in a narrower paragraph, and looser in a wider one. This is to aid the readability and can be achieved by changing the line-height inside our media queries, or by using Mat Marquis’s plugin called Molten Leading.

High DPI screens add some extra complexity as they tend to require different line-heights than the lower DPI screens. Joni Korpi thinks this is because the text looks visually thinner with the extra pixels in use. Less weight = less line height needed.

In the example below, I’ve adjusted the leading of the header, para­graphs, margins, and also the line lengths to be more comfortable to the eye. Everything is based on the numbers found from the scale I created earlier. The example you see here is now basically a ready typography prototype which can be used as the base for the rest of our work:

Typography prototype, example 4

Additional Tips

  • Screens with different pixel densities require different grades of the same font, just like different papers in print do. In theory, this is a great idea, but in reality, there aren’t that many fonts which would have grades (and hardly any have been designed for screen use). Newspapers have been using graded fonts for different papers for a long time, but it’s a quite new concept on the Web.

  • Sometimes using different body fonts for different screen types is better than using the same font all the way. A List Apart’s new redesign is experimenting with this idea. They are using Georgia Pro Condensed in the smallest breakpoint, to see if layouts are enhanced by fitting in more characters per line.

  • If needed, use non-breaking spaces between last two words to avoid orphans in fluid paragraphs ( ).

  • Always use non-breaking spaces in expressions in which figures and abbreviations are separated by a space (e.g. 20 kg, 4:00 pm) and where text breaking across two lines might be disruptive to the reader.

  • Try to keep the line length between 45-75 characters per line.

Conclusion

The finished typography prototype will be used as the foundation for the rest of our work. We have the recipe, and now we need to start thinking how the colours and the layout will be cooked. This way, when we start our work from the most crucial parts—the content and the typography—and build everything else up from that point, there’s much less chance that we will get lost along the way. ❦

File Upload Support On Mobile

I were quite surprised few weeks ago when I found out with Matt, my colleague, that no one has tested thoroughly which mobile browsers support input type=file and how to reliably detect the support. After an hour of Googling we literally gave up and decided to find it out ourselves. The results are shared here to everyone for future reference.

For the detection part, I am using similar code as Modernizr does, but I’ve added a separate user agent regexp to check against browsers that falsely report support. There are quite many of those false positives really, at least all Windows Phone devices running OS 7.0-8.0, Android devices running OS 1.0-2.2, Kindle devices running OS 1.0-3.0 and all WebOS devices running OS 1.0-3.0.5 (Although the latter ones being quite old already).

Testing

For the testing part, I used this page which was loaded on to all devices in our device lab. Thanks to David Blooman, Juha Ristolainen and Mike Arvela, I were able to test this on older Blackberry devices, Windows RT tablet and on Windows Phone 8 too. Below is the JS part used for the detection, which can also be found from GitHub:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Detect file input support
var isFileInputSupported = (function () {
  // Handle devices which falsely report support
  if (navigator.userAgent.match(/(Android (1.0|1.1|1.5|1.6|2.0|2.1))|(Windows Phone (OS 7|8.0))|(XBLWP)|(ZuneWP)|(w(eb)?OSBrowser)|(webOS)|(Kindle\/(1.0|2.0|2.5|3.0))/)) {
    return false;
  }
  // Create test element
  var el = document.createElement("input");
  el.type = "file";
  return !el.disabled;
})();

// Add 'fileinput' class to html element if supported
if (isFileInputSupported) {
  document.documentElement.className += " fileinput";
}

Additionally, I tested manually on every device that the uploading actually works, and for that I used just basic html form:

1
2
3
4
<form action="http://www.tipjar.com/cgi-bin/test" enctype="multipart/form-data" method="post">
  <input type="file" name="image">
  <input type="submit" value="Upload">
</form>

Test Results

OS Works
Android 1.0–2.1 No
Android 2.2+ Yes
Blackberry 1.0–5.0 No
Blackberry 6.0+ Yes
Blackberry Tablet 2.0+ Yes
Firefox OS 1.0 No
iOS 1.0–5.1.1 No
iOS 6.0–7.1.2 Yes
iOS 8.0 No
iOS 8.0.2+ Yes
Kindle 1.0–3.0 No
Maemo 5.0+ Yes
Meego 1.2+ Yes
Symbian 9.1–10.1 Yes
WebOS 1.0–3.0.5 No
Windows Phone 7.0–8.0 No
Windows Phone 8.1 Yes
Windows RT Yes

Notes

  • Android devices which are running OS2.1 and under still support file uploads through Opera Mobile and Opera Mini, but not through the default Webkit based browser.

  • Amazon Kindle Keyboard reports that it support file uploads, but when you click the “browse” button, the device displays an alert box saying “file uploads not supported.”

  • On older Windows Phone OS the file input shows up, but doesn’t respond to touch at all or give any kind of feedback that it isn’t supported.

Conclusion

The support is actually quite good nowadays, Windows Phone OS and older iOS being the biggest drawbacks. I were also quite surprised to notice that even our oldest Symbian devices from around 2004 supported file uploads. Also, with almost all of the test devices, if the upload worked on the default browser, it also worked on other browsers like Firefox Mobile and Opera Mobile/Mini too. ❦

Update 8 Jan 2013: False positives on Modernizr are now fixed and it’s using the same UA detection introduced in this post!

Update 28 Apr 2014: Windows Phone 8.1 added.

Remote Preview

Remote preview is a tiny JavaScript based tool which I built for our test lab. It allows you to preview any URL on large number of mobile devices simultaneously. Just enter a URL, hit enter, and new URL gets automatically loaded on each device. Remote preview works on platforms like Android, Blackberry, iOS, Maemo, Meego, Symbian, Windows Phone and WebOS.

Remote Preview is a tiny JavaScript based tool that allows you to preview any URL on large number of mobile devices simultaneously.

Remote Preview works by making an ajax call every 1100ms to check if the url in the ‘url’ file is changed. If it is, the script will then change the src attribute of the iframe and load a new page into it. If there’s no changes, the script will just keep polling the url file until something changes. Remote Preview allows very fast previewing of different URL’s to check for possible layout problems, which can then be debugged using various other tools depending on the platform where they occur.

There are some issues and limitations with the way it’s being done, but as there currently is no other tool which allows you to preview web pages on all these platforms, I think this can be a handy addition to any test lab’s toolset.

Basic usage

Copy and paste all files to a public Dropbox folder/server/localhost, edit ‘url’ file and wait for devices to refresh. That’s all! You might also want to bookmark Remote Preview to your device’s home screen for fast & easy application like access later on (bonus: If you moved all files to a server or localhost, you can control the devices via web browser by pointing your browser to the directory named ‘control’).

Browser support

Current version is tested to be working on at least:

OS Browser
Android 2.1 – 4.1.2 Stock WebKit + Chrome
Blackberry 7.0 Stock Browser
iOS 4.2.1+ Mobile Safari
Mac OS X Safari, Chrome, Firefox, Opera
Maemo 5.0 Stock WebKit
Meego 1.2 Stock WebKit
Symbian 3 Stock WebKit
Symbian Belle Stock WebKit
WebOS 3.0.5 Stock WebKit
Windows Phone 7.5 Internet Explorer Mobile
Windows 7 Internet Explorer 9

Download

Remote Preview on GitHub

Building A Device Stand

Not so long after the device lab was born I realized that we need a much better way to store and charge all the 40+ devices. There didn’t seem to be any existing solution available which you could just buy, so I started thinking what would be the easiest way to do something like that myself. After some research I ran into this device testing station by 64 Digital and thought it looked like a perfect solution.

The main idea is to provide a dynamic and secure way to store phones, tablets and other devices and make it possible to use them for testing without the need to actually remove them from the stand. Devices are held in place using Velcro tape which is attached both to the back of the phones and the stand. That makes it easy to detach the phones, but it also makes them stick securely to the wall. The whole stand system is done from two 800mm wide racks, and I’m planning to make a third one too so that we have available space to continue expanding our device collection.

The wood materials for both racks cost under 30 euros. The Velcro tape was actually the most expensive part as 25 meters of it cost about 70 euros + shipping. I used two full work days to built these and third to paint them. I guess someone with actual experience might be a lot faster as about half of that time went into trial and error. ❦

See the process below and grab my drawings:

Stand drawings