When screens are small and used in our hands, touch screens make a lot of sense. They essentially turn the entire mobile device (not just the keypad or trackball) into an interactive surface. As a result, touch is being integrated into more and more mobile devices each day. Looking at the percentage of Nokia’s smartphones that support touch illustrates this story very well (fig 5.1).
Fig 5.1: Nokia’s smartphones illustrate the transition to touch in mobile devices. (Source: Nokia)
While some of these devices have hardware input controls like trackpads, trackwheels, and keyboards, it’s touch that increasingly manages people’s interactions with the web on mobile. So how can we ensure everyone is able to interact with our sites using touch? Designing the right affordances and controls for touch-based user interfaces requires:
It’s not uncommon for web designers to respond to smaller mobile devices by shrinking things down in order to fit them on screen. After all, there’s less room to work with, so smaller is better, right? Despite the soundness of this reasoning, you actually want to move in the opposite direction and make things bigger—often even bigger than you’re naturally comfortable with (fig 5.2).
Fig 5.2: Actions on YouTube’s mobile web experience are big enough to use with one thumb and few errors.
Human fingers are imprecise pointing instruments: they lack the pixel-level accuracy of a mouse pointer; they come in different sizes; and it’s not uncommon for them to slip or move around as we interact with our devices. Bigger actions mean bigger touch targets that help people get things done when they are in “one eyeball and one thumb” mode.
Just how bad is it? One study found that almost half of mobile app users are more likely to tap an ad by mistake than intentionally. Appropriately sized and placed actions (and thereby touch targets) can help people tap with confidence and accuracy. So just how big is just right?
In their iOS Human Interface Guidelines, Apple recommends making touch targets 44×44 points. They use points instead of pixels to deal with differences in screen density, which we’ll discuss in more depth later on. To account for screen density (or ppi) variations, it’s better to measure touch targets in physical dimensions.
Microsoft takes this approach in their Windows Phone 7 Guidelines by recommending 9mm touch targets, a minimum size of 7mm, and a minimum spacing between actions of 2mm. Other touch-UI guidelines from Nokia (and even Ubuntu) fall in the same range because they all take the average size of people’s fingers into account. MIT’s Touch Lab determined that average to be 10–14mm for finger pads and 8–10mm for fingertips.
Taking these touch-target sizing recommendations into account doesn’t necessarily mean every icon and button on your mobile page needs to be exactly 9mm wide and 9mm tall. The touch target itself should fall in this range, but the visual representation of the action can be 50–100% of the actual touch target size. The image from Microsoft (fig 5.3) illustrates the use of padding or margins to ensure targets are the right size without having every visible user interface element appear the same.
Fig 5.3: Microsoft’s Windows Phone 7 Touch target guidelines.
Microsoft’s guidelines also do a nice job of specifying when touch targets may need to be bigger than 9mm: if “the UI element is frequently touched; the result of a touch error is severe or really frustrating; the UI element is located toward the edge of the screen or difficult to hit; or when the UI element is part of a sequential task—like using the dial pad.”
When it comes to what we touch on mobile, bigger is generally better. Ensuring actions are appropriately sized and spaced apart can avoid serious usability issues as well—not just accidental slips of the finger. Take a close look at the mobile login screen of Q&A site Quora (fig 5.4). Notice any potential problems?
Fig 5.4: Quora’s login screen places “cancel” and “Login” much too close for touch-target comfort.
That’s right, in this case poorly sized and spaced actions (remember 2mm between touch targets!) mean the difference between logging in and canceling out.
Flickr’s advanced search screen is another example of being too close to touch comfortably (fig 5.5). The size and spacing between each search option could definitely benefit from “bigger is better.”
Fig 5.5: Flickr’s Advanced Search options are too close together and too small to tap accurately.
When talking about the placement of navigation controls earlier, I mentioned that actions toward the bottom of the device naturally align with how people hold and use their mobiles. Well, there’s a bit more to it than that. Where you expect to find primary actions on a touch-screen mobile often depends on which fingers (thumb or index) you are using for tapping and if you are right or left-handed.
Since the majority of people are right-handed (about 70-90%) and use their thumbs while operating a mobile with one hand, optimizing for right-thumb actions is most common. This means primary actions can be placed in the middle or bottom of the screen and arranged from left to right (fig 5.6).
Fig 5.6: While holding a touch screen phone with only your right hand, it’s easy to hit the dark green area and a stretch to tap the yellow area with your thumb.
Destructive actions like cancel or delete can be placed outside people’s comfort zone. If you’re holding a mobile device in your right hand and using your thumb to operate it, getting to the upper left corner is a stretch. It’s uncomfortable and you have to work for it. It’s perfect for making you think twice about deleting all the hard work you just did.
While touch targets can ensure we have appropriately sized actions on our mobile web experiences, touch gestures give people a way to interact with them. Despite different terms and documentation for touch gestures in the various mobile platforms out there today, there’s a good deal of consistency in the gestures we can expect people to use on our mobile web experiences.
To better understand what’s available, Dan Willis, Craig Villamor, and I combed through the documentation for:
Thankfully in our audit we found more consistency than diversity. In fact, there’s a set of core touch gestures that are common across most touch platforms. These gestures form the basis of how you can expect people to interact with touch screens; they include: tap, double tap, drag, swipe, pinch, spread, press, press and tap, press and drag, and several variations on rotate. And because of spotty multi-touch support and “reserved” system actions in some mobile web browsers, this list can be even further reduced for mobile web experiences to tap, drag, and swipe (fig 5.7).
Fig 5.7: Core touch gestures: basic gestures for most touch commands.
While it’s useful to know what touch gestures are possible, it’s even better to have a sense of how people are using these gestures to interact with touch-based user interfaces. In other words, if someone wants to take action on an object or screen, or to navigate between objects and screens, which touch gestures are they mostly likely to use? The Touch Gesture Reference Guide created from our initial audit answers these questions and more (fig 5.8).
Fig 5.8: A sample of user actions and the gestures that support them.
You can get a sense of how the guide is organized in these examples. It starts with what someone hopes to accomplish, such as changing modes, deleting an object, or scrolling a list. Next to each of these potential actions are the most commonly supported (and increasingly expected) gestures used to get it done.
The Touch Gesture Reference Guide is freely available and includes templates for every core gesture in PDF, EPS, OmniGraffle, and Visio so you can use them in your wireframes, mock-ups, and prototypes as well. So have at it!
Widespread adoption of touch UIs is really just happening now, which means we can expect to see new touch-based design solutions continue to emerge. Gesture-based actions like “pull down to refresh” often start out in a single application, slowly become adopted in more places, and over time become expected by the people using your sites. So don’t be afraid to experiment with what gestures can do (fig 5.9–5.10).
Fig 5.9: Yahoo! Mail’s mobile web experience allows people to use touch gestures to reveal mail actions and pull down to expose search. Because there are no visible affordances for these gestures, they introduce people to them in an overview up front.
Fig 5.10: Twitter’s mobile web experience allows people to use the drag (down) gesture to refresh the screen.
I, for one, welcome our NUI overloads. That is, I believe in the potential of natural user interfaces (NUIs) to push us toward a new era of computing. NUI principles—such as make content the user interface; enable direct interactions with content not chrome; and reduce visuals that are not content—drive us toward a more direct way of interacting with digital information and media.
Gone are the days when you need to make use of windows, icons, menus, and pointers (WIMP) to zoom into a photo. Simply touch the photo and spread your fingers apart to make it bigger. This direct interaction is not only easier to learn (just ask all the kids and grandparents on iPads) but more reflective of how we actually interact with the real world as well.
As great as that sounds, we’re still in a transition period between graphical user interfaces (GUIs) and NUIs. As a result, actions that rely solely on gestures might not be immediately discoverable by everyone using our web experiences. So for now, we may need to stick with buttons for the primary actions in our mobile web experiences. But that’s no reason not to experiment with gestures in other parts of our sites, like advanced controls or shortcuts.
When you do, try to align with natural gestures (those common to us in our daily lives) in order to aid discovery. A recent study across nine different countries found very few cultural differences in the gestures people attempted to use for common tasks. So when it comes to touch, we have a lot in common.
Lastly, visible affordances, tips, and animations can help ease the transition as well. You can start out by using these interface elements to explicitly call out where gestures are possible, then gradually reduce their presence as people become more familiar with where they can use gestures to get things done. Just be aware that when you’ve got too much help text explaining how things work, the gesture-based interactions in your app might not be as natural as you think.
Also make sure you set the right expectations about gestures. Though the NBA scoreboard on ESPN’s mobile web experience above looks like it can be swiped, you actually have to use the arrows to move between scores (fig 5.11).
Fig 5.11: ESPN’s mobile web experience uses a visual affordance common to swipe gestures, but this particular menu can’t actually be swiped.
Since we’re on the topic of tips, it’s worth noting that any tips or actions that happen “on hover” (when a mouse pointer is positioned over a trigger) won’t work the same way on touch-only devices. Quite simply, there is no pointer to position over an interface element. There’s just our fingers, and though they cast a shadow, no mobile device I know of considers that a hover yet.
Therefore, any actions that rely on mouse hovers in our desktop web experiences need to be rethought—and that’s a good thing. Many uses of hover actions on the web assume too much. Just because someone places their mouse cursor over something doesn’t mean they are asking for a pop-up menu of actions and options (fig 5.12). Unlike clicks, hovers are usually not explicit actions.
Fig 5.12: Placing your mouse cursor over a book’s title on Barnes & Noble’s website brings up a pop-up window with just a bit more info.
On-hover menus on the web have also become dumping grounds for actions not deemed important enough to be on the screen but still important enough to reveal on hover. Often that amounts to a miscellaneous bin of options that really don’t have a place as primary controls on a screen. These hovers won’t be missed when you make the transition to mobile.
On mobile, your options for on-hover menus are: on screen, on tap/swipe, on a separate screen, or (my favorite) gone for good.
If what’s in a hover is important enough, taking actions and information out of on-hover menus and placing them directly on the screen could be the right approach. This is the solution Twitter used on their original mobile web experience.
On the desktop, placing your mouse over a message on Twitter reveals several important actions: Favorite, Retweet, and Reply (fig 5.13).
Fig 5.13: Hovering over an update on Twitter reveals a few additional actions.
Twitter thought these actions were important enough that in their mobile web experience, they placed them directly on the screen (fig 5.14).
Fig 5.14: Twitter’s original mobile web experience made Favorite, Retweet, and Reply visible at all times.
Depending on the mobile web browser, if you do nothing with the hover menus on your existing website, they could be turned into on-tap menus by default. This might be good if the actions or content in the hover menu are a logical next step for people. But it could be annoying if the hover menu content introduces an unneeded extra step that gets in the way of people’s progress.
Swipe gestures are less discoverable than tap and likely require some extra development work to get right, but they won’t get in people’s way like on-tap actions that aren’t part of a logical sequence. If you do use swipe gestures, you may want to include an affordance—or light animation—to let people know how things work (fig 5.15).
Fig 5.15: As we saw earlier, the Yahoo! Mail mobile web experience has an overview that highlights its swipe feature.
It’s also important to note that actions and information revealed using a non-obvious touch gesture (like a swipe), should have some alternate way of being accessed. In Yahoo! Mail, the actions revealed on swipe are also included on the full email screen (fig 5.16).
Fig 5.16: Yahoo! Mail’s touch gesture shortcuts are also present on the message screen.
If the content within a hover is extensive, it may be best to move what’s inside the hover menu to a separate screen on mobile. This is the approach used by Barnes & Noble (fig 5.17). What used to be a large (and annoying) hover menu on their desktop site is now a separate page on their mobile web experience.
Fig 5.17: The content in the hover menu on the desktop is a separate screen on the mobile website.
If there was never any value in your hover menus to begin with, just get rid of what’s inside them entirely. Removing extra options and information that’s not valuable to your customers not only simplifies your product’s user interface, it also gives you less to develop and maintain over time. So don’t be afraid to toss those hover menus out.
Whichever approach is right for you, just make sure when you go mobile your hovers have been covered.
Just when you thought we were done: covering hovers also includes thinking about and designing for non-touch and hybrid devices as well. Mobiles with indirect manipulation modes for input—such as trackpads, trackballs, keypads, scrollwheels, and physical keyboards—allow you to use the web without getting your fingers all over the screen.
When people navigate a web page using these types of intermediary controls, the CSS :hover state can be used to highlight the currently focused interface element without using JavaScript. While it may be better to set a style for this mode using the :focus state, many websites don’t specify an implicit :focus state. So mobile browsers like OperaMini, do the best they can and use :hover to let people know which element is currently actionable from those visible on screen.
All the actionable links, buttons, and menus on your mobile web experience can benefit from having explicitly defined :hover and :focus states. This will provide valuable feedback to anyone using your site or application through indirect manipulation hardware on a mobile device.
But when thinking about non-touch mobile devices, we don’t just have to worry about focus. While most of the big smartphone manufacturers have fully embraced touch, not all the devices they released in the past and will continue to ship in the future have touch screens. On these devices, appropriately sized touch targets will take up too much room (as non-touch mobile devices often have smaller screens), and touch gestures will be non-existent. So we need to adapt.
The layout techniques we will discuss later in the book can help your sites adjust to make interactive targets smaller, while thoughtful uses of progressive enhancement can ensure basic interactive actions still work. But I promised not to get into development and to keep this book short, so I’ll save the overview of progressive enhancement to people more qualified than me.
As more touch-screen mobile devices get into people’s hands, we need to make sure they can use our websites with their hands. To do so:
Now that we’ve covered the basics of actions, let’s turn our attention to the most important action of all: input.