Global Moxie - Full Feed

The Mobile Book

Josh Clark — Thu, 13 Dec 2012 22:43:39 UT

Smashing Magazine published The Mobile Book this week, and wow… it’s a humdinger. It’s full of smart advice from all the people I simultaneously love, fear, and admire in the universe of mobile web: Jeremy Keith, Peter-Paul Koch (PPK), Stephanie Rieger, Trent Walton, Brad Frost, Dave Olson, and Dennis Kardys. With such great company, I was especially honored to contribute the book’s final chapter about designing for touch.

The book is not only smart but beautiful. The dead-tree version is hardcover with stitched binding and, get this, an old-school ribbon bookmark. The thing is just gorgeous. Even if you prefer your books in pixels instead of paper, you still get an elegant interior design featuring the illustrations of Mike Kus.

Much of the book looks at mobile through the lens of the web, but it’s also a useful resource for developers and designers on other platforms. The book is neatly organized into three sections: the mobile landscape, responsive web design, and UX design for mobile. The first and last of these are applicable to any platform, and frankly, the web-specific responsive-design techniques will quickly become matters of basic digital literacy.

This matter of evolving literacy is very much the point of Jeremy’s forward to the book:

This book is an artefact of its time. There will come a time when this book will no longer be necessary, when designing and developing for mobile will simply be part and parcel of every Web worker’s lot. But that time isn’t here just yet. So in the meantime you’ve got the current state of all things mobile packed together into this single volume.

I’m flattered to report that the first round of reviewers agree with Jeremy about the book’s stature as a well-rounded and authoritative review of mobile design technique.

Design Shack: “It’s a handbook for web design today. Earlier I mentioned that you should add this book to your shelf, in reality, you’ll probably want to keep it on your desk.”

UX Magazine: “I highly recommend this book to both the blossoming and the experienced UX designer. The various voices of different authors breathe fresh narrative air that carries diverse-and-deep domain knowledge along in a cohesive story about how to harness the chaos of our ever-evolving world into a mobile-UX delight. Consider the lessons in this book a whopping set of New Year resolutions.”

Open Designs: “As somebody who spends a lot of time tinkering and tweaking websites to make them work better, I thought this book was bloody brilliant. There is so much depth and information packed into its 336 pages that I think it will become the book for the mobile Web.”

The table of contents:

Jeremy Keith: Foreword
Peter-Paul Koch: What’s Going on in Mobile?
Stephanie Rieger: The Future of Mobile
Trent Walton: Responsive Design Strategy
Brad Frost: Responsive Design Patterns
Dave Olsen: Optimization for Mobile
Dennis Kardys: Hands-On Design for Mobile
Josh Clark: Designing for Touch

I’m admittedly biased, but my advice is to run out and buy The Mobile Book immediately. It belongs on every webslinger’s bookshelf and/or ebook. Buy the book, or download a free chapter, “Responsive Design Strategy” by Trent Walton (PDF, 8MB). Enjoy.

Tags: books, design, josh, mobile, responsive, writing

New Rule: Every Desktop Design Has To Go Finger-Friendly

Josh Clark — Mon, 05 Nov 2012 20:31:50 UT

Photo by Jeffrey Riehle.

Touch has landed on the desktop. A whole new category of touch devices is flooding the consumer market in coordination with the release of Windows 8: touchscreen laptops and tablet/keyboard combos. These new hybrid combinations of touch and keyboard create a new ergonomic environment... and fresh demands on designers.

Like tablets before them, the ergonomics of these hybrid gizmos demand UI conventions that depart from desktop layouts of similar screen size. The hybrids not only need big touch targets to accommodate clumsy fingers, but they also need controls and navigation conveniently placed where hands naturally come to rest. Designing for touch introduces elements of industrial design: physical comfort and ease are critical considerations.

Unfortunately, the top-of-screen navigation and menus of traditional desktop layouts are outright hostile to hybrid ergonomics. Tried-and-true desktop conventions have to change to make room for fingers and thumbs. For now at least, the solution is not just a matter of designing separate interfaces for touch and non-touch gadgets. That won’t fly, because as designers (and especially web designers) we often don’t have enough information about the device.

After poking at this problem for a few weeks, my conclusion is: every desktop UI should be designed for touch now. When any desktop machine could have a touch interface, we have to proceed as if they all do.

Walk with me.

Gorilla Arms Get a Rest

Hybrids require us to move our hands back and forth between the keyboard and the touchscreen just behind it. Before this new onslaught of hybrids arrived, many (including a dismissive Steve Jobs) criticized the concept as untenable: people wouldn’t want to shuttle their hands back and forth to point at the screen. The effort would be too much, too inefficient, and the result would be the fatigue of “gorilla arms.” It’s a criticism leveled at Minority Report-style interfaces of science fiction, too: who wants to work with your arms constantly in the air?

Early returns suggest those initial worries were unfounded. People do embrace touch with these hybrids, but they do it by barely lifting their arms. In usability studies by John Whalen of Brilliant Experience and by Intel,¹ newcomers shifted naturally to interacting directly with the touchscreen, ignoring any mouse or trackpad. Despite the availability (and greater precision) of these time-tested pointers, people said the touchscreen felt more intimate and direct. The hand became their preferred pointer for buttons, scrolling, you name it. Even expert users accustomed to tabbing between fields switched to independently selecting form fields by touch.

There seems to be something irresistible about the touchscreen, even when more precise or efficient options are available. Jeff Atwood put it nicely in his review of Microsoft’s Surface tablet:

I’ve stopped thinking of touch as some exotic, add-in technology contained in specialized devices. I belatedly realized that I love to touch computers. And why not? We constantly point and gesture at everything in our lives, including our screens. It’s completely natural to want to interact with computers by touching them. That’s why the more unfortunate among us have displays covered in filthy fingerprints. …

After living with the Surface RT for a few days now, I’m convinced that this form factor is the replacement and way forward for the stagnant laptop. I can’t even remember the last time I was this excited about a computer. The more I use it, the more I think that touch plus keyboard is the future of all laptops.

But what about those gorilla arms? John Whalen’s research found that people avoid raising their arms with hybrids by instead resting them alongside the keyboard, keeping a loose grip at the bottom corners of the screen. (Among other things, this grip helps to steady a sometimes floppy laptop screen when you tap at it.)

People who use hybrids tend to rest their arms alongside the keyboard with a loose grip on the bottom corners of the screen.

As with any handheld touchscreen device, the way you hold the thing informs where primary controls should go. So this bottom-corner grip has important implications for the visual layout of websites and apps on hybrid devices. But first, to basics...

Rule of Thumb

Designing for touch means designing for fingers, yes, but to be more specific, you’re really designing for thumbs. On every handheld touchscreen, from phones to tablets to hybrids, the thumbs call the shots. Here’s why.

