All Thumbs, Why Reach Navigation Should Replace the Navbar in iOS Design

As devices change, our visual language changes with them. It’s time to move away from the navbar in favor of navigation within thumb-reach. For the purposes of this article, we’ll call that Reach Navigation.

Read the rest of the article for a fascinating analysis as to why we should redesign navigation in iOS applications to support “reach navigation” by placing important elements towards the bottom left of the screen, and by supporting certain gestures, such as swipe to move back on the screen.

Of course I have two problems with the idea of completely obliterating the UINavigationBar.

Discoverability.

One of the trends we see in iOS and on mobile devices in general is the loss of discoverability: the loss of the affordances which allow a new user to, for example, recognize something can be tapped on, or something reveals a drop-down list of items. You can see this in iOS 10 on the new iPhone 7: pressure-taps on home screen icons for some applications pop up a list of options–but you have no way of knowing this. On earlier versions of Android if you wanted to delete an item in a table, you would do a “long-tap”: press and hold for some period of time. But is there anything in the table telling you this? Scrolling on both platforms give no hint that something can be scrolled if the list happens not to have an item that is “clipped” by a boundary–which is why Android started adding fade effects, and why some designers on iOS were adding the same thing.

Affordances allow us to determine that we can do a thing. And the UINavigationBar, even in it’s post iOS 7 stripped down state (where only color–a violation of the idea that some people are color-blind) indicates something can be tapped on, still communicates the screen we’re on can go back to a prior screen.

If we do away with the UINavigationBar, how will someone new to the platform know to swipe to cancel?

Further, if swipe to cancel becomes a standard gesture, how do we accommodate swiping left and right to browse a list of photographs? I know that Apple prefers swipe up and down for browsing and reserves swipe left and right for other gestures–but most designers working on the iOS platform don’t understand such subtitles, and Western speakers generally think in terms of scanning left and right.

Lower usage controls.

Sometimes we need to provide controls which permit us to do an operation, but which we don’t expect the user to commonly use. They still need to be discoverable.

Formerly when we considered design as an inverted L (with the most visually important thing upper left, and the top being the important branding and navigation area), we’d place the least used controls at the bottom.

But just because in today’s world the easiest to reach controls are at the bottom doesn’t mean we don’t have need for those lesser-used controls–nor should they be accessed by a hidden gesture. (I imagine for Pagans that a custom swipe of a pentagram on the screen reveals a secret settings page. And for the advanced, invoking pentagram swipes invoke different settings: swiping to invoke water, for example, brings up a different screen than invoking spirit.)

Instead, with the notion of reachability navigation, the ideal place to put lesser used settings would be the upper right–where you would need two hands to reach.

Further, while the designer in this article may hate branding–it still is useful from a business perspective.

So use the UINavigationBar. But rethink your navigation. And try to design your application so the most important elements are within thumb’s reach–at the bottom of the screen, where you would normally dump functionality you don’t want to deal with.