Mobile Typography

As a designer you are probably keenly aware that more often than not, your dream font is not available on every device and every browser. Whether this knowledge is founded in the experience of designing and developing a site yourself, or from a horrifying experience such as your developer showing you the implementation of your design and feeling the special tug on your soul as part of you dies when viewing your original font choice rendered down into an abomination that makes comic-sans look vaguely desirable.

Previously you may have even decided to give up the fight of using the perfect font for the entire site and opted to use it only on special portions of the design as an image. This, you tell yourself, will help you sleep at night and fix all the problems in the world as they can see the effort you have put into product names, hero images, and various call-to-action buttons.Unfortunately, due to the increased pixel ratio of devices, the regular text on your site now appears crisp and sharp while your sacrificial “stylized” renderings now offer the user no quarter as they content with blurred lettering, rough edges, and pixelation worthy of an 8-bit video game. Do not despair however, because there is an answer. For a few years it bordered on the nearly impossible, or even in the “works on every device and browser except the one you need it to work on” realm, but now we have a valid solution; The web font. Web fonts come in different formats so that a browser may download and use them. They also come with a few compatibility cautions, but to help you implement them correctly and to guarantee that you are using quality fonts, there are several services available.

Font Formats

Using fonts on the web is both similar and quite dissimilar to how you use fonts on your own computer. Your computer may be able to use True Type, Open Type, and perhaps even PostScript fonts, but when it comes to the web, the fonts that are supported depend heavily on the browser that is interpreting them. The formats that are commonly used are TTF, EOT, WOFF, and SVG.

TTF

The TrueType (TTF) font format has existed since the 1980s and has enjoyed popularity and a rather long life due to the support of Windows and Apple systems. This format is fairly compatible with only Opera Mini and Internet Explorer (including IE Mobile) unable to use the format. It is also worth noting is that OpenType (OTF) files can be interchanged with TTF files and have the same browser support. To see which browsers currently support TTF/OTF, visit http://caniuse.com/ttf.

EOT

Embedded OpenType (EOT) was created by Microsoft as a way to help distribute fonts through the web. These fonts are created by starting with a TrueType font and then using a conversion process to create the EOT version of it. This format was submitted as the official format for web fonts, but was ultimately rejected by the W3C and replaced with the WOFF format. Being a Microsoft creation, and having been rejected as the standard for web fonts, the EOT format is only compatible with desktop versions of Internet Explorer. At the time of writing no versions of IE Mobile supported EOT.

WOFF

When the standard for deliverable web fonts was being decided by the members and developers it was decided that the Web Open Font Format (WOFF) would be used. As the agreed standard for web font delivery, WOFF is supported by every major modern browser except for Opera Mini. Currently version 1.0 of WOFF has been approved and considered a complete work in CSS3. A draft of WOFF version 2 was started in 2014 and contains suggestions including sending both version 1 and 2 formats to increase browser support as well as including new compression algorithms and preprocessing data to reduce redundancy. To see which browsers currently support WOFF, visit http://caniuse.com/woff.

SVG logo

SVG

The Scalable Vector Graphics (SVG) format is used extensively for icons and images that need to retain clarity without regard to pixel density. Many agree that this particular format was not meant for use a “body” font, but rather as a means to add flair and intrigue to an otherwise boring display. Before iOS 4.2 the only way to use a web font was to use an SVG font. Today many browsers support SVG fonts, although Firefox has decided to focus on WOFF and has not added support for SVG fonts. Internet Explorer and Opera Mini do not support SVG fonts either.

Browser and Device Support

There is an expression that I often here when working with various pieces of technology and getting this to work, that expression is “the devil is in the details”. When dealing with the myriad of devices available and browsers that they run, this expression is quite accurate as it is not the overall inclusion of web fonts that will be a problem, but the smaller details of getting everything put together. Depending on the software that a device uses as well as the browser used, you can expect to see some different behavior.

Device Differences

You know that iOS and Android are operating systems, but did you know that they have some default system fonts? The following list shows some of the system fonts that are either included or used on each platform:

iOS: Helvetica Neue
Android: Droid Sans, Roboto
Firefox OS: Fira Sans, Fira Monotype
Tizen: Tizen Sans
Mobile Ubuntu: Ubuntu, Ubuntu Monotype

Tip A mobile OS may not be limited to one or two system fonts. For example, iOS shares many of the same fonts that OS X has. To see a list of the fonts that are available for iOS devices, visit http://support.apple.com/kb/HT5878.