Phones: One Hand Means One Thumb

On phones, the best interfaces optimize for a one-handed grip, because it’s at once the most freeing and the most limiting. It’s freeing because it lets you do things with the other hand—write, sip coffee, hold a baby—a fact that makes it the most common grip. But it’s limiting because working a phone one-handed means working it with your thumb. Thumbs separate us from the beasts, but alas, when it comes to driving software, thumbs lack both reach and dexterity.

This peculiar combination of freedom and constraint requires specific design concessions, most of them imposed by thumbspan. While a thumb can manage to sweep most of the screen on all but the most oversized phones, only about a third of the screen is in truly effortless territory—at the bottom of the screen on the side opposite the thumb. When holding a phone in the right hand, for example, the thumb falls naturally in an arc at the bottom left corner of the screen.

This is a big reason why apps and mobile operating systems pin primary controls to the bottom edge of the screen—precisely the opposite of typical desktop layouts. (It’s not only simple comfort and convenience that drive screen-bottom conventions, though. It’s also the awkward fact that fingers obscure the screen. Pushing controls below the content keeps hovering hands out of the way.)

Tablets: On the Edges

Tablets are trickier because we hold them so many different ways. We grab, tilt, lean, cradle, and clench in a whole variety of embraces, many of which depend upon stance. The rule of thumb still applies to these guys, except that the thumb zone changes. The special headache here is that the thumb zone isn’t consistent even for individual devices; it changes depending on posture.

Standing up, you use two hands to tap away on a large tablet like iPad. You likely hold it halfway up the sides for leverage (hold it too close to the bottom, and the thing goes floppy.) Or perhaps you have one arm wrapped around it like a clipboard while you tap with the other hand. Sitting at a table, you’re likely to prop a tablet with one hand at the lower third and tap with the other. Reclining in an armchair, you tend to rest it in your lap and tap with the other hand. Lying down or reclining, you rest the thing on your belly or nestled in a blanket, propping it with one hand, tapping with the other. In all of these grips, fingers fall in different places on the device.

When it comes to tablets, in other words, we’re all hands. We roam all over the things—all over, that is, except the top and bottom edges. As varied as tablet grips can be, two things are true for all of them. First, we tend to hold tablets at the sides; though the specific location wanders up and down, thumbs tend to settle at the middle- to top-third of the screen.

Second, the larger the screen, the harder it is to take in the whole thing at a glance as you can on a phone. On larger tablets, as with print design, our visual attention naturally focuses on the top of the tablet, and the design’s information hierarchy should reflect that.

These factors mean eyes and thumbs naturally occupy the top half of tablets, with thumbs straddling the edges. Spreading navigation and primary controls across the bottom—the standard pattern for phones—turns out to be ergonomically hostile on tablets. Sometimes the bottom isn’t even visible at all. In the laziest and perhaps most common of positions—lying down or reclining—the bottom bezel tends to disappear into blankets, sweaters, and soft bellies.

Tablet navigation and other frequent controls should hug the sides or top corners for easy thumb access. Avoid forcing people to lift and haul their entire arms over to the top or bottom edges for frequent touch targets. Some arm lifting is of course inevitable. Tablets are thumb and index-finger devices, with the index finger driving interaction inside the tablet’s canvas. You have to move your arm for that, no way around it, but focusing navigation around the thumb as the anchor at least means that you can spare your arm the most frequent taps. The top corners are within thumb striking distance while also remaining in the tablet’s primary visual area.

A typical grip puts the thumb zone at the sides and top third of larger tablets like iPad.

But what happens when we strap a keyboard onto the thing?

Hybrids: All thumbs

Here again, the rule of thumb calls the shots. You’ll recall that hybrid users frequently adopt a bottom-corner grip, resting their arms alongside the keyboard. Placing primary controls and navigation in easy reach of bottom-corner thumbs means you avoid gorilla arms. The result is a vertically flipped version of the thumb zone we saw for standalone tablets.

Not everyone adopts the bottom grip, though. Others (especially newcomers) go freeform, jabbing their index finger at the screen. This approach unhinges the hands from the screen edges, giving freedom to roam the interface. Still, the center of the screen tends to be an easier touch than the corners with this technique. Trouble is, this finger hot zone is exactly the reverse of the thumb zone.

The upshot: optimizing for thumbs means a subpar experience for the index finger—and vice versa. One layout has to win, though, and as with every other touch device, the winner is the thumb. John Whalen’s study suggests that hybrid users begin to prefer thumb use over time, with expert users going nearly all thumbs, reaching them in and out of the screen from the edges to drive interaction. Once again, thumbs are the primary utility pointer.

Cluster primary controls and gestures for hybrid screens around the bottom corners and sides. That’s one reason Windows 8 uses edge gestures to summon system and app controls. A swipe from the right edge conjures the system charms, and a swipe from the bottom edge brings up a shelf of app tools.

What all of this adds up to: input type and grip should drive the placement of controls, not screen size. For web designers in particular, this is a big headache.

A Touching Problem for Responsive Design

For most of its short history, web-design practice has focused on the visual—on screen size. It’s not yet in our industry’s DNA to consider physicality and environment in our layouts. That’s why many are still surprised at the idea that they can’t just use their legacy desktop layout on iPad, even though the screen size is the same. The layout looks good, sure, but that rarely means it’s also finger-friendly.

The rise of the hybrids means touch is no longer the sole province of phones and tablets. It’s arrived on desktops and laptops, too. Most desktop website layouts, however, are not optimized for touch. They challenge our clumsy fingers and thumbs with small touch targets for links and menus, or they lean on hover interactions that can’t be triggered by touch at all. Few sites place primary navigation in easy reach of the thumb zone for either tablets or hybrids; they favor cursor-friendly screen-top navigation instead.

Ideally, we would all tweak our CSS to accommodate a range of input types in the same way responsive design has encouraged us to accommodate a range of screen sizes. Responsive web designers have so far used screen size as a proxy to assume support for touch. “If it’s a small screen, it’s touch. If it’s a big screen, it’s mouse-driven.” That distinction was already in trouble with large tablets like the iPad, and hybrids break that approach even more.

Unfortunately, we don’t yet have media queries to specifically target touch devices, but that may change soon. Recent draft proposals for CSS4 include a pointer media query to target gadgets with “fine” or “coarse” pointing tools. A mouse, trackpad, stylus or any other precision accessory would be a fine pointer, while fingers would be coarse. This would allow you to create specific rules to pamper fat fingers:

/* Make input fields taller for touch */
@media (pointer:coarse) {
    input[type=”text”] {
        min-height:44px;
    }
}

