Tag Info

Hot answers tagged

44

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


38

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.


27

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


11

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


10

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


10

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


9

You shouldn't override the default behaviour of the browser. While it would be nice to be able to cope with the user hitting "back" and returning to the previous state I can't see anything wrong with putting up a large warning: Please don't use the browsers back button to navigate between pages and returning the user to the start if they do. As long ...


9

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

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 fpr people that regularly use the full screen mode and want to leave it with the push of ...


8

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


8

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


8

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


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

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

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


7

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


6

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


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


5

An excellent article that I think summarizes the issues around the Back problem very well and puts forward some suggestions: Rich web apps a need for Undo rethinking what the Back button should be rethinking what the Back button should do A must read.


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


5

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)


4

How about something like this. Indenting submenus can make a lot of difference. Keep the breadcrumb but have the submenu look more like this: When the user is in the main Accounts page When the user is in the Change Password page The problem with using "Index" is that it probably doesn't mean much to users.


4

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


3

Your first guess is in general a good guess. Yet there are some "details" you need think of. First, it has to follow the overall structure of your website (e.g. when you're in your list of articles, where is the "back to home" button?). Generally, once a user went through 3-4 pages in your website, he will get a mental model of how it is structured and how ...


3

I think you should give the Apple User Interface Guidelines a read. Consistency Consistency in the interface allows people to transfer their knowledge and skills from one application to another. A consistent application is not a slavish copy of other applications. Rather, it is an application that takes advantage of the standards and paradigms ...


3

"A Study of Tabbed Browsing (CHI 2010) suggests that users open pages in new tabs and use that for "revisitation" more often than the back button, which is an interesting find" This study asked for "mozilla firefox users who used multiple tabs or windows" as requirements for participants. This is completely ungeneralizable.


3

If you have a full screen information dialog (or even a full screen dialog with more than information e.g. settings), you could place a "Back" button at the button instead of an "OK" button, since "OK" is more common for smaller pop-ups. ("OK" makes me think, "OK" I have read this, close this window. However, if the windows is full screen, I can't tell if ...


3

It's always a good idea to keep the item that's in focus in the viewport. However, as soon as the user has taken control of the positioning of the screen (eg. by scrolling to the side) you need to be careful about repositioning (eg. scrolling back to put the focussed item within the viewport again). I would propose to only do this initially when a ...


3

I came across a very similar situation when designing the navigation for the application I'm working on. We evaluated several different types of navigation patterns and landed on two when we got into thorough user testing: The standard hub-and-spoke pattern (when drilling in, the menu button goes away and you must navigate all the way back to the ...



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