Designing Buttons That Don’t Suck (Mobile Web Part 3)

A button is something that seems to be made just for mobile: it’s designed to be big and easy to activate, as opposed to small and harder to activate, like normal text links. This seems ideal for a mobile devices, which have a small display area and whose form of input is a person’s (relatively) fat finger interacting with the screen. Contrast this with the desktop, where the display area is much larger and the input device, the mouse, is a much more highly refined and sensitive pointing device.

But you probably don’t want to make everything into a button. After all, there’s still a place for good old fashioned anchor tags. So what do you make into a button? Simple: areas of your website that get frequent usage. For instance, [mobile.twitter.com][1] has buttons for Search, Refresh results, and More (display more tweets), but leaves other things as anchors/hyperlinks, such as usernames and links in tweets. Basically, use common sense. You should have a mixture of both buttons and hyperlinks.

There’s a distinction to be made between form input buttons and other things that look like buttons. The former occurs within a Form tag and can be used to submit a form of data when clicked (and you can [style it up all you want][2]!). The latter is simply an Anchor tag disguised as a big clickable button, which is the focus of this article.

A button can be a very useful thing, and can make the user experience much much better. Yet it’s surprisingly easy to fail to create a proper button.

How to fail at creating a button

See if you can tell the difference between these two buttons:

More

If the difference isn’t immediately apparent, try mousing over the following buttons:

More

What’s the problem? The button on the top is only clickable when hovering over the text. In other words, it looks like a button but it acts just like a regular hyperlink. This is a common problem that I’ve seen a LOT, and I’ve even seen it on major websites (in fact, the faulty button is inspired by the live code on mobile.twitter.com).

How does this happen?

My theory is that when a design is passed down to a developer, the developer may think their job ends when their code produces output that looks like the original design documents. But they fail to take into consideration the actual usability of the website.

This is a simple mistake, but it definitely causes frustration when I find it on websites. And I find myself even more annoyed when I see this while browsing websites with my iPhone. It basically tells me that the developers don’t use their own website. That’s not a good impression to leave with your visitors.

Summary

In summary, buttons are an important part of your mobile website. They are designed to be easy to activate, so make sure that frequently used functions on your website are buttons. Also, don’t be lazy: TEST your code for usability and don’t assume that the product is done when it looks identical to the design specs.

More from the Mobile Web series:

Part 1: The viewport metatag
Part 2: The mobile developer’s toolkit
Part 3: Designing buttons that don’t suck
Part 4: On designing a mobile webpage
Part 5: Using mobile-specific HTML, CSS, and JavaScript
Part 6: Dealing with device orientation
Part 7: Mobile JavaScript libraries and frameworks

[1]: http://mobile.twitter.com [2]: http://girliemac.com/blog/2010/02/04/css3-box-shadow-with-inset-values-the-aqua-button-rerevisited/