Browsing articles in "Web Design"

Sneak Peek Into The Future: Selectors, Level 4


The buzzword “CSS4” came out of nowhere, just as we were getting used to the fact that CSS3 is here and will stick around for some time. Browser vendors are working hard to implement the latest features, and front-end developers are creating more and more tools to be able to work with the style sheets more effectively. But now, on hearing about CSS4, you might ask, “Hey, what about CSS3? Is it over already?

We’ve been working hard to spread the goodness of CSS3, and now it’s obsolete? In fact, nothing’s wrong. It’s just natural evolution — a process that will help CSS as a whole — because “Level 3” and “Level 4” just follow the naming convention of the various documents of the specification.

Why Level 4? What About CSS3?

“Level 4” is just the number of the W3C document. Have you heard about the new “Filter Effects, Level 1” specification? Where should it go? To CSS3? CSS4? Hey, maybe CSS1 because it’s Level 1? Doesn’t matter, because CSS is just CSS. Selectors are the first document to reach the fourth level of the specification, and it’s still a draft, a work in progress. Each document is on its own when it comes to the specification number; the documents are developed independently of each other.

This is a big advantage, because finished parts of the document can be closed and set as recommendations — like Selectors Level 3. Finishing a document quickly and moving problematic parts to the next level helps to push the Web forward because it implements the specification one chunk at a time.

How the CSS4 logo could look like.

The buzzword “CSS3” will share the same fate as “HTML5”: we’re not talking about a specification number, but about the language as a whole. HTML5 is basically just the next version of the markup language, which adds support for new elements. But when you talk about it, you can bring up anything you want, from the audio API to Web sockets to geolocation (which isn’t even in the HTML5 specification).

The same goes for CSS3: it’s the shiny bit of magic that we do with CSS when building cutting-edge demos. You don’t have to know what part of the specification border-radius or box-shadow belongs to, as long as you know how to properly use it. Same goes for selectors; they’re just another version of the “Selectors” specification.

What Are Selectors?

The specification explains selectors as patterns that match against elements in a tree. Most of the selectors from the Level 4 specification are pseudo-classes. Selectors have been with us since the beginning of CSS, but now they are at the fourth level and have gotten a lot of cool new additions. Let’s jump into the action and see what’s interesting. I won’t describe the entire document — only the new additions in Level 4.

Logical Combinators: :matches, :not