This will get us part of the way, although it’s not clear whether a browser with a keyboard/mouse and a touchscreen should identify itself as coarse or fine. Even better would be targeting the combination specifically. As we’ve already seen, the layout for a touch-keyboard hybrid should be different from that of a touch-only tablet, because the ergonomics are different. That makes it important to identify not only the availability of touch but whether it’s combined with other input types. It would be helpful if media queries could target additional input types. While we’re at it, it would be great to have http headers that announce to the back-end server what type of device it’s dealing with:

“Hi, I’m a touchscreen!”
“Howdy, I’m a touch-keyboard hybrid.”
“Greetings, I have no screen at all...”

Until we get these “Hello, my name is” name tags in CSS or http, we have to make do. There’s only one sensible way to do that:

Assume every screen your website serves is a touchscreen

If a device can be used for touch, its interface should be finger-friendly. This isn’t a problem that’s specific to touch, either; it’s just that touch got here first. A new desktop design language is needed, one that replaces cursor-only interactions with conventions flexible enough to handle any of several potential input styles. For the moment, that means covering touch-only, keyboard and mouse, or these new touch-keyboard hybrids. It won’t stop there; even more input methods are on their way.

Windows 8 is one of the first ambitious—and imperfect—efforts to try to address this thorny issue. It’s the first attempt at an operating system whose interface can handle any input (from handwriting to speech to touch) and any output (screens of any size or no-screen spoken experiences). That’s a hard problem, and Microsoft is wrestling with it earlier than most of us, but it’s a problem all of us will have to address in the very near future.

Despite their valiant effort, however, Microsoft’s designers still run headlong into a collision of input styles, which is probably unavoidable. You see this, for example, in the difference between the desktop-style Internet Explorer and the Metro-style Internet Explorer. Both are present in Windows 8, and the one you get depends on what mode you’re using. They have very different interfaces, with the desktop layout tuned for mouse and Metro tuned for fingers. The address bar, for example, slips to the bottom for the Metro version, as Matthew Honan describes in his Surface review:

Web browsing works well. I liked having the ability to swap between multiple browser windows by right clicking, but the address bar on the bottom side is something I still haven’t gotten used to. It makes sense when you are using the device in touch mode, because that’s where your thumbs naturally land, but it’s just plain odd with a keyboard.

New Navigation Standards for the Desktop

So how to build this new touch-and-every-other-input desktop experience? This one is going to take some time. Luke Wroblewski and Jason Weaver shared some useful suggestions this week for responsive navigation across touchscreen devices, and it’s exactly the kind of exploration we need.²

I’d add to Luke and Jason’s work a few guidelines to inform how we might evolve our desktop designs:

Pin controls to the left and right edges for easy thumb access on both tablets and hybrids.
Favor the left for primary controls. Most index-finger users use their right hand for poking the canvas, leaving the left hand in place for thumb navigation.
Treat hover as an enhancement, not a requirement.
Make sure all touch targets are large enough to accommodate fat fingers.

As we’ve seen over and over again in the last few years, the growing range of devices and platforms continues to make our work both more exciting and more challenging. Our job is getting harder, but it’s also our job, period. The ideal of the web, after all, is a platform that can be accessed from any device, no matter what its input or output method. For now, that means opening up all desktop layouts for easy finger-tapping.

Luke described the Intel study as part of the fine video series he created for the company about adapting desktop interfaces for touch. ↩
I quibble a bit with Jason’s and Luke’s strict emphasis on bottom corners on tablets and hybrids; I’d nudge those up the side to accommodate more varied thumb grips. ↩

Tags: design, future, hybrid, ipad, mobile, responsive, touch, windows8

Wroblewski's Theorem

Josh Clark — Sat, 21 Jul 2012 17:20:19 UT

Luke sure knows how to spin a meme, and I think he’s got a good one in Wroblewski’s Theorem:

Anything that can be connected to the Internet, will be.

Truth.

Also, while Wroblewski’s Theorem has more weight, I believe Clark’s Theorem may have more universal appeal:

Anything that can be eaten with bacon, will be.

Tags: future, mobile

Touch Means a Renaissance for Radial Menus

Josh Clark — Tue, 17 Jul 2012 18:49:03 UT

Everything old is new these days. A constant parade of new input methods (touch, speech, gesture, facial recognition) demand that designers revisit “settled” ways to build interfaces. New interaction patterns sometimes evolve (yay!), but more frequently it’s a chance to dredge up older methods that never got their fair shake. Exhibit number one:

The radial menu is seeing a renaissance in touch interfaces, and that’s a good thing.

Microsoft yesterday previewed the Office 15 productivity suite [video], including OneNote, its first Metro-style app for Office. (Metro is the touch-based design language introduced in Windows Phone and now set to storm Windows 8 this fall.) OneNote features a radial menu as a kind of right-click contextual menu. Tap the ever-present menu circle, and out pops a wheel of icons to work on your current selection. Here’s a clip from yesterday’s demo that illustrates the action.

Radial menus (sometimes called pie menus or marking menus) have been around since the late 1960s but never really got much traction in traditional mainstream interfaces, with one exception: games. Combat-based RPG games have a particular fondness for radial menus and often use them for quick access to inventory or combat options.

It makes good sense that itchy-trigger-finger games have adopted the radial menu over more typical list-based menus. In games, limiting interruptions is essential to the experience, and radial menus are more efficient than other selection tools. More interfaces should follow the gamers’ example here.

The kind-of-awesomely-named "Game of Thrones: The Game" uses a radial menu to control the action.

Radial Menus Are Fast

Radial menus are faster to access than list-based menus in every kind of pointer-based UI, including cursor, stylus, and touch. One big part of that is because every option is spaced at the same distance from the pointer. That’s classic Fitts’ Law: the closer the target and the bigger it is, the easier and faster it is to hit. (So you know: Fitts’ Law also explains why golf is such a miserable sport.)

Even better: you get faster with radial menus over time, because they take advantage of muscle memory in a way that list-based menus cannot. Radial menus are essentially gesture-based: touch-swipe-release. That’s why some call radial menus “marker menus”: it’s like making a mark on the screen. Swiping to 2 o’clock has one meaning, and swiping to 6 o’clock another. Like all physical actions—playing an instrument, typing a keyboard, serving a tennis ball—gestures get embedded in muscle memory, which is faster to access than visual memory. Tap-swipe is faster than scanning for an item in a linear list, just like touch-typing is faster than hunt-and-peck.

The research on this has been in the can for nearly 25 years. A 1988 study did the comparison and found that for a specific test of eight-item lists, users were faster with radial menus than linear ones. And it turns out that speed only improves.

The application used in 1994 to test stylus users’ increasing speed of radial menus over time. Credit: Bill Buxton and Gordon Kurtenbach.

The more you use radial menus, the faster you become. That was borne out in a 1994 study by Bill Buxton and Gordon Kurtenbach, who tested radial-menu speed with a stylus. Over time, they found that expert users stopped looking at the menu at all. They no longer needed the visual cues and went entirely “blind,” marking the screen with gestures, or “marks,” instead of pecking at buttons:

