I read with interest Brad Ellis’s article on Medium, All Thumbs, Why Reach Navigation Should Replace the Navbar in iOS Design, and I wanted to add a few observations on the matter.

He writes:

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.

This introduction is also the core of Ellis’s thesis. And I both agree and disagree. I agree that, instead of stretching a thumb or readjusting the device in one’s hand to tap out-of-reach UI elements, a navigation within thumb reach would be ideal. It would be better from a usability standpoint. At the same time, I think that doing away with the navbar is a mistake, again from a usability standpoint.

The navbar is important for all the reasons Ellis himself lists, and I’d emphasise its importance in navigating apps with lots of hierarchically-arranged screens, such as iOS’s Settings app. The navbar helps users find where they are in a series of nested screens; it’s like the Path Bar in Mac OS’s Finder.

Of the solutions Ellis proposes, I find the best to be suggesting developers to design their apps in a way that renders the navbar unnecessary. But here I want to stress another point: discoverability. Don’t make apps that are obscure to navigate. I like the navbar as a core UI element because it’s generally transparent in telling you where you are, and also because, as a personal preference, I’d rather tap on self-explanatory labels than start to ‘guess-swipe’ on different areas of the screen to see what happens. Will I uncover a hidden drawer/sheet/panel the UI design never hinted at, for example? 

I’m not a fan of swiping as a navigational gesture, or better, as the only navigational gesture. My main peeve with swiping is that with some apps it’s very easy to inadvertently tap on a UI element on the current screen that triggers some other action, like dropping a pin on a map, highlighting a text field (which in turn triggers the virtual keyboard), or opening another screen entirely. This is something I’ve noticed happening (to me, at least) the bigger the iOS device screen gets — i.e. on the Plus-sized iPhones and on iPads. Tapping on the navbar, in this regard, feels safer.

The navbar is also a better solution with regard to accessibility. Tapping may require more precision than swiping, but I think it also requires less effort.

And here’s a good piece of advice from Ellis:

Prioritize placing buttons at the bottom of the screen.

[…]

Move the most-used items to the bottom.

Which inspired my humble proposal: Just move the navbar to the bottom of the screen.

Now, I haven’t tested my idea with all the apps, but as far as iOS’s built-in apps which feature a navbar, my proposal seems to work. Here are two examples in the Settings app. On the left, the screen as it is now in iOS 10.3.2. On the right, a quick mockup of my bottom navbar proposal:

In this second example, I find that moving the navbar to the bottom (and maintaining the screen’s Title at the top) also makes for a less cluttered and more legible top area, especially on the 4‑inch display of the iPhone 5/5c/5s/SE. Long labels like Display & Brightness here can finally be centred on the screen, and feel less condensed.

Another example, with iOS’s Photos app:

I chose this app because here we see that the navbar would be placed above a bottom-row of buttons. In this instance, a possible criticism may be that placing the navbar there could create a bit of interference with the Photos, Shared, and Albums buttons. But I think that with the navbar within easy reach, accidentally hitting an element of the bottom row instead of one of the labels in the navbar is also less likely, unless you have really big fingers.

These are quick and rough mockups, I’ll admit. The navbar at the bottom could be made visually more prominent, for example. I also realise it might take a while before getting accustomed to the new placement, but the added convenience of having more reachable navigational tappable labels could facilitate the process. Again, this is just an idea I haven’t fully explored in all possible instances system-wide, but I think it could be a ‘best of both worlds’ solution: make navigation easier with more reachable controls, without losing the navbar and creating a potentially opaque navigation interface.