iOS Global Tab Bar Navigation - Reset navigation "stack" when switching between tabs?

Question

I have an iOS app that uses a tab bar global navigation scheme (UITabBar), with 4 tabs. Some users are getting confused when they go from Tab A, to Tab B, and then back to Tab A, where they see the last state of Tab A and not the root screen.

My question is - is it better to have the user return to the root screen of each tab if they switch tabs temporarily, then return; OR to show the user the state they last left the tab in?

Does Apple recommend anything on the subject?

Here's some context:

• When the user is on any one of the 4 tabs, they can drill quite deeply into the tab screens. Typically, a user may go 10+ screens deep within any one tab
• The same screen type (there are 5 types of content screens) can show up on any of the 4 tabs

I'm also considering switching the global navigation scheme from Tab Bar to the "Hamburger" menu, so that may be a factor if that scheme helps address this UX issue.

Answer 1

As already said in earlier answers, the normal behavior in iOS is that each tab keeps its state. Users can go back to the 'root' of a tab by tapping on the tab button again. I think you already identified two possible sources for the confusion:

Tabs navigate 10+ levels deep

That is really a lot. It sounds like a browser-style (android style) back stack instead of a representation of hierarchical data. Is each level you go deeper actually a deeper level in your data?

Each tab can lead to the same data, and similar views

Again, sounds like a website. It sounds like your tabs are just navigation starting points, but it all ends up with the same data.

Look at Apple's music app. Its main navigation are tabs, but eventually it all leads to a song. So, they made the song view full screen (tab buttons are no longer visible).

In the end it all depends, but here are some ideas to consider:

• If some of your deep navigation has a short-lived context (eg. Completing a task) then consider making it modal, so that the tab buttons are hidden.

• separate the data better, so that each tab has its own data and views. This makes it more recognizable for the user what tab he is in. This might require links that take you automatically to another tab, so be it.

• consider a hamburger menu instead.

Answer 2

I don't think there will be a definite "right" or "wrong" answer here, as it depends on the content of your application and what your users are trying to accomplish.

Some users are getting confused when they go from Tab A, to Tab B, and then back to Tab A, where they see the last state of Tab A and not the root screen.

Are the users indicating why they are getting confused? Gathering more information on the source of confusion may help you get an answer.

Personally, I like when apps retain state. Both Twitter and Facebook retain state in certain areas, and it's especially useful when you need information from one tab to use on another.

Edit: To expand on my reply, this is from the iOS App Programming Guide found here:

From the user’s perspective, quitting an app should just seem like a temporary interruption. When the user returns to an app, that app should always return the user to the last point of use, so that the user can continue with whatever task was in progress. This behavior provides a better experience for the user...

Of course, this is refering to entire apps, and not within an app itself. However, I feel the same idea can be applied to one app with many states.

Answer 3

Retaining state on each tab is the default behaviour for iOS tab bar navigation.

Users can reset the state when they tap on the tab they're currently on.

This however is unknown to some users.

There are a few reasons why this is: - lack of familiarity. My parents have never used a pc, the iPad will be their first computing device. - inconsistent experience across different apps. - insufficient cues.

This isn't necessarily resolved by switching to the hamburger menu since retaining state could also be achieved here.

While I prefer to fall back on default behaviour, you need to assess your specific use cases.

Would the user benefit more from having the state reset or persisted? What is the most undesirable experience in both case and whether there is an option to alleviate that experience. E.g. going 10+ levels deep and having to tap back 10+ times or reset to root and tapping 10+ again.

Answer 4

Tabs + state within a tab + back button is very reminiscent of a web browser. It sounds like you are currently mimicking browser behavior with respect to tabs and back buttons, and this sounds like the right thing to me. However you say some users are confused. If they are also confused by the workings of a browser then I would be inclined to think they are outlier cases. If they are not confused by browser behavior then I would try to find out why the browsers makes sense to them but your application does not - why is it their understanding of browser behavior doesn't transfer to your app? What is different about your app (than a browser)?

With regard to the outlier cases that find browser behavior confusing, they simply must learn (or be taught) this ubiquitous pattern (tabs and backbuttons), the ubiquitous pattern shouldn't be abandoned to cater to the few.