Using a mark on average was 3.5 times faster than selection using the menu. … A user begins by using the menu, but, with practice, graduates to making marks. Users reported that marking was relatively error free and empirical data showed marking was substantially faster than using the menu. … Marking menus, however, are not appropiate when the list of items changes dynamically. In this situation, users can still use the menus but will never graduate to using marks since menu item locations change.

Wow, great, right? All of which begs the question...

Why Doesn’t Everyone Use These Things?

Like any technique, radial menus have their drawbacks, too.

They don’t scale. You can only cram so many items around a circle. Eight seems to be the reasonable maximum for radial menus.
They’re big. Radial menus swing a big stick and take up a wide swath of real estate. On phones, a radial menu gobbles up a big share of pixels.
First use might be awkward. Despite the evident speed boost that comes with experience, we’re more at ease scanning linearly than around a circle. That’s especially true for content that is naturally ordered in a list. But that comfort level may not be so important when you look at actual use. Back in 1994, Bill Buxton wrote:

When a user is familiar with the layout of a menu, selection from a radial menu will be faster than selection from a linear menu. Callahan et al provide empirical evidence of this for eight-item menus. It is possible that a linear menu may be more suitable when there is a natural linear ordering to the menu items and a user must search the menu for an item before making a selection. Alternatively, a radial menu may be more suitable when there is a natural radial ordering of menu items. However,…the effects of organization disappear with practice. Callahan et al provide evidence that, for eight-item menus, even when menu items have a natural linear ordering, selection using a radial menu is still faster and less error-prone than selection using a linear menu.

Why the Renaissance Now?

Radial menus are starting to trend. Tap Path’s splashy menu button to spray out posting options in a 90 degree radius—a one-quarter radial menu. There’s even some experimentation on the web, where you can find the occasional jquery plugin for radial menus or a CSS3 clone of the Path radial menu.

But the expansive screens of tablets seem to be where radial menus have the most opportunity. Microsoft explored the radial menu’s potential in its never-released Courier tablet. Check out the proposed use of nested radial menus in the first part of this concept video for Courier.

Radial menus are great for touch. Part of this is simply experiential. There’s a subtle sense of magic to touching an object on the screen and seeing options sprout from your fingertip.

But it also works neatly with the touch-driven trend of pulling back on controls, buttons, switches, and menus. In the best touch interfaces, the content itself is the control. The information is the interface. Touch the data itself to manipulate it.

That’s why, while bold and useful, the radial menus in OneNote and Path don’t show off the best face of radial menus.

Liberate Radial Menus from the Button

Why do we have to tap a tiny patch of the screen in order to trigger the Path navigation or the OneNote contextual menu? This feels like a vestige of desktop conventions. Especially for large screens, seeking out and pecking at a small button takes effort and concentration. Big screens demand more finger freedom; big screens demand big gestures.

Just as important, the action of tapping a button is removed from the item we want to work on. In almost every case: We don’t want to act on the button. We want to act on the content.

Contextual menus—which is where radial menus are at their best—should be triggered by touching the object you want to affect, or in some cases by touching an empty part of the canvas, probably with a long press. Many apps trigger contextual menus in this way, but it’s typically via linear lists, like popovers on the iPad. Radial menus may work better for you than popovers.

iPad collage-making app Layout uses a radial menu to display options for manipulating a photo. Touch a photo, get the menu. Screenshot by Judith Leist.

Don’t get me wrong; buttons aren’t evil. They are clear, visual calls to action. Every gesture requires an invitation, and buttons are an efficient way to draw people in, to invite them to touch. But so is the content itself. As we begin to create new conventions for touch interfaces, I suggest the trigger for contextual menus should be the object you want to work on, not a free-floating button.

That gives you the sense of direct interaction with the content. Even better, when you introduce broad canvas-wide gestures, that kind of interaction even allows eyes-free interaction. That gets back to the gesture-based nature of radial menus. As Bill Buxton observed nearly 20 years ago:

Unlike linear menus, marking menus can be operated “eyes free” because selection is based on direction of movement, not position. Hence, they are especially suited to tasks that require attention on other matters (e.g., transport control while watching video).

Radial menus may seem novel, but they aren’t new. It’s just that their time has come. This is more than fashion. This is good interaction design with a wealth of research behind it.

Tags: design, gestures, history, touch, usability, windows8

With iOS Buttons, Know Your Right from Your Left

Josh Clark — Wed, 11 Jul 2012 11:01:01 UT

Back! Done! Cancel! Save! Mobile apps sport a bevy of buttons to dismiss a view, but their proper placement isn't always obvious. Let me cut through the fog: for iOS apps, it boils down to these general rules.

The Back button always goes at top left.
A Done or Save button always goes at top right.
A Cancel button goes at top right, unless paired with a Done or Save button, in which case it slides over to top left.

Here's why. In iOS, the Done, Save and Cancel buttons are almost always used to dismiss a modal view, a screen that temporarily interrupts the action by sliding up from the bottom to cover the "regular" screen. Modal views themselves often have internal navigation that requires a Back button at top left, so those Done/Save/Cancel buttons have to make way. As a result, they stake out a default location at top right. For consistency, they should stay there even when there is no Back button in your modal view.

The inimitable Lukas Mathis spells out the whys and wherefores in his Back Button Placement blog post:

This is reinforced using animations: if something slid in from the right (the user moved further into the currently visible information hierarchy), use «Back» (the button on the left) to move to the left. If something slid in from the bottom (a modal view), use «Done» (the button on the right) to have the currently visible sheet slide back down again. To the user, there’s a spatial system that conveys how screens are arranged, and which button should be used, depending on where she wants to go.

Tags: buttons, design, ios, usability

Grids, Design Guidelines, Broken Rules, and the Streets of New York City

Josh Clark — Tue, 10 Jul 2012 11:01:01 UT

What do the streets of New York City have to do with web and graphic design? For better or worse, the grid.

I finally made my way this past weekend to “The Greatest Grid,” a terrific exhibition at the Museum of the City of New York. The show traces the evolution of New York’s grid street system. I came away with a new appreciation for the ambition and willfulness of the city’s design—but a fresh skepticism for our own rigid adherence to grid design on the web and elsewhere.

The Natural History Museum loomed over empty lots during the expansion of the grid along Central Park West.

Our Story Begins in 1811

That’s when New York’s commissioners outlined a brazen plan to extend the city north from 14th street. They drew streets and avenues across the island without regard to its rugged landscape. And they went big: 155 east-west streets slicing up Manhattan across 12 north-south avenues.

The city grid wasn’t New York’s invention. “The grid was the default approach of surveyors to laying out land: it was logical, repetitive, uncomplicated, and facilitated land division,” the exhibition curators explain. It was an urban pattern that was useful to empires as far back as Rome; impose a grid on a conquered city and you have tidy parcels to dole out to colonists. Savannah and Philiadelphia were American cities that followed that pattern for the same reason: real-estate convenience.

