There and Back AgainDecember 15, 2015
There and Back Again
A few weeks ago I made the biennial trek down to my wireless carrier’s store to purchase a new phone. This time differed from previous trips as this year I settled on an iPhone as my cellular companion for the next two years. Making the switch from an Android (Moto X Gen 1) phone to an iPhone got me thinking about how to design an app for both platforms.
My primary focus when it comes to making apps is development, not design, so to compensate I try to look at what others have done and written to inform my decisions on an app’s design. One of my favorite resources I found is this article which includes a helpful comparison between iOS and Android’s native UI components.
RIP Back Button
Most of the platform differences come down to a difference in UI style (flat vs. material). However, as the article points out, one thing that Android has on iOS is the presence of a back button.
At first I did not think that I would miss the Android back button much, after all there are other ways to navigate to the previous screen on iOS (back chevron, swiping from the left edge, etc.). And it is true that I don’t miss the functionality the back button provides. What I do miss is the consistency it provides.
Apple provides a fairly detailed guideline on how to approach app navigation and even includes a section on what should appear in the navigation bar itself. The main takeaway is that the navigation bar is intended to show state and, more importantly for the examinations to follow, how to get back.
When the user goes to a new level in a navigation hierarchy, two things should happen:
The navigation bar title should change to the new level’s title, if appropriate. A back button should appear in the left end of the bar; it can be labeled with the previous level’s title if it adds value.
This guideline is straightforward enough; use the left side of the navigation bar as a means to go back.
Case Study in App Navigation
The question I want to ask as a (relatively) new iOS user is: can I depend on app designers and developers to abide by Apple’s guidelines and provide a consistent experience across apps?
Take Twitter’s iOS app as an example. Below we can see what the view of my Twitter profile looks like.
Tapping on a tweet pushes the detail view of that tweet onto the screen using the (very) familiar navigation controller push animation. To navigate back to my profile, we can either tap the “back chevron” in its standard location as the left button in the navigation bar or “pan” from the left of the screen. Excellent.
Navigation starts to break down when we open an image attached to a tweet. A view is presented in full screen containing a larger version of the image.
Our options here to navigate back to the tweet view are tapping an “X” in the upper right corner or panning up/down from anywhere in the view. While not inherently poor navigation, the consistency reverse navigation in iOS is somewhat lacking when compared to the consistent safety of the Android back button.
The situation only gets worse as we look at other apps. Below we see the item detail for a posting on eBay.
Our options to navigate back to the eBay homepage include tapping the back chevron located almost in the standard location (displaced by that tasty hamburger button) or swiping from the left edge.
Here it is worth noting the difference between a swipe and a pan gesture. By default, when you use a navigation controller in iOS you are given the back pan gesture for free, as seen in the Twitter example from before.
The content is animated with the gesture (anchored beneath the user’s finger) for a smoother back transition. In contrast, the swipe gesture seen in the Ebay app triggers the back action as soon as the gesture is recognized.
While both gestures have a similar action and identical outcome, the swipe results in an unexpected experience as it differs from the norm.
Google Inbox does not use the typical back chevron to close an email as it presents an email in more of a modal form. However by positioning its “close” button in the upper left, Inbox maintains consistency with the iOS convention.
Netflix also presents content in a modal style like Inbox, but the location of the close button floats to the upper right.
So why do we care? My gripe with Twitter’s navigation is pretty minor, but it impacts the usability of the app as I get the navigation wrong (nearly) every time. As developers and designers we should strive to keep each of the apps we create consistent with the system guidelines and consistent within itself.
For a cross-platform app this will often mean allowing room in the designs for each version of the app to be tailored to its platform. Additionally, when laying out the navigation for your app, keep in mind what users are accustomed to for navigation both in your app and in other system apps and be consistent.
For some further reading, the iOS Human Interface Guidelines has a nice section on Design Principles, one of which is Consistency.
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
Using View Model Protocols to manage complex SwiftUI ViewsMarch 11, 2021
Managing complex screens or views that depend on asynchronous services or the need to pull in state from across your app can be tricky to get right. The most common way to address this in SwiftUI is by abstracting that logic into a dedicated view model for that piece of UI.Read more
Drinks on the Deck 2022July 19, 2022
Join us and ~250 other friends for Drinks on the Deck 2022. Come help us celebrate the new office in Ada. Free drinks & appetizers.Read more
Michigan Software Labs Named One of the Country's Best Workplaces by FortuneAugust 9, 2021
Michigan Software Labs has been named as one of the 100 Best Small and Medium Workplaces based on an independent survey by consulting firm Great Place to Work® and Fortune Magazine. Michigan Software Labs came in 79 on the list. This is the second year the company has won the prestigious award.Read more