1

Ask DN: I'd like your feedback on a bottom navbar proof-of-concept

4 months ago from , UI Designer at WodUp; Creator of 2048

Hi all, I'm working on a mobile web app that will feature two main sections (tabs) that the user will switch between often. Because of this, I imagine a classic navigation bar at the top will be frustrating to use as it's hard to reach.

I could find a few examples of websites that use bottom navigation bars, such as Pitchfork and Quartz, but I wasn't satisfied with their implementation. Specifically, Safari's bottom toolbar will capture any tap in the bottom 10% of the screen when collapsed, forcing you to tap twice AND moving your target when you're trying to use the navigation bar. Both of these navigation bars also interact badly with iPhone X and XS because they end up under the Home Indicator.

I attempted to address both issues with a floating navigation bar that automatically hides away whenever Safari's interface is collapsed. It will come back when you scroll up, or when you summon Safari's toolbar by tapping anywhere in the bottom 10% of the screen.

You can try it out here. This fiddle only works on iOS Safari currently.

I'd like to hear what you think in general about this, and have a few specific questions, too:

  • Will this pattern feel familiar to users?
  • Is the behavior I've implemented confusing or unintuitive?
  • How could I test whether this is a good idea?
  • I should probably show some sort of indicator when the navigation bar is hidden to let the user know where to tap in order to get it back. Do you have any suggestion for how I could do that?

Thanks for your help!

2 comments

  • Steve O'ConnorSteve O'Connor, 4 months ago

    Hi Gabriele

    It's difficult to say whether this will work for your app without more context - understanding what data will be in the tabs and how people will use them.

    However, I don't think it's a pattern that would be problematic for users.

    Obviously, iOS has always had bottom nav with their Tab Bar, and Android introduced the same with their Bottom Navigation bar. Android recommend using tabs if less than 2 options, though they don't say why and, despite spending 7 years designing apps, I don't see why only 2 options would be a problem. But this tells you that bottom navigation is a familiar pattern for all mobile users.

    There is a slight element of stacking as it sits on top of the Safari tabs, but this isn't that unusual with websites.

    To test it you need to get some realistic data and other elements of UI in there first. It's no good testing one elment of UI in isolation as the results will change when it's then put into the full app. Then either test it properly with actual users - if possible - or using a site like usertesting.com.

    Build it out or put it together in Adobe XD or similar.

    I'm not convinced that an indicator is needed. As the tabs are floating elements, having them disappear and reappear in the same manner as the Safari UI shouldn't be an issue. But that would come out in testing anyway.

    0 points
  • Koos Looijesteijn, 4 months ago

    I think the usefulness of the concept depends on the application and users, so I’d try to do a bunch of tests with actual people.

    My impression: 1. If the tabs look like tabs I guess they’re familiar enough. Right now they look like actions, the plus button in the center adds to that. 2. I find it counterintuitive to scroll up to get the bottom nav.

    I like the creativity in the solution to work around that awful iOS Safari behavior. I don’t think it solves the problem you’re stating though. In the initial solution with the standard bottom nav, they’re a clear indication for users where to tap. In your new solution there isn’t. Another problem you had with the initial solution was that there are two actions necessary that aren’t 100% intuitive, because the buttons jump. With the new solutions you haven’t really solved that: it still requires 2 actions and the behavior of the nav appearing and disappearing is likely less predictable as it’s not standard iOS Safari behavior.

    But that’s just me.

    0 points