Skip navigation

desktop web

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.

Vexing Viewports

“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.

This agreement has never been more important.

That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.

You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768x1024 pixels), even though the Mini's screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.

Two iPads, one too small.

But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.

The trouble with pixels

Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.

The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.

Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.

Two devices, each with a two-inch-wide display. The one on the right, at 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.

This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352x416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.

The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.

Enter viewports

Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.

In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.

The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.

Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”

Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.

Mini problems

The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.

And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.

Solving for content size

One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.

Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.

When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.

On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.

Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.

This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.

Three seven-inch tablets. Note the difference in rendering.

So why did Apple do this?

To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.

In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024x768-pixel layouts precisely targeted at these devices.

Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024x768 viewport suddenly looked unexpectedly wretched on the new device.

The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).

A way forward

The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.

Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.

Let’s move into the future—together.

RSS readers: Don't forget to join the discussion!

Your rating: None

Universal Design IRL

What you tolerate defines your community.

—Heather Champ at Web Directions South 2012

We talk a lot here at A List Apart about designing for the future. About being thoughtful, accessible, forward-thinking, and compassionate. About building a web that serves more of us, more fully.

And yet, when it comes to building our own communities—the events and conferences in which we learn new skills and discuss new ideas—we’ve spent precious little time designing with this inclusivity in mind. We accept conference lineups loaded with white men because “we couldn’t find any other qualified speakers,” or “all the women we asked said no.” We host bro-tastic hackathons fueled by beer-serving babes. Sometimes, we even give straight-up harassment and vitriol a place at the podium.

This isn’t good enough.

If the web’s ideal is universality, as Sir Tim Berners-Lee says, then shouldn’t this be the driving principle behind our own communities and organizations as well? If we want a web that works for everyone, then don’t we need a web profession that reflects just as much diversity? After all, the best way to understand the audiences we design for is to know those audiences. And the best way to know people is to have them, with all their differences of perspective and background—and, yes, age and gender and race and language, too—right alongside us.

“But I don’t want to exclude anyone,” you might be thinking. “I’m not trying to keep women or people of color or those from different backgrounds out of the spotlight.” I’m sure that’s true. Yet our community is far from diverse: According to the 2011 findings from our very own Survey for People Who Make Websites, just 18 percent of you are likely to be women, and even fewer of you are non-white. Add in the fact that women, people of color, and those from outside the U.S. are all much more likely to perceive bias in their careers, and it starts to get pretty hard to pretend everything’s OK. In fact, sexism at “geek” events is so prevalent, there’s a whole wiki devoted to cataloging known incidents.

However you participate in the web community—organizing conferences, holding hack nights, publishing articles, hosting meetups, or simply attending events—you have the power to do something about this, and in turn bring the web closer to its ideals. And it’s not as hard as you might think.

We have the tools

The web’s ability to connect people, facilitate understanding, and amplify ideas has enabled us to build incredible things. It’s also given us a wealth of lessons in how to design thriving, thoughtful communities. Lessons it’s time we turn toward ourselves—toward reaching this more personal, more intimate goal.

What can we learn from designing online communities, social systems like Flickr and Facebook? I propose four key skills: setting expectations, making it easy to report abuse, fostering diverse participation, and avoiding blaming our users.

Set expectations for behavior

The right tone of voice can turn someone’s confusion into trust, skepticism into optimism, boredom into curiosity. The wrong tone of voice can turn someone’s interest into annoyance, anticipation into disappointment, frustration into full-on anger.

—MailChimp’s Voice & Tone guide

Online communities are fertile ground for misunderstandings. Without the benefit of nonverbal cues like nods, smiles, motions, and postures, we misinterpret sarcasm. Our jokes fall flat. Our feelings get hurt. So what do we do when building these communities, besides writing up explicit terms of service? We set implicit expectations.

Implicit expectations include the voice and tone of an interface—from the signup forms to the welcome messages, the email reminders to the error notifications. Design, too: Typography, color, and layout choices all influence how a user sees an experience, and help her form an impression of not just what the site is, but how it feels, and how she’s expected to behave there. With every bit of content you communicate, you’re modeling the discourse you expect from others.

In addition to having explicit rules of conduct (and training your volunteers to enforce them), you can also create these types of implicit expectations in IRL. In fact, if you organize events, you already have models for behavior: the people who take the stage. Placed on a platform, both literally and figuratively, your speakers’ and organizers’ behavior and actions become your event’s norm. Their tone becomes your audience’s tone.

