0

I know my question isn't very specific and uses Android specific terminology (i.e. views) but the idea is there's a many to many relationship between Provider's and Location's and we need to display it with the constraint that this is being done in a mobile application (both phones and tablets, watches and tvs are ruled out).

The original designers only thought about this one layer deep and wanted the user selecting something from the Provider list to be taken to an Provider detail screen which has information on Provider as well as a list of related Location's which are all clickable and will take you to a Location detail screen.

Guess what's on the Location detail screen? THAT'S RIGHT! It's Location information with a list of related Provider's!. So now the application's navigation will look like this (roughly, assuming the user clicked on Provider2 was presented with Provider2's detail page then clicked on Location2):

  • Provider1
  • Provider2
    • Location1
    • Location2
      • Provider2
      • Provider4
      • ...
    • Location3
  • Provider3

You get the idea. Even worse, no one seems to want to commit to what they think the "back" button should do. Does it take you back up the tree (thereby making the app navigation infinite and quite frankly more difficult to code and maintain) or does it take you back to the root or does it serve some other function? Is there a good design pattern for mobile to handle this in a better way? If so, does it address the "infinite navigation" problem?

Improve this question

3 Answers 3

Reset to default
2

Pretty simple, as an Android developer there is a very clear description of the back button. As others have posted: http://developer.android.com/training/implementing-navigation/temporal.html.

What I must say the way your app seems to work sounds to me like a poor design in this case the back button should indeed allow to create a huge backstack ending in an out of memory exception. So if possible try to find a different solution to this. In general you use the same back navigation to keep a nice structure as an iOS device. (So left top back arrow reflecting the structure). The back button should return you to your last visited view.

About maintaining the code it doesn't sound like a big problem to me since Android has pretty simple support to this, you could also look into limiting the backstack and just keep track of like 20 pages in history to avoid using too much memory. I'd even suggest writing your own solution to just keep track of a unique ID (location or provider detail).

But again this unlimited nesting does sound like a problem and a bad design choice but I can understand people would like this but they would probably won't be able to grasp the structure this way.

If you really have to keep this structure, either go with limiting the history or use the general structure going back to the main screen when you are on a Provider detail page, either cases will confuse the user anyway.

Improve this answer
2
  • It's tought to work around a bad design... thanks for the input, we were not able to convince the client this was not a good way to go, but your options provide a better way to handle the logistics at least. As I responded to other questions, I'm aware of what the temporal back button does, but that's not what I was talking about. I was referring to the "ancestral" back button. In the scenario I describe, which view is the parent? going back to the main screen when you are on a Provider detail page, this is what we ended up doing.
    – akousmata
    Jun 15, 2015 at 15:28
  • Yes that makes most sense in this case.
    – Mathijs Segers
    Jun 15, 2015 at 19:57
1

So first of all, the "back" button has a specific use within Android UI guidelines: http://developer.android.com/training/implementing-navigation/temporal.html.

Second of all (and I would post this in a comment but you need 50 rep to do so), your question is confusing because it's hard to understand the relationship between the As and Bs. Could you update it with sample content? It might be easier to answer.

Improve this answer
1
  • Sure, question updated a Provider can provide service at many Locations and likewise a Location can have many Providers . I'm aware of the fact that Android has a specific use for the back button in terms of the activity stack, but this app is going to exist across many platforms and the idea is that the experience should be somewhat similar. So in the case of Android, we would need to think about the "up" button I suppose.
    – akousmata
    May 14, 2015 at 14:22
1

I think that any interface with this kind of "circular" navigation is going to be potentially confusing and thus bad. Is it the case that the user could end up in an endless loop of Location 1>Provider 1>Location 1>Provider 1, or something like that?

What about using a metaphor of "available" vs. "unavailable"? Think about the way online retailers display availability of a product while letting you simultaneously selecting color AND size. You could do this with dual lists: A selection made in one (Location) will limit the other (Provider) to only valid options.

Another way, if the numbers aren't too big, is with dual icon/label grids, as Uniqlo does in their online store.

Or maybe there is a way to use cascading lists to navigate.

Improve this answer
1
  • Yes that is the case. I like the idea of the dual label grids, just trying to envision that on a mobile device. I suppose a dropdown for filtering by location would work on the provider list screen. I think we're going to have to convince the client that the endless loop is not a good idea and to try to have them pick a stopping point or some way of keeping the "depth" of the navigation to be limited to a certain number of levels. (i.e. leaving off the list of locations on the provider's detail screen or something similar.)
    – akousmata
    May 15, 2015 at 15:36

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.