2

There's a great function from the web that I want to reproduce in iOS and Android. I'm calling it a recursive tableview because I can't think of any other descriptive name.

For example, in a shopping app, you go into "cars", then "hatchbacks", then pick one from the list, say "SX4". When viewing the details of SX4, I want to show recommendations of other cars they might be interested in, so at the bottom I add "Cobalt" and "Volt". Tapping on Cobalt pushes a new view, adding to the hierarchy. The Cobalt view also has recommendations, like "Volt", and tapping on Volt pushes another view. And so on... infinitely. Eventually the app will die because of memory, because both iOS and Android automatically store the hierarchy to allow the back button functionality that we're all used to.

I'm curious if anyone has come up with a clever way to solve this interface problem. Memory problems aside, when users want to get back to the category list (hatchbacks), they have to tap the back button dozens of times to pop up the hierarchy. Not a great user experience.

The only "solution" I've come up with is to change the behaviour of the back button; tapping the back button brings you back to the category list (hatchbacks), essentially short-circuiting the hierarchy and not storing the moves down the hierarchy.

Improve this question

1 Answer 1

Reset to default
2

We've dealt with this in our app as well; we don't yet have a solution that we're entirely happy with, but two things we've found to work reasonably well:

  1. A separate "close" button, either located just to the right of the back button or at the top right corner of the screen. (the former is perhaps a bit more intuitive, but the latter is much easier to code since you just stick it in your navigation bar controller as a right button)
  2. If you're using a tab bar controller on the bottom of the screen, make tapping on the current tab a "return to top" gesture; it's fairly intuitive (albeit not especially discoverable) and avoids the need for an extra control.
Improve this answer
1
  • The tab bar is a reasonable way, but does not get around the memory issue. We're thinking of an alternative now. Instead of pushing a new view, load the new content in the same view. Now, the "back" button becomes a "home", sort of a hybrid of your #1. We're also playing around with a history idea, like web history, which would allow you to track the hierarchy and access any element in it. This solves both the memory and the "too many back buttons" problems, though it is HIGHLY non-standard on every platform.
    – Andre
    Feb 22, 2013 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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