New York’s plan, however, was remarkable in how uncompromising it was. The 1811 grid gave way to nothing except a tiny collection of small parks. Everything was even, everything was regular, and no region of the city escaped this relentless order. (Central Park, not yet imagined, wasn’t part of the plan.)

This was not the fashion of contemporary city design. The great cities of Europe followed a pattern like that of Washington, DC, designed just 20 years before New York’s grid plan was unveiled. While a basic grid underlies Washington’s design, it’s criss-crossed by diagonals and chopped up by frequent squares and parks. The design emphasizes grand boulevards that create vistas for elegant monuments.

New York’s grid provided none of that.

Such distinctive advantage of position that Rome gives St. Peter’s, Paris the Madeleine, London St. Paul’s, New York, under her system, gives to nothing.
—Frederick Law Olmsted, 1877

For six decades after the 1811 plan was released, the city was relentless in imposing its grid on Manhattan, flattening hills, mowing forests, and filling ponds to create the flat expanse we know now. Along the way, farmlands were seized, old roads erased, and property owners enraged. The grid uprooted both the physical and fiduciary landscapes of the city.

Nothing is to be left unmolested which does not coincide with the street commissioner’s plummet and level. These are men…who would have cut down the seven hills of Rome.
—Clement Clarke Moore, 1818

"View of 2nd Ave. Looking up from 42nd St." Egbert L. Viele, 1861. The new streets carved canyons into Manhattan, leaving existing homes on the precipice.

Efficiency = Ease = Profit

So what was gained? Modern New Yorkers won’t be surprised to learn that the essential motive was real-estate profit. Regular city blocks created a dense set of regular property lots, creating a rational market—and overnight fortunes. Better still for developers, rectangular lots made for rectangular buildings: “straight-sided and right-angled houses are the most cheap to build and the most convenient to live in,” city commissioners pointed out. The grid enabled developers to build faster and cheaper.

That’s what visual designers get from the grid, too: efficiency, ease, and cheap builds. No question, a well-deployed grid also bestows order and visual harmony on a layout, and those are worthy goals (perhaps the best goals!) of good design. But when you look around at how we use grids on the web, one has the strong impression that we lean on them more for efficiency than aesthetic delight.

Just like the real-estate barons of the 19th century, we like how grids make orderly subdivisions possible. A grid lets us stretch columns across predefined units, just like city blocks span property lots. Plug those values into a CSS framework and, presto magico, the layout reveals itself. We shift columns across grid units with just a few keystrokes.

I don’t dismiss the importance of efficiency in our design tools, not at all. But I do wonder if web designers aren’t squashing some creative opportunities with our rigid adherence to the grid. Formal grid design is still a newish thing to our field, and we haven’t mastered it.

The Storied History of Grid Design

Draftsmen used grids for centuries to break down their work into manageable stages. Painters deployed grids to create perspective. Graphic designers arrived late to the party, exploring the grid in the late 1950s in a movement championed by the post-war Swiss. Grid Systems in Graphic Design by Josef Müller-Brockmann was the seminal work which, in 1961, changed the entire design practice.

"Draughtsman making a perspective drawing of a woman." Albrecht Dürer, 1525.

The ever-talented Khoi Vinh almost singlehandedly did the same for web design only a few years ago, applying and popularizing this modernist technique for the web. (If you haven’t read his book, Ordering Disorder: Grid Principles for Web Design, you oughtta.)

Out of Khoi’s advocacy emerged the many grid frameworks you know and love. That means we can happily browse blog posts with titles like, “The 25 Best CSS Grid Frameworks.” The extreme popularity of these frameworks invites parody.

But there’s trouble here.

Grids Are the Foundation, Rarely the Design

New York’s rigid adherence to the grid is unusual in city design—so much so that the grid actually becomes the design. It’s an extreme case that creates one of the most unique and identifiable cityscapes in the world. The grid’s dense uniformity creates canyons of skyscrapers, with buildings pushed right up to the sidewalk in walls that stretch for miles. The grid itself is the prevailing design of the city.

That’s not how most designs should work, for cities or otherwise.

Typically, the grid should be a quieter influence, providing the underlying armature but not necessarily restricting every element to its strict borders. Graphic design provides thousands of examples daily. Magazine design elements erupt out of the page grid, pushing text out of the way to flow around rounded or jagged edges. Even newspapers, rigidly devoted to their column layouts, are frequent grid scofflaws whose design elements bust columns and gutters. The grid remains a strong foundation in these examples, but the design overflows its neat boxes.

A layout from Politiken, a Copenhagen newspaper.

Web design tends to be much boxier than most print work—and getting more so. Responsive web design nudges us to fall back to boxy layouts, organizing content blocks that rearrange themselves into new column grids for different screens. As a result, most modern designs mirror the rigid rectangles of their component parts. The design is the grid, and the grid is the design.

We could stand to loosen up.

As we become more confident in the techniques of these dynamically shifting columns, I’m optimistic that we’ll slowly return the grid to its proper role as background guide, rather than foreground design. For now, we’re still figuring out how to make responsive design work at all. Style and art direction will continue to emerge, and we’ll become more playful with our grids.

A proposed feature for CSS, exclusions, would help certainly help. Exclusions let you flow text around shapes, making it easier for web designers to adopt some of print’s grid-busting mojo, for example.

I also like my pal Luke Wroblewski’s experiments with off-canvas layouts which, while still grids, cleverly slide columns on and off screen for mobile devices. The effect is to turn a phone's screen into a magnifying glass that focuses on one section of the grid at a time. The grid remains rigid, yes, but the user floats around it.

Exceptions Make the Design

Winking diversions from the grid elevate the best designs. In the case of New York City, that diversion is called Broadway. The famous boulevard slices diagonally across the grid (and in fact all of Manhattan). Originally an Indian path predating the arrival of Europeans, Broadway is one of the few pre-grid remnants allowed by the 19th-century commissioners.

The Great White Way gives character not only to the city’s map, but also to its street-level view. Broadway creates “bowtie” intersections that challenge architects to extend the intersection’s shape into the sky, into three dimensions. The canyon wall splinters in a moment of relief. Gorgeous.

The Flatiron Building, at the bowtie intersection of Fifth Avenue, Broadway and East 22nd Street.

Rules Are For Breaking

Right from the start, New York’s grid was always contentious, despised by legacy property owners and naturalists, too. The construction of Central Park in the 1860s created a new appetite to preserve what was left of Manhattan’s natural features. In 1867, opponents won a reform of the 1811 plan, making it bend more gracefully to the landscape of undeveloped areas north and west of the park.

