Mapping

(This section has a lot more opinion and personal experience in it than previous sections. Take it with a grain of salt)

The principle of Mapping or Natural Mapping relates to how an application controls translate to the appropriate action. In the real world Natural Mapping is usually based on a physical spatial relationship. Take a simple toaster for example. Pressing down the toast lever to make the toast go down. The action of pressing down on the lever translates into the toast (bread technically) going down as well. It’s a Natural Mapping between the physical action of the lever and action of the toast.

If toast comes out, where did the bread go?

On mobile or digital devices the natural mapping is slightly more subtle with its implementation and relies more on convention over spatial relationships. What I mean by convention is that there are a number of assumed relationships that users of those devices will immediately assume without you having to prompt them. And what I mean by that is that there are “Android” ways of doing things and you should do that.

Content will usually scroll top to bottom, forward buttons on the right, back on the left, Menu on the top left hamburger icon. Those conventions are usually platform specific and while they don’t usually correspond to a physical action they are still “natural” motions for the mobile device user.

Mapping conventions are where users expect actions to be. This may not be the same on Android and iOS and as a result your designs should be adapted for your specific platform. You cannot carry one design between two platforms effectively

On Android, those conventions are loosely documented on the Google material design site, mostly in the form of “Best Practices” or layered deep within a component specification. The problem with those cultural conventions is that they really depend on the user. Like any true Scotsman, cultural conventions are dependant upon the user and it doesn’t help that we’ve migrated from different design patterns in Android since 1.0.

Additionally, your user base may be different in how they expect the device to function and their expectations for mapping will differ than others. There is no easy way to determine this and outside of A/B testing with real users there isn’t much you can do.

But A/B testing doesn’t need to be complicated. In the past I’ve pointed a camera at a device and asked the user to talk through their thinking out loud. It is really enlightening to see how users engage with your app and you will be surprised at how your expectations are wildly different from your users. In one situation I was surprised to find that most users will ignore the Toolbar overflow menu almost entirely during testing. The Google Design spec includes it as a component but for our use case we needed to move those features out of the menu because of the results from testing. The Natural Mapping for this user didn’t include the overflow menu and it would be a poor design on our part to include it.

Of course, as any true Android user knows there are a couple of conventions that shouldn’t be violated. Here are a couple of my personal conventions that I have found that most users like to follow. Feel free to comment in below if you have any others.

Let’s talk about Back.

The soft/hard back button is a confusing combination of back navigation and undo. In my opinion, undo should always take priority over back navigation and you should override the OnBackPressed() function for actions initiated by the user. That means if you pull up a dialog, back should close it. A menu drawer, back should close it. Halfway, through editing a field? Back should revert the changes and stop editing. Only when there was no action does back navigate back through the stack. Intuitively this is how I look at the back button. If anything ever goes wrong, back will fix it.

Gestures and Scrolling Directions

Gestures are a great placebo for Natural Mapping. They seem like a good idea at first but never seem to work out. Unlike normal placebos these can often have the effect of being more detrimental for mapping than beneficial. Quickly, which direction should you swipe to delete an item? Do you scroll the item up or move the content down? I don’t believe there is a convention for swipe gestures so making the assumption that your users have one won’t work. I usually avoid most gestures within an app for this reason.

EditText and Form Field Navigation

While I would prefer to never enter text into any application eventually something will have to go in. I don’t think I’ve ever entered a form (digital or otherwise) and said “That was truly enjoyable” but we can at least strive to make it less painful. Handling Input Types training on the Android developer site should be read and enjoyed. You can setup your form so that you advance to the next field using the keyboard and submit it with the IME_ACTION_DONE feature without ever closing the keyboard. Having to click on a field, edit that field, click on another field is a painful way to enter data.

And if you ever have a user enter data in landscape mode, always include the following option in your EditText field.

android:imeOptions="flagNoExtractUi"

Without it the Android keyboard might take over the whole screen. Users will have no idea what they are entering. I can’t imagine a more painful experience than that. (Relevant SO)