3

In my application I've got some multi-part articles, about test-driving a car. The articles are split into multiple section.

I'm using this control to navigate between the sections (note: it's not located in the navigation bar, but in the body of the article):

bread crumbs control 1

The user can tap on any of the sections and navigate to it. The current section is also displayed with a different background. When navigating from "Intro/History" a new view is pushed and slides in from the right (using the default navigation bar on ios).

enter image description here

My question is when navigating in reverse, for example from "Exterior" to "Intro/History" should I push a new view from the right, or "simulate" the back button being pressed and slide the view from the left ?

If I just push a new view situations like this might appear : A>B>A>B ... >A>B (infinitely stacked). Would this be confusing to the user ?

Also consider the situation when the users skips from the 1st section to the 4th. Should the back button then lead him to the 1st section, the 3rd section or always point to the list of articles?

Any suggestion would be appreciated.

EDIT: Here is a rough mockup of my navigation as it currently is (note that the app is for ipad not iphone; Also articles don't have their title displayed in the navigation bar, because it's in the article body):

enter image description here

Improve this question
5
  • You say that it is not located in the navigation bar, so does that imply that there is a navigation bar? What is the function of that?
    – Charles Wesley
    Commented May 10, 2013 at 16:14
  • basic master-detail navigation
    – Lescai Ionel
    Commented May 10, 2013 at 17:02
  • So when you say "Should the back button then lead him to the 1st section, the 3rd section or always point to the list of articles?" are you referring to the back button in the navigation bar? Wouldn't that take you back to the master, which i'm assuming is some kind of table view with a list of articles?
    – Charles Wesley
    Commented May 10, 2013 at 17:29
  • Can you update the question with a diagram of what the root view would look like with both the navigation bar and the sub-nav?
    – Charles Wesley
    Commented May 10, 2013 at 17:31
  • @CharlesWesley I've edited the question with a rough mockup.
    – Lescai Ionel
    Commented May 11, 2013 at 7:18

2 Answers 2

Reset to default
1

Since the user will be reading in downwards direction for each article, it would make more sense for each next article to be below the current one. This way a user can just keep on scrolling to go through the article, instead of switching downwards, sideways, downwards, sideways. One app that does this well is Reeder on the iPhone, but there are many others.

If you're sticking to the existing design though, a number of elements strongly suggest a direction. Your breadcrumbs tell me that Interior is to the right of Exterior. You're further supporting this with an animation sliding Interior in from the right when I switch to that page. This animation is not just something fancy, it suggests that the pages I'm looking at exist in a certain location and that I'm pulling each on into view. It makes the pages behave more like actual physical objects which makes it easier for me to understand how to navigate from one to the other.

You can't have Intro/history be on the left of Exterior one moment and to the right the next moment. It completely breaks a user's mental model of how the pages are arranged and makes it much harder and frustrating to navigate.

If I can go from A to D without visiting B and C, hitting "back" at D should take me back to D without visiting B and C. "Back" is there to undo a navigational step. Take Windows Explorer for example. If I take a shortcut from the Desktop to Documents/Some folder/, hitting back takes me back to the Desktop, not to Documents. Some interfaces have an "Up" button that would take me to Documents.

Improve this answer
3
  • -'you can't have intro/history on the left...' would using a different animation than left/right (drill-down,back) like up/down or page curl up/down be more suited for this kind of navigation since the user stays on the same level in the hierarchy ? - I also took a look at Reeder 'pull to go to prev/next' feature. it might fit in this scenario. - Would enforcing the order of navigation between the article's page make sense ?
    – Lescai Ionel
    Commented May 11, 2013 at 7:33
  • The important part is that if you establish, in any way, a direction in which the items are arranged, you have to stick to it.
    – Koen Lageveen
    Commented May 11, 2013 at 9:48
  • 1
    Take a mail client. If the emails are in a vertical list, navigating from one email to the next would be down or upwards, not sideways. It irks me to no end that Gmail has this wrong. Page curl won't work because you also have scrolling and that breaks the metaphor. With your mockups in mind, go for the pull-for-next/prev thing for multi-part articles because it allows you to keep on going in the same direction. You maintain the same flow throughout the article.
    – Koen Lageveen
    Commented May 11, 2013 at 9:56
2

If you are using sliding animations between screens, you should stick to the convention that pushing a new view from the right = forward, and from the left = backwards. Otherwise your sliding animation not only looses its purpose, but it actually then causes confusion by implying something that isn't true.

The second part of your question is more complicated. 'Back' on iOS is usually a historical back, not a hierarchical back (called an 'up' button on Android). So 'back' should normaly take you back to the last screen that you were on before the current one. However iOS apps usually have a simple structure, and so there is often little difference between historical back and hierarchical back (up).

However, that wouldn't make sense in your situation, and so I would recommend using it as a hierarchical back (up) button, but in your case I would recommend it always going to the a central starting point like 'contents'. However, you should label it correctly and not just call it 'back'. You should label it according to the screen that it will navigate to.

The closes example to your situation I have come across is the Economist app on iOS. Here the back button is always hierarchical, but because it is labelled clearly, it has never been a usability issue.

enter image description here

Improve this answer

Your Answer

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

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