As a result, New York’s Upper West Side respects the grid where appropriate, but often breaks ranks to allow streets and parks to curve along steep ridges (Riverside Park, Morningside Drive, Convent Avenue) or waver and wobble across the grid (St. Nicholas Avenue).

The 1867 plan broke the rules of the grid, but did it knowingly, carefully, to preserve a beauty more striking than rectangular order. All designers should be so wise in their work.

Grid systems should be respected but, when appropriate, flaunted. Like any guideline, grids are rules that exist to be broken.

That Goes for Interface Guidelines, Too

For those of us making mobile apps, we should bring a similar canniness to the interface guidelines of companies like Apple or Microsoft. Both companies have minutely detailed guides to what you should and should not do when building apps for their mobile platforms. In both cases, those guidelines helped establish a consistent design language across third-party apps. (The same can’t be said for Android, where guidelines were AWOL for several years, and the platform’s design practice grew in an ungoverned sprawl—New York without a grid.)

In the first years of iPhone apps, few developers strayed from Apple’s guidelines. Offbeat designs like the robot-themed apps from Tapbots went off the grid and were rightfully celebrated. Most app designers, however, hewed to the standard controls, widgets, and navigation systems that Apple provided out of the box.

Over time, designers and developers learn to bend rules. As the iOS developer community matures and grows more confident, we’ve seen corresponding experimentation with new design patterns, gestures, and navigation schemes. The iOS design language is flowering beyond Apple’s design guidelines. The babies are flying from the nest, and with great results.

This hasn’t happened yet with Windows Phone, a younger platform, but I suspect it will. My friend Marco Arment recently suggested that the rigid consistency of Metro app design is a potential weakness of the platform:

If designers create beautiful, rich, iOS-style Metro interfaces, they’ll look garish or out of place. And if they follow Metro’s lead instead, there’s a good chance that everything will look stark, bland, sterile, and undifferentiated.

Assuming neither approach can produce great, desirable designs that fit well on the platform and give designers the creative freedom and differentiation that they need, can Metro’s rigid design language accommodate a middle ground?

I’m more optimistic than Marco here. I believe that the design language will loosen over time, just like it has for iOS. If Windows Phone and Windows 8 are successful, the Metro look will evolve to include “non-standard” designs. That’s the way of things; creative people learn the rules and then build upon them. The first step, though, is to establish those rules. Successful platforms begin with consistency, a sturdy baseline.

The best designers know this: you’re allowed to break design rules as long as you actually know the rules and understand why you’re breaking them.

New York had to build its grid in order to learn the right way to depart from it.

Want More on New York’s Grid?

The exhibition’s catalog is chock full of documents, maps, and photos cataloging the progress of the grid as it crept up Manhattan. You can pick it up at Amazon: The Greatest Grid: The Master Plan of Manhattan, 1811-2011. Recommended.

Tags: design, history, ios, metro, nyc

iOS App Icon Template for Illustrator

Josh Clark — Tue, 10 Jul 2012 03:07:21 UT

Mo' Pixels, Mo' Problems. As Apple's Retina Display screens keep blooming on new devices, the number of app icons developers must generate keeps blooming, too. The new iPad added five new icon sizes:

Application icon (144x144)
App Store icon (1024x1024)
Spotlight search results icon (100x100)
Two sizes of document icons (128x128 and 640x640)

And that brings the final tally to—hang onto your pixels—SIXTEEN different app icons you need to generate for a universal iOS app. Hooboy.

Never fear, though, the sensational Jon Hicks has you covered with his Illustrator template for iOS app icons, freshly updated with the iPad 3 icon sizes (except for document icons). Snap it up.

Tags: design, icons, ios

The 967 Grid System

Josh Clark — Mon, 09 Jul 2012 13:14:27 UT

“Stop thinking, and start designing!” Here at Global Moxie, we’re kinda in love with The 967 Grid System, Jonathan Ogden’s send-up of grid frameworks as well as half-baked nods to mobile design. “One column, one size, one amazing website. The 967 grid is mathematically engineered to bring you less hassle, and less columns. Perfect for single-column websites, or websites with just one column.”

And what about mobile? “The 317px Grid System is a perfect fit for any mobile phone, as long as the screen is bigger than 317px wide. It works much like the 967 grid in that it uses just one column, with the added option of 317 1-pixel columns.”

The stock photo treatments alone are worth a visit.

Tags: design, fun

Survey: Tablets, Windows Phone Hit Tipping Point with Developers

Josh Clark — Mon, 09 Jul 2012 11:01:02 UT

A survey of mobile developers reveals trends in the platforms and motivations that intrigue app builders. The study by VisionMobile asked 1500 developers about their preferred operating systems, their reasons for choosing a platform, and the associated costs of building apps for those platforms.

A few highlights:

Tablets are heating up. More than 50% of developers are now targeting tablets, with iOS developers most likely (74%) to do so.
Windows Phone becoming attractive. A majority of developers (57%) plan to adopt Windows Phone.
Reach over revenue? 54% of developers say user reach most important for choosing a platform; only 30% cite revenue potential.
One in three developers lives below "the app poverty line." 35% of apps generate only $1 – $500.
Apps cost. iOS earns the most for developers, costing an average of $27,000 per app, 21% more than Android.
Apps take time. The average mobile app takes three man months to develop.

Tags: ipad, mobile, stats, winphone

Sync O'Reilly Ebooks to Dropbox

Josh Clark — Sun, 08 Jul 2012 15:48:25 UT

My publisher O'Reilly Media just rolled out a nifty feature, letting you sync your O'Reilly ebooks with Dropbox. Buy a book, and it pops up in your Dropbox automagically. You can choose which of the many available formats to sync (ePub, PDF, Kindle, DAISY, or Android), all of them DRM-free.

And hey, your first test run might as well be with my book, Tapworthy: Designing Great iPhone Apps, if I may be so bold. If you have the print edition but not the ebook version, you can snap up the ebook for just $4.99. Just register the print book with O'Reilly, and you'll see the option to "upgrade" to ebook on your products page.

Got it? Start syncing that awesomeness to Dropbox.

Tags: publishing, tapworthy

"Small Screens, Big Changes": Full-Day Mobile Workshops in Europe

Josh Clark — Mon, 23 Apr 2012 21:18:44 UT

Karen McGrane and I are taking a European road trip. We’re leaving the backpacks at home, though, and instead bringing mountains of mobile know-how.

We’re teaming up to give full-day workshops in three cities—Amsterdam, Hamburg, and Barcelona. Karen McGrane, as you no doubt already know, is a whip-smart (and hilarious) content strategist and internet genius. She’s also author of Content Strategy for Mobile, a forthcoming book from A Book Apart. She’ll be delivering the goods on how to navigate content strategy in a multichannel world, while I’ll focus on crafting finger-friendly touchscreen interfaces.

It’s a heckuva one-two punch. Actually, scratch that. IT'S A FRICKIN' MOBILE KNOWLEDGE EXPLOSION.

