There and Back Again
December 15, 2015There 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.
![](/uploads/blog/posts/twitter-profile.png)
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.
![](/uploads/blog/posts/twitter-tweet.png)
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.
![](/uploads/blog/posts/twitter-image.png)
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.
Others
The situation only gets worse as we look at other apps. Below we see the item detail for a posting on eBay.
Ebay
![](/uploads/blog/posts/ebay-item.png)
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.
![](/uploads/blog/posts/twitter-pan.png)
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
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.
![](/uploads/blog/posts/inbox-email.png)
Netflix
Netflix also presents content in a modal style like Inbox, but the location of the close button floats to the upper right.
![](/uploads/blog/posts/netflix-show.png)
So What?
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.
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
![To RFP or not to RFP?](https://gratis-creeper.transforms.svdcdn.com/staging/blog/rfp-thumbnail-updated.png?w=1080&h=1080&auto=compress%2Cformat&fit=crop&dm=1708017616&s=2b9b4ed116cf1104e3070bea42445dfe)
To RFP or not to RFP?
January 19, 2024Selecting the right digital product partner is not just about ticking boxes in a request for proposal (RFP). It’s more important to engage in a meaningful discovery process to find a collaborator who can turn your vision into a successful digital reality. Here are three things to watch out for as you search for the perfect digital collaborator.
Read more![When to “shape up” versus be more “agile”](https://gratis-creeper.transforms.svdcdn.com/staging/blog/Mark-Fast-Company-May_1080x1080_040424.jpg?w=2250&h=2250&auto=compress%2Cformat&fit=crop&dm=1717093184&s=2b2fe4e9a630aeced51650360ce8a8f5)
When to “shape up” versus be more “agile”
May 30, 2024Should you develop your new software using the Agile or Shape Up method? Here’s how to decide.
Read more![Between the brackets: MichiganLabs’ approach to software development](https://gratis-creeper.transforms.svdcdn.com/staging/blog/approach-to-software-development-thumbnail_2024-02-15-200634_fdwn.png?w=1200&h=1200&auto=compress%2Cformat&fit=crop&dm=1708027595&s=b1cfebad3bdfb518b25297b50603c688)