People are creatures of habit. We learn the mechanics of interacting with everyday things and our "muscle memory" leads the way ever after. Sometimes patterns break and we find ourselves scratching our heads wondering what to do next. Often times we proceed with habitual set of actions only to realize that something that once looked and felt so familiar doesn't anymore. This can lead to frustration and the necessity to re-educated ourselves. Case in point: the back button in mobile applications. Since I'm an iPhone user, I will go over a few cases of implementation of the back button in iOS apps.

The primary function of the back button is to, duh, take a user back to the previous screen, whatever it was. To eliminate hesitation, a good button will be labeled with something more meaningful than "Back".

Making things worse – hopefully, unintentionally – sometimes the back button in an iOS app looks like an arrow or triangle pointing to the left. While it's okay to do this in a web-browser, such as Safari, because page titles are often too long to fit in a small button, I can't see a good reason to follow this pattern in applications that aren't browsers.

Now, many mobile applications allow you to view a website without leaving it, essentially bringing the web view inside, for convenience. It's an awesome idea indeed, but here lies the so often overlooked usability problem: there are now two back buttons. One for the browser and one for the app. What to do? My favorite solution is one used in Instapaper where the back button – placed inside the bottom control bar – is used exclusively for the browser. In place of the back button comes the "Close" button clearly explaining that you are in the browser and if you want to continue using the main app, you should simply close the browser "overlaying" the app. No confusion there.

Safari naturally has its back/forward controls at the bottom, I'm guessing to make give all of the available space to the URL bar at the top. Many app developers follow this pattern, probably for consistency. It's all good and great but once I start navigating from page to page in the enclosed browser, I often tap the "Back" button in the upper left to go to the previous webpage only to find myself at the previous screen of the application. It often causes frustration as I lose track of what webpage I intended to be at, and now I have to tap through to find it again (Pulse, I'm looking at you). How much easier would it be if everyone followed Instapaper's example? The answer is: much much easier.

I urge mobile developers to give more thought and attention to frequently used UI elements that carry the same function across most mobile applications, and remember: breaking conventions for the sake of great usability will earn you more love from your users.

(download)

Click here to download:

why-reeder-s-interface-rocks-GiocuCvwfqEAAFIkvduk.zip (954 KB)

Reading RSS has been a big part of my professional life in the last three years. It all started with Google Reader, the most straight-forward and popular feed subscription web app known to me. The problem was, I never fully enjoyed Google's design aesthetics so I started tweaking the Reader site with my own CSS using Stylish. Crafty designers shared their own "skins" for Google Reader, of which most notable to me was Helvetireader by Jon Hicks.

Then I had realized that I wanted to have my collection of RSS feeds with me anywhere I went, so I started using Google Reader Mobile. It was a decent experience but not enough for my liking. In search of a native app that synced with Google Reader I got NewsRack, and it was good. Seemed like the best app at the time and I readily shelled out a few bucks on it. Later down the road the app started becoming buggy and not always in perfect sync with Google. Eventually, I stopped using it.

Then someone recommeded Reeder for iPhone and was instantly hooked. The level of polish, excellent usability, the way it takes advantage of gestures to this day leaves me in awe. So what's so good about this little app?

Soothing color scheme, well-balanced font size, the choice to use Helvetica exclusively through out the app (the creator is based in Switzerland, no surprise there), perfect Google Reader syncing capabilities. But the true interface innovation that I want to point out is very subtle. It's the way the screen real-estate is used on a smartphone screen. Typically, in most applications the ways to display interface feedback—like loading and updating events—are rather crude and even Apple's own native apps are not quite perfect. Reeder for iPhone takes advantage of the parts of the screen that are not crucial to the main application experience but still noticeable. For example, when feeds are being synced and updated, the little loader icon moves the battery indicator slightly to the left. When the phone is in the landscape mode, the system bar is not shown at all, allowing for taller area to show content. Clever and delightful.

You may also get Reeder for iPad and Mac (in beta at the time of this writing). All versions are designed with high consideration of the platforms they run on. Look at the unified branding that slightly differs for each version made for a specific device. The icons, the color scheme, the interaction flow. If you are a feed junkie like me, don't just take my word for it, try the variety of Reeder apps for yourself.

Sometimes even a seasoned user experience specialist doesn't know how to create a perfectly good interface without taking it to the real world. There are several essential aspects to a successful UI design: the purpose of the application, by whom and how frequently it's going to be used, the environment in which it's going to be interacted with.

Case in point: the Yelp iPhone app, a companion to the excellent web service yelp.com. Purpose: find services around your immediate geographic location; who: nearly everyone with an iPhone; how frequently: a few times a day; where: everywhere, mostly on the streets. Here is what their neat filtering screen looks like:

(download)

Click here to download:

mobile-ui-contrast-matters-or-accessibility-for-the-rest-of-us-jngiAAvJDhxdGrvsiHbo.zip (76 KB)

Notice the low contrast of the selected items? Well, in the open sunlight those are virtually indistinguishable from their non-selected neighbors which renders this screen practically useless. Since there is no physical response to the touch or a way to add texture to the iPhone screen (yet?), the user has very little indication that something is in fact selected.

The second image is my take on that same screen. I understand and respect the attempt to have uniformity in app design, but sometimes conventions need to be bent in order to create a better user experience. I have added high contrast to the selected elements of the interface, increased the font size for better legibility, tossed the unimportant label "Narrow result by", and finally made the Search button look more like an actionable button. I am not saying this is the perfect set of improvement by any means, but you get the point.

Morale: don't just create trendy design (subtle, understated palette in this case) and stick with uniformity, test it. Test it everywhere you go, on the actual device. On the whole range of devices your users might have, for this matter. Put yourself in as many pairs of shoes of your potential customers as you can. Then, iterate, iterate, iterate until you reach higher usability. In the end, nice-to-have features don't matter nearly as much as the core functionality with good usability.