It’s your job to make sure it’s the right one.

If you're in charge, talk with presenters, organizers, and volunteers about the expectations you want to set. Remind them that their actions are on display, and will reverberate across the event. Empower them to model the sorts of behavior you want to see, and be explicit about what’s inappropriate—like slides that objectify women or statements that marginalize non-U.S. attendees.

If you’ve picked the right speakers, this won’t impose on their creativity one bit.

Provide easy-to-navigate outlets to report abuse

Imagine a 14-year-old girl logging onto Facebook to find that she’s been called a slut and tagged in obscene photos by a classmate intent on ruining her reputation. She’s got enough on her plate without having to also wrangle with an interface that makes it hard to stop the harassment, right? So Facebook offers the option to delete any item posted to your page, right alongside the post—and to block a user and report abuse, just by visiting that user’s profile.

Now think about the last conference you attended. If you’d been harassed, would you have known where to go for help? Would you have had a clear outlet to voice concerns? Or would you have been @-messaging a generic conference avatar, unsure who was on the other end? Sidling up to a harried registration desk to discuss your grievances in public?

Would you have said anything at all?

I didn’t. A couple years back, I was propositioned by an employee of the company organizing the conference—a much-older man who was also a vendor for my then-employer. We’d had drinks with another colleague of mine, where we’d made mundane cocktail talk about business and spouses. We said goodnight, and approximately two seconds after he knew I’d be alone, he sent me a demanding, aggressive text message—one that assumed I’d already consented to a liaison. I was disgusted and furious, but unsure what to do: He was my main contact at his company, and knew the owner of mine well. The prospect of explaining all this over and over to people I wasn’t sure would understand seemed like a further humiliation waiting to happen.

So I let it go. And I spent months feeling ashamed of myself for it.

No event organizer wants attendees—especially those dropping hundreds or thousands of dollars on a conference pass—to feel this way. But if you’re in charge, you’ve got to do more than want. You’ve got to plan, and you’ve got to make it clear to the people attending that there’s an outlet for their concerns—before they have any.

Hearing about inappropriate behavior is difficult, sure. But no matter how awkward it is for you, I promise it’s much worse for the person who’s been made to feel uncomfortable or unsafe, who’s trying to hold it together while telling you, and who’s scared you’ll just write it off.

Don’t let that happen. If you organize events, name a person or provide a place—virtual or physical. Promise confidentiality. And publish this on your website or in your collateral, right from the start. You don’t need to make it scary—just include a simple note reminding attendees that everyone should feel welcome, and if they don’t, there’s a place to go and a person who’ll listen.

If you volunteer or speak at events, make a point to ask about policies for harassment or inappropriate behavior: Does the event have any? What are they? Raising the question may be all that's needed to get an organizer thinking about these issues.

Whatever you do, don't you make it a burden for someone to figure out how to tell you they’ve been harassed. If you do, many of them never will.

Foster diversity to foster longevity

Back in 2010, when Twitter first started suggesting people for users to follow, it made a rookie mistake: recommending the same people to everyone, all the time. This created a dynamic where “the rich got richer,” as Heather Champ, who’s known for her work building communities like Flickr, has noted. In other words, it made a few big names even bigger (Bieber, anyone?), but it failed to foster deeper connections or build robust communities. Over time, Twitter realized this wasn’t working and responded with major updates designed to give users more varied, relevant suggestions.

As we design community events, it’s important to ask the same thing: Are we just allowing the same people to keynote each year? Are we creating a divide between the haves and the have-nots—those with all the speaking experience, and those with none? If so, which people are we leaving behind? What value could they bring, what new connections could they build across our community, if we amplified their voices instead? What is our industry not learning, where is our industry stagnating, because we’re inviting the same cast to perform the same show each night?

Sameness is boring. It’s predictable. It’s stale.

Perhaps worst of all, it’ll only sell tickets or entertain audiences for so long. The best events feel fresh and different each time—they bring forth a variety of voices, tell a range of stories, and share a breadth of perspectives. They shift and adapt—just like the web.

As an attendee, you might argue that you want to see polished speakers and big names. There’s nothing wrong with that, and it's normal to seek out lineups that have a few. But how many times have you looked at a speaker roster and thought, “man, that guy’s at everything”?

