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


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


10

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


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


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

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


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


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


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.


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


3

2 different usage patterns mentioned in the Win 8 UX navigation pattern guidelines: Initial pattern says Back button should take you back to previously visited page and not hierarchy. Header and Back button: The header labels the current page and is useful for wayfinding. The Back button makes it fast to get back to where you were. Further down ...


3

This warning is "allowed" by the browser. Each browser implements the behavior differently. However, it is most common to allow the user to "leave this page" by default. The reason is that pages can maliciously prevent you from closing the window with a simple script and the user is forced to take action to leave a page. Making this choice the default, ...


3

Good Question. The difference lies in General Usability Guidelines vs new navigation models found in App Guidelines. If your web app acts and feels like a native app (like forecast.io) I might defer to the App guidelines. If not, stick with the general usability guidelines to not the break the back button. Apple HIG guidelines that states "When navigating ...


3

You are thinking in programmer terms rather than user terms. The way a system is implemented is of no concern for the user, and users are typically completely unaware of whether a page was reloaded or simply update by AJAX. What you should account for is the mental model of users - if the interface appears as if it moved forward one step, most users would ...


3

No, because often on a mobile device, the user can be temporarily distracted and attention can be sporadic. Mobile users multitask more often. For this reason, you don't want to have to put the onus on the user to remember where they came from (in order to make the decision of where they want to go next). In any case a back button on a mobile device can ...


3

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



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