Considerations for Mobile Design (Part 3): Behavior

This article is a part of a series:

  1. Part 1: Speed
  2. Part 2: Dimensions
  3. Part 3: Behavior
Considerations for Mobile Design: Behavior

How do users behave different on touch-based interfaces, and how can you start implementing new gestural actions into your mobile web products.

As we conclude our series, Considerations for Mobile Design, we wish to spend a little time looking at how users behave differently on handheld devices compared to desktops and laptops. In this final part of our introduction to mobile design, we explore how touch interfaces are different from more traditional means of user input, and how designers can start implementing new gestures into their own products.

Click vs. Touch

On desktops, we click. We pilot a tiny cursor, control it as it flies across the screen, and precisely hit the targets we’re aiming for. There might be an occasional misclick, but even then, reversing our actions in a web browser is typically easy to do.

On handheld devices, we tap. Our hands become the main input of the device, and our hands aren’t as nimble and precise as a mouse cursor. We touch areas of the screen rather than an exact pixel. We readjust the grip on our smartphone as we attempt to hit a button with the same hand. When there is a mistap, the consequences are more time consuming; slower page load times, and slower device speeds make the wait less forgivable.

We readjust the grip on our smartphone as we attempt to hit a button with the same hand. When there is a mistap, the consequences are more time consuming; slower page load times, and slower device speeds make the wait less forgivable.

In an effort to aid users in navigating mobile interfaces, some groups have determined the average tap size. Using these averages, we should be able to build interfaces that are easier to use, and result in fewer mistaps.

Apple suggests that a minimum of 44×44px pts (thanks Vicente!) should be used for tapping. According to Apple, this is the average area of a finger tap on their mobile devices.

The UI Design and Interaction Guide for Windows Phone 7 (.pdf) suggests using at least 9mmx9mm for tapping (which on Windows Phone 7 devices translates to about 34x34px). At least 2mm of space (or 8px) should be given between controls. With the introduction of more devices with high resolution displays (like the iPhone 4), measurements that describe physical space may be more useful than pixels since pixels per inch varies by device..

These are great benchmarks to base our own interactive elements on. We can say things like, all touchable items on the page should be at least around 40x40pts, and should be at least around 10pts away from other touchable items. Simple enough.

What’s really important to take away from this is that your controls need to facilitate touch interaction. This might mean giving links in content body extra padding so they’re easier to tap. This might also mean you need to add extra space between items in an ordered list of links.

The importance of implying touch

It probably goes without saying, but in the same way that links should look like links on desktop browsers, touchable items should look like touchable items on handheld devices. In fact, it’s probably even more important. Aside from mistakes typically taking longer to correct on mobile devices, there is no such thing as a mouse hover. In other words, a user can’t check to see if something is tapable by hovering over an item on a page and checking to see if a cursor changes to a pointer.

Andrew Maier has written in the past about creating usable links and buttons.

Form interactions

While there isn’t widespread support across mobile devices yet, declaring input types will certainly be important in form design moving forward. Some devices (such as iOS 4 and Android 2.2 devices) already have some support for the latest input types outlined in the HTML5 spec.

A big reason to be using these new input types is to provide contextual interfaces for entering data. In other words, if I click an input with “type=number”, show me a number pad instead of a full QWERTY keyboard. If I’m using a “type=url”, get rid of the spacebar, and make symbols like “.” and “/” more prominent.

In addition to speeding up data entry, these additional field types limit possible errors. It’s hard to accidentally type a letter in an input if only numbers are allowed.

Details on the newly introduced types can of course be found on w3.org, but a few common useful types are shown below:


<input type="text" />   <!-- Default text entry -->
<input type="email" />   <!-- Email addresses -->
<input type="url" />     <!-- URLs -->
<input type="tel" />     <!-- Telephone numbers -->

Different keyboard types on the iPhone.

Several different keyboard types from the iPhone OS. (From iOS Developer Library)

Pete Freitag has put together a pretty handy demonstration of support for these contextual controls on iOS 4 and Android 2.2 devices.

