User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Consider the following scenario:

I have an Android application with three screens: a list of items, a search results screen, and a show item screen. A search bar can be invoked on every screen, and the search bar will either take you to search results screen or directly to an item screen if autocomplete finds a perfect match.

Now, the questions is, how should the flow between screen be organised? The simple flow is easy: list > search > results > show. Clicking the back button in either state moves one item down the stack.

However, what if search is invoked from the show screen? The stack would then be list > search > results > show > search > results. And we could possibly end up with a tall stack of search results and show screen.

I'm considering making the flow such that whenever you invoke the search bar (and perform a search), any show screens are removed from the stack, and the stack will never be more complex than the simple list > search > results > show.

I guess the core of the question is whether a user invoking the search bar from a show screen mentally "goes back to search" or "moves on to the next search", and thus might expect the first show screen to be accessible or not.

The IMDb app for Android follows the latter approach, easily building a stack of tens of screens, and I'm personally not thrilled about this.

share|improve this question

I think it depends on the usage and the sort of content the app contains.

The app I use to plan a journey by train uses the simple stack that resets when a search is initiated. This often results in me losing an earlier search result because I started a new search. In this case, a bigger stack that doesn't reset would be preferred.

If the app features a very simple usage scenario, or a collection of items that don't really have a big relation to each other, it might be confusing to have a long and complicated stack.

share|improve this answer

Hmm, I see this as a 3 Screen scenario.

  1. Search
  2. List/Results
  3. Item

List is really just a preset search... SELECT * from TABLE

Search > Results > Item

With the additional direct path

Search > Item (in the case of an exact match)

share|improve this answer
I might be, although in my app I need a different presentation for searches. But still, what would be the most relevant page flow when search is invoked from item? Should pressing backing after searching from an item page take the user back to the previous item, or back to homepage/list/other root view? – Gunnar Lium Dec 9 '10 at 12:57
I don't think this is a answer to the question. Gunnar is asking about how different screens get saved in the android stack. Not how a user searches for an item and gets directed to that page. – TomvB Dec 9 '10 at 13:35

Your Answer


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.