Hot answers tagged

63

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 ...


51

What Jakob said As far back as 1999 (or 1996 if you include the "frames" problem), Jakob Nielsen's number one "web design mistake" was "breaking the back button": 1. Breaking or Slowing Down the Back Button The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily ...


39

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. See source Rightly so, IMO.


28

Yes it is. I'm not sure exactly what you mean by unexpected behavior, but users expect the same thing from a back button, whether they are using an application or a regular website. Think of it this way: the back button is part of the browser, out side of your website. It should perform the same way no matter the content being viewed. If you are designing a ...


25

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 ...


17

From an UX perspective there's not doubt that you should always show the user the current state of the system, if not, 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, ...


12

The SDK contains an icon called "ic_ab_back_holo_light.png" which looks the same as the icon from the design guidelines: Located in ...android-sdk\platforms\android-14\data\res\drawable-xhdpi


11

The default behavior is to go to the previous screen no matter what it is. If you're deep in the menu then it takes you up a level. If you're in the top level of a menu it takes you back to the application. If you're in the main screen of an application it takes you either to the desktop or to the app, from which you launched the current one (e.g. from ...


11

Yes, the user should be able to go back using the browser's back button. Wherever possible consistency should be maintained, as should meeting user expectations. For many users 'going back' on a web browser whether via the button or a shortcut (including dedicated shortcut buttons in mice etc) will be automatic behaviour which will be difficult for user to ...


11

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 ...


11

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 ...


10

You shouldn't override the default behaviour of the browser. You should really be able to cope with the user hitting "back" and returning to the previous state, however, I have seen something along the lines of the following added to the page: Please don't use the browsers back button to navigate between pages and if you do click the back button it ...


10

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 ...


9

I personally always expect 'back' buttons on multi-page form processes. Having a button to move forwards without the equivalent control to move backwards is disconcerting. As you note, the browser back button won't always work with forms, so some people are nervous about using it. You'd also be surprised (as I was the other day when presented with the ...


9

If this application is to be designed for iOS then placing the button on the right is actually a violation of Apple's Human Interface Guidelines for the Navigation Bar (see the Guidelines section): A back button should appear to the left of the title, and it should be labeled with the previous level’s title. If this application is being designed for ...


9

If your users are telling you that they don't know how to get back, then that's a pretty clear indication that yes, you need a back button in your app. It might be worth doing some quick usability studies to see if it is platform-specific (like JohnGB's answer indicates), but this sounds like a case where you should listen to your users. Also, in every ...


9

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 ...


8

The back button in apps depends largely on which platform you're developing for. Here's a few use cases. Android apps 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 ...


8

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: Back button You should never, ever, break the behavior of the back-button. At all times, you must strive to keep it's functionality in ...


7

dnbrv and Pewpewarrows have it exactly right, but to point to the most definitive resource on the matter, the Android Design Guide says this: The Up button is used to navigate within an application based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which ...


7

A quick search of the Adobe site shows the reasoning for this - albeit for CS5 but I would imagine the reasoning is still the same. (emphasis mine): By default, the Photoshop History panel retains only the last 20 actions. This is a compromise, striking a balance between flexibility and performance. You can change the number of levels in the History ...


7

If you're talking about mobile apps, the top left is the standard position for both iOS and Android (technically it's the up button on Android, but that's close enough). If you're talking about a website, there is no standard placement for a back button, as there is a keyboard back button, and so most sites don't bother with a back button. That said, I ...


7

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 submission? 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 ...


6

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 ...


6

I think this hinges on whether the order of the playlist has meaning. On a 10 track CD, the songs are meant to be played in a certain order. But a user constructing a playlist with hundreds of songs is not thinking "I want to play all of these songs in order". If the latter is what you see as the common use case for your software, I agree with going back ...


6

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 ...


6

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)


6

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 ...


5

I don't think there's any reason to have a back button that does the same thing as the browser's back button. (It's generally safe to assume by this point that your users know how to click back. Just make sure that your site functions in a way that the in-built browser back button will work.) However, you may want to include an up button, as explained in ...


5

Part of the decision is the amount of memory used per undo. In a large, complex application such as Photoshop, there is a large amount of state that is restored in an Undo operation. In a web browser such as Chrome, on the other hand, the only state required is the address, and in some cases form data; this state is maintained anyway (browser history), so ...



Only top voted, non community-wiki answers of a minimum length are eligible