The sensational Karen McGrane.

You can register and get more details here: “Small Screens, Big Changes: A Full-Day Mobile Workshop with Josh Clark and Karen McGrane.” But before you head over, here’s the quick gist:

Mobile represents a massive shift in how users interact with content and interfaces. Are you ready? Spend a whole day learning how to make the most of mobile.

Designing for Touch. The morning session with Josh Clark presents nitty-gritty “rule of thumb” design techniques that together form a framework for crafting finger-friendly interface metaphors, affordances, and gestures for a new generation of mobile apps that inform and delight.

Content Strategy for Mobile. The afternoon session with Karen McGrane explores the challenges and constraints of presenting content in mobile interfaces and contexts. Desktop websites have gotten cluttered with useless information that doesn’t meet user needs. Mobile offers an opportunity to re-prioritize messages, rewrite jargon, and remove outdated information. You’ll learn how to use mobile as a wedge to create a better experience for ALL users.

Three Cities

The workshops run from 10am to 6pm each day, with lunch included.

Extra Bonus Talks!

Whether or not you attend the workshop, you’re invited to join Karen and me for a free mobile salon. The evening before the workshop in each city, we’ll each give a talk while we ply you with delicious and intoxicating liquids. Details and venues are coming soon. Watch the workshop website, or follow along on Twitter.

Hope to see you in Amsterdam, Barcelona, or Hamburg!

Tags: content strategy, josh, karen mcgrane, mobile, touch, workshops

Mobile Isn't the Lite Version

Josh Clark — Fri, 13 Apr 2012 16:04:56 UT

Jakob Nielsen's dubious guidelines for mobile websites got a rise out of me this week. After conducting usability tests on hundreds of websites, his advice included these guidelines, all of which made me shudder:

Build a separate website for mobile
Cut features to eliminate things that are not core to the mobile use case
For removed content and features, link to the desktop site

I don't doubt his research, but I do doubt its assumptions and conclusions. The notion that mobile should be a lite version of the "real" and complete desktop website is a popular one, but wow is it problematic. It makes a host of assumptions about what the mobile use case is that I find to be out of step with how smartphones are actually used.

So when .Net magazine sent me a note to ask me my thoughts about his recommendations, a quick email response turned into an email essay. The editors asked if they could publish my email as its own opinion piece, which they published under the uncomfortably provocative title, "Jakob Nielsen is wrong on mobile." An excerpt:

Nielsen is confusing device context with user intent. All that we can really know about mobile users is that they’re on a small screen, and we can’t divine user intent from that. Just because I’m on a small screen doesn’t mean I’m interested in less content or want to do less.

Stripping out content from a mobile website is like a book author stripping out chapters from a paperback just because it’s smaller. We use our phones for everything now; there’s no such thing as “this is mobile content, and this is not.”

Read the rest of my thoughts and concerns here.

For what it's worth, I do wholeheartedly agree with one of his recommendations, which is to defer secondary information to secondary pages. The web has made us skittish about extra clicks or taps, thanks to network latency. But in many cases, crafty caching, and pre-fetching reduce that problem so that there's no latency between taps. Instead, you organizing screens for a single idea or action works well. Tap quality, in other words, is more important than tap quantity.

So, yeah, feel free to reprioritize content for different devices, but don't start cutting content and features willy-nilly. Mobile isn't a lesser platform than desktop; it's just one of many platforms among equals.

Update: .Net posted Jakob Nielsen's response to the criticism, and I'm afraid my mind isn't eased. His counsel — "If users do want the longer and more complex information, they are always able to click through to the full site" — feels more like an admission of defeat than a content strategy. Also, his suggestion that user experience can be separated from technical implementation worries me. More than ever, UX designers have to have a sophisticated notion of the possibilities and drawbacks of various technical approaches in order to properly craft a stunning experience.

Tags: content strategy, design, mobile, responsive

Designing for “Context” Is Tricky Business

Josh Clark — Fri, 09 Mar 2012 03:54:42 UT

“Designing for context” is a popular phrase these days, and it makes me a little antsy. Designers often conflate device context with user context—or worse, with user intent. “This is mobile, so they’ll never want to do that.” ”This is mobile, so it’s aimed only at users on the go.” Friends, this is hooey.

I shared a few thoughts about this on Twitter last night, and Scott Klein helpfully gathered them into a single view at Storify. For what it’s worth, I thought I’d post ‘em here, too:

Tags: design, mobile, psychology

“Buttons Were an Inspired UI Hack, but Now We’ve Got Better Options”

Josh Clark — Thu, 08 Mar 2012 19:30:41 UT

The good folks at O’Reilly interviewed me this week about how new technologies change how we should think about interface design as both consumers and designers. It's a long interview, but here's a quick excerpt:

It's a really exciting time for interaction design because so many new technologies are becoming mature and affordable. Touch got there a few years ago. Speech is just now arriving. Computer vision with face recognition and gesture recognition like Kinect are coming along. So, we have all these areas where computers are learning to understand our particularly human forms of communication.

In the past, we had to learn to act and think like the machine. At the command line, we had to write in the computer's language, not our own. The desktop graphical user interface was a big step forward in making things more humane through visuals, but it was still oriented around how computers saw the world, not humans. When you consider the additions of touch, speech, facial expression, and physical gesture, you have nearly the whole range of human (and humane) communication tools. As computers learn the subtleties of those expressions, our interfaces can become more human and more intuitive, too.

Touchscreens are leading this charge for now, but touch isn't appropriate in every context. Speech is obviously great for the car, for walking, for any context where you need your eyes elsewhere. We're going to see interfaces that use these different modes of communication in context-appropriate combinations. But that means we have to start thinking hard about how our content works in all these different contexts. So many are struggling just to figure out how to make the content adapt to a smaller screen. How about how your content sounds when spoken? How about when it can be touched, or how it should respond to physical gestures or facial expressions? There's lots of work ahead.

Here's the whole thing.

And hey, if this stuff interests you and you happen to be in Austin for SXSW this week, I'm giving a talk about the future of touch-based interfaces on Friday. In particular, I'm focusing on how you can use gestures to create experiences that are more fun, more intuitive, and more efficient. At least as important, the talk will explore how to make gestures easy to discover, too:

Teaching Touch: Tapworthy Touchscreen Design
Friday, March 9, 3:30–4:30pm
Ballroom A, Austin Convention Center

Discover the rules of thumb for finger-friendly design. Touch gestures are sweeping away buttons, menus and windows from mobile devices—and even from the next version of Windows. Find out why those familiar desktop widgets are weak replacements for manipulating content directly, and learn to craft touchscreen interfaces that effortlessly teach users new gesture vocabularies.

