Mobile app with tabs a bad idea?

Question

I am trying to draw out what I want to build for a new mobile app, and I've run into a conundrum with tabs. I have four main categories of content, and thought it would be nice to have tabs at the top users could select to get to the content they wanted quickly, as shown below. (Please excuse the crudity of my MSPaint drawing. Currently, the Users tab is selected.)

The problem I've run into is in my flow diagram (this is what I'm calling a diagram that shows how one page flows to the next, looked at from a user perspective). Let's say I have content on the Users tab, and I want to add a screen that allows me to add a New User or a screen that that allows me to update an existing user's information. I had thought I would just do a pop up if they clicked on an existing users's name (or New User), but I'm starting to wonder if tabs and popups don't mix well.

Until some of the feedback below, I had thought I did not want to have different breadcrumbs for each tab, as I think that could be terribly hard to navigate (but now I'm re-thinking that). So the root of my question is: what is a common guideline for having more than one screen per tab? Or should I abandon tabs entirely? Each of these 4 tabs could have more than one screen.

Answer 1

I actually ran into a similar issue whilst designing one of my own apps earlier this year.

One thing I want to point out immediately is that common practice for mobile interfaces is to have tabs at the bottom of the screen or below a heading and navigation buttons. In the case of Apple, if you don't follow the strict UI guideline of having tabs at the bottom, your app may not even get accepted into the App Store. I'm not entirely sure what platform you plan on distributing your app, but I wanted to point this out first. I highly recommend checking out the Apple Human Interface Guidelines, and the Android Design Guidelines to see if you need to make changes to your layout.

In regards to your question about page tabs, I highly recommend you stick to your current plan because they are a crucial part of many mobile interfaces. It's whether you choose to use Tabs to display "dead-end" pages (pages that don't provide navigation to another page), or a separate view hierarchy with multiple pages. To best determine your best option, you must consider a few simple things:

1. Think of each Tab as a category. Your "Users" tab should only contain views (pages) relating to creating users, modifying users, etc. Giving a tab a broad name allows you to still convey what "area" of your app the user is currently within, and allows you to display many pages whilst that tab is highlighted. If you have many similar views, you should have multiple pages in a tab. You will also want to provide a way for the user to back-out of a hierarchy of views, and eventually lead to the original view that the tab presents - otherwise this becomes unintuitive and hard for the user to navigate.

2. If you only present a single page for each tab, you should look into pop-ups or lightboxes that display over the original page, because otherwise you're not going to have a logical place for any corresponding User pages to go. Popups that cover the entirety of the page (including the Tab Bar) work perfectly fine. They are not unintuitive and present a direct request for input from the user - and this is also quite a common practice.

In my example, I was creating an app for a live event that occured in my local area. It needed to have multiple tabs for Food vendors, entertainment information etc., and I wanted to be able to provide more information on specific food vendors when they were tapped. I made a detail view and filled labels accordingly, and added back buttons so that the original page could be accessed, and a tap of the tab would also pop back to the original page in the hierarchy. I found this worked well for my app and met all of Apple's guidelines in my case.

Let me know how you go, and if you have any other questions!

Answer 2

Tabs are a big part of mobile life. For both Apple and Android, tabs are at the bottom of the screen. This allows for a header where you can keep your navigation controls and buttons associated with that view of the selected tab. Note: most Android phones have a dedicated (hardware) back button.

There's a good article on Medium explaining how to use a iOS navigation controller with a tab bar. Check out the gif at the bottom—it's worth it's weight in words. https://medium.com/@ITZDERR/uinavigationcontroller-and-uitabbarcontroller-programmatically-swift-3-d85a885a5fd0

Additionally, here are the developer resources for iOS and Android

https://developer.apple.com/documentation/uikit/uitabbarcontroller https://material.io/components/bottom-navigation/

Hope this helps

Answer 3

Popups are a poor UX choice in most cases, and even more so for capturing user input beyond a binary button press (Yes|NO, CANCEL|OK, etc). "Popup Pyramids" get created by careless design that doesn't think beyond immediate needs, doesn't consider the wider ecosystem within which the app will exist. Popups demand the user re-orient their understanding of the controls they are working with, depending on the amount of content in the popup those controls often manifest in different parts of the physical screen. Easy to say, easy to mockup, irresponsible and prone to breaking the experience in reality.

As for Tabs, on Android you can drill-in to a tab and leverage the Up button to quickly get back to the tab root (or sub-section root), thus displaying the tab bar at every level of depth within a tab is redundant (and an anti-pattern on Android, I don't care if Instagram do it >.< try not to be so shallow). iOS only has a software back button and traditionally displays the tab bar at every level of depth within a tab, leveraging a re-click on the current Tab to navigate back to the tab root - there is no room for sub-sections OOTB (you would need to provide your own controls and pattern for that on iOS).