Let’s start with logical pseudo-classes. The first, :matches, some of you might already know from Mozilla’s :-moz-any(), which was implemented a long time ago in Firefox 4. Thanks to this selector, we can group and match items in our CSS document. Why is it so useful? Well, the most basic use I can think of is to gather multiple definitions of anchor states into one. So, instead of this… li a:link, li a:hover, li a:visited, li a:focus {
   color: red;

… we can just do this: li a:matches(:link, :hover, :visited, :focus) {
   color: red;

Simple, right? Although this example might look silly, it shows the power of the :matches pseudo-class, and it can be used in more complicated situations:

article:matches(.active, .visible, p#important) {
   background: red;

The second logical combinator we’ll look at was introduced in the CSS3 specification, but it became even more powerful in Level 4. I’m talking about :not, the simple negation pseudo-class, which now can take a list of selectors as parameters:

p:not(.active, .visible) {
   color: red;

The code above will apply red to all paragraphs to which the active or visible class are not assigned in the markup.

Location Pseudo-Classes: :any-link, :local-link

Thanks to the location pseudo-classes, we will have more control over the styling of links. First, :any-link (a temporary name that could change) gathers definitions of a:link and a:visited into one, so you don’t have to write them both:

a:visited {
   color: red;

Now, it won’t matter whether a link has been visited or not. It will be styled the same either way:

a:any-link {
   color: red;

Our second pseudo-class, :local-link, is way more interesting. You could, for example, give a different style to the links that target your home page, leaving all others untouched:

nav :local-link {
   text-decoration: none;

Thanks to this line of CSS, links pointing to the current page will not have the text-decoration style, so they’ll look different than the others in the menu or breadcrumb.

Let’s see another example:

:not(:local-link(0)) {
   color: red;

This style will apply red to all external links. (You could add, say, an icon or background image to them if you’d like.)

As you can see in this last example, :local-link can be used with a parameter. The number in the parentheses determines the level of the URL path that will be checked and matched against every given link. Sounds a little complicated, but an example should clarify:

nav :local-link(0) {
   color: red;
nav :local-link(1) {
   color: green;
nav :local-link(2) {
   color: blue;
nav :local-link(3) {
   color: yellow;
nav :local-link(4) {
   color: gray;

Suppose the current address is, and you have these links in the breadcrumb:

  1. Home
  2. 2012
  3. October 2012
  4. 20 October 2012
  5. Article

The first link will be red, the second green, the third blue, then yellow, then gray.

Time-Dimensional Pseudo-Classes: :past, :current, :future

This pseudo-classes is very handy for users of screen readers. With only one line of CSS, the word being spoken can be given a different style (think karaoke-style):

p:current {
   background: yellow;

This will highlight the word being spoken in yellow.

The second use case is styling subtitles for the WebVTT video format, changing their color and other properties. The :past and :future pseudo-classes refer, respectively, to elements that have been selected and ones that will be selected.

UI State Pseudo-Class: :indeterminate

While the UI elements of online forms can be given many interesting pseudo-classes, such as :enabled, :disabled or :checked, one is quite new: :indeterminate. As you may know, checkboxes and radio buttons have two states, either checked or unchecked. Either state can be enabled using the :checked pseudo-class (and :not(:checked) for unchecked). But what if you want to style inputs that haven’t been used? They’re neither checked nor unchecked, so their state is indeterminate. Easy, right? We can give nice styles to these inputs that haven’t been used yet or for which a default state hasn’t been set:

input.checkbox:indeterminate {
   background: #ccc;

Similarly, a progress bar could be given an indeterminate state when its percentage of completion is unknown:

progress:indeterminate {
   background: #ccc;

In this situation, we can target the default state and style it to indicate to the user that the time left to load a resource can’t be determined.

Tree-Structural Pseudo-Classes: :nth-match, :nth-last-match

Tree-structural pseudo-classes are also new and interesting in the Selectors Level 4 specification. With the help of :nth-match, you can now achieve more than ever. Curious how it works? Well, if you take the :nth-child pseudo-class, which selects an item, and combine it with the power of :matches, you’ve got the answer.

Suppose you have a list of links, some of which have the class active, and you want to select only the even-numbered items from the active links. We could use :nth-child(even) to select all of the even-numbered children in the list, but that’s not what we want, because then we wouldn’t be accounting for the active class. Nor is :matches(.active) sufficient, because then we’d be targeting all elements with the class active. This is where :nth-match comes in:

li a:nth-match(even of .active) {
   color: red;

Thanks to this one line, we can finally select only the even-numbered items from among those that have the active class.

This is just a simple example. We can achieve a lot more using the complex syntax An+B, like so:

p:nth-match(2n+1 of .active, .visible, #important) {
   color: red;

This combination of selectors we want to match here is more complicated. The :nth-last-match works exactly the same as :nth-match but starts matching from the end of the DOM structure.

Grid-Structural Pseudo-Classes: :column, :nth-column, :nth-last-column

Let’s apply some pseudo-classes to tabular data. We all know that tables are bad for layouts but good for data that warrants it. An HTML table is row-oriented (<tr>), so columns are missing out. Creating a column-based table is possible, but then you’d be missing rows because you can’t have both at the same time, and row-based tables are more popular. Being able to use CSS to style the columns in a table that is row-based and created in the DOM would be useful when you want to, say, alternate background colors. Of course, we could use additional classes or markup; but with a little help from Selectors Level 4, we can do it with grid-structural pseudo-classes.

:column(.total) {
   background: red;

:nth-column(even) {
   background: blue;

This will set red as the background color of every cell in the .total column, and blue for every even-numbered column in the table.

Now we can select columns just like rows, and even get crazy with something like :nth-column(3n+2). Just remember that columns are styled based on their order in the DOM structure, not how they are displayed on the page. Of course, a table isn’t the only thing that benefits from grid-structural pseudo-classes: column-based layouts are on the way.

Parent Selector!

This is the long-awaited Swiss Army knife, the holy grail of CSS. It is the most discussed aspect of the Selectors Level 4 specification, and it gives you a lot more power with CSS. Thanks to the parent selector (also referred to as the subject of the selector), you can easily style elements other than the default last ones in a selectors list. This can be super-useful when styling generated menus, and you avoid having to add classes for styling purposes only.

Let’s see it in action with the most basic example. Suppose we have a menu, a simple list of links. We want to be able to style it, but the PHP on the server is generating the menu, so we can’t change it. The problem arises when we want to style the li element based on the active class added to the anchor; we can style a using {}, but we can’t get to the li element. The easiest thing to do would be to add the active class to the list element, not to the link itself — like so: ul a — so that we can style both the list and the anchor if needed. The problem is that the menu is generated by a script over which we don’t have control, so we end up with ul li

In the normal structure of a CSS document, we always refer to the last item in the selectors list. In ul li, that would be the link with the active class; in article p span, it would be the span; and so on. Thanks to the parent selector, we can change the subject of the used selector. This gives us incredible power and flexibility when styling:

ul li! {
   color: red;

Now we can style the li element according to whether the active class has been added to the link. When we add the parent selector, we are saying that we want to style the li element instead of

We can also manipulate the background color of the whole page just by adding a simple link somewhere in the document:

body! header a.styleSwitcher:hover {
   background: red;

This applies a red background to the body of the document whenever the user hovers over an anchor with the styleSwitcher class. To do this without the parent selector, you’d have to add custom classes in JavaScript. It’s not impossible, but the native one line in the CSS is definitely the best solution for this.

Note: The first draft of the specification document (dated 29 September 2011) targets the parent selector with a dollar sign before the given selector ($li). The latest draft (22 June 2012) uses new syntax in which the subject of the selector is indicated by an exclamation mark after the given selector (li!). Of course, this could change (it’s just a draft), so don’t forget about it. What matters is that the parent selector will be implemented sooner or later, and the exact syntax is just a matter of preference. It doesn’t matter to me what it looks like, as long as it works properly in the browser.

To see the parent selector in action, check out the cssParentSelector jQuery plugin.


As you can see, the new additions to the Selectors specification look very interesting. I can’t wait to use them in my projects. The only problem is that we will have to wait for them to be implemented in browsers — although you can test some in the browser with the help of a JavaScript library.

State of the Document

Level 4 of the Selectors document is not yet an official recommendation — just an evolving draft (as demonstrated by the parent selector, which has changed a couple of times and is still in flux). You can’t rely on the document because it will certainly change in future. But there’s an advantage to this: you can take part in the discussion and suggest ideas. Everyone with an interesting point of view can add something that will eventually be made part of the official specification.

Implementation and Browser Support

Some think it’s hard to implement something that’s still a work in progress. Yes, that’s partially true; browser vendors start to think about implementation only when the documentation has gone from messy to solid. But even though we can’t use the goodness of Selectors Level 4 today, we can use something like Sel, one of a few engines that have already implemented some of the features. Thanks to shims and polyfills, we can start experimenting with features that will be available in our favorite browsers in the coming months and even years.

Other Level 4 Specifications

There are already other Level 4 documents:

All of them are still in development, so we will have to wait a bit for the next official W3C Working Draft. Of course, you can get involved right away and influence the decisions that will be made.


The first and most interesting place to visit, of course, is the official W3C documentation for Selectors Level 4. Just remember that it’s still in development. You can also check out a couple of interesting articles in the wild, like the one by David Storey, a W3C Working Group member.

Shape the Future

Help with the document, suggest ideas, comment on other people’s ideas — now is the best time to be a part of the future. Who knows? Maybe in a few years from now, you’ll be in the Working Group and will be responsible for an awesome breakthrough CSS feature that will be used by millions of Web developers every day? It’s an incredible opportunity: to be at the bleeding edge of a standard or, better still, to take part in the creative process as one of the main contributors!


© Andrzej Mazur for Smashing Magazine, 2013.


Mobile Myths Debunked: Think Again: Assumptions About Mobile To Reconsider


The popularity of mobile has skyrocketed over the past few years. We’ve seen six generations of iPhones, five iPad models, hundreds of Android phones and thousands of different devices being manufactured. Design and development have gone all the way from static and desktop-centric to responsive and device-aware. And it has been a very exciting journey.

The field is relatively young — we are all learning (usually by mistakes). Because of that, we are also struggling with generalizations and even stereotypes. Let’s have a look at common myths associated with the mobile universe.

Myth: Mobile Is Well-Defined

It has become widely accepted that “mobility” refers to handheld devices, which you can easily use on the go, for Web browsing or anything else. Following that thought, we could easily make an assumption that even a remote control or MP3 player could potentially be a mobile device. But are they?

Barbara Ballard, author of Designing the Mobile User Experience, does a great job explaining the idea behind mobile:

“Fundamentally, ‘mobile’ refers to the user, and not the device or the application.”

Mobility is strictly connected to the user and situation they’re currently in, not to the piece of hardware they’re using. This easily leads us to the conclusion that what really matters is the context, not the device. Some mobile industry luminaries have stated that the idea of context has been overblown. Indeed, it can easily lead to many unfortunate decisions and false assumptions which can drastically affect the end product.

As Jeremy Keith, author of HTML5 for Web Designers and mobile specialist, has said:

“We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.”

By defining mobile as a set of circumstances, a setting, we are in danger of making some sweeping generalizations. We analyze, we study reports and use cases, but mobile interactions are far less trivial than we think.

As studies show (PDF), over 70% of Americans use their phones while in the bathroom. In some countries, the percentage of people with Internet access that is solely provided by mobile exceeds 50%. According to ComScore’s Mobile Metrix, Facebook’s mobile app accounts for 80% of their traffic. These facts prove that assuming short attention spans and oversimplifying interfaces are not solutions to addressing the problem space.

People tend to use their phones or tablets at home while sitting on the sofa or in a cafe. What’s even more important is that they’re willing to perform complicated tasks and actually spend money. Rather than guessing what the user is trying to achieve on a mobile device, we should assume they want to do everything and try to better understand the constraints of each device. We should be concerned about the content that we’re trying to serve while bearing in mind the context is continuously changing.

As developers, we need to ditch our desktop-centric thinking which taught us to prototype for a certain set of conditions, and aim towards more flexible content. Instead of focusing on a single platform, we should create reusable copy and assets, which will serve as a base for multiple scenarios.

Myth: Mobile Is iOS

We have already established that we cannot take network speed, screen dimensions, operating system or browser for granted. The mobile market is hugely diversified. Yet it’s still sometimes identified with iOS devices only.

Apple products are high profile. Their brand is hyper-consistent and instantly recognizable. But iOS represents less than half of the mobile market. And favoring iOS (or any one platform in general) might lead to poor user impressions.

Within the US, Google owns roughly 53% of the smartphone market. That basically amounts to a huge number of wildly different Android devices.

Let’s have a look at market share:

Both Android and iOS are growing while other platforms are slowly loosing more and more users.
Both Android and iOS are growing while other platforms are slowly loosing more and more users.

These numbers mean that we have thousands of resolutions ranging from the first phone with Internet access, Nokia Communicator (640 × 200 pixels), up to Samsung Galaxy S3 (1280 × 720 pixels). While some of the models are discontinued, it still gives us a greater picture of the market’s diversity.

When talking about screen size, it would be a crime not to mention pixel density. The real boom with higher-density screens started when Apple introduced retina display along with iPhone 4. But what does it mean for us? It’s one more factor we need to take into account. Because we are dealing with more pixels per inch than usual, we need to supply higher resolution graphics or else rely on SVG, which isn’t always a solution we can use.

We not only need to consider the diversity of original equipment manufacturers (OEMs), operating systems and screens but also the multitude of browsers. Some of the most well known and widely used are:

  • Opera Mobile,
  • Opera Mini,
  • Safari,
  • Chrome,
  • Dolphin,
  • Internet Explorer Mobile,
  • Blackberry,
  • WebOS browser.

Some of these are default browsers, provided by vendors, and some are user-installable. This is only a small fraction of available browsers, though. Taking this even further, all of the aforementioned browsers have a rendering engine, and while they are usually built upon WebKit, the distributions vary which introduces us, developers, to a whole new range of cross-browser issues.

That leaves us with a few factors to consider: type of device, such as smartphone, tablet, personal digital assistant (PDA), etc.; resolution; orientation; pixel density; and the browser with its rendering engine. All these limitations define how the implementation process will look. It would be a crime to assume device uniformity.

Myth: Mobile Means Less

Imagine you’re reading the delivery menu for your favorite American restaurant, and you want to order a steak. To your utter shock and dismay, you find that it’s not on the menu. You’ve had steak before when visiting the restaurant in person, so you wonder why you’re not seeing it on the delivery menu.

Someone in charge decided that Americans have poor eating habits, and if they are not willing to come to the restaurant in person for the full experience, then they are likely to be sitting at home on a couch in front of the television, and are not fit to have the meal. You enter into absolute food rage and never return to the restaurant again.

When you think about this situation, you should quickly notice that it’s not that different from daily decisions developers and designers make.

Having too many features may be just as harmful as cutting them down, as you can see when viewing The New York Times website on mobile.
Having too many features may be just as harmful as cutting them down, as you can see when viewing The New York Times website on mobile.

You decide what set of features and interactions are necessary for a perfect user experience. It’s especially important on mobile, when you try to cut features to make the interaction as easy and seamless as possible, basically making assumptions and decisions for your users. Nothing is more frustrating than being deprived of the ability to make your own choices.

It’s critical to put the users’ needs first. If mobile gets less features by default, customers can potentially be left without the means to engage with your actual product. People perform all kinds of actions while using a wide range of devices. 25% of mobile users engage in online shopping through their phones and tablets. Would you ever think that every three minutes (within the UK) a vehicle is purchased using the eBay mobile app (PDF)? Tiffany & Co. also noted a significant rise in sales and traffic after launching their mobile app — would you think that people buy diamonds on mobile?

The main focus should go to delivering great experiences within the feature set you’re offering on desktop, not limiting them. While some features appear as unnecessary, you cannot assume that they aren’t without proper testing and real interaction. As Aral Balkan points out:

“If you’re not involved in building what you’re designing, you’re not designing, you’re assuming; you’re drawing pretty pictures.”

Myth: Mobile-Specific Content Is Mandatory

Stephen Hay once tweeted:

“There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.”

Mobile isn’t an independent creature — it’s an experience we’re creating. We could not possibly accommodate all devices that are currently available. The ideal situation would be to have one, uniform experience of the brand, served according to device.

It all comes down to the most crucial part of Web design — content. Being perfectly aware of goals that you’re trying to achieve and leveraging content strategy is essential for creating cross-universe compatible experiences. While we try to tailor, cut and paste content that we think is essential on mobile, again we are trapping ourselves in false assumptions of users’ context (by choosing what’s the most appropriate piece of information they are potentially looking for) and finally ending up making mobile less compelling and bereft of features.

That’s why we should consider designing content out rather than canvas in. Being focused on content from the very beginning will help keep you from being trapped within visual limitations that come with the wide variety of available devices, and make the copy usable regardless of the platform it is being served on.

Myth: Mobile Means Apps

There are few approaches for serving optimized content for mobile. Having an app is one of them — not necessarily the best, though. An app is just a container for the content we are trying to serve. While some apps bring us delightful experiences (such as Solar or Instagram), we can’t rush ourselves and create an app for every website or product we are working on. Especially if we are planning to give the app a subset of desktop features.

“See, your product isn’t really a product at all. Your product is something called content. It’s a service.”

An app is considered a product by many. As Josh Clark outlines above, the essence of the product is and always will be the content and service or set of functionalities you are giving to your customers. Currently, both App Store and Google Play are each offering over 700,000 apps for download. Are all of them being used? Probably not. Are they all providing the content or features the user would like to see? For sure, no.

Responsive design has been adopted by well known brands such as Tiffany & Co.
Responsive design has been adopted by well known brands such as Tiffany & Co.

Since having an app isn’t always the way to go — what is? A good alternative is responsive design. It has been a really hyped topic over the past few months, and not without reason. It certainly can be easier to use media queries than to write a native iOS app or play around with PhoneGap. It also gives the impression of cohesion and creates a seamless experience. Development-wise, it prevents you from creating a couple different apps (for different platforms) and code bases.

Instead of creating an app to make the “New & Noteworthy” section within the App Store, and therefore limiting yourself to the container you’ve chosen, try to think about a strategy which will reduce the amount of redundancy in your work and that will serve all users. Before jumping on the bandwagon of apps, be sure that you have good content strategy thought out.


These are exciting yet overwhelming times for Web development. We are forced to rethink the purpose of websites or apps we are creating. We have no ability to predict what will happen next, what constraints and abilities the next devices will bring. What is important these days are back-end systems which provide all the data we are trying to display — it’s not only presentation layer we need to care about, which still somehow remains the most important factor. We are observing robust growth and increasing interest in APIs, which along with content are drivers of layout change.

It all comes down to both knowing the needs of your audience and revolving around content. We tend to acknowledge the constraints of platforms and design strictly for given requirements. Let’s make sure that the data is accessible anywhere, anytime, on any device.

Further Reading


© Karolina Szczur for Smashing Magazine, 2013.


Structural Semantics: The Importance Of HTML5 Sectioning Elements


Whatever you call them — blocks, boxes, areas, regions — we’ve been dividing our Web pages into visible sections for well over a decade. The problem is, we’ve never had the right tools to do so. While our interfaces look all the world like grids, the underlying structure has been cobbled together from numbered headings and unsemantic helper elements; an unbridled stream of content at odds with its own box-like appearance.

Because we can make our <div>s look but not behave like sections, the experience for assistive technology (AT) users and data-mining software is quite different from the experience enjoyed by those gifted with sight.

Now that HTML5 has finally made sectioning elements available, many of us greet them with great reluctance. Why? Partly, because we’re a community which is deceptively resistant to change, but also because of some perceived discrepancies regarding advice in the specification. In truth, the advice is sound and the algorithm for sectioning is actually easier to use than previous implementations. Some dev’s are just very married to their old workflow, and they think you should be too. There’s no good reason why.

Make no mistake: Sectioning elements help you improve document structure, and they’re in the spec’ to stay. Once and for all, I will be exploring the problems these elements solve, the opportunities they offer and their important but misunderstood contribution to the semantic Web. If you’re unfamiliar with the concept of the “semantic Web,” this video is a great introduction.

Making Websites

My introduction to Web design was via a university course module called something like “2.1: Dreamweaver,” and I recall my first website well. I remember my deliberately garish choice of Web-safe colors. I remember it looking right only in Netscape Navigator. Most of all, I remember hours of frustration from tugging at the perimeter of a visual layout tool named “table.” I had no idea at the time that this layout tool represented a type of annotation called an HTML tag. Furthermore, no one told me that this annotation invited my patchwork of primary colors and compressed JPEGs to be computed as a sort of demented Excel spreadsheet. In other words, I had no idea I was doing it wrong.

A Dreamweaver table
*Bites tongue*

The fundamental failure of most graphic, product, architectural, and even urban design is its insistence on serving the God of Looking-Good rather than the God of Being-Good.

– Richard Saul Wurman

Macromedia’s Dreamweaver didn’t make the creation of valid documents impossible, but it was one of a number of emerging GUI editors that pandered to our desire for visual expression more than it encouraged informational clarity. Dreamweaver, and other editors classified under the misnomer “WYSIWYG,” helped transform a standardized information system into a home for graphic design and enabled a legion of insufferable Nathan Barleys to flypost the World Wide Web with their vapid eye candy. I was one of many.

Web Standards

By the time I made my first website, the Web standards movement, promoting compliance, uniformity and inclusion, was burgeoning. I just wasn’t aware of it until much later. I didn’t have to be: Agency-based Web design was still mainly graphic design with a reluctant programming department clumsily bolted on. If you’re doubtful of the grip that this culture has had on the World Wide Web, look no further than the fact it took until 2010 (2010!) for us to concede that Web browsers are not really made of paper.

When I finally became familiar with Web standards and the practice of “doing things right,” it was as someone who still worked primarily as a visual designer. Inevitably, my first forays into standards-based design revolved around mastering “CSS layout,” the practice of visually arranging content without relying on the semantically incorrect <table> element. We’ve held up <div>-based layout as a mark of quality for a number of years now. You might even say that it has become a time-honored rite of passage for graphic designers who are moving into “proper” HTML coding.

As I shall demonstrate, the <div> is the ultimate Graphic Design tool. By affecting only appearance, it licenses poor document structure and overengineered interfaces; all without making your document technically invalid. As such, it sanctions the worst kind of hacks.

The Problem With <div>

Every day, thousands of Web developers invoke the almighty <div> to divide, partition and ring-fence their Web pages’ content. We use the <div> to police content, to prevent disparate chunks of information from collapsing into each other. In truth, the <div> has no such power.

Consider the following example:

Two column layout with sidebar encircled with dark border

In this basic layout, I have included a body of text and an adjacent “sidebar.” To make it absolutely clear to the reader that the sidebar is tangential and does not belong to the main content, I’ve drawn a fat line around it using the border property. For those of you screaming, “That sidebar heading should be an <h3>!”, I’ll get to that shortly. All of my design decisions (the adjacent position, the border and the reduced font size) are facilitated by CSS alone. So, when I take the CSS away, I get this:

The same layout as before is now one column, no borders

Not only is switching off CSS the quickest way to make a Web page responsive, but it’s a great way to see how HTML4 documents (which lack sectioning elements) are actually computed. In this case, our so-called “sidebar” is revealed to be just another raft of information in the linear flow of the document.

Why Is This So?

The reason for this is that the <div> is, and always has been, a flow content element. No matter how thick the <div>’s borders or how dark its background color, it does not stand apart in the structure of the document. Neither, therefore, does its content. With the CSS removed, the faux sidebar’s heading of “Resources” now seems less a distinct component of the page and more a part of the main content. To a parser or screen reader, it would have seemed this way all along.

For reasons of clarity, let’s look at a further example using a snippet of HTML:

	<div class="parent">
	<p>Some content...</p>
		<div class="child">
			<h2>Another heading</h2>
			<p>Some other content...</p>

I’ve done something slightly different here by entering the two <div>s into a parent-child relationship: The div.child tag belongs to div.parent. We can certainly make it look that way with CSS, anyway. However, <div>s, to quote the specification, “have no special meaning.” Not only do they not mean anything semantically, but they have no impact on the computable structure of the page (sometimes called the “document outline”). The <div>s we’ve used may as well be invisible; so, to get a meaningful map of the structure we’ve created, we should remove them completely. That leaves just four elements and reveals the parent-child relationship to be an illusion:

	<p>Some content...</p>
	<h2>Another heading</h2>
	<p>Some other content...</p> 

As HTML coders interested in sound structure, we should be interested that the above reduction — which omits all meaningless elements — is what we’ve actually made, and it’s not what we set out to do: By not really belonging to “parent,” “child” has a different contextual status in the document than intended.

Heading Levels Don’t Really Help

It’s popular to believe that replacing the second <h2> with an <h3> would solve our problem. If we did so, we’d get the following, more dynamic outline:

  • A Heading (h2)
    • Another Heading (h3)

This solution certainly seems more purposeful, but is it the right decision? Should the second heading be a subheading within the same topic (an <h3>) or be the introduction of an entirely new topic (an <h2>, as we had in the first place)? Headings alone can only show where a piece of content starts, not where it ends, which makes it difficult to tell what belongs to what. We have to simulate belonging by choosing the correct heading level for the context. Just think about that for a second: We’re defining the content’s structural status by labeling it retroactively. It’s just begging to go wrong.

Lets have a look at the homepage of accessibility experts The Paciello Group. Naturally, it’s a highly accessible and pretty well organized site, but could the structure be improved with HTML5 sections? You’ll notice their use of a <div> to collectively wrap the three <h2>s, Software Developers, Website Owners and Mike Paciello. Since the <div> doesn’t computably contain these three blocks, the last <h2> and the following <h3> are allowed to pair off in this relationship:

  • Mike Paciello (h2)

    • Contact Us Now (h3)

Wait … so, “Contact Us Now” is a subtopic belonging to the larger theme of “Mike Paciello”. Can that be right? It certainly doesn’t look this way in the visual layout. It’s worth noting at this point that the <div> which fails to thematically group those three <h2> blocks has a class of class="region". Ironically, if this <div> had been a <section>, some screen readers would consider it a “region”. If a <section> had been used in place of the <div>, the observed relationship would not have emerged: The “region” would be self-contained. The class of “region”, however, is not taken into consideration in any meaningful way and does not affect the structure.

Okay, so that’s a weird one, but the situation only gets more confusing when we start to include items for which headings aren’t really even appropriate. Take this further example:

This layout has an h1, an h2 for content and an h3 sidebar with a footer div at the bottom

In my HTML4 page, I have an <h1> to introduce the document, an <h2> for the main content and an <h3> to mark the start of my “sidebar” (which is just a wishy-washy <div>, as in previous examples). The page follows long-standing convention by having an untitled div#footer resting at the foot of the document for copyright information and other such necessary evils. (It has to be a <div> in HTML4, because the <footer> tag doesn’t exist yet.) The question is, to which heading does the footer belong?

Whose Footer Is This?

Most of us, based on appearances, would agree that the footer must belong to the document. That is what we’ve learned to expect. To the unsighted, it is a different story: Because there is no new introductory heading between the sidebar <h3> and the footer content, it could be extrapolated that these two components are as one (see image below left). By the same token, one could also argue that we’ve included the “sidebar” as a mere “break” from the flow of the main content, before returning to that flow at the advent of the footer (see image below right). This would make the <h2> the footer’s heading.

Red outlines show different interpretations of structure

The only decent chance we have of understanding the intended structure of the page is by inferring it from a reading of the content. Remembering that the whole point of a “markup language” is to make the structure of information easier to follow, I may as well have chucked the HTML and written my Web page on the back of a napkin.

Some accessibility gurus would suggest that you use a remedial <h2> to head the #footer and bring it back in line, marking up the end of the sidebar like so:

  • h1 (page)

    • h2 (main)

      • h3 (sidebar)
    • h2 (footer)

This kind of works as a hack, but it’s not really sound. Do you really want to make a big announcement of the footer — an announcement as big and bold as the one used to summon the main content, not to mention bolder than the sidebar? No. If our Web page were a film, the footer wouldn’t be the titles — it would be the credits. In HTML5, the <footer> element “contains information about its section.” This is semantically superior: We don’t use footers to introduce topics; we use them to conclude them. Accordingly, footers — unlike their parent sections in HTML5 — do not require headings.

Tweet reads: Marking up lots of headings in a page significantly dilutes a screen reader user's ability to navigate between parts of a page efficiently
Just because the nesting level of headings is correct doesn’t necessarily make a page easy to read.

The closest thing we have to a “system” for structuring documents properly in HTML4 is numbered headings. Not only does this lead to ambiguity, as explained, but in practice we don’t really even use headings to define structure. We use <div>s to define structure and throw in some apologetic headings for accessibility’s sake. To make matters even worse, advice regarding the deployment of numbered headings isn’t even clear on whether we should use them in order (h1-h6) or not.

The loose coupling between headings and <div>s is inadequate. Now, with the introduction of sectioning elements, we still use boxes, of sorts, but boxes that actually say something on their own. We are making a move from merely implying sections (by labeling them) to letting them define themselves. Simultaneously, sighted readers and unsighted parsers can experience content that one has effortlessly divided into clear, manageable portions.

The HTML4 spec is very imprecise on what is a section and how its scope is defined. Automatic generation of outlines is important, especially for assistive technology, that are likely to adapt the way they present information to the users according to the structure of the document. HTML5 removes the need for <div> elements from the outlining algorithm by introducing a new element, <section>, the HTML Section Element.


Aware of our desire for legitimate elements to create computable sections, HTML5 offers <section>, <article>, <aside> and <nav>. Like some sort of obnoxious holiday rep’, I’ll introduce the topic of practical sectioning using these elements with a quick quiz. Study the following diagram. How many sections do you count?

An HTML5 page with header, aside and footer

Multiple-choice answers:

  1. 1
  2. 2
  3. 3
  4. 4

The correct answer is (a), 2. We have included just one of HTML5’s new sectioning elements in the form of an <aside>. Because <footer>s and <header>s are not sectioning elements, what does that leave us with? The <body> tag is the outermost element, making the document itself a kind of section (a supersection, to be precise). So, there you have it: We’ve been using “sectioning” since HTML 1.0, just not with any subsections to speak of.

Some of you may have missed the clue earlier in this article and thought that <header> and <footer> were sectioning elements. Don’t fret; it’s not your fault. Whenever developers like myself try to explain HTML5 page structure, they usually brandish a diagram like the one I used above. In these diagrams, the boxes marked “header,” “aside” and “footer” exist in the same visual paradigm and occupy a similar area. They seem alike, you might say. The other culprit for this endemic confusion is the way the specification is written. Believe it or not, the document structure of some pages in the specification that refer to document structure is structurally unclear! This sort of thing sometimes happens when a standard is constantly evolving. The navigation tree for “4.4 Sections” found in this draft is laid out like so:

  • 4.4 Sections
    • 4.4.1 body
    • 4.4.2 nav
    • 4.4.3 article
    • 4.4.4 aside
    • 4.4.5 h1, h2, h3, h4, h5 and h6
    • 4.4.6 hgroup
    • 4.4.7 header
    • 4.4.8 footer
    • 4.4.9 address

You’d be forgiven for thinking that anything in this list qualifies as a sectioning element, absurd as some of them (<address>?) may sound. It’s only when you navigate to 4.4 Sections > 4.4.8 Footer that you’re told that “the footer element is not sectioning content; it doesn’t introduce a new section.” Thanks!

Despite these ambiguities in the spec’ itself, as well as in the surrounding publicity for HTML5, sectioning in practice just works. The following three axioms are probably all you’ll need to understand the algorithm:

  1. <body> is the first section;
  2. <article>, <section>, <nav> and <aside> make subsections;
  3. Subsections may contain more sections (subsections)

Aside from a few trifling details, that’s it. In a little while I’ll cover the completely unnecessary worry that is had over headings combined with sections. For now, let’s take another look at that example from before about footer ownership. This time, I’ll make a few HTML5 substitutions:

The diagram clearly shows the footer in the context of the document
Note the lack of illustrated headings. Wherever a section is opened, it assumes responsibility for nesting: The heading type is unimportant. More on this soon …

The outline for this example looks like this:

  • Document
    • Article
      • Aside

Now that we’ve implemented sections, the boundaries are clear. Our document contains an article, which, in turn, contains an aside. There are three sections, each belonging to the last, and the depth of each section is reflected in the outline. Importantly, because sectioning elements wrap their contents, we know perfectly well where they end, as well as where they begin. And yes — screen readers like JAWS actually announce the end of sections like these! We know what content belongs to what, which makes deducing the purpose of the footer much easier. Because it exists outside the bounds of both the <article> and its <aside>, it must be the document’s footer. Here’s the same diagram again, with subsections faded out:

The same diagram with subsections faded out

The power of sectioning lies in its ability to prescribe clearly defined boundaries, resulting in a more modular document hierarchy. The footer unequivocally belongs within the immediate scope of the highest-level section, giving assistive technologies and indexing parsers a good idea of its scope, which helps to make sense of the page’s overall structure.

Headings And Accessibility

When Sir Tim Berners-Lee conceived the <section> element all the way back in 1991, he envisioned the obsolescence of ranked heading levels. The thrust of the idea was that headings should act as mere labels for blocks of content, and the nature (i.e. the importance, scope, etc.) of the content would be calculated automatically based on the content’s standing in the document.

I would in fact prefer, instead of <h1>, <h2> etc for headings [those come from the AAP DTD] to have a nestable <section>..</section> element, and a generic <h>..</h> which at any level within the sections would produce the required level of heading.

Why is this preferable? Determining heading level systemically, based on nesting level, is much more dependable because it removes a layer of decision-making: By “producing” the required heading level automatically, we no longer have to decide separately which numbered heading we should include. It effectively prevents us from choosing the wrong heading level, which would be bad for parsable structure. A subsection must be subject to its parent section. Because this relationship between sections determines “level,” numbered headings are made redundant — hence, the proposed <h>.

A lot of fuss over nothing

Now, this is the supposedly tricky part; the part that causes all the consternation and gnashing of teeth. This is the part that caused Luke Stevens to write this diatribe, and prompted Roger Johansson into a state of uncharacteristic apoplexy, asking, “are you confused too?”. Ready?

In the WHATWG specification (in the same place where <footer>s were ostensibly classified as sectioning elements!), we are “strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.” On first appearance, this seems contrary. Surely only one of these courses of action can possibly be right? What do you do? I’m thinking maybe the first option. Or the second. Who am I?

It certainly confused me, so I spoke with HTML Editor, Ian Hickson. He explained the outline to me in detail and I’m convinced it is perfectly robust. I’m going to do my best to explain it to you here.

Okay. As it turns out, we didn’t get the generic <h> element. This wouldn’t be backwards compatible because older browsers wouldn’t recognise it. However, headings that introduce sections are — regardless of their numbered level — treated as a generic <h>. Quite correctly, it is the section itself that takes responsibility for nesting in these situations — not the heading — and whenever you introduce a new section, you introduce a new nesting level without fail. What does this mean in practice? It means that we can introduce and benefit from the structural clarification offered by sections without abandoning heading levels. Take the following example:

<h4>Page heading</h4>
<p>Introductory paragraph...</p>
    <h3>Section heading</h3>
    <p>some content...</p>
    <p>content following subheading...</p>
        <p>content two levels deep...</p>
<h5>Another heading</h5>
<p>Continued content...</p>

Our heading levels are all over the place. This is not recommended by the specification, but it helps demonstrate just how robust the HTML5 outlining algorithm really is. If we replace all the headings that open sections with a generic (“wildcard”, if you prefer) <h>, things become clearer:

<h>Page heading</h>
<p>Introductory paragraph...</p>
    <h>Section heading</h>
    <p>some content...</p>
    <p>content following subheading...</p>
        <p>content two levels deep...</p>
<h5>Another heading</h5>
<p>Continued content...</p>

It’s important to note that the only errors revealed in the computed outline are ones relating to badly ordered numbered headings within the same section. In the original example, you’ll see that I’ve followed an <h3> with an <h2>. Because they are in the wrong order, the outline interprets them as being on the same level. Had I encapsulated the <h2> in <section>, this error would have been suppressed.

Well, how about that? If you’re not convinced, go ahead and paste my example into the test outliner and play around. It works just fine. In fact, it’s really difficult to break.

If you think there is a benefit to screen reader users, you may wish to adhere to the second of the two clauses from the specification and incorporate numbered headings that reflect nesting level. As demonstrated, this will have no effect on the outline, but since heading level (“Heading Level 2 – The Importance Of Sections”) is announced, it gives a clearer impression of structure to those who can’t see boxes inside boxes.

The assertation that heading levels are perpetually indispensable to screen reader users comes under pressure when you consider advancements being made by screen reader vendors. Screen readers like JAWS mark the territory of sections more clearly than headings, by announcing the beginnings and ends of sections and the thematic regions they represent (“Article End!”). From this perspective, using more than one <h1>s in your document might sometimes be applicable. You’ll come up against some accessibility experts who are keen on their “there can only be one [h1]!” mantra, but research shows that even in HTML4 or XHTML, this is not necessarily case.

The approach you choose is yours to make; just employ some common sense and consistency. Bear in mind, though, that not all screen readers are able to announce the bounds of sectioned content. In these cases, there are measures you can take …

ARIA Enhancement

Transition to an HTML5 document structure is made smoother by incorporating some ARIA landmark roles, which are both relatively well supported and somewhat analogous to the section-based navigation we should expect later. ARIA offers many more accessibility-specific features than baseline HTML5 could ever withstand; so, including “bolt-on” ARIA enhancements is certainly polite. However, regarding ARIA roles as a substitute for semantic HTML would be a grave misconception.

Landmark roles, such as role="navigation" and role="banner", address accessibility only — not data mining — and each may be used only once per document. They are essentially shortcuts to parts of the page. HTML elements are more like building blocks, which are used in a repeated and modular fashion. So, while you can assist accessibility by placing role=”banner” into the <header> element closest to the document’s root, this does not preclude you from using <header> to introduce other sections:

The banner landmark role is used just once

Are Sections The New <div>s?

This is a common misconception.

If it wasn’t clear already, it should be clear to you now that <div>s are semantically inert elements — elements that don’t really do or say anything. If this is clear, then it should also be clear that, when building a structured document, relying heavily on “an element of last resort” makes for a very poor foundation.

If the new <section> element, for example, was just <div> with a new name, adopting it would be a straightforward matter of search and replace. It wouldn’t exactly be progress, though. The truth is, <div> still has a rightful place in the spec’; we’ve just given its organizational responsibilities to a team of elements that are better qualified. Sorry, <div>, old mate. What do we use <div>s for, then? Precisely what they were good at from the beginning: as a tool for “stylistic applications… when extant meaningful elements have exhausted their purpose.”

For instance, you shouldn’t employ sections as box-model controlling measures like this…

	<section class="outer">
		<section class="inner">
			<h1>Section title</h1>

… because there’s nothing that the outer section does that the inner section doesn’t. We’ve created two sections for one piece of content. A quick run through our outliner throws the “Untitled Section” warning:

  • [Untitled Section]

    • Section title

The brilliance of <div> in this context is that it refuses to affect the outline, which is why we can use it without fear of reprisal. This…

			<h1&gtSection title</h1>

… averts disaster and results in this unsullied, if simplistic, outline:

  • Section title

Sections And Semantics

A lot of developers have trouble with the word “semantic.” You might even say that they don’t know what the word means, which (if you are familiar with the term) makes an interesting paradox. For instance, when Jeffrey Zeldman advocates for the “semantic” application of the id attribute, he’s kind of missing the point. The main purpose of semantic HTML is for the automated extraction of meaning from content. Applying a private, non-standard id to a <div> would not improve the semantics of the element one iota: Visitors can’t see it and parsers will ignore it. So much for the semantic Web!

Sections are often characterized as the “semantic” equivalent of <div>. This is a half-truth at best, and I apologize for throwing the term “semantic” around so much — it’s become a bit of a shorthand. Some HTML elements are inherently semantic in that they prescribe specific meaning to their contents. The <address> element is a good example: When a parser reaches <address>, it knows that the contents should probably be interpreted as contact information. What it chooses to do with this knowledge is another matter, but it’s plausible that a screen reader could provide a shortcut to the address or a search engine could use it to refine its results pages.

Definition of syntax from Google search: The arrangement of words and phrases to create well-formed sentences in a language

Sectioning elements are not so much semantic as syntactic. All <section> tells us is that it is a part of a whole. However, the syntactic contribution of sectioning elements to document structure is not unimportant. Consider the following sentence: If sections you don’t websites your are use obsolete. A lot of recognizable words are in there, but the lack of sensible syntax makes the sentence difficult to unpick. So it is with sectioning: You are not creating meaning so much as assembling it. Meaning isn’t always about the “thing”; it’s sometimes about what that thing’s role is amongst other things.


Efficient, syntactically sound data structures are worthless if they are semantically lacking. Fortunately, HTML5 has both angles covered and provides a mechanism for attaching semantic meta data, called “microdata,” to our structured content. Using microdata, and by consulting, you can define a page’s content as anything from a scholarly article to an exercise regimen. Unlike classes and IDs, this is information that can actually be interpreted usefully.

Google's structured data dashboard
This microdata was found by Google and displayed in its “Structured Data Dashboard” for the WordPress theme Typical.


HTML isn’t just an SDK or a Graphic Designer’s palette. It is a metalanguage, a language that tells you special information about information. Sometimes we — or, more precisely, the parsers we employ — benefit from added information about the subject, timing, origin or popularity of content. This is what APIs such as microdata and RDFa are for. Other times, the context, hierarchy, relative importance and codependence of the information are what need to be determined. This is where appropriate syntax, facilitated by sectioning elements, can be employed.

Some people will tell you not to bother with sectioning. They say that it’s hard work or that it doesn’t make sense. This is hokum. Sure, if you’re lazy, don’t bother with sectioning, but don’t pretend you’re doing it on principle. Using sections demonstrably enhances HTML structure without breaking accessibility. We’ve covered this.

Still, there will always be people who will attack this aspect of the specification. Perhaps we’ll enjoy some of these objections in the comments:

  1. They will point to bad implementations by specific vendors:
    “These are bugs and bugs get fixed!”
  2. They will cite the actions of large websites who don’t use sectioning elements:
    “Just because large sites haven’t implemented sections doesn’t mean they wouldn’t like to. Since when does big mean ‘right’ anyway?”
  3. They will flood you with examples of developers implementing sections badly:
    “Some developers do stupid things and their misuse of HTML doesn’t stop at sections. I include myself here, by the way.”
  4. They will present you with anecdotal evidence about user behavior within specific groups:
    “It is expensive and impractical to address problems on a case-by-case basis. Fragmentation and complexity would also be inevitable: a loss for the majority, not a specific minority, of users.”

I don’t think anyone would advocate making badly structured Web documents any more than they’d suggest building a house by stuffing a bag full of bricks and throwing it into a ravine. The case has been made and the specification bears it out: Sections aren’t just good for document structure — they finally make proper structure attainable. Some browsers and screen readers have some catching up to do, that’s for sure, but the situation is improving rapidly. Any kind of change is a little turbulent, but this kind is worth it.


© Heydon Pickering for Smashing Magazine, 2013.


The Myth Of Hand-Lettered Typography: Understanding The Difference Between Type And Lettering


Coming out of the grunge, graffiti and David Carson era through the ’90s, there has been a major resurgence of interest in typography. We have seen a number of designers and artists make their careers out of designing type or custom lettering, and it has become common to list typography among our skills and disciplines.

Unfortunately, as with any popularity surge, there have come with it a lot of misunderstandings of some of the terms and concepts that we use. This article will help you gain a clearer understanding of what typography is and isn’t, and why.

One rather common example of this is the myriad of blog posts and showcases claiming to display “hand-lettered typography” — I’ve even heard university professors say it. Though the phrase seems to make sense, it’s actually a contradiction in terms — hand-lettering is not typography at all! Before you throw your pens and brushes at me in protest, please let me explain!


Even though lettering and typography share many of the same concepts, and a good eye and understanding of one will enable you in the other as well, they are completely different disciplines. Let’s begin by defining how we understand each term.

What Is “Typography”?

Typography is essentially the study of how letterforms interact on a surface, directly relating to how the type will be set when it eventually goes to press. One definition is stated as “the style, arrangement or appearance of typeset matter,” and is a product of the movable type printing system that much of the world has used for centuries. It is related to typesetting and can include type design. In our current digitally-driven design world, this means working with fonts on a daily basis for most of us.

Typography is actually a subset of lettering, because it is the study of letters applied to typefaces. Many designers have also taken up letterpress printing as a hobby or side interest, which also utilizes aspects of typography or typesetting, depending on the project.

Typeset book pages.
Typeset book pages. (Image: Tom Garnett)

Gerrit Noordzij, professor of typeface design at the Royal Academy of Art in The Hague, Netherlands, from 1960 to 1990, defines typography as “writing with prefabricated characters.” Peter Bil’ak, founder of Typotheque, notes that this “implies a complete distinction from lettering, handwriting or graffiti, which are also concerned with creating letter-shapes, but don’t offer a repeatable system of setting these letters.”

It is quite common for people to refer to lettering as typography, but you should always avoid doing so when speaking with a client. Typography might be used in a logo, but so might custom lettering. Your client may not know the difference, but you do, and it’s important to have an educated client. This requires that we speak to them using the right terms, and it makes things easier to understand for both you and your client.

In addition, as designers of any sort, we strive to maintain a high level of professionalism, and using terminology correctly is an important part of showing pride in our line of work and being confident that we can do it, not simply to get the job done, but to produce excellent work.

What Is “Lettering”?

Lettering can be simply defined as “the art of drawing letters”. A lot goes into making lettering look right, and that’s an entirely different topic, but the concept is very simple: a specific combination of letterforms crafted for a single use and purpose as opposed to using previously designed letters as components, as with typography. Often lettering is hand-drawn, with pens, graphite or brushes, although some people start their work directly in Adobe Illustrator. Engraving and similar arts are related to lettering.

New York script by Simon Ålander.
New York script by Simon Ålander.

Just as typography is not lettering, lettering is not typography. Widely respected lettering artist Jessica Hische gave a talk on the subject at the FRONTEND 2011 conference, for those who “don’t understand the difference between lettering and type,” getting into the pertinent information with some concise definitions at around &frac34; the way through the video.

Typography does indeed have similarities to lettering — it is still dealing with letters, but within the context of typefaces and their proper use. Therefore, it’s not a good idea to refer to typography as lettering, since they have different connotations and you don’t want to confuse your client by swapping terms. Again, accuracy in terms is an important element in any profession and design is no different.

Similarities And Differences

The visual concepts that are behind typography and lettering are largely shared by both disciplines. Letterspacing, consistent weight and contrast, the rules that we go by for what works and what doesn’t work, still apply. However, often the terms used are different. For space between two lines of text that are typeset, we use the term “leading,” referring to the strip of lead that printers would set between the lines of type to give more space. The same concept applied to lettering would simply be called “line spacing.”

Upper case of type containing uppercase glyphs.
“Upper case” of type containing uppercase glyphs. (Image: Marcin Wichary)

The space between letters is also an important concept, and lack of attention to it is responsible for much of the bad typography we see today. When working with type, we call adjusting the horizontal space between characters “kerning,” but this is a modernized understanding of the term. In typesetting, a kern is part of a glyph that extends beyond the type block on which the character is molded, e.g. the terminal of the “f” in the image below.

A kerned f type block.
A kerned “f” type block.

In lettering, however, avoid referring to this as kerning. Rather than saying that the “A” and the “V” could be kerned, we could say that the space between them could be tightened up.

Typography is used for endless applications, from titles to body text, some of which present a myriad of typographic considerations that those concerned with lettering will not have to think about. Lettering is almost exclusively used as display text — imagine lettering a few paragraphs of text by hand!  Calligraphy is a much more likely to be used in longer passages of text. While calligraphy and lettering are once again related, there is a fundamental difference between the two that I’d like to point out.

Calligraphy is based on penmanship; it’s essentially “writing letters.” Lettering, on the other hand, is based on draftsmanship, i.e. “drawing letters.” Persevering calligraphers and scribes have famously done books as long as the Bible, which are incredible works of art in their own right (e.g. the Lindisfarne Gospels, the Book of Kells), but those were a lifetime endeavor, and for practical purposes we now use typefaces. Whew!

Illuminated (lavishly decorated) lettering in the Lindisfarne Gospels, from the Gospel of Mark.
Illuminated (lavishly decorated) lettering in the Lindisfarne Gospels, from the Gospel of Mark. This particular page showcases a lettered portion as opposed to a calligraphic passage, i.e. drawn rather than written. (Image: manuscript_nerd)

The differences, in the modern digital age, are sometimes theoretical, but the practical differences are huge — nobody wants to hand-letter 500 pages!

Some tenacious calligraphers, however, have undertaken monumental projects, such as the St. John’s Bible, a modern manuscript completely written and illuminated — a calligraphic term for embellishing — by hand. It took about 13 years, from commission to completion, using traditional techniques such as quill pens and manually-applied gold leaf, and cost an estimated $8 million. The incredible proportions of this project are a testament to the beauty of traditional techniques, but also a reflection on how printing and typography have changed the world.

Historically Speaking

The arts of both lettering and calligraphy have been around since time immemorial. Spoken languages quickly developed writing systems, which were then used to communicate through a more enduring medium than speech. Lettering and calligraphy evolved alongside each other, along with other letter-related arts such as engraving. We can follow the progression, from the Rosetta Stone and ancient Roman inscriptions to the works of scribal art mentioned above and more. History has provided us with endless examples of lettering and calligraphy, by engraving, pen and brush.

Traditional Chinese Calligraphy.
Traditional Chinese calligraphy. (Image: Terry Madeley)

Although very few people could read, and writing was relegated to monasterial and royal scribes through the Middle Ages in Europe, we have some awe-inspiring work from that period. Unfortunately, we often overlook the beautiful calligraphy and lettering that was being done in Asia and the Middle East, where an education in the arts was much more accessible. Both lettering and calligraphy have thrived in the eastern hemisphere and continue to be a source of inspiration today.

Calligraphic art in the Hagia Sophia, Istanbul.
Calligraphic art in the Hagia Sophia, Istanbul. (Image: Simona Scolari)

When Johannes Gutenberg built his printing press around 1439, the concept of typography, which had been developing slowly, was revolutionized. The moveable type system, metal alloy and casting methods gave the world a practical solution to printing. This gave rise to the discipline of typography as we know it, with kerning, leading and the terms we still use today. Each letter had its own type block on which it sat, and typesetters would arrange the type character by character.

Inside a Gutenberg Bible.
Inside a Gutenberg Bible. Note the mixed use of blackletter typography and hand-lettered drop caps, mimicking the contemporary German calligraphic style. (Image: jmwk)

Typography was, and has continued to be, primarily the skill of setting type. It was a very time-consuming process, and people were constantly trying to find ways to streamline it and increase production rates. Standardized methods for arranging the glyphs so their positions could be memorized and picked up by the typographer without having to look were developed. This gave us our terms for upper case and lower case characters, because an upper case, or drawer, typically contained the capitals and the lower type-case the minuscules, before the California Job Case, popular in the United States in the 19th century, combined both levels into one larger case.

A chart displaying the layout of the California Job Case method for arranging type.
A chart displaying the layout of the California Job Case method for arranging type. (Image: Marcin Wichary)

Leaving typography at this point in its development, I’ll follow the progression of lettering and calligraphy. During this period of experimentation with printing, calligraphy still played a huge role in communication, and the educated would write in a hand that amazes us today as to the beauty and accuracy of their manuscripts. Swashes, ascenders and descenders wove themselves into amazing patterns and borders, sometimes all but obscuring the text itself.

Ornate sample of penmanship by Jan van de Velde, Amsterdam, 1609.
Ornate sample of penmanship by Jan van de Velde, Amsterdam, 1609.

Lettering and calligraphy followed cultural trends, leaving the Rococo era and becoming more sober during the early 19th century, only to flower into ornament once again through the Victorian era and the florid shapes of Art Nouveau. The worlds of type and lettering constantly intermeshed. Many people, such as Oswald Cooper, achieved respect for their lettering and were hired by type foundries to design new typefaces.

Title pages from German avant-garde publications Dekorative Kunst and Pan, examples of lettering during the Art Nouveau movement.
Title pages from German avant-garde publications “Dekorative Kunst” and “Pan”, examples of lettering during the Art Nouveau movement.

Lettering figured strongly through Art Deco and Modernism, for posters and ads, logotypes and book covers. The relatively recent art of film titles also provides us with a wide range of illustrative lettering styles from the 20th century. Coming out of the Modern era and through the latter half of the 20th century lettering went through a variety of permutations — the organic styles of the 70′s, the new modernism of the 80′s, and the grungy 90′s styles aforementioned — bringing us to our modern lettering scene, with a smorgasbord of visual references to every period of history imaginable. Designers such as Herb Lubalin and Doyald Young, the metaphorical giants of lettering, have left a huge legacy from this time period.

Lettering by Herb Lubalin displaying his studio address.
Lettering by Herb Lubalin displaying his studio address.

Here I will step back in time to pick the thread of typography back up. The development of techniques continued through the 19th century, and printing played an important role in world history, such as Benjamin Franklin’s publications and Thomas Paine’s printed materials — The Rights Of Man, Age Of Reason, et al — that were instrumental in the American Revolution.

Meanwhile, after many inventors had tried and failed to create a practical typesetting machine, Ottmar Mergenthaler succeeded in building the linotype machine in 1884, which revolutionized the newspaper industry. I won’t say more about it here, but if you’re interested in the history of typography, I would highly recommend taking a look at the documentary Linotype: The Film. This is not a sponsored statement, I simply enjoyed the documentary immensely and you may want to check it out!

A look at a linotype machine.
A look at a linotype machine. (Image: Marcin Wichary)

The linotype was just one of the machines used to expedite the typesetting and printing processes, and although some people still hand-set type, the industry as a whole was continuously changing to introduce faster and better techniques. Typography was explored in the various art movements, from Dada to Modernism and beyond, rethinking ways in which type could be used and given expression and meaning. As typography, experimental and traditional, progressed, the techniques segued to phototypesetting and from thence to the digital age in which we find ourselves today. Typography as a discipline looks very different than it did 50 years ago. Instead of setting metal type and locking in forms, we use panels in Illustrator or InDesign to kern, add leading and align our type.

Lettering has also moved into the digital format in which we enact most of our design work. Many artists, however, stay true to analog media by hand-drawing lettering.

Lettering by Tom Lane for Hook & Irons.
Lettering by Tom Lane for Hook & Irons.

The digital amalgamation has been largely responsible for the confusion of lettering and typography, since they are now often created using the same programs — the difference between the two is no longer the difference between a brush and a letterpress machine, or a drafting table and linotype matrices. However, lettering and typography are still different concepts, and understanding them and their similarities and differences will help us become better designers.

Getting Started On Your Own Hand-Lettering

For those looking to begin creating hand-lettering of their own, it can feel a bit daunting. The letterforms that we see so often prove very difficult to draw freehand. Thankfully, there are a lot of tips and tricks you can use to familiarize yourself with the process and learn how to create pleasing compositions.


Get some tracing paper, and print out samples of well-known typefaces. Trace them over a few times, letting your hand become used to the lines that type designers have carefully worked over and revised until they were perfect. Some good ones to start with are time-honored classics such as Garamond and Caslon, or exceptional recent works such as Okay Type’s Harriet. Avoid using free fonts, since they are often poorly crafted and wouldn’t provide a good model. This allows you to train your eye and hand using the work of masters.


Read voraciously! I’ve listed a number of resources at the end of the article for you to check out — books, blogs and other resources. Knowledge is power, and understanding principles behind type design and letterforms help you develop your eye.

Photo Safari

If you live near a town with a historic district or old buildings, make a point to spend a few hours on a weekend just walking around and finding samples of good typography and lettering. You can find great examples in outdoor signage, whether lighted signs, painted or vinyl. Often there are huge letters painted on brick walls at old factories or restaurants. Then, use your photos as models to draw historic styles of lettering.

Use a Grid, but Don’t Use a Grid

When lettering, you’ll find that perfect measurements often don’t actually look “right.” Draw lines to help yourself keep a consistent stress and even weight throughout your lettering, but trust your eye rather than the grid if something doesn’t look quite correct. This is particularly true if you’re doing something with a curved baseline. Remember, you’re making this to be seen, not measured, so perception trumps geometric perfection.


Here are a few resources that I have found to be particularly helpful, concerning both lettering and typography.


  • Dangerous Curves, Doyald Young
    This volume showcases some of the best work over Young’s illustrious lettering career, including rejected logotype options and in-process sketches.
  • Scripts, Steven Heller and Louise Fili
    From two of our contemporary design landscape’s most respected proponents of lettering and type comes a “veritable festival of rare and unknown scripts.”
  • Typography Sketchbooks, Steven Heller and Lita Talarico
    Heller teams up with Talarico to present a look inside the minds and processes of more than 100 esteemed letter-lovers.
  • Designing Type, Karen Cheng
    Cheng walks us through a semantic look at the rationale and aesthetics behind the typefaces we see and use regularly, replete with diagrams and illustrations.


  • Typeverything
    A tumblog of lettering and typography, curated by some of the most respected current lettering artists.
  • Calligraphica
    Another Tumblr website showcasing calligraphy of all styles and languages, again curated by amazing calligraphers and letterers, including some of those involved in Typeverything.
  • I Love Typography
    In-depth blog posts about type history and lettering, interviews with type designers, updates on upcoming type-related publications — ILT provides a good read for serious letter lovers.
  • We Love Typography
    Compiled by typographers and designers of all sorts, another showcase of type and lettering with styles for everyone.
  • Beautiful Type
    This site isn’t updated terribly often, but whatever and whenever they do post, it’s inspiring!


Here are a few portfolios from great lettering artists that have inspired many:

In Summary

Hopefully this dissertation on lettering and typography has enhanced your knowledge of design and will further equip you to improve your skills. Lettering and typography, so similar yet so diverse, are a huge part of design and thus deserve our full understanding.


© Joseph Alessio for Smashing Magazine, 2013.


Frank: A Free WordPress Theme Designed For Speed


Today we are pleased to release Frank, an open-source WordPress theme designed and built to provide a light, responsive and unobtrusive reading experience. The theme’s default home page makes 9 database queries and consists of 2 requests weighing at roughly 30KB (9.5KB gzipped). Frank keeps it basic: no Javascript dependence, no unnecessary images, just a simple, no-frills, fast blog theme. The theme is introduced by its developer, P.J. Onori. —Ed.

Frank is a responsive WordPress theme. It uses a modified version of the Foundation grid system. It also offers the unique feature of a modular home page layout system. The theme comes with various different layouts for your home page (1 column, 2 column, 3 column, 4 column, etc.) that can be mixed and matched. This allows for a home page with different content sections in different layouts.


With intense use of HTML5 and CSS3 Frank cuts down on complexity and improves performance. Frank works decently on Internet Explorer 8+. However, at the moment no guarantees are given for any earlier IE versions. It is packaged with the parent theme (in the frank directory) as well as the child theme (in the somerandomdude directory) which I use for my own site. By using Frank, my home page weighs in at 43.65KB over 6 requests (Google Analytics accounts for ~15.5KB and 3 requests). In addition, 33.78% of global page loads completely within 1 second or less (55.75% in the US). On Google Page Speed, the demo gets an overall PageSpeed Score of 97 (out of 100).

Also, Frank uses a subset of Foundation to provide a responsive layout for desktops, tablets and phones. Add this to the theme’s small footprint and you have a mobile-optimized blog. The theme is 100% open source and developer-friendly. The parent theme (/frank) is released under the GNU Public License and the child theme (/somerandomdude) directory is released under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Demo and Downloads

You can check the live demo of the theme.


Why Did I Make Frank?

There are three reasons:

The first reason was to make good on a promise. I made the commitment that everything I created on my site would be open source. That is how Iconic was born, and this is how Frank came to be. My site is now 100% open source.

The second reason is that I believe that speed is an essential part of user experience. I wanted my site to reflect that belief.

The last reason is that WordPress has an unfair reputation of being a slow, resource-hungry blogging platform. Make no mistake, WordPress can be slow, but that is often due to poor use. I wanted to make a WordPress theme to break the unfair stereotype.

Frank shines for sites that need a no-frills blog that focuses on the reading experience. Frank is not for everybody, but it shines when used in its sweet spot.

Reading Experience: Example

Future Development

Frank is ready to be used, but there is still a long way to go until it’s in tip-top shape. This theme can and will get faster. Here’s what is currently being worked on.

  • Greater typographic and visual polish
  • Increased CSS optimization
  • HTML cleanups and structural improvements
  • Modernization and optimization of Javascript components
  • Improved organization and structure of SCSS files
  • Developer-friendly build tools
  • Guides for optimal use of Frank


This theme was built with significant help of some great folks. My sincere thanks to Felix Holmgren, Jon Christopher and Josh McDonald for their tremendous contributions.

(ea) (vf)

© P.J. Onori for Smashing Magazine, 2013.


Killing Contracts: An Interview With Andy Clarke


Editor’s Note: Andy Clarke is known for his design work, books, conference presentations and contributions to the design community. Over the last 14 years, he has designed for amazing clients, written two books, and has given over 50 conference presentations and hosted workshops and training events for Web professionals all over the world.

Andy Clarke
Image by Geri Coady.

Do you remember those “10 Useful Legal Documents for Designers?” Well, it turns out that you, designers who read Smashing Magazine, liked one in particular: a plain-language, straightforward “Contract of Works for Web Design,” which is based heavily on Andy Clarke’s “Contract Killer”. Since Mr. Wong published that template ten months ago, more than 1,600 designers have downloaded it on Docracy alone.

Why is this legal template so popular? Does it really work better than other contracts? Can it help you close that job faster and protect you from getting stiffed? Could it become an industry standard, like grid systems and agile development? Could it help designers save money on legal fees? Who better than Mr. Andy Clarke himself to answer these questions!

Question: Hi, Andy. Your company is called Stuff and Nonsense. That’s how many people would define contracts. Why do you think contracts are often unreadable and puzzling, and what brought you to write your own model from scratch?

Andy: Being at best obscure or at worst intentionally misleading is precisely how many people view contracts. That’s likely because the contracts we are so often asked to sign have been written in language that’s unfamiliar to most of us. You might think that contracts must be written this way, but they don’t. Contracts can be written in any style you like, in language that’s as formal or as informal as you are. Use your contract to set the tone for the relationship with your clients. Of course, you’ll need to cover all the issues, but there’s no reason you can’t do that while still being you.

I appreciate plain speaking, and I try to be as direct as possible in the way that I talk with my clients. Over the years that I’ve run Stuff and Nonsense, I’ve seen a lot of contracts, and none of them either had my “voice” or covered the specific aspects of Web design or development that are important to my work. I was frustrated with what I found, so I sat down one day to write my own contract, the “Contract Killer,” and published it for anyone to use.

That was, amazingly, four years ago, and although some of the details of that original Contract Killer have changed, the fundamental principles have stayed the same. That’s because many of the issues that designers and developers and our clients face have also stayed the same. Still, in the latest version, Contract Killer 3, I’ve made some changes to reflect what many of us are doing now, particularly in relation to responsive and mobile design.

Battle of forms.
Conflicting terms of standard form contracts often result in legal disputes. Image by Steve Snodgrass.

Question: How do clients react when you send them the Contract Killer? Do you ever have to fight the “battle of the forms”?

Andy: The original reaction to Contract Killer was astonishing, and over the last four years the feedback I’ve received from designers and developers has been overwhelmingly positive. I know of some people who say that the contract has helped them get work. Many use Contract Killer out of the box, while others include their own payment terms and copyright assignment. Some have added whole new clauses — for example, about termination. I feel very, very happy that so many people have found Contract Killer useful.

Reaction from my own clients has been overwhelmingly positive, too. No one has ever refused to sign it, and no one has asked for it to be replaced with another contract. In fact, the simple straightforward language has encouraged my clients to sign and return it faster than any other contract I’ve ever used. I guess that’s because being clear means there’s less need to check with a lawyer.

Question: You’ve been using this contracts for years now. Has it held up? Did you find some edge cases that exposed certain weaknesses? And, if so, how did you fix the problem?

Andy: I’ve used Contract Killer with every client for the last five years. Occasionally I’ve made changes to specific clauses — often around copyright assignment — when clients have requested that. But you know what? That’s OK. A contract is just another point for us to communicate — in this case, negotiate — with our clients. Changing a few words doesn’t matter much. How we handle changing those words matters a lot.

I’m now much more explicit about the fact that browser testing is about ensuring that a person’s experience of a design should be appropriate to the capabilities of the browser or device they’re using and that websites will not look the same in browsers of different capabilities or on devices with different-sized screens. I’m also particular about the desktop and mobile browsers I test on, although I know this will vary between designers and developers.

Question: Do you have any tips on how to use a contract as a communication tool? For example, how do you handle a client who requests an overly broad license?

Andy: Many clients, too many in fact, know little about what’s expected or involved in a successful Web project. They may have had a poor prior experience, so even if they don’t come right out and say it, they’re looking to you to show them how it’s done. Your contract is a great place to start showing them how you do business. Handle this stage well, and your project will run much more smoothly. Let’s look at an example from Contract Killer 3, the copyright ownership clause:

We’ll own the unique combination of these elements that constitutes a complete design and we’ll license that you, exclusively and in perpetuity for this project only, unless we agree otherwise. We can provide a separate estimate for that.

It’s a fair clause that’s designed to prevent a client from using and reusing the work for other projects without agreement. This means that if you design an e-commerce store for them, they can’t launch a second site using the same design. This is a sticking point for many people, who wrongly expect that they will own the rights to everything they pay you to produce for them for any purpose.

When this happens, explain the good reasons why the clause exists and, if it’s appropriate, offer them a new price that includes complete ownership and that reflects its potential value to them in the future. Don’t be afraid to stick up for what you’re asking, and always, always remember, this is your contract that you’re asking them them to sign. Make it work for you.

Make your contract work for you. Image by Steve Snodgrass.

Question: In Contract Killer 3, you argue against fixed pricing, but you also promise flexibility. Can you explain how to negotiate a pricing scheme with a client who prefers fixed pricing or insists on a cap?

Andy: Fixed or project-based pricing has its roots firmly planted in the old-fashioned waterfall development process. But many people, including me, have moved to a more agile-based way of working. In an agile workflow, change is embraced, even encouraged. This means that fixed-price contracts quickly become irrelevant because if the requirements change, the price might change, too.

I organize my projects into week or two-week long sprints. Each sprint has a theme, a set of requirements that I’m going to finish during the period. It might be a sign-up process one week and a shopping cart the next. We’ll cover all the areas of a project across these sprints; and because the client knows the price in advance, he or she can budget. If a client has a great idea for something new or wants to change their mind, no problem. I roll up those requests into another sprint week, and the client can then make a business decision about spending money on those items.

Question: Have you ever faced a situation in which a client was asking for too many changes, one after another? How did you deal with that?

Andy: Several years ago I worked with an agency on a new site for a travel company. The agency had negotiated the price with its client, and I worked on a fixed price. Although the agency had drawn up the original brief and I followed that up with my own scoping meetings, things quickly went downhill as the client flip-flopped through ideas and change requests that were costly and complicated. I tolerated the situation as long as I could, but it became apparent I was making a loss on the project, and I withdrew.

This problem arose not because the client changed their minds — no, that shouldn’t ever be considered an issue; in fact, it should be encouraged — but because the agency and I were working to a fixed price. This left everybody with a bad taste in their mouth. Had we all worked in the agile way I just described, changes would never have been an issue, and it’s likely the project would have been a success, rather than a failure.

Question: What are the top three things a designer should keep in mind when preparing or reviewing a contract?

Andy: First, and possibly most importantly, you should ask your clients to sign a contract every time you work with them. It doesn’t matter whether they’re a first-timer or you’ve worked with them a dozen times: it’s vital that you agree on the scope and terms of the work. It took a while, and one or two unfortunate experiences, for me to learn that contracts are intended to set out what both parties should do.

Make the contract your own. It’s great that people like Contract Killer so much that they’ll use it out of the box, but your contract should be in your voice, not mine. Use the writing of a contract as an opportunity to put your personality into your paperwork. There’s no reason why a contract shouldn’t be funny and a joy to read. After all, you want someone to sign it.

Lastly, take the time to tailor a contract to a particular client and project, and make sure you’ve addressed everything you’re going to do for them. If you get a hint of any potential issue — for example, that they personally use an old browser or device — write about how you’ll handle that in your contract.

Stuff & Nonsense
Stuff & Nonsense – amazing design work for amazing people.

Question: Despite the saying, the client is not always right. How can you say that to them without being the a*shole?

Andy: No one, no matter who they are or what they think, is always right. (Well, except my wife. She’s always right about everything. Obviously.) One thing I’ve learned over the years is that clients love to feel involved in the design process. Sometimes, though, they make suggestions only so that they feel they have put their stamp on the project. There are simple ways that designers and developer can prevent this from happening. This is something I wrote about recently for Smashing Magazine:

  • Don’t email pictures of websites to your clients and then ask for their “thoughts.”
  • Don’t wait until after weeks of work to have a “big reveal.”
  • Set up the proper environment to receive structured feedback, and then ban all unstructured feedback you might receive by telephone or email.

Please remember: you are the designer. You are the person who has been hired to solve a problem that the client either can’t or doesn’t have the time to solve themselves. Your solution to that problem is worth a lot to their business, so never underestimate your role, skills and influence in the design process.

Question: I hear you are working on a “Killer NDA” (non-disclosure agreement). Sounds great.

Andy: Writing a Killer NDA has been on my mind for a while, as I’ve been asked to sign some horribly confusing examples over the years. I have no idea why NDAs have to be so complicated; after all, their intent is to make sure that everything that’s shared stays secret.

I’ve called this contract “Three Wise Monkeys” — see no evil, hear no evil, speak no evil. Three Wise Monkeys deals with just three things:

  • What’s confidential?
  • What can we say?
  • How long does the agreement last?

You can read it here. It’s licensed under Creative Commons 3.0, so if you want to personalize it, you can do so. It’s also on GitHub and Docracy.

Andy's Three Wise Monkeys contract.
Simple is good. Andy’s “Three Wise Monkeys” contract deals with just three things. Image by Anderson Mancini.

Question: Last question: who are the “men with big dogs” referenced at the very end of your contracts?

Andy: I’m not afraid to say that on several occasions we’ve been forced to hire a debt collection agency to recover our money. On one occasion, we hired a debt collector from the client’s town, because we knew he would be ashamed if it became known locally that he was a bad payer. There’s no excuse for late or non-payment, and you should never be apologetic about wanting your money. Always remember, if you’ve done the work, you deserve to be paid. So, when all else fails, hire a professional. Preferably one with a big dog.

Have you used Contract Killer or a version of it? Share your experience in the comments!

© Veronica Picciafuoco for Smashing Magazine, 2013.


Implementing Off-Canvas Navigation For A Responsive Website


The varying viewports that our websites encounter on a daily basis continue to demand more from responsive design. Not only must we continue to tackle the issues of content choreography — the art of maintaining order and context throughout the chaotic ebb and flow of the Web browser — but we must also meet the expectations of users. They’re not sitting still.

With the likes of Firefox OS (Boot to Gecko), Chrome OS and now Ubuntu for phones — an OS that makes “Web apps” first-class citizens — delivering native app-like experiences on the Web may become a necessity if users begin to expect it. Many in our field have argued for a degree of separation between the Web and native platforms for both technical and philosophical reasons. They’re certainly wise to heed caution, but as consumer devices continue to blur the boundaries, it’s worth thinking about what we can learn from native app design.

A Demonstration

In this article, I’ll be walking through a build demo that centers on two topics. The first is responsive design patterns that embrace the viewport and that improve content discoverability beyond the basic hyperlink; in this case, off-canvas navigation. The second is the complexities of implementing such ideas in an accessible and highly performant manner. These are two topics that I believe are at the heart of the Web’s future.

With that in mind, let’s get building.

The Accessible Base

All good things begin with a solid foundation of semantic HTML and widely supported CSS. In theory, this baseline should function as a usable experience for all browsers that visit our website. (It might also be the final experience in less-capable browsers.)

As a starting point, I’ll use a technique very similar to Aaron Gustafson’s “Smart Mobile Navigation Without Hacks.” It requires no JavaScript to function.

Responsive Off-Canvas Menu Demo 1
Step 1 of the responsive off-canvas menu

  • View demo 1
    Be sure to view on a mobile or small screen, and take a while to inspect the code. Although our final design will be significantly different, starting simple is vital; retrofitting accessibility isn’t trivial.

The HTML body looks like this (I’ve stripped a few attributes for semantic clarity):

<header id="top" role="banner">
    <h1>Book Title</h1>
    <a href="#nav">Book navigation</a>
<nav id="nav" role="navigation">
        <li><a href="#">Chapter 1</a></li>
        <li><a href="#">Chapter 2</a></li>
        <li><a href="#">Chapter 3</a></li>
        <li><a href="#">Chapter 4</a></li>
        <li><a href="#">Chapter 5</a></li>
    <a href="#top">Return to content</a>
<article role="main">
    <!-- [main content here] -->

You could consider the HTML alone, with little to no styling, as being “breakpoint zero.” If it’s not logical at this stage, then accessibility will not improve.

Demo 1 Breakdown

  • Media queries are based on a viewport width of 45em (that’s content-dependent). Above this breakpoint, the navigation is permanently visible. I prefer em units because they allow breakpoints to maintain a relationship with text size. Lyza Gardner explains in detail in her post “The EMs Have It: Proportional Media Queries FTW!
  • I’m using both min-width and max-width media queries to scope CSS. This adds a bit of complexity. Most people prefer a “mobile-first” build, using only progressively larger min-width queries. The downside with that technique is the amount of resetting required if an element has noticeably different visual states. Neither method is right or wrong.
  • The crux of this initial stage is the :target pseudo-class selector, utilized to show and hide the navigation. Only IE8 and lower lack support. However, this is a non-issue if you serve a semi-fluid desktop style sheet to old IEs. Jake ArchibaldNicolas Gallagher and Stuart Robson can tell you more.

As the demo takes shape, I’ll continue to introduce the main development principles. There’s a long way to go yet…

Going Off-Canvas

For some websites, the above may suffice — but not for us! We’re experimenting with off-canvas patterns and striving for that native experience. Because we cannot ignore older browsers, it’s now time to progressively enhance.

Responsive Off-Canvas Menu Demo 2
Step 2 of the responsive off-canvas menu

  • View demo 2
    You will see the restyled navigation with basic functionality.

Demo 2 Breakdown

  • I’m adding the class js-ready to the document element after the DOMContentLoaded event fires. The selector .js-ready is used as a hook to safely restyle the navigation off-canvas. If for whatever reason JavaScript doesn’t load, then the original functionality from demo 1 still exists.
  • To show and hide the navigation, I’m toggling a class of js-nav on the document element when the user clicks (or taps) the relevant buttons. This simply applies a style of left: 70% to the #inner-wrap element (#outer-wrap is used to hide any overflow and to avoid scrollbars).

This is a fairly basic enhancement, but importantly it remains usable before JavaScript is ready. It’s also notable that no inline styles are written with JavaScript; only classes are used to manage states.

Jumping between open and closed navigation states makes for a jarring user experience. Users need to understand — or even see — how an interface has changed. This is often the point where developers let the Web down. To be fair, building user interfaces is incredibly difficult. What I’m going to show below is far from perfect, but it’s certainly a step in the right direction.

So, we have the set-up. Now let’s add transitions.

Transitioning (The Wrong Way)

I’ll start by getting it all wrong, because this is how I would have done it a few years ago, and learning from mistakes is important.

Responsive Off-Canvas Menu Demo 3 (jQuery)
The responsive off-canvas menu using jQuery .animate for transitions

jQuery is a resource that many front-end developers begin with to learn JavaScript. Personally, I am a big fan (never blame the tools), but unfortunately jQuery has a habit of making things look deceptively simple. It masks complexity and, with that, understanding.

Transitioning our off-canvas navigation with jQuery is very easy:

$('#nav-open-btn').on('click', function() {
    $('#inner-wrap').animate({ left: '70%' }, 500);

$('#nav-close-btn').on('click', function() {
    $('#inner-wrap').animate({ left: '0' }, 500);

Visually, this achieves the effect we’re after, but test it on mobile and watch the frame rate stutter. Performance is dreadful.

This method is bad for several reasons:

An animation of jQuery updating the DOM

  • jQuery’s .animate increments the element’s style attribute on every animation frame (as can be seen in the GIF above). This forces the browser to recalculate the layout.
  • It leaves inline styles in the DOM that have very high specificity and that will override our well-maintained CSS. This is a big issue if the viewport is resized and triggers different breakpoints.
  • A separation of concerns is lost because styles are defined in JavaScript files.

Overall, it’s a performance and maintainability nightmare. There is a better way.

Transitioning With CSS

Putting the jQuery experiment aside, I’m now building from the second demo again, this time using CSS transforms and transitions. These enable us to smoothly animate the off-canvas navigation with great performance.

Responsive Off-Canvas Menu Demo 4
The final responsive off-canvas menu using CSS transforms and transitions

  • View final demo
    Performance has drastically improved compared to the jQuery example.

Final Demo Breakdown

  • Returning to CSS, I’m once again using the .js-nav class to toggle the navigation, while making no actual style alterations with JavaScript.
  • I’m progressively enhancing with the classes .csstransforms3d and .csstransitions (applied to the document element by Modernizr).
  • Instead of moving the navigation with negative positioning (left: -100%), I’m using the transform property: transform: translate3d(-100%, 0, 0).
  • CSS transitions are used to animate transform changes: transition: transform 500ms ease. And I’ve added a few more transforms to enhance the visual effect.

With the help of Modernizr, this will fall back to demo 2 if browser support is lacking for CSS transforms and transitions. (In theory, I could fall back to jQuery animation, but it’s really not worth it.) When you download Modernizr, you can include only the feature detection that you need. It also includes the HTML5 shiv for IE. All in all, it’s a very useful script.

The benefits here are immense. First and foremost, by transitioning elements with 3-D transforms, the browser can generate render layers that are hardware-accelerated. Secondly, there’s no need for JavaScript to worry about style or media-query breakpoints. JavaScript need only interpret user interaction and apply classes to maintain states — CSS defines the visual changes.

We can look deeper into performance by using Chrome’s Developer Tools. The results below are from the desktop browser, but for mobile performance you could use USB Remote Debugging on Android devices.

jQuery Animation Performance

jQuery animation performance in Chrome Developer Tools

The four events above represent the opening and closing of the navigation twice. In the diagram, yellow represents the JavaScript running, purple is the rendering (recalculating the style and layout), and green is the painting to the screen. On mobile, we’d be shooting way below that 30 FPS line. I also tested on an iPhone 3GS and could literally count 3 FPS with my own eyes — it’s that slow!

CSS Transition Performance

CSS transition performance in Chrome Developer Tools

What a difference! The only JavaScript that exists is there to manage user interaction before and after the transition. The green we’re seeing is the minimum that the browser needs to repaint the transition at a respectable frame rate, using GPU acceleration.

Possible Concerns

As with all new Web standards, nothing is inherently perfect.

In WebKit-based browsers, the font smoothing may switch to antialiased from the default subpixel-antialiased when CSS transforms or transitions are applied. This could result in visually thinner text, which many designers actually prefer — but not something you should “fix.”

Flickering can also occur if an element goes between transform and no-transform. To avoid this, always start with a default like translate3d(0,0,0) on an element that will move later, so that the render layer is composed and ready.

The Next Step

Enhancing further, we could detect and take advantage of touch gestures, like swiping, to really bring this implementation closer to par with its native counterparts — “closer” being the operative word, but I do believe the gap is closer than many would have us believe.

It’s also — in my opinion — a gap that we need to bridge.

There are other clever ways to increase interaction speed. Mobile browsers tend to wait around 300 ms to fire click events. Google’s Ryan Fioravanti has a great article on “Creating Fast Buttons” to reduce this latency.

Transition easing can radically change the visual effect and the user’s perception of what’s happening. Whether elements need to spring, bounce or accelerate into action, Lea Verou has a useful cubic bezier resource to generate custom easing functions.

Hopefully, this article has shown the improvements that can be made if we take extra care to understand the technology we’re using.

Download The Code

So, there we have it: a three-tiered responsive, interactive, off-canvas menu. I’ve set up a GitHub repository where you can view all the code. Have a play with it; there are a few bits and pieces I haven’t covered to avoid bloating this article.

Further Reading

To really understand why the techniques highlighted above are my preferred solution, I point you in the direction of these resources:


© dbushell for Smashing Magazine, 2013.


Using WP_Query In WordPress


If you’ve been around WordPress for a while, you’ll know how difficult it used to be to create lists of posts based on complex criteria while also conforming to WordPress’ standards. Over the course of a few years, the platform has come a long way. By using the power of the WP_Query class, we can lists posts in any way we want.

wp_query (1)

What Is WP_Query?

The WP_Query class is one of the most important parts of the WordPress codebase. Among other things, it determines the query you need on any given page and pulls posts accordingly. It also saves a lot of information about the requests it makes, which helps a great deal when optimizing pages (and troubleshooting them).

The other role of WP_Query is to enable us to perform complex database queries in a safe, simple and modular manner.


Throughout our interactions with this object, we are supplying parameters and using functions to reach our goal. The object’s internals take care of many annoyances, such as protecting against SQL injection attacks and making sure that proper data types are used.


The object abstracts much of the query complexity away so that we don’t have to muck about with the specifics of our database. Because we are using an array to supply our criteria, everything is more self-explanatory. No manual database joins or nested queries are needed — just create an arguments array and instantiate the class!


My favorite of all is modularity. When making raw queries, it is hard to manage those frequently used bits because they are just fragments of SQL code. WP_Query does away with this by using an associative array as an argument. A plethora of goodness ensues: you can merge arguments from different places, run array functions to your heart’s content and manipulate it in ingenious ways.

Getting Started

The “Regular” WordPress Loop

Let’s look at a regular loop first, and then create the same loop using WP_Query. Let’s assume that we’re coding in the category.php file.

   if(have_posts()) : 
      while(have_posts()) : 

         <h1><?php the_title() ?></h1>
         <div class='post-content'><?php the_content() ?></div>
   else : 

      Oops, there are no posts.


The Same Loop Using WP_Query


   $args = array('cat' => 4);
   $category_posts = new WP_Query($args);

   if($category_posts->have_posts()) : 
      while($category_posts->have_posts()) : 

         <h1><?php the_title() ?></h1>
         <div class='post-content'><?php the_content() ?></div>      

      Oops, there are no posts.


As you can see, there is not much difference at all! Let’s break it down:

  1. Constructing a query
    On a category page, WordPress already knows that you want to list posts from that category. Because we are constructing a query from scratch using WP_Query, we need to specify this ourselves. We’ll delve a bit deeper into this in a bit.
  2. Instantiating the class and querying for posts
    By instantiating a class with the constructed argument array, WP_Query will try to pull the posts specified and a load of other details.
  3. Creating a loop
    You can use all of the usual functions; just be sure to use them as the methods of your object:

    • Instead of have_posts(), use $category_posts->have_posts().
    • Instead of the_post(), use $category_posts->the_post().
  4. Resume business as usual
    Once you’ve done the above, you can use all of the template tags you’ve come to know and love.

If you look at this in detail, you will find that the global $post object is also available. This means that if you use a custom loop like this within another loop, things can go wrong. Be sure to store the original value of the $post object and restore it after the loop.

   $temp_post = $post; // Storing the object temporarily
   $my_query = new WP_Query();
   while($my_query->have_posts()) {
      // Loop in here
   $post = $temp_post; // Restore the value of $post to the original

Digging Deeper

The Power of a Good Argument

The ease with which we can create loops is obvious, but what about actually querying for posts? Let me show you a common technique I use when creating sliders for commercial themes.

In many cases, users of your theme will want a great-looking slider, but they might be a bit lazy in creating content. Many users will also want to show future content. Let’s query for upcoming (i.e. unpublished) posts that have an attached featured image.

   $args = array(
      'post_status' => 'future',
      'meta_query' => array(
            'key' => '_thumbnail_id',
            'value' => '',
            'compare' => '!='
   $slider_posts = new WP_Query($args);

<?php if($slider_posts->have_posts()) : ?>

<div class='slider'>
   <?php while($slider_posts->have_posts()) : $slider_posts->the_post() ?>
      <div class='slide'>
         <?php the_post_thumbnail() ?>
   <?php endwhile ?>

<?php endif ?>

Short, sweet and utterly understandable — just beautiful. And we’ve just scraped the surface.

Know Your Defaults

You may have noticed that I didn’t specify a number of things in my queries. What about how many posts to list? What about the post’s status in the first query we made?

Default values are supplied for many of the most common arguments. Here are a few that you don’t have to specify, unless you want to change them:

  • posts_per_page
    Defaults to the value specified in the reading settings for the number of posts to list.
  • post_type
    Defaults to post.
  • post_status
    Defaults to publish.

You can find the complete list of parameters in the Codex, of course!

Arrays Are Awesome

In many cases, you will want to specify a number of values that an argument can take. Where it would seem logical, WP_Query usually allows you to use arrays to make your life easier. Here are a few examples:

  • You can use an array for post_status to pull posts from a number of different statuses. Note that you can use the string any to get posts from all statuses.
  • If you use custom post types, you’ll be happy to hear that you can use an array for the value of the post_type parameter as well.
  • For the taxonomy type parameters category__in, tag__in and so on, you can use an array to indicate a multitude of values.

Handling Taxonomies

WP_Query is nice enough to offer a simple way to make advanced taxonomy queries as well. This is especially useful for websites with complex set-ups and for commercial themes with large feature sets. The mechanism used is called tax_query. Let’s look at an example.

Say you have a website all about movies. You store movies in a custom “movie” post type; you have a custom taxonomy for genre, a custom taxonomy for actors, and you use the regular ol’ category to indicate how good a movie is. Let’s find all “Action” movies starring “Bruce Willis” that aren’t “Bad”:

   $args = array(
      'post_type' => 'movie',
      'tax_query' => array(
         'relation' => 'AND',
            'taxonomy' => 'category',
            'field' => 'slug',
            'terms' => array('bad')
            'operator' => 'NOT IN'
            'taxonomy' => 'genre',
            'field' => 'slug',
            'terms' => array('action')
            'taxonomy' => 'actor',
            'field' => 'slug',
            'terms' => array('Bruce Willis'),

While this hardcoded example would be useful only to people who love Die Hard, it’s not hard to see how an advanced filter can be built that lets users filter through your content in any which way they want.

Learn more about all of the awesome things you can do with the taxonomy parameters in the Codex.

Having Fun With Meta Data

You’ve already seen that WP_Query is great at handling meta data — we used a meta_query in the second example to build a slider from posts that have featured images. Just as with the taxonomy queries, a lot of flexibility is built in here.

We’re currently building a WordPress theme to be used to create a Web page for apartment(s) for rent. We store apartments as a custom post type and use meta data to store the details. With a meta query, we can easily pull in all apartments that can house four or more people, that have a balcony and that are non-smoking.

   $args = array(
      'post_type' => 'apartment',
       'meta_query' => array(
         'relation' => 'AND',
             'key' => 'persons',
             'value' => '4',
             'compare' => '>=',
             'type' => 'NUMERIC'
             'key' => 'balcony',
             'value' => '1',
             'type' => 'BINARY',
             'compare' => '='
             'key' => 'smoking',
             'value' => '0',
             'type' => 'BINARY',
             'compare' => '='

Again, this is very modular, very understandable. To learn more about the parameters you can use, just visit the “Custom Field Parameters” section in the WP_Query documentation.

Methods And Properties

Once you’ve made a query, you can coax a lot of information out of your object. You can find a full list of “Methods and Properties” in the Codex. Here are the ones I tend to use most:

  • $query
    Shows you the query string passed to the $wp_query object. This is quite helpful for troubleshooting in some advanced cases.
  • $query_vars
    Shows an associative array of the arguments you’ve passed. If you do plenty of mixing and matching before passing arguments, this tool could be helpful indeed to check that all is well.
  • $posts
    Holds the requested posts from the database. I rarely use this property, but it’s good to know that this is where your items come from.
  • $found_posts
    A handy little thing that shows the total number of found items (without the limit imposed by the posts_per_page argument).

With Great Power Comes Great Responsibility

While WP_Query gives you plenty to play around with, it does have its drawbacks. Many people (my past self included) go nuts when they realize how easy it is to bang out queries all over the place.

Keep in mind that more queries mean more server load. I’ve found that on hosted systems, complex queries can be especially naughty because they eat at your RAM, which is probably your scarcest resource.

Make sure to check out what the default query holds on each page. What’s the sense in creating a new query for the latest posts on the front page if it’s there by default? Use what you can more than once, cache results, and so on.


© Daniel Pataki for Smashing Magazine, 2013.


Preparing Websites For The Unexpected


Designing websites for smartphones is easy compared to retrofitting those already in place. More than that, it’s embarrassing how, almost eight years after CSS gained practical acceptance, a lack of foresight haunts those of us who write HTML.

Converting older websites to responsive design causes headaches not because small screens are difficult, but because most HTML documents were written under an assumption about screen size. Prior to the iPhone’s introduction in mid-2007, designers could rely on windows at least 700 pixels wide (if they ignored accessibility). Conventions like navigation bars, two- and three-column layout and hover effects evolved to fit the mouse-based wide-screen standard. Designers made their upper left corner logos clickable because it was expected.

Mobile devices shake old habits in two ways. Now, not only do we have small-screen iPhones, Android phones, Kindles, iPads and other mobile devices, but we’re asking websites to adapt to whichever device comes knocking. You want CNN on an xBox? It could happen. You want Smashing Magazine on a Web-enabled TV? If it’s not here, it will be soon.

Designing for future cases affects both page layout and website structure. We can’t control on which devices our digital content is viewed — rather, experienced. No amount of “best viewed with…” badges will stop people from reading and remixing what we write, paint, compose or otherwise create. Web pages don’t have to use 12- or 16-column grids, and websites don’t have to follow strict hierarchies. But getting there means facing a legacy that did.

Mobile Is Also A Content Problem

Let’s say you’re employed by a large company. Surveys indicate that many customers are more likely to visit your website with a smartphone. The large company is planning a redesign of their existing site. Your organization (or more likely you and your Web-savvy coworkers) adopts a mobile-first strategy. Yet before sketching icons, perusing responsive grids or cramming HTML5, one fact threatens to derail the redesign project. The content isn’t just ill-formatted for small screens — it’s ill-formatted for anything other than desktop browsers less than 960 pixels wide.

  • Details in large images get lost when shrunk.
  • Layouts with more than two columns of text or nested columns compress poorly on narrow screens.
  • Wider ranges of text sizes do not fit well.

Exceptions compound the problem. WYSIWYG editors added their own formatting or layout to individual pages, and over time different people updated the website their own way.

Variations on a website make it difficult to fit everything into a mobile solution.
Variations on a website make it difficult to fit everything into a mobile solution.

The more pages a website has, the more likely it has variations. One solution does not fit all variations, especially when some were intended for a specific screen. We could divide ill-fitting pages into multiple pages for mobile devices, but not without consequences.

Dividing long content into multiple pages makes information harder to reach.
Dividing long content into multiple pages makes information harder to reach.

If designers choose extra pages over long layouts, then conventional structures make information harder to reach.

As an industry, Web design has met similar challenges before. Designers who practiced table-based layout may remember how headaches up front lead to more flexible code later. This time around, we can think beyond today’s move to mobile. Responsive design bridges the gap with use-case instructions. But designers themselves can do more than respond to today’s issues. They can anticipate tomorrow’s.

To ask “what makes content mobile-friendly?” misses the point. Ask instead, “what makes content flexible?” and we address many problems at once. The ideal solution meets a few criteria.

  1. Don’t sacrifice content for a new medium.
    We don’t want to offer a watered-down version of the original website.
  2. Make it usable.
    We don’t want to simply shrink layouts. Everything from text and images to navigation and forms must be easy to use.
  3. Prevent (or at least minimize) similar problems in the future.
    Twenty years ago people questioned the need for a website. Five years ago people questioned the need for a mobile website. What will they question tomorrow?

Layouts designed for larger screens often don't easily translate to mobile screens.
Layouts designed for larger screens often don’t easily translate to mobile screens.

Smaller and more narrow, today’s mobile screens need layouts composed for their distinctive sizes. The task gets harder when each page has columns or text sizes baked in. Once we commit to changing a website — whether our goal is to optimize for mobile or another reason — we must accept that change includes choosing what to save and what to delete.

Popularity, Priority And Vitalness

What content is worth keeping? Back up — what is content?

Traditionally “content” is the information that a website contains. But tradition also said designers could rely on windows at least 800 pixels wide.

To make digital content supple enough for mobile (and prepare for whatever comes next), a website needs focus. And to focus a website, we need to find its vital content.

“Vital” is a subjective measure of content’s usefulness to all parties concerned. It may take the form of text, images or video. It might cover many pages or just a few tweet-length sentences. But vital content is why the website exists. Content does not fill a website; a website is the stage on which designers present content.

While vital is not synonymous with popular, the two are related. Popularity is how the public ranks vital information against itself. Contrast that with priority, or which information the website’s owners consider most-to-least important. Owners may consider information important, but if end users don’t need it, it’s not vital.

The diagram for a fictitious bank website shows two questionable items, namely the staff list and the video. Each column shows how priority and popularity add up to overall importance.
The diagram for a fictitious bank website shows two questionable items, namely the staff list and the Karaoke video. Each column shows how priority and popularity add up to overall importance.

Factors that influence importance include:

  • Timeliness
    Does the information’s importance wax or wane over time? (e.g. seasonal events, latest updates, today in history, upcoming deadlines)
  • Proximity
    Does the information’s geography matter? (e.g. local sales, disasters, city or regional politics, concerts)
  • Scope
    Who does the information affect? (e.g. a circle of friends, special interests, hobbyists, the general public, veterans, newcomers)
  • Scale
    How big is the information? (e.g. width, height, duration, density)

If a bank’s annual retreat video goes viral — the one where its CEO reveals a lack of karaoke talent — then the video is popular even if the CEO is not. But the bank might place a higher priority on its low fees or savings options (certainly the CEO would.) Similarly, blogs tend to put their latest posts first, but a groundbreaking post from last month might still receive more attention than a minor post today.

Some websites — news or blogs, for example — provide vital content on the home page. But many home pages are not necessarily vital. Home pages with static content introduce a website and help people to choose which pages contain the information they want.

Importance may be subjective, but the need to prioritize is not. The bottom line is to keep information that is vital; question information that either is popular or has priority; archive and remove information that is neither.

Oddly enough, this doesn’t mean removing pages.

Tossing Out Pages And Content Blocks

When computers first gained graphical user interfaces, software engineers helped people make the transition from physical offices to digital files with the metaphor of a desktop. Folder icons represented groups of files; document icons had a dog-eared corner that’s still common long after it was no longer needed. Skeumorphic trash cans are still with us.

Likewise, Web pages were akin to pages in a book or magazine. But the analogy doesn’t fit modern websites, let alone websites for mobile devices. A page is not the smallest unit of information. Rather, websites are collections of useful or informative media which may be sorted into different screens (or sections, or blocks, or views — time will tell which term becomes popular).

The arrangement of blocks of content may change as needs vary.
The arrangement of blocks of content may change as needs vary.

Blocks of content may be arranged onto one or more pages as appropriate. Some even appear on several pages; navigation, for instance. Responsive design deals with adapting elements to their medium. The idea of “content blocks” goes further. Because each HTML document (formerly called “pages”) may contain many blocks, Web designers can use mobile devices’ limited screen sizes to their advantage.

Mobile or not, websites may be organized into hierarchies or other formats. But thinking of blocks rather than pages suggests a structure between pages. Because small screens can only show so much of a page at once, they actually reduce clutter. When spaced by gaps — visual pauses — people effectively scroll through “pages.”

Content can be spaced by gaps, or visual pauses.
Content can be spaced by gaps, or visual pauses.

Nothing says wide-screen websites can’t also organize views with space. But mobile devices’ limited viewing areas make them naturally suited to a more focused experience.

A mobile-optimized structure may result in less screens being needed to display content on mobile, compared to displaying the same content on desktop screens.
A mobile-optimized structure may result in less screens being needed to display content on mobile, compared to displaying the same content on desktop screens.

Traditional hierarchies branch from the home page (general overview) to sub-pages (specific information). But each page stands alone. A mobile-optimized structure, however, leans towards a “taller” arrangement in addition to hierarchies. Six mobile-centric screens provides as much complexity as eight screens arranged for desktop.

Ideas such as these demonstrate the power of creating content without a specific use. In fact, the more digital media we consider, the more flexible websites become.

Moving Forward

It’s impossible to predict what tech revolution will make mobile design feel antiquated, but we can take reasonable steps to ease the transition. Remember that the goal is not just to reinvent what you have, but to see it with new eyes.

  • Delete the website’s home page.
    (After saving a copy, of course.) Nothing helps find a website’s real introductory content like removing its assumed introductory page. On which page do you find content that introduces the website’s purpose? Can that replace or be combined with the home page?
  • Practice repurposing.
    As you rework individual pages, try it in different environments — and not just other Web browsers. How does the page respond to being emailed? Does it make sense when read aloud? Can it be exported to another CMS? Can it be pasted into Microsoft Word, printed and faxed? Don’t discount ridiculous scenarios. After all, a few years ago designing for 320-pixel-wide screens was laughable.
  • Consider variations of metadata.
    Titles, for example, may be used as standalone links. Take page titles. Even if “about us” is all the visual design needs, it may be insufficient on a Google result page. “About Acme Co’s commitment to quality anvils” is more than a title: it could also double as a link with enough information to decide if the page is worth a visit.
  • Find elevator pitches.
    In each page, seek one sentence that sums up the rest of the page. If there is none, the page may need to be reworked, disseminated into other pages or eliminated altogether. For example, the page you’re reading now has two possible summary statements: the first sentences of its second and fourth paragraphs.
  • Substitute suggestions for instructions in content.
    Sometimes information is created for a particular medium. A video may work best at particular dimensions or a long text file may be broken into chapters. But there’s no guarantee that someone won’t embed the video differently than intended, or that the long text will always be read on a Kindle. Instructions say “display content this way.” Suggestions indicate “this is what I mean.” <aside> and class="alignright" are suggestions open to interpretation. style="float:right" and table width="300" are instructions. Put another way, when was the last time you favored <font> tags written into HTML over font properties in a separate CSS file?

While each medium has unique traits which designers may take advantage of (such as a website’s hyperlinks, a video’s motion and linear path, Flash’s interactive animation, an eBook’s bookmarks, a tangible book’s ability to be shared by hand), the cost of porting information between media increases the more we target a few specs on a single platform.

In years past, Web designers laid out pages according to monitors of the day. That hampers today’s move towards mobile websites. If we learn from past mistakes we’ll be better prepared for the next revolution.


© Ben Gremillion for Smashing Magazine, 2013.


iOS Prototyping With TAP And Adobe Fireworks (Part 1)


One of the strengths of Adobe Fireworks lies in its ability to produce basic-level prototypes in HTML format for the purpose of sharing concepts, evaluating them and conducting usability tests. But did you know that you can use Fireworks in combination with other tools to create complex iOS prototypes (for both the iPhone and iPad) with similar ease?

In this series of three articles, you’ll learn how to use Adobe Fireworks together with another tool, called TAP, to create prototypes with animated transitions. The process is fairly straightforward, but because there are many properties and features one can tweak to enhance a prototype, I have separated the content into three parts:

  1. In part one, I’ll shed some light on the major stages of the design process that projects at Cooper go through — Fireworks plays an important role during all of these stages. Next, I’ll talk about my preferred method of organizing Fireworks PNGs, which will be important later and will serve as the basis for the next part of the tutorial.
  2. In part two, I’ll speak in detail about the use of pages, hotspots, gestures, transitions and timers and how to set them up for use with TAP. Then, I’ll show you how to start building a click-through prototype in Fireworks, which will later be converted into an interactive iOS prototype.
  3. In part three, the conversion to a TAP iOS prototype will be covered in detail. I will also share some tips on its use on iOS devices. You’ll get all of the demo files needed to complete the tutorial, as well as an extensive list of related resources on Fireworks and prototyping.


There has been an explosion of prototyping applications that claim to be mobile-centric, but few actually focus on the core differentiators of the modern mobile experience: gestures and transitions. One design tool that I have come to rely on for iOS prototyping is Adobe Fireworks — an application that has received a bit less attention from the design community. However, Fireworks is a powerful, extremely efficient and extensible program that has many indispensable features that cannot be found anywhere else. (Check out a couple of articles on what it can do and what makes it unique for details on what makes Fireworks so special.)

With TAP (a free extension), you can transform Fireworks from a general wireframing application into an iOS prototyping powerhouse. Let’s find out how!

How Fireworks Is Used At Cooper

As an intern at Cooper in the summer of 2011, I learned how to use Adobe Fireworks to make both interactive prototypes and polished visual designs. The versatility of Fireworks meant that everyone on the team could easily share files back and forth during a project.

Interaction designers use Fireworks as the digital equivalent of a refined sketching tool. More flexible than pen and paper (when using shared layers, symbols and styles), Fireworks retains the fast and direct nature of drawing but with a higher fidelity than pen and paper or a whiteboard. This technique is very useful early in the design process when many major decisions are still being evaluated. Many other tools for wireframing are out there that include libraries of UI components, but Fireworks is one of the only wireframing applications that also has robust illustration and design capabilities that can be used to create original content. This is one of the most overlooked benefits of Fireworks, because it increases the likelihood that you will come up with an original design that is tailored to the problem(s) you are designing a solution for.

Our Tool of Preference for Both Interaction Design and Visual Design

In the article “Designing Interactive Products With Fireworks,” published on Adobe Developer Connection, Nick Myers (principal visual designer at Cooper) shares his thoughts about the design process and how Fireworks fits into the various stages:

“At Cooper, we design a wide variety of interactive products for platforms, including the desktop, the web, and mobile devices. Our design teams are small and usually consist of an interaction designer, design communicator, visual designer and, if there is a hardware component, industrial designer. The interaction designer and design communicator work together to design and document the behavior of the interface, while the visual designer is responsible for the interface’s visual appearance. The industrial designer handles the physical form factor of hardware. Finally, the team is managed by an engagement lead who designs the engagement and provides guidance and direction to the team.

During the solution-creation phases of a typical project, a design team begins storyboarding scenarios on whiteboards and then transfers these sketches to the screen, where they are iterated and refined over and over. The design is then documented for our clients to follow and reference as they build their products.

After the big ideas are generated, the interaction designer quickly transfers his work to Adobe Fireworks where the details are added to the product. Other design groups or firms may use one tool, like Visio or OmniGraffle, for interaction design and another, like Photoshop, for visual design, but we have learned over the years that working in Fireworks throughout the design process has many benefits.

First, it encourages our teams to be more collaborative as we pass our work back and forth and solve problems together. We also work much faster, as we don’t have to recreate elements or check our work against each other’s files. Finally, it reduces mistakes during design, as we aren’t managing multiple versions of files.”

(You can also watch a video on the same subject, in which Tim McCoy and Nick Myers discuss how they use Adobe Fireworks for interaction and visual design.)

In another article, “Industry Trends in Prototyping,” Dave Cronin (previously director of interaction design at Cooper and now at General Electric) shares more about the role of Fireworks at Cooper:

“While pen and paper can be a perfect medium for creating storyboards, we’ve found that the combination of a Wacom tablet and Adobe Fireworks allows us to work even more quickly and efficiently. At Cooper, we use Fireworks as our primary screen rendering and production tool for work from sketch to final graphic assets.

To create a sketchy storyboarded scenario in Fireworks, we typically rely on the States panel to represent each state in the scenario. We use layers, shared across states, and symbols to reuse screen elements, eliminating the need to draw the same thing over and over again.”

Cooper’s Project Workflow

For most projects at Cooper, the following are the four major stages of the design process. (Technically, there are many more — such as primary research, competitive analysis and persona development — but they are beyond the scope of this series of articles.)

  1. Framework drawing,
  2. Framework wireframing,
  3. Detailed visual design,
  4. iOS prototyping with Fireworks.

Stage 1: Framework Drawing

The framework drawing (or sketch) is a high-level depiction of the main underlying concept and supporting structure that the whole design is based on. Lack of detail is intentional in order to elicit a broader scope of feedback from stakeholders.

Cooper: four stages of solution evolution
Framework drawing stage

Stage 2: Framework Wireframing

The framework wireframe is a refined digital depiction of the framework that is used to further clarify and iterate on ideas from previous sketches. While key features may be explored at this stage, excessive detail is avoided so that stakeholders are not distracted by elements that haven’t yet been completely thought out. Renderings of the wireframe have a “pencil sketch” style and are not too polished, in order to elicit a moderate level of feedback from stakeholders.

Cooper: four stages of solution evolution
Framework wireframing stage

Stage 3: Detailed Visual Design

The detailed visual design is a fully rendered, detail-oriented, fleshed-out depiction of what the interface will look and feel like when the design is finished and in the hands of users. At this final stage, brand attributes are added to determine color, typography, iconography and other visual properties.

Cooper: four stages of solution evolution
Detailed visual design (visual rendering) stage

In the later stages of the design process, Fireworks can turn the wireframes into fully rendered, production-ready graphics. And by adding hotspots to each page in a Fireworks document, non-linear navigation can be simulated, and click-through wireframes can be used to test and share the design flow.

Stage 4: Extending Fireworks To Create iOS Prototypes

On its own, Fireworks can be used as a simple wireframing tool with linking capabilities — far different from the more robust prototyping tools that can accurately demonstrate more complex or nuanced interactions, especially ones that involve animated transitions.

Luckily for designers, some very smart people at UNITID (based in the Netherlands) have developed Touch Application Prototypes (TAP), a utility that enables you to design in Fireworks and, with almost no coding, convert the design into an animated prototype that responds to particular gestures.

Touch Application Prototypes and Adobe Fireworks combined
TAP and Fireworks are all you need to create animated prototypes that respond to gestures.

Best of all, you can experience the prototype right on any iOS device! Seeing your prototype respond to your touch and animate in real time is a satisfying and immersive experience, and the experiential learning and exploration can elicit a new understanding of the prototype.

Why Animated Transitions and Gestures Matter

Thanks to the proliferation of touch interactions, animations have become essential characteristics of the mobile experience, and they are even beginning to influence the desktop as well (as can be seen in Mac OS X Lion and Windows 8). Animated transitions provide useful feedback; they help visualize the results of actions taken; and they enhance the sense of direct manipulation. For more information on how essential transitions are to the mobile touch experience, check out Greg Nudelman’s article “Storyboarding iPad Transitions.” Gestures help to make a prototype feel like a native application and can help designers evaluate a product’s effectiveness, something that’s becoming more critical as chrome disappears and affordances become less visible. For a taxonomy of gestures used for mobile, check out Luke Wroblewski’s “Touch Gesture Reference Guide.” Much can be learned from using and testing animated and gesture-based prototypes.

Laying The Foundation: Fw PNG Organizational Framework

Fireworks’ framework for file organization will play a very important role later, so let’s take a good look at it.

As with any powerful design tool, there are many ways to use Fireworks. The way in which we at Cooper organize Fireworks files (or Fw PNGs) has evolved over time. The organizational methodology that we’ll cover in this article enables designers to create intricate scenario-based wireframes that can be exported as interactive HTML prototypes or demos that allow observers to see and evaluate the merits of a design.

Fireworks elements' hierarchy
How Fw PNG files are organized: pages contain states, states contain layers, layers contain objects.


Pages icon

Each Fireworks PNG file can contain many pages, which are used to represent the various stages in a scenario and which build on one another.

Pages Panel
Pages in Fireworks: a brief interaction example that contains three pages.

In the example above, on page 1 the user types in their name; on page 2 the user types in their password; and on page 3 the user clicks the log-in button.

Note: Although states may be used to create rollovers and other interactive behaviors, they are not generally used in wireframes that are designed according to the methodology followed in this article. For more on how to use pages and states in Fireworks, check out Dave Hogue’s detailed article “Using Pages, States, and Layers in Fireworks CS4.”

When you use pages as the primary way of organizing a scenario, you are able to export the work as a prototype consisting of HTML and images, where each page can be linked to others through hotspots. This HTML prototype allows anyone with a browser to experience your work in a way that is interactive and that replicates the feel of a real application. Non-linear and branching scenarios may be set up with multiple hotspots per page and can really make a project come alive.

Shared Layers

Share to Layers icon

You can use layers to organize the visuals shown on each page by controlling the stacking order of elements. Layers may be shared to pages when those pages must contain the same visuals. Sharing a layer is more versatile and efficient than merely copying and pasting objects from page to page because shared layers maintain consistency. This is a huge time-saver because common elements that appear across many pages can be changed once and updated across the entire project in one click! Share a layer if you want the same objects to appear across pages consistently (known as “object persistence”). Two commands are used to share layers: “Share Layer to Pages” and “Share Layer to All Pages.”

How to share layers to specific pages:

First, select the layer that you want to share in the Layers panel. Then, right-click (or Command + click on a Mac), and select the option “Share Layer to Pages.”

Share Layers context menu
The contextual menu in the Layers panel lets you share layers to specific pages or to all pages in a document.

A dialogue box will appear with two selection lists: the one on the left lists the pages that this layer is not shared with (named “Exclude layers from page(s)”), and the one on the right (named “Include layer from page(s)”) lists the pages that this layer is shared with. To share a layer to more pages, select the pages you want to share to in the left column (you can select multiple pages by pressing Control/Command + click), and click the “Add >” button to move the pages to the list on the right.

Share Layer to specific Pages dialogue box
The “Share Layer to (Specific) Pages” dialogue box controls which pages a layer is shared to. Note that there are no previews here, so naming your layers well is key.

Sharing a layer to pages can be done and undone by selecting the “Share Layer to Pages” option and moving pages to and from the “Exclude layers from page(s)” and “Include layers from page(s)” lists.

Note: The stacking order of shared layers is controlled per page. The order of layers on a page may be unique and changed as needed without affecting other pages that share those same layers. This ability to change layer stacking per page is a powerful feature in Fireworks and makes it possible to draw multiple versions, modes and states of an interface just once on multiple layers, share those layers, and then choose which version is shown on each page simply by rearranging the layers.

How to share layers to all pages:

Use the same process as for “Share Layer to Pages,” but this time selecting the option “Share Layer to All Pages.” This command ensures that whenever a new page is created, it will not be a blank slate — those layers (and their contents) will be copied over automatically. When a single layer is shared to all pages, it will appear at the top of the layer stack.

When multiple objects within a layer are selected and then collectively shared to all pages, the stacking order of layers on newly created pages is different than the stacking order when the layers were created on the original page. The stacking order of layers is not always predictable and will not reflect the stacking order on the page you are sharing from; this seems to be a limitation (or a bug?) in Fireworks CS5. By comparison, in Fireworks CS6, the stacking order of objects within a layer is much more likely to be respected and maintained throughout a document.

Note: Be careful when using the “Share Layer to All Pages” command because there is no global “unshare layers” command. Once a layer has been shared to all pages, it will be automatically included (or shared) on every new page you create. You can manually unshare it from all pages in the document by using the “Share Layer to Pages” option and removing all of the shared pages. As long as “Share Layer to All Pages” remains checked in the menu, then all new pages will inherit that layer; if you uncheck “Share Layer to All Pages,” then all pages already sharing that layer will retain the shared layer, but any new pages created will not inherit that layer.

Here’s a brief example. If you create a layer on page 1, share it to all pages, and then go to page 5 and right-click on the shared layer, you can “detach” or “exclude” that shared layer from page 5. The “Detach” option will make a copy of the shared layer and break the connection with the original (similar to breaking off a symbol), without affecting the original or any other page. The “Exclude” option will remove the shared layer from the current page without affecting the original or any other page.


Symbols icon

A symbol in Fireworks is a special kind of reusable graphic element — think of it as a master version of a graphic. Use a symbol whenever you will be repeatedly using a graphic, such as a logo. The advantage is that copies of a symbol (called symbol “instances”) will all be linked to the original; so, when properties of the original instance are changed, the other instances will change automatically.

Instances of symbols can be transformed (including by scaling, skewing, distorting and rotating) without affecting the original or other instances, and they may be given different properties (i.e. different from one another and from the original symbol):

  • Transformations (scale the size, skew or distort the shape, and rotate the object);
  • x and y coordinates (location on page);
  • Blending modes;
  • Opacity;
  • Apply live filters.

When a symbol is created, it is placed in the “Document Library.” The Document Library panel gives an overview of all symbols used in the current document. You can find symbols that you have already created there, and you can drag and drop them onto the canvas to create new instances.

The Document Library panel in Fireworks
The Document Library panel

Symbols may also be saved to the “Common Library” and, thus, made available for global use in Adobe Fireworks.

The Common Library panel in Fireworks
The Common Library panel

To save a symbol to the Common Library, select it in the Document Library panel and use the “Save to Common Library” option in the panel’s menu. Later, whole collections (or libraries) of symbols can be easily shared between designers on the team.

Why not turn every object into a symbol?

If symbols are so cool and offer so much power, you may be wondering, why not make everything a symbol? The answer is that if an object won’t be used repeatedly, there is no added benefit of making it a symbol; in fact, it would make your workflow slower, for two reasons. First, in order to edit the master symbol, you would usually enter a special “edit symbol” mode (similar to single layer editing), which slows down the workflow. Secondly, all symbols are listed in the Document Library panel, and this panel would soon become full of symbols, making file management difficult.

Because symbols are not the main topic of this article, I’ll simply refer you to the following resources:


Object Styles icon

Just like in InDesign, Styles in Fireworks allow for the consistent application of fills, strokes, live filters and other styling properties. When a style is changed, objects with that style are automatically updated, too, similar to how global CSS styles work in HTML documents.

(Object) styles are perfect for when you want to create a consistent visual language in a design and want to be able to update the look and feel easily.

Let’s suppose you want to explore three variations of a button set design in an interface.

At the beginning of the design process, you would place the buttons on the canvas and apply a pencil-sketch style to them (so that the buttons don’t look too polished at this early stage of the project). Once the pencil look is achieved through various filters and effects, you can save the look as a style.

Note: Saving a new style in Fireworks is easy. Select the object with the style that you want to save, and then click on the “New Style” button in the bottom-right corner of the “Styles” panel. Or, alternatively, use the “New Style” option, accessible in the “Properties” panel (also known in Fireworks as the Property Inspector (PI) panel).

Later on, when the design is more refined, you might want an OS X aqua look. Because you are using styles, there is no need to redraw the buttons! To convert the design from a pencil-sketch look, select the button you want to modify, alter its visual properties to appear more glossy and fluid, and then click the “New Style” button. Repeat these steps to create a third style based on, say, a plastic-y Web 2.0 look. You can apply the three different styles to any button from now on! If you modify the style itself, all objects with that style will update as well.

Example of using Styles with the Styles panel
The Styles panel is used to create new styles and apply existing ones. Update a style in the panel and all objects with that style will update throughout the entire document.

With the help of the Styles panel, you can also duplicate, delete, rename and redefine styles, break a link to a style, import or export whole style libraries, and more.

Because styles are a powerful feature on their own, I’ll refer you to Jim Babbage’s video tutorial “Understanding Styles and Symbols in Fireworks.”


Now that you understand the fundamental components of Fireworks (pages, shared layers, symbols and styles), let’s explore how you can use them to start building your own prototype!

In the next section of this tutorial, you’ll learn how to use pages, hotspots, gestures, transitions and timers, and how to set them up for use with TAP. Then, we’ll create a click-through prototype in Fireworks, which will in turn be exported as an iOS prototype. Stay tuned!

(mb al)

© Shlomo Goltz for Smashing Magazine, 2013.