Global Moxie

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

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.

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

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

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

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.

1. The Back button always goes at top left.
2. A Done or Save button always goes at top right.
3. 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

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

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

“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

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

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