A web application should always strive to be compatible with the browser's back button. That is, using the back button should have deterministic results within that application that match expected behavior (global consistency).
A common scenario that comes to mind with this is an eCommerce site
that has a list of products. A user clicks on one of the ...
The back button is important. Users should be able to correct any mistakes and review what they have already entered. Also, I do not find the back button a reason users will not finish the form, on the contrary the back button will give them a sense of control and safety.
Allowed but not emphasized
The key is to provide the ability to step back, but not encourage it. If it's over-emphasized, some people will feel compelled to review their work regardless.
The example above shows a wizard that allows stepping back either through the progress indicator (click a number) or a subtle back link.
A little background: Users are ...
Microsoft's MSDN Guidelines claim:
Preserve user selections through navigation. For example, if the user makes changes, clicks Back and then Next, those changes should be preserved. Users don't expect to have to re-enter changes unless they explicitly chose to clear them.
Rightly so, IMO.
Yes. You should rely on the browser back button.
Users expect the button to be there, so make sure it's functional.
But should you mimic the same button with its functionality?
If your application or website needs it, yes, but not always exactly the same.
In some cases, like your example of a webshop, a button that just says back or an arrow might not be ...
From an UX perspective there's no doubt that you should always show the user the current state of the system, otherwise users could think that their action was not really performed / recorded which can only derive in bad things. (users untrusting the system, getting mad, redoing actions then to discover they have duplicated data and have lost their time, etc)...
From my perspective there is two views on this question:
On standard websites people do not expect the Esc key to work. Instead people do (still) use the back button a lot.
In animation and video the Esc key is actually a commonly known interaction pattern – at least for people that regularly use the full screen mode and want to leave it with the push of ...
The back button in apps depends largely on which platform you're developing for. Here's a few use cases.
Android phones typically have a soft key for the back button. The function is to go to the previous page. This is referred to as temporal navigation.
According to the Android design principles, arrow in the action bar is to go one level up. ...
Preserve the information when you can. Consider the 3 data entry pages as one big form that you happen to split into three. As the user completes one section/page, that part should be treated as completed as they move forward. If they move back, they should see what they saw when they left the page - the information that they entered/selected. You'll ...
If you added this back button, to make the app work like an iOS app you should indeed remove these.
Android does suggest adding an arrow (home) action to the action bar on the left hand corner, this however should direct to the parent activity, does not have to be the same functionality as the hardware back button.
And yes, it's available on all devices ...
What creates confusion i.m.o. is the back and the close button being on the same level in the visual hierarchy where as they act on different levels. Wouldn't it be more clear when the close button is visually more separated from the back button?
I would not recommend moving the previous/back button and replace it with a close button, because now the user ...
In my experience, modal windows are best used to present clear interactions that the user either:
needs to do (e.g. resolve an alert)
has chosen to do (e.g. open a photo gallery).
Resolving that interaction should close the modal, and there should already be a control in place that does that.
This is because modal windows interrupt the user flow and break ...
Rely is the wrong word
You're asking if you should rely on the button, which you shouldn't. You're also asking if you should offer another option. Which you could, and in certain situations, should.
So here's the thing:
You should never, ever, break the behavior of the back-button. At all times, you must strive to keep it's functionality in ...
Question 1: Back button is totally needed! There is a few reasons for this.
With a back button, you ensure consistancy accross devices and browsers. Each browser could have the button in different places, different shapes or even hidden in a submenu. Essentially, you maintain control of the experience.
Not all user uses the back button in browser, myself ...
I would encourage you to consider whether a cancel button is truly necessary in this situation.
What is the likelihood that the user will wish to cancel their entire
Is it more likely that the user would wish to change pieces of the submission more easily accessible using the back navigation rather than the entire submission?
Will other on-...
For most users, this will be just another page. And conceptually, they will be right, they have no idea about the technical part, they only know that by clicking or doing something they are presented with different content. This is a very common (and quite studied) situation, of course.
From NNG Overuse of Overlays
You should also consider ...
I find the second version confusing. I think that the same button should be placed at the same place in the different screens.
But I have to say that I find the first option confusing as well. To me, the button on the left should go back and the button on the right should go forward.
Maybe it is a good idea to give us some more information of the rest of ...
You should remove any buttons that are not available to the user.
A disabled state implies that there may be some action that will re-enable the button.
However, you need to make sure the user is fully aware when moving from pages with 'Back' buttons to pages with no 'Back' button - you could achieve this by changing the 'Next' button on the last editable ...
Arguments of the appropriateness of modal windows aside (because I don't think we have enough context for that from your question), I think your reasoning for why this is a good idea is sound. Some users rely very heavily on the back button:
The Back button is the lifeline of the Web user and the second-most used navigation feature (after following ...
Usability shouldn't be looked at in terms of 'will it be acceptable to do x', if you know doing something is bad and you're looking for excuses to do it then you really shouldn't be doing it.
Usability should be approached in terms of 'what advantages does doing x have?'.
Disabling the back button...what does it give you? I am struggling to think of any ...
You shouldn't do that.
The back button is a navigation element. Check the Core App Quality Guide, and especially the Back Navigation Guide.
Android users will expect the button to navigate back. If you want an undo, add an action to the action bar or provide it via a popup (http://developer.android.com/design/patterns/confirming-acknowledging.html)
No, it's not a good idea. Apart from the fact that nobody would expect it (principle of least surprise), it's already established that the back and forward buttons move through your browser history -- that is, pages that have already been visited.
The forward button also has no ability to indicate, like a 'Next' button often does, whether proceeding at this ...
I usually try to provide both on-screen back-button and support for browser back-button.
If the user is immersed in the flow of the app, an on-screen back button can help keep focus inside the flow and avoid losing the user's attention.
Supporting the browser back button is important to me, even at great cost, because it's presumptuous design to ...
By default an Android application minimizes and returns to the home screen when it is no longer possible to go back further inside the app itself. Deviating from such a pattern is likely to result in irritation and annoyance amongst users.
Or as the say in the android guidelines
Consistent navigation is an essential component of the overall user ...
On developers.android.com you can find very useful information about "Navigation with Back and Up" button in Android Apps.
The standard behavior of the "Back" button is to navigate in reverse chronological order:
The system Back button is used to navigate, in reverse chronological
order, through the history of screens the user has recently worked
You should allow the user to use standard practices to go back :
Pressing Esc key should take the user Cancel/Close.
Have a Back - icon followed by the context where it would go to.
Have a CLOSE icon which closes the modal without change of State. Similar to #1.
Clicking outside the modal should take the user back.
Hitting the back button on the browser ...
Be weary of mixing form buttons and navigation links. A user will likely think 'Back' button is a navigational item not a form submission. Assuming button click = server trip to save data.
The confirmation page is probably the best page to put a back or 'Update' link. The summary of highlighted issues links them to areas needing respective updates.
If the ...
The issue that you are facing is primarily caused by the fact that your QA team is expecting single-page application (SPA) behavior out of (what sounds like) a multi-page application (MPA) design.
You are right to question altering the behavior of the back button because users have been taught to expect that if the page reloads as they "move forward" ...
The left-pointing arrow in the action bar is actually an "Up" button. It works a bit differently than the back button -- instead of going back to the screen you visited last, it goes to the screen that's one level up the hierarchy.
Google's Developer Guide gives a detailed look:
The Up button is used to navigate within an app based on the hierarchical