The best events avoid this sort of speaker fatigue by mixing in fresh faces and ideas—and that requires actively looking for new voices. If you're recruiting talent, ask past speakers whom they’ve been reading recently. Trawl Twitter for interesting blog posts hashtagged to your field. Invite longtime attendees to submit a talk. Consider whether women might be declining your invitation to speak for reasons you hadn't considered, and address those, too.

A star-studded speaker roster might generate buzz, but a diverse lineup adds texture, depth, and color. It adds richness and fullness. Done well, it makes people remember how your event changed the way they think and feel—not just which internet celebrity gave the keynote.

Don’t blame your users

Users aren’t perfect: They’re busy. They’re distracted. They’re human.

When we design for humans, we know we need to be forgiving. We know that when they need help, we can’t talk down to them. We know they deserve respect, understanding, and compassion.

Perhaps most of all, we know that when they fail, it’s our job to get better.

The same is true in person. Every time you make an excuse for a bad experience—“It was just for fun. I don’t know why you’re so offended,” or “We’re not trying to exclude anyone…you must be imagining things!”—you’re blaming your user. You’re making it his problem, not yours.

I’ve felt like this, too. Recently, I was accosted by a conference organizer at an official event happy hour. He had always come on a bit strong—too many cheek kisses, too much touching, too-tight hugs, too everything—but I’d always ignored it, figuring he wasn’t worth getting worked up about.

I was wrong. This time, when I questioned something he’d said in his talk that I considered divisive, things turned a very different direction. He screamed at me, in public, pointing his finger and advancing on me aggressively. I kept reiterating that I wasn’t sure why he was so upset, but the yelling continued for what felt like an eternity. I finally told him that the way he was talking to me was inappropriate, that I needed to be treated with respect, and that if he continued, I wouldn’t speak to him anymore.

I’d gone from someone he thought he could paw at to someone he thought he could scream at, and the combination left me shaken. I felt degraded. I felt humiliated.

But most of all, when trying to talk to people about what had happened, I felt marginalized. “He was probably drunk!” some folks said. “Oh, you just got him agitated! You know how he is,” I was told.

Whether or not I’d said something controversial doesn’t really matter. Disagreement and discussion aren’t the problem. His response was abusive and inappropriate, if not overtly sexist, and excusing his bad behavior made it my fault: If I’d just avoided him while he was drinking, just not asked a question, just not gotten him so “worked up,” then this wouldn’t have happened.

You know how condescending, blame-ridden error messages—like “FAILURE. FILL OUT ALL FIELDS CORRECTLY”—frustrate the hell out of users? It’s no different here. Blaming someone who’s been treated poorly is taking what’s already an alienating, isolating experience and deepening it. It’s making them feel incompetent and ashamed.

It’s like the lite version of telling someone she shouldn’t have been wearing a short skirt if she didn’t want to be groped. And it’s a problem you can fight, even if you’re just an attendee, by taking a stand against bad behavior—one that puts the blame squarely on the person who’s really responsible.

It’s up to us

I don’t pretend my experiences are tragic. I wasn’t terrorized or physically assaulted. My life goes on.

But my stories also aren’t unique. I could regale you with hours of anecdotes from friends and colleagues—mostly women, but not all—who’ve poured their time and love and attention into preparing presentations and articles, only to be humiliated or marginalized. People who’ve chosen not to talk about their piss-poor experiences for fear of being retaliated against. People who’ve stopped attending events or speaking up, because it’s just too damn hard to keep smiling while feeling left out, degraded, or attacked. Instead of outing others, though, I’ve told you my own stories. Stories I wish I didn’t have. Stories I wasn’t sure I’d ever share.

I’m sharing them now because I believe we have the power to improve things.

We already know how to make design choices that support inclusivity, set expectations for users, and model the interactions we want. There’s no excuse not to fix this—and, in fact, there’s a real danger in not trying.

We’ve spent two decades talking about a web that’s inclusive and flexible. We’ve devoted countless hours to creating spaces where conversations and relationships can thrive. The longer we tolerate a community that excludes others, the more we, as an industry, are defined by exclusion—and the further away we remain from the universality we’ve worked so hard to build.

RSS readers: Don't forget to join the discussion!

