Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question

4 Answers 4

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.

share|improve this answer
    
I'm facing a similar situation and am thinking about forcing some views to only live under certain tabs, and switch tabs for the user. The counter-argument I've received is that this is unusual (can't name a single app that does this), so the user will be confused, especially when he wants to go "back". –  mpoisot Mar 31 at 22:20
    
It will depend on how alike your views are. I have an app that does this. Instead of a right chevron eg. "More >" I used a left one: "< See Player Details" –  Kris Van Bael Apr 1 at 5:56

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.

share|improve this answer
    
Users say that the primary confusion is that when switching between the tabs, they will often see a screen type that either: a) isn't the root screen they expect to see, or b) is a screen type they were just looking at on another tab and there is momentary confusion along the lines of "wait, I thought I just switched tabs?" Thanks! –  Rohan Jul 18 '13 at 6:55

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.

share|improve this answer

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.

share|improve this answer
    
Users say that the primary confusion is that when switching between the tabs, they will often see a screen type that either: a) isn't the root screen they expect to see, or b) is a screen type they were just looking at on another tab and there is momentary confusion along the lines of "wait, I thought I just switched tabs?" I think a difference between the web browser analogy you brought up and my particular case is that the content of the tabs on web is likely to be very different, whereas in my case, the screen types are likely to be the same and less immediately distinguishable. Thanks! –  Rohan Jul 18 '13 at 6:50
    
An iOS app is not a website. A browser doesn't have (that kind of) tab buttons. A browser doesn't have a back button (in the sense of an iOS navigation back button). So dismissing the confused users as outliers is a bit easy. –  Kris Van Bael Aug 8 '13 at 17:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.