First Line Software is a premier provider of software engineering, software enablement, and digital transformation services. Headquartered in Cambridge, Massachusetts, the global staff of 400 technical experts serve clients across North America, Europe, Asia, and Australia.
When people really first started thinking hard about mobile UIs, the issue of going back to the previous screen was addressed very simply: you used a dedicated physical button on your phone with the back arrow on it.
At the dawn of the mobile phone era, the problem of getting back to the previous screen didn’t really exist. On a desktop or a laptop, there was always the helpful ESC button.
With the advent of advanced mobile phones, when people really first started thinking about mobile UIs, this issue was addressed very simply: since phones had lots of physical buttons, in order to get to the previous screen, you used a dedicated button with the back arrow on it (sometimes this function was given to the C or ON/POWER buttons), or a “soft” button with an on-screen prompt.
It all changed with the iPhone’s debut and the proliferation of large touchscreen phones it ushered in. The market was shocked by a device without multiple buttons – in fact, with the single home button. Applications didn’t need to be closed, they were simply sent to the background (although for a while there was no multitasking in iOS, that’s not the point here). So how did Apple designers address the need to return to the previous screen? They simply designated an area of the display (top left corner) for the on-screen back button. This was justifiable and uncontroversial: the location was convenient enough, and the size of the button made it quite usable on the 3.5” screen (before the iPhone 5).
The rival Android soon offered the market its own solution: it introduced the back button along with the home and menu buttons. The first Android devices, like T-Mobile G1/HTC Dream and HTC Hero, actually had physical pushbuttons.
Time went on, touchscreens gained new ground, and physical buttons continued to lose their luster. The back button evolved with the times: first, it went from an actual button to the touch-sensitive bezel, and then new devices started coming out with just the on-screen buttons for everything.
The Android (and Windows Phone – they can be grouped together in this regard) approach could be seen as superior: its back button is more conveniently situated for one-handed use. However, both the on-screen button and the bottom bezel touch button are really easy to swipe inadvertently, especially while you’re playing games, which can be extremely frustrating.
On an iPhone with a 4” screen, trying to reach the top left corner with your thumb is now even less convenient. iOS7 introduced the swiping gesture for going back, but that may be kind of unintuitive. If the rumors of even bigger screen sizes coming soon to an iPhone near you are true, Apple will probably have to abandon its top-left-corner paradigm for good. Whatever they replace it with, I hope it’s elegant and usable.
My personal gripe with Android’s implementation is that the last press on the back button closes the application. In other words, if you find yourself deep in the bowels of an app and try to find your way back to the surface by touching the back button multiple times, you could end up on the home screen. Hell, if I wanted to go to the home screen, I would just press the home button! There is an option to ask for user confirmation before closing the app, but not too many app developers take advantage of it.
These things really impact the user experience and influence customers (if you are an app developer or a development firm). Life is made up of many small things like that, so seemingly small and trivial details can become big in the eyes of the beholder. This is especially true when you are developing for several platforms at once. In this case, you are dealing with conflicting preferences. Customers centered on the Android experience want you to make the back button as small as possible, perhaps turn it into an icon, and hide it somewhere on the screen where no one can find it. This leaves users confused and irritated, as they are panicking and looking for the back button, pressing and swiping everything else in the process. At the other extreme, iPhone-centric customers want the back button to be on-screen, even though the Android interface already provides for it: they believe the physical button isn’t enough. Sometimes customers insist on not calling the button “Back” – they believe this is not original enough, insist on creating some kind of an innovative icon instead of the word, and ultimately make users suffer.
My advice: do not be afraid to seem unoriginal in navigation. This is exactly the part of your app where you shouldn’t reinvent the wheel, and just sticking to the guidelines is the best way forward. This will make users feel right at home, for which they will be eternally grateful.