You have probably heard the of “web safe fonts”, these are fonts that are installed on many operating systems and can therefore be used “safely” on any system. As more mobile devices enter the market, this list of fonts that are safe to use changes. It is recommended that you use multiple fonts when declaring your font-family so that the browser has a choice of fall back fonts that it can use. An example of this is “Better Helvetica” by Chris Coyier (http://css-tricks.com/snippets/css/better-helvetica/). Feel free to mix-and-match your own fonts for your project.

Some browsers will have an internal list of fonts that will be used if a system font cannot be found. This may not be a problem, however if you are counting on a serif font then you may be surprised when your page is suddenly rendered with a sans-serif font. To help illustrate how using a font-family works, the image below shows a page rendered on different operating systems so that you can see how the fonts vary depending on what is supported by the device.

iOS (left), Android (middle), and Firefox OS (right) display fonts based on system rules.

As you can see, each OS has displayed the text in a font that it supports. As Android does not support “Helvetica Neue”, or “Fira Sans” it has used a fallback font to display text. If we were to use a common web font, each device would show the same font. As mentioned earlier some browsers such as the mobile version of Firefox (including the Android Firefox Browser) use a sans-serif font as the default font rather than the traditional serif font. The image below shows how the page is rendered on different devices when a web font is used.

Each OS now displays the same font in the middle paragraph even though the header and footer text are displayed in the default system or browser font.

Browser Behavior

Knowing that different devices may not support the font you would like to use, you also have to worry about browser support.

Tip Opera Mini does not support @font-face, this shouldn’t be too surprising as the browser is geared toward the feature-phone market rather than the smartphone market.

Almost every modern browser supports web fonts, however just because it is supported doesn’t mean you should jump for joy and start throwing as many fonts as you want in your design. The reason why you shouldn’t quickly abandon all of your senses and plaster your site with multiple fonts (other than it ending up looking like a ransom-note) is that every web font has a hidden price. That price is data. You could argue with yourself and rationalize that mobile users are at home on broadband speeds and not in a store, cafe, or out with friends when they are looking at your site so it doesn’t need to be small. Of course in so doing you’d be wrong, but you’d probably feel pretty good about it.

Paying close attention to which styles you are willing to use, as well as how many files you will be downloading are crucial to mobile users who may have to wait an extra 1-3 seconds for your fonts to load. For an example, the OpenSans font is available in bold, bold italic, extra bold, extra bold italic, italic, light, light italic, regular, semibold, and semibold italic. That is 10 different styles for one font. If you were to size these by the smallest version available (WOFF in this case), then you would add an extra 232KB to your page as well as 10 URL requests adding a potential 200-1000ms of load time per request.

Doing some quick math, by including every style of the OpenSans font could end up adding over 10 seconds of load time to your page. For a mobile user this is roughly the equivalent length of time that it takes to order a pizza, post an update about your favorite show and watch an entire season of Game of Thrones. This is especially concerning for eCommerce sites as a study published in Janurary of 2014 (http://programming.oreilly.com/2014/01/web-performance-is-user-experience.html) found that for every 160KB of images included on the Etsy site, the bounce rate of visitors increased by 12%. That study may have called out the bounce rate for images, but where typography is directly related to style and presentation if the page will not load because it is waiting to download them, a user is still going to get frustrated and leave. The solution for this, is to limit the amount of font resources that you use. If you can get by including the regular style of the font and using the CSS font-weight property to make it bold, that will save you some data and URL requests.

Another important reason for minimizing the use of multiple web fonts is that if you use a font that includes complex glyphs (which increase the size of the font file) and you specify that font for copy of your site users may experience a site that does not contain any text. This is because the text will not be rendered until the font has been downloaded and initialized. To avoid this issue, specify a fall back font or two on the body element and then use apply your specialty font by using a class. This may cause the page to “flicker” or suddenly change as the text will load with one font and then suddenly change when the web font has been downloaded. Unless your design absolutely hinges on the web font being there when the user views the page, consider this as a means to deliver content to the user.

Serving Web Fonts

After you have settled on the font you would like to use and have decided on the format or formats that it will be distributed in, you need to use CSS to tell the browser how to use the font. The CSS rule that is used to include custom fonts is @font-face. This rule allows you specify the font or fonts that you would like include in your site. The following is a sample of including a the “Regular” font from the OpenSans family:

@font-face {
  font-family: 'open_sansregular';
  src: url('OpenSans-Regular-webfont.eot');
  src: url('OpenSans-Regular-webfont.eot?#iefix') format('embedded-opentype'),
       url('OpenSans-Regular-webfont.woff') format('woff'),
       url('OpenSans-Regular-webfont.ttf') format('truetype'),
       url('OpenSans-Regular-webfont.svg#open_sansregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

To get technical on what is happening with this CSS snippet, the rule of @font-face is created and wraps the font-family, src, font-weight, and font-style properties. The src properties all point to where the file lives in relation to the CSS file (as there is not a path specified in this example the font files are in the same folder or directory as the CSS file). The font-weight and font-style are used to set the default values for the font and may be changed as per your unique tastes.

Now that the font has been set up, you need to either create a class that uses the font, or add the font to an existing element. The following shows how the font can be applied by using a CSS class:

.open-sans {font-family: 'open_sansregular';}

Here the class open-sans can now be applied to different elements and will style them with the OpenSans Regular font. The image below shows a paragraph styled with the font as well as another paragraph using the default font styles.

The top paragraph does not have the custom font applied, but the lower paragraph does.

Tip When hosting your own custom fonts, some web servers need to be told how to serve the files so that browsers will understand what the files are. If you are using Apache, locate your httpd.conf file and add the following:
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-opentype .otf
AddType image/svg+xml .svg
AddType application/x-font-ttf .ttf
AddType application/font-woff .woff

Readability Guidelines

A smaller screen reduces comprehension for two reasons:

Users can see less at any given time. Thus users must rely on their highly fallible memory when they are trying to understand anything that’s not fully explained within the viewable space. Less context = less understanding.
Users must move around the page more, scrolling to refer to other parts of the content instead of simply glancing at the text.

The following is a list of legibility guidelines for mobile devices: - Avoid using all caps for text. Users read paragraphs in all caps about 10% slower than mixed cases (Nielsen 2000). - With age, the pupil shrinks, allowing less light to enter the eye. By the age of 80, the pupil’s reaction to dim light becomes virtually nil (Nini 2006). Use typefaces that have more visually distinct characters in certain cases, while still maintaining a desired unity of form. - Older viewers with aging eyesight can benefit from typefaces that have consistent stroke widths, open counter forms, pronounced ascenders and descenders, wider horizontal proportions, and more distinct forms for each character (such as tails on the lowercase letters t and j). - Try to use plain-color backgrounds with text, because graphical or patterned backgrounds interfere with the eye’s ability to discriminate the difference. - Sans serif is often the default choice as it works well enough for all uses, at all sizes. Serifs may or may not help with readability, so there is no special reason to use them. Consider using default faces that carry through the sensibility of the OS, such as Helvetica (iPhone’s default typeface). Verdana is also good, as it has a larger x-height and simpler shapes, designed specifically for on-screen readability. There are numerous mobile-specific faces as well. - Almost all text should be left-aligned, and only items such as Titles should be centered. - Use typefaces that have strong and open counters (or counter forms). Often, using squared-off shapes for small counters is a good idea. - Use typefaces with unstressed forms; straight, even-width lines. - Consider how different pixel densities across mobile platforms affect physical sizes of elements. Using ems to define the size of fonts in CSS may provide ease.

The following guidelines and suggestions should be considered when designing readable mobile displays:

Vocabulary - For on-page elements—such as the text of Titles, Menus, and Notifications—use vocabulary that will be familiar to your user. Do not use internal jargon or branded phrasing only familiar to the company and its stakeholders. - Use vocabulary specific to the task at hand. General and vague titles will create confusion. - Strive for no help or “FAQs” documentation. With clear enough labels, you can often avoid explaining in a secondary method.

Images as aids - Images can provide additional visual aids to reinforce a message’s intended meaning. When needed, use images that are clear in meaning. Do not use images that have arbitrary meanings or require learning. - Image meanings are socially and culturally created. Even the best icons will not be understood for some users. Using images alone without text labels may result in varying interpretations.

Overflow or truncation - Make sure key titles, button labels, soft-key labels, and similar items fit in the available space. Do not allow them to wrap, extend off the screen, or truncate. - For certain cases, such as lists, tables, and some other descriptive labels, the text may truncate. When possible, do not break words. To indicate the truncation, use an ellipsis character. If not available, use three periods, never two or four or any other number. Sometimes it may be suitable for the word to disappear under the edge of the viewport or some other element instead to indicate the truncate. - Rarely, the marquee technique may be useful for list items. Text is truncated, flowing off the screen, and when in focus it scrolls slowly so that after a brief time the entire text can be read by the user. - Long text, in paragraphs, will always wrap using one of the methods described in more in the Alignment section. - If the entire text of a paragraph cannot fit, or is not needed (such as the beginning of a long review) it may begin as a paragraph, and truncate at the end, to indicate there is more content.

Line length - From 50 to 60 characters per line is suitable. If you need longer lines, increase leading, but there are limits to how far you can go. At around 120 characters, users might find it difficult to scan that far. - The optimal line length varies around a multitude of factors. These factors include display size, line size, type size, kerning, color, margins, columns, and visual acuity. - Users’ subjective judgments and performance do not always correlate. Studies have shown that users may prefer shorter line lengths, but may actually read faster with longer lines.