The challenge: gestures are invisible, without the visual cues offered by buttons and menus. As your touchscreen app sheds buttons, how do people figure out how to use the damn thing? Learn to lead your audience by the hand (and fingers) with practical techniques that make invisible gestures obvious. Designer Josh Clark (author of O'Reilly books "Tapworthy" and "Best iPhone Apps") mines a variety of surprising sources for interface inspiration and design patterns. Along the way, discover the subtle power of animation, why you should be playing lots more video games, and why a toddler is your best beta tester.

See you there!

Tags: design, gestures, josh, sxsw, touch

3.1 Million Pixels Are Heavy

Josh Clark — Thu, 08 Mar 2012 19:01:36 UT

As everyone in the world knows by now, Apple bumped the iPad's screen to retina-display density, quadrupling the number of pixels to a whopping 3.1 million. That's fantastic news for iPad owners—the display will be gorgeous—but it also means more headaches for designers and a potential blight on your bandwidth bill and download speed.

In bandwidth terms, pixels are heavy, and four times the pixels means four times the image size for bitmap images, give or take. If you want to take advantage of this gorgeous screen, every image you push down the wire is about to put on a ton of weight. That has implications in lots of places.

Trouble for magazine publishers

For utterly understandable business and workflow reasons, a vast number of publishers have adopted platforms like Woodwing and Adobe's Digital Publishing Suite.¹ Trouble is, these tools publish images of pages, not actual text-and-image layouts. They're giant bitmaps.

These big bundles of pixels already make for mammoth file sizes for individual issues, and downloads can take a long time. (Apple's Newsstand does its best to make this invisible by downloading issues in the background for you.) For publishers who want to take advantage of the new iPad display—that is, all of them—they're gonna see these already giant files quadruple in size. As David Sleight wrote this morning:

Now apply the volumetric increase in pixels that’s upon us, and it’s easy to see why the size of an average iPad magazine issue is about to go through the roof. Very roughly speaking, a single page of text built this way and saved using light JPG compression weighs in at around 150-350kB. At the new Retina dimensions these same app platforms will generate pages on the order of 2MB. That’s per page.

This isn’t just a question of the bandwidth these apps will devour while downloading issues, it’s also a question of whether or not a user can actually store these things anywhere. The screen volume may have quadrupled, but the new iPad still ships with the same three memory options: 16, 32, and 64GB. As I noted on Twitter, the growth rate of the potential payload size just outgrew the growth rate of device storage exponentially.

This is obviously untenable, and publishers either have to start thinking (and fast) about new tools and workflows, or toolmakers need to start thinking about generating these app magazines in leaner formats. A recent briefing from Condé Nast hinted that Adobe is starting to move to HTML5 layouts for its tools. That would be good news for file sizes and would almost certainly benefit the reading experience, too. Readers would finally be able to select text, copy it, resize it, and so on.

But that still won't get us completely out of the woods. Web technologies like HTML5 are going to have issues to manage with a retina-display iPad, too.

Trouble for responsive designers

Building just one website for all devices and platforms should be the ideal for every webslinger, the starting point for every project. Ask yourself: can we create just one base set of HTML and then use responsive design and progressive enhancement to gracefully adapt that HTML to any screen? (This one-web approach isn't always practical, and as always, it depends on the project.)

As an industry, we're still learning the right way to do responsive design, and one of the big sticking points is how to cope with images. While it's easy enough to make the browser resize a big image to fit a tiny display, bandwidth concerns suggest we shouldn't send that big file to devices that can't use the extra pixels. The new iPad only magnifies this problem. Sending a full-screen iPad image (1536x2048) to an iPod Touch browser (320x480) is overkill to the tune of 25 times the file size. Over a wireless connection, that's gonna smart.

This isn't a new problem. Folks at the forefront of mobile web design have been wrestling with this responsive-image problem for the past year. How do we nudge the server to send a properly sized image instead of sending a giant one-size-fits-all file?

We don't have a good answer yet. Jason Grigsby has outlined a slew of techniques (and more and more), none of them perfect, and Matt "Wilto" Marquis suggests a way forward by extending HTML itself. Whatever the ultimate solution, though, that means image editors will have to start adding more and more cut sizes to their server-side arsenal. And yep, that means:

Trouble for content creators

I recently did some work for a magazine website. Over the years, their various image contexts had sprawled so that they were doing as many as ten different crops and sizes for any one photo. Thumbnail images, gallery images, primary and secondary article images, you get the idea. Lots of image sizes to accommodate various layouts. This had all evolved in a single-platform environment—the desktop—and didn't even begin to contemplate the varied screen resolutions of the desknot devices of recent years.

Here's the kicker: for all those image sizes, almost all were too small for mobile. You heard me right. Max image dimensions of 600x600 have, until recently, been plenty big for a website. On the desktop, that's pleasingly large, even for a magnified view. But that won't even fill the screen of a retina-display iPhone. The physical dimensions of the latest phones might be small, but the screen resolutions of some desknots are much higher than the desktop. Cut sizes have to adapt to match those resolutions.

To accommodate the iPhone and iPad, the magazine created a new cut size, up to 768x1024. But now they'll have to consider adding at least another cut size, perhaps several. Some of this work can be automated, sure, but in many cases, adding new sizes means adding new crops, and that's necessarily manual editorial work. So the growing variety and size of screen resolutions means more work, more disk space, more database management.

Trouble for iOS designers

And finally, of course, we've got more work for iOS designers. As they did for iPhone 4 and 4S, designers will have to generate yet more image sizes for icons, app graphics, and so on. The already large list of icon sizes for a universal app has just grown. Louie Mantia kindly shared a Photoshop template cheatsheet to help you keep track of your icon efforts.

Don't be glum: this is awesome

Look, this is hard work. We have tons of devices to support, and we have to create designs and assets that not only fit their new screens, but also fit the new interaction models of each. Our job is getting harder, and this is only the beginning of it.

But man, it's in the service of something really incredible. The proliferation of devices is all in the service of creating technologies that adapt to our specific contexts. Beautiful tablet screens, speech interfaces, gestural interactions—all of these things are going to tax us as designers and content creators. But wow, such creative opportunities! As both a user and a designer, I for one welcome my new 3.1-million-pixel overlord.

Woodwing and Digital Publishing Suite tools are essentially plugins for Adobe InDesign. They let you convert print issues into reasonably interactive iPad editions. That lets publishers use the same essential designs, workflow, and staff to sling print content onto the iPad platform. The process has tons of disadvantages from a UX perspective, but I'm sympathetic to the decision to use them. These tools represent a transitional stage that allowed publishers get on the iPad (relatively) quickly and (relatively) cheaply. The next phase is about figuring out how to create experiences that feel more native to tablets, or whatever platform publishers choose to target. First-generation tools like Woodwing and Digital Publishing Suite are a necessary evil. ↩

Tags: apple, design, ipad, mobile, responsive, webdev