These controls are super easy to implement, and will definitely expedite data entry for the on-the-go mobile user.

New user behaviors

If you use a touch-enabled handheld device already, chances are that you’re accustomed to actions like pinching, flicking, and sliding. In fact, these gestures might seem very natural in some applications (ie: zooming in on a photo by stretching it out with two fingers).

There are a few frameworks out there that have made integrating these actions into your own applications pretty simple. jQuery Mobile is one such framework, and one that many already have experience with. Quite a few events are offered in the framework by default, and using the existing code additional events can be added in pretty easily (like Swipe Up and Down).

In addition to these sorts of events, jQuery Mobile makes page transitions, layout development, dialogs and more far easier to create for mobile devices.

jQuery mobile also offers a layout system with progressive-enhancement driven form controls

jQuery mobile also offers a layout system with progressive-enhancement driven form controls.

When should you use new input methods?

imgur allows users to upload files by dragging a photo directly from the desktop into the web browser.

imgur allows users to upload files by dragging a photo directly from the desktop into the web browser.

A relatively new convention on desktop browsers is the ability to drag and drop files from your desktop directly into a web page. Gmail allows this (but doesn’t it make it obvious to users that don’t already know about it), as well as several image sharing sites like Imgur.com.

Because this isn’t a very common interaction, it requires explaning. You wouldn’t simply start dragging and dropping files from your desktop to a browser to upload a file (usually). You either already know that this site accepts that type of input, or the site has done a good job explaining that this is a possible interaction.

It’s not a mature convention yet. There isn’t a commonly accepted way of visually communicating this input type… though a few are surfacing.

On the other hand, there already exist a lot of very practical conventions in web design. Obviously, underlined text (usually a separate color from surrounding text) constitutes a link. Modals can usually be closed by clicking outside of the modal area (or by hitting a close button). The list goes on…

Windows Phone 7 devices often let content overflow the right edge of the screen to communicate that the viewport can be panned with a swiping motion.
Photo Credit: Cedric Chee

Returning to mobile design, the same holds true: while many clever new interaction types like “swiping” can potentially offer great solutions to UI design problems, they’re still very new gestures. People aren’t used to “swiping” in a browser. Does swiping on one site do the same thing on another site? Does swiping affect an entire page, or is it used inside of a containing element?

These new interactions in the immediate future need to be taught to the user. Also, you most likely should not be going out of your way to cram every possible type of gesture into your trendy new app. Only use these newer types of input when you truly believe they make sense. There’s no sense in reinventing the wheel if no one knows how to use it.

Moving forward

This wraps up our series on Considerations for Mobile Design, but this is merely a stepping stone for people who are just beginning to wrap their heads around the mobile web. If you’re like me, you may have have been dismissing the mobile web for the past few years. For some of us, it just didn’t feel quite ready to handle complex applications with rich user experiences.

If we’re not at a point where the mobile web is ready today, we’re certainly very close. Between device availability, high speed connections, and new web technology, the groundwork is in place (or at least falling into place) to develop new generations of web-based applications that assist us, travel with us, and connect us with others at all times.

Between device availability, high speed connections, and new web technology, the groundwork is in place (or at least falling into place) to develop new generations of web-based applications that assist us, travel with us, and connect us with others at all times.

There are a few resources that I’ve found useful in discovering more about mobile design that you might also find interesting:

There are also quite a few books out there on the subject of mobile web design, many widely applauded. However, the mobile web landscape has changed (and continues to change) so quickly that much of the information written about the mobile web even a year ago is no longer relevant. I would strongly encourage focusing on recent articles and publications to avoid misinformation.

And of course, the UX Booth will continue to discuss the mobile web as it continues to gain momentum. We’re hoping that this series is just the beginning of a topic we consider to be extremely interesting, and we’re actively seeking contributors to help us explore the mobile web as it continues to blossom. If you’re interested in becoming a guest author on the UX Booth, please be sure to visit our Contribute page.

About the Author

David Leggett

David (TheLeggett) Leggett is a young entrepreneur who specializes in building successful online businesses. For seven years, David has been designing, developing and managing online projects as a self-employed individual. With strong values, a relentless work ethic, and an undying love for self-education, Mr. Leggett has built a career since the age of 15 with little regard to the conventional workplace.

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. Vicente March 22, 2011

    Fantastic series and much appreciated. One minor correction:

    Apple actually recommends “44 x 44 points” not pixels. The difference is important as mobile screen resolutions vary wildly.

    Thanks again for the terrific read and useful reference!

    • Ah! That makes SO much more sense. I was very confused as to why they chose “px” considering they’ve done so much with retinal displays.

      Thank you for the heads up Vicente!

  2. I’ve really enjoyed reading this series, and this is a good finish to it. Thanks very much for sharing David.

    Looking forward to seeing a lot more mobile UX articles in the near future. Cheers!

  3. Vicente March 22, 2011

    Forgot to include the reference link:

    iOS Developer Library

  4. Very interesting articles! With regards to the tapable area, just a note to say that the visual area not just the hit area can effect how users perceive the hitability of the area. I did several user tests on this which tested accuracy and perception for Sony Ericsson and the results can be very surprising. It’s always worth creating a few variations and testing them with users. The best solution, in my opinion, is to have a larger hit area than your visual area, that way you account for reasonable errors in your design. And mobile users on the move and multitasking are very prone to inaccuracy!

  5. I intend to buy an iPhone, but I am concerned on this part with touching screen,I tried one and I didn’t like it, because it took so long to open a page, i had to type the button a few times. So should I get one or stay with my old phone?

  6. David:

    Thanks for taking the time to do these. Great timing and glad to see members of the community adding to the value of the information.

  7. Koen Haarbosch March 24, 2011

    Great series, i realy enjoyed your articles.

  8. Thanks for these series! Very insightful, definitely useful for a future mobile website

  9. Great series, David! I enjoyed it very much.

    Apple’s suggestion, however, does not convince me. From my perspective the size of the control elements depend on the precision – not on the size of the tap. If the average size of the tap is 44 pts and the average precision is 10 pts a button size of 20 pts would be pretty enough.

    From my experience Fitt’s law (http://en.wikipedia.org/wiki/Fitts%27s_law) is the most relevant rule when talking about button sizes. From Fitt’s law we can deduce: The bigger a button is, the easier the user can click it.

    From my personal perspective this 44 pts rule is made up out of thin air. Nevertheless it might be useful in some cases.

    If you want to achieve really fast input times, I would suggest you to make all controls as large as possible. Usally the wish to have a neat screen design will automatically lead to some limitations at that point.

    • When you say from your perspective, do you mean that you’ve tested this number, and it has not worked for you?

      I do think there is a by-case approach here, as with many other areas of design, but I doubt (or at least hope) that Apple/Microsoft made these numbers up out of thin air. It seems likely to me that they actually determined the side of the avg. finger tap, and based these numbers from that statistic.

      Either way, I think you’re right in saying that buttons have to be big enough for users to use them!

      I’m curious when Hover interfaces will start making appearances, as a handheld device with the ability to sense fingers hovering over the screen would surely help in creating more accurate UIs.

  10. I completely agree, the possibility to hover has many advantages – especially with regard to precision. I’m not sure, however, if input times can be increased as well.

    Unfortunately I hadn’t time to test that number on my own, yet. In the past we made some evaluations with different softkeyboards. We were not able to deduce a threshold from our evaluations.

    If Apple and Microsoft are really convinced by their heuristics, they would follow them. When looking on the sizes of different UI elements (e.g. http://www.idev101.com/code/User_Interface/sizes.html): Why is the size of navigation bar icons 20 x 20 pts and the size of tab bar icons 30 x 30 pts?

    That leads me to the conclusion that – even if there is a correlation between “tap size” and “button size” – the assumption “tap size = button size” might be wrong.

    Even if the tap is 44 x 44 pts you can calculate the center of the tap!

  11. There’s nothing but a great series of mobile thought for the masses from you! Love your articles from the beginning and save me a lot in explaining those limitation to the customer (whose always think they are right) :)

Related Posts