Navigation Misappropriation

Navigation Misappropriation

When designing applications for any platform, but especially platforms with established UI guidelines, there are always instances where innovation strains against the edges of those guidelines. Since the release of the iOS SDK app developers have tested and stretched those guidelines in their applications to the result of new and established UI normatives. Functionality like ‘pull to refresh’, and center focused nav buttons are just a few instances where well designed functionality has found its way into apps by other developers.

As mentioned in my first post, the purpose of leveraging existing design patterns is to make your designs approachable and as simple as possible to intuit by users. By that same token, if you take a pre-defined feature or interaction pattern and change the way it behaves then you are intentionally teaching your users to no longer trust that interaction. Thereby introducing doubt on any further uses of that feature by the user, in yours or other applications. Additionally, failing to use the feature or guideline correctly limits your options when implementing features. In this case there is a specific instance I want to discuss. The Navigation Bar.

iOS Human Interface Guidelines – Navigation Bars

Avoid crowding a navigation bar with additional controls, even if there appears to be enough space. The navigation bar should contain no more than a view’s current title, the back button, and one control that manages the view’s contents.

Accounts List (Correct Use)

The HIG here tries to be clear about the navigation bar, but at times companies ignore some or all of these guidelines. I want to focus on two in particular.

View’s Current Title
A common abuse of the navigation bar begins with marketing. Like any stake holder in a company, marketing wants to have a say in the design of an application, and that usually entails making sure that the company brand is upfront and in people’s faces as long as possible to cement the product.  The effectiveness of this tactic is debatable in other platforms or web applications, but for iOS specifically this technique is unnecessary and intrusive. Step back for a moment and think about how your user reaches the screen in question.

1. Lauch App Store by finding icon and tapping it. 2-3 seconds.
2. Tap Search. 1 second.
3. Enter in the name of the application. 5-10 seconds.
4. Wait for list of results. 3-5 seconds.
5. Scroll through list of results. 3-5 seconds.
6. Select application from the list. 1 second.
7. Tap Install icon. 2-3 seconds.
8. Wait for application to download. 2-10 minutes.
9. Tap application icon.
10. See opening screen.

Total Time: 2:17-10:17 minutes

By the time the user sees the branding or logo in the navigation bar they have already invested a great deal of time to get there. The user knows the name of your company or product pretty well by then. Each additional use of your logo in the title bar of the application only serves to reduce the usefulness of the screens it appears on, as you can no longer display the view’s current title. This is the mobile equivalent of screaming your companies name at your customer as they walk in the door of your store, and every few minutes after that. It is not necessary. Using the above example when talking to stake holders can help to combat this requirement. It is not necessary for every screen to bare the burden of selling the product or brand to the user. To the contrary by the time the user has the app in hand, you’ve already succeeded at selling them. Now it’s time to keep them through rewarding and intuitive interaction.

Additional Controls
The second common mistake when dealing with navigation bars centers around the use of the additional control. Referring back to the HIG the additional control is intended to be contextual, and directly connected to the view’s state and purpose. What that means is that the upper right hand control is always a direct action to start or end a task or a flow. For sending an email, or adding a note. These buttons are directly relevant to the task at this very moment.

Logoff is not relevant to managing alerts (Wrong use)

In the example here we see a screen deep into a flow of the application related to managing a user’s alerts. The navigation bar in this case is being abused in two ways, as it is missing a title and has a button that is irrelevant to the task at hand. Not only is it difficult to identify the purpose of this screen without a title, but it’s not clear how we proceed or effectively complete this task.

Now it might be argued that Log Off is a relevant action at all times because the user must be able to disconnect from their banking session at any time. While I admit that it is imperative that users be able to disconnect. The placement of that functionality should be at the top level of each main task listed in the tab bar, because at the top level the user is not in a flow, or in the middle of a task. Additionally if the application is written appropriately then not only should pressing the home button end the session, but also the power button and, a timeout. Putting a log off button at the top of every screen is the mobile equivalent of welcoming your customer, and showing them the door at every opportunity, instead of trying to help them accomplish the task they came in for. Use that space effectively, instead of crippling your application by reserving that space for a single unrelated task.

Conclusion

When building an application there are often many stakeholders, each trying to make sure their considerations are being heard and addressed. Sometimes it takes time to explain why certain design considerations are made, but above all it’s important to remember that every departure from accepted and expected interface patterns leaves your user in the dark as to how to proceed, and negatively trains them to second guess their own expectations when it comes to your application. Use the navigation bar effectively and as intended to maximize it, and your application’s usefulness.

Back to Top