Like a newspaper, web apps may have multiple text elements at similar levels of importance throughout the layout. Unlike a newspaper, web apps might not have editors and designers to direct and define the information hierarchy on a daily basis.
Defining rules for type styles and applying them consistently provide the cues people need to quickly process and make decisions about where to read or what to do in a web app. Aside from aiding usability, typography can be what transforms your design from good to great. We don't expect you to be type geeks, but we do think that with a few tips and examples, you'll be able to create and use simple and effective type hierarchies and avoid common mistakes.
Choosing a font
This blog post covers choosing fonts for an application's content and features, not for its logo (visual identity). Selecting fonts for identities requires different criteria, and for that reason, we assume that a professional designer will be responsible for creating a memorable identity.
In a web application, typically one font family is enough as long as it has three weights: for example, roman, bold and italic; or roman, semibold and bold. You can get away with a font with two weights if you add the use of caps to the hierarchy, but this needs to be done with restraint. (See examples later in this post.)
A serif font will make your application feel more traditional and print-like, while a sans serif is more workman-like. Serifs create more visual activity and sans serifs typically create less, but this varies from font to font. Many aspects of a font contribute to (or detract from) its readability online. This, combined with the fact that you may need to complement an existing style or establish a visual style for brand purposes, means that you may have to try a few different options before you find one that feels right for your application and its audience.
Typetester is a great tool for selecting and comparing fonts.
Choosing a size and weight
Size and weight differences are one way to establish visual hierarchy with type. For example, larger, bolder text emphasizes more important headers, and small, italic text is better for captions or in-context help, places where you are providing supporting, not lead content.
Use boldface and italics sparingly. They're cues to highlight information, and when applied too often, make your text less readable. Reserve them for headers as much as possible, and never use underlines unless you're indicating hyperlinked text.
In general, you won't want to use type any smaller than 8 pixels high onscreen, and even at that size, some browsers may begin to render the type with jagged edges. Check your type across multiple browsers and platforms to ensure it's legible everywhere, and consider sizing your type with the more accessibility-friendly em units.
Sample type hierarchies
To illustrate some of what we've been talking about, here are some sample type hierarchies. The goal of these hierarchies is to create a set of type styles that show a visual progression from strongest to weakest in relation to one another.
Tahoma hierarchy:
Georgia hierarchy:
Myriad hierarchy:
Choosing a link style
As the web has evolved, people have learned that underlines aren't the only way to identify a hyperlink – but the problem is that there is no one convention to take its place. Color change and highlighting are two other conventions.
Links on the MIT Media Lab's website display a light blue background tint on rollover.
Blue headlines are underlined on rollover on The New York Times' website.
Color change is an appealing cue, but it's prone to contrast problems, and rollover effects can't help users who never figure out where to roll over in the first place.
The New York Times can get away with using non-underlined discoverable links because the online newspaper format is a convention its readers understand. If you have an application that does not follow known patterns and/or people need to learn it quickly to get things done, underlining is the clearest way to convey "clickability."
Type hierarchies in practice
The hierarchies shown progress in visual importance from most to least. However, in practice, hierarchies are often not linear progressions. For example, Level 1 heads often need to be less visually prominent so as not to upstage more important content – a case of being more important from a semantic markup perspective, but less important from a visual one.
The illustration below shows one way a hierarchy might map to levels of heads in a web app. (Click image to enlarge.)
Getting your font online
There's been an explosion of tools available to move type on the web beyond common system fonts such as Arial, Verdana and Georgia (although these are fine choices for web app fonts). CSS and JavaScript-based options – the @font-face attribute,
Typekit,
Google Font Previewer,
Cufón, etc. – offer simple and often free methods of incorporating other fonts into your web apps as HTML, not Flash or graphics. Our preference so far is Typekit, for its inexpensive access to a wide range of well-known and well-designed fonts.
Licensing, however, remains a thorny problem, with each type foundry having its own set of rules about font embedding or linking. No matter which option you choose to bring additional fonts into your app, be careful to check the fonts' licensing requirements to make sure your application stays nice and legal.
Basic rules of thumb
- Body text should be roman, with a limited column width (ideally no more than 600 pixels) to enhance readability.
- It's okay to use caps, but they create a lot of emphasis, and making text bold and all caps is the VISUAL EQUIVALENT OF SHOUTING. Don't do it unless you really need to or you reduce the visual volume by shrinking the font size slightly and/or adding letterspacing. (See the hierarchy examples for effective uses of all-caps headers.)
- Just because you can use tons of fonts on the web now doesn't mean you should. Sticking with system fonts is better than using an unusual font that will distract from the content.
For more information
Posts