Your rating: None

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant ( Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” ( (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of and, says:

We cannot predict future behavior from a current experience that sucks (

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

RSS readers: Don't forget to join the discussion!

Your rating: None

What do you do when you have a lot of things to display to the user, far more than can possibly fit on the screen? Paginate, naturally.


There are plenty of other real world examples in this 2007 article, but I wouldn't bother. If you've seen one pagination scheme, you've seen them all. The state of art in pagination hasn't exactly changed much – or at all, really – in the last 5 years.

I can understand paginating when you have 10, 50, 100, maybe even a few hundred items. But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What's the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time?

Once you have thousands of items, you don't have a pagination problem. You have a search and filtering problem. Why are we presenting hundreds or thousands of items to the user? What does that achieve? In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for.


But perhaps you don't know exactly what you're looking for: maybe you want a variety of viewpoints and resources, or to compare a number of similar items. Fair enough. I have a difficult time imagining any scenario where presenting a hundred or so items wouldn't meet that goal. Even so, the items would naturally be presented in some logical order so the most suitable items are near the top.

Once we've chosen a suitable order and a subset of relevant items … do we really need pagination at all? What if we did some kind of endless pagination scheme, where we loaded more items into the view dynamically as the user reaches the bottom? Like so:

It isn't just oddball disemvowelled companies, either. Twitter's timeline and Google's image search use a similar endless pagination approach. Either the page loads more items automatically when you scroll down to the bottom, or there's an explicit "show more results" button.

Pagination is also friction. Ever been on a forum where you wished like hell the other people responding to the thread had read all four pages of it before typing their response? Well, maybe some of them would have if the next page buttons weren't so impossibly small, or better yet, not there at all because pagination was automatic and seamless. We should be actively removing friction where we want users to do more of something.

I'm not necessarily proposing that all traditional pagination be replaced with endless pagination. But we, as software developers, should avoid mindlessly generating a list of thousands upon thousands of possible items and paginating it as a lazy one-size-fits-all solution. This puts all the burden on the user to make sense of the items. Remember, we invented computers to make the user's life easier, not more difficult.

Once you've done that, there's a balance to be struck, as Google's research tells us:

User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks.

Interestingly, the cases when users didn’t prefer the view-all page were correlated with high latency (e.g., when the view-all page took a while to load, say, because it contained many images). This makes sense because we know users are less satisfied with slow results. So while a view-all page is commonly desired, as a webmaster it’s important to balance this preference with the page’s load time and overall user experience.

Traditional pagination is not particularly user friendly, but endless pagination isn't without its own faults and pitfalls, either:

  • The scroll bar, the user's moral compass of "how much more is there?" doesn't work in endless pagination because it is effectively infinite. You'll need an alternate method of providing that crucial feedback, perhaps as a simple percent loaded text docked at the bottom of the page.
  • Endless pagination should not break deep linking. Even without the concept of a "page", users should be able to clearly and obviously link to any specific item in the list.
  • Clicking the browser forward or back button should preserve the user's position in the endless scrolling stream, perhaps using pushState.
  • Pagination may be a bad user experience, but it's essential for web spiders. Don't neglect to accommodate web search engines with a traditional paging scheme, too, or perhaps a Sitemap.
  • Provide visible feedback when you're dynamically loading new items in the list, so the user can tell that new items are coming, and their browser isn't hung – and that they haven't reached the bottom yet.
  • Remember that the user won't be able to reach the footer (or the header) any more, because items keep appearing as they scroll down in the river of endless content. So either move to static headers and footers, or perhaps use the explicit "load more" button instead of loading new content automatically.

For further reading, there's some excellent Q&A on the topic of pagination at ux.stackexchange.

Above all else, you should strive to make pagination irrelevant because the user never has to look at more than a few items to find what they need. That's why I suspect Google hasn't done much with this technique in their core search result pages; if they aren't providing great results on page 1, it doesn't really matter what kind of pagination they use because they're not going to be in business much longer. Take that lesson to heart: you should be worried most of all about presenting a relevant list of items to the user in a sensible order. Once you've got that licked, then and only then should you think about your pagination scheme.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

Your rating: None

When organizing content and actions on mobile, solid information architecture principles like clear labeling, balanced breadth and depth, and appropriate mental models remain important. But the organization of mobile web experiences must also align with how people use their mobile devices and why; emphasize content over navigation; provide relevant options for exploration and pivoting; maintain clarity and focus; and align with mobile behaviors. In this exclusive excerpt from his new book, Mobile First!, Luke Wroblewski explains how to do all that.

Your rating: None