A New Path

Today, after over two years, I’ll be leaving my position at Kisko Labs. I’ve started working on a new responsive advertising solution for smartphones and tablets called Adtile. Another big news is, that we have just received a $2.7 million funding to bring this product to the market. There’s also a story about us on TechCrunch, so check that out.

Banner ads might still function well in print, but it’s clear that they just don’t work on screen and especially on mobile devices anymore. Instead of trying to make the current model work somehow, we decided to start with an entirely new idea and ditch the old model—and the annoying banners. As we are focusing on mobile and building a customizable SDK for both web and native app developers, we will be also building another device lab soon only for this purpose.

The company where I’ll be working at, TenFarms, is based in Los Angeles, so I will be most likely spending time in the US a lot more too. Besides Adtile, I’ll be soon revamping the whole web presence of our second product, Photopoll iOS application too.

Helsinki Device Lab, which I established about 10 months ago, will still stay at the Kisko Labs offices and I will be still maintaining it together with the Kisko guys, so that’s one thing which won’t change because of all this. The Helsinki Device Lab will also soon be at the Webshaped conference, so come say hello if you are coming there.

Kudos to everyone at Kisko Labs and thank you for the past years! I don’t think that I’ve ever been so productive or learned so much new in such a little time. That’s all because of y’all. I will miss you a lot, but will also be visiting the office occasionally to check the devices, do some testing, and to have a chat & tea with you. ❦

A Hot Air Balloon

Plugin For Responsive Navigation

Responsive Nav is a tiny JavaScript plugin which weighs only 1.6KB minified and Gzip’ed, and helps you to create a toggled navigation for small screens. It uses touch events and CSS3 transitions for the best possible performance. It also contains a “clever” workaround that makes it possible to transition to height: auto, which isn’t normally possible with CSS3 transitions. The plugin, along the site, was released today on Smashing Magazine.

Read the article

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:

$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:

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.


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).


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:

// 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:

<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">

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


  • 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.


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.