Is it still necessary to put a "Go Back" button? Or do users already intuitively know that they can use the browser's back function instead? I just feel it can be an unnecessary "action" to put and removing it helps simplify a page especially if it already has a number of other buttons that performs actions necessary for the application.
asked Mar 21, 2013 at 2:09
Add a comment
|
5 Answers
Honestly, I don't think it has ever been necessary to put a back button on a website. Even in 2001, when I first started making web sites, I never placed a "back" button on the page - because it's redundant within the tool being used to view the site.
Now, there are exceptions - but very, very, few. When I made Flash sites, before using hashtag URLs to maintain the functionality of the back button - if there was no other way for a user to back-track to the view they were just on, I would add a back button. What that means is, if the user could, based on the storyboards, go from say page A to page B, then, using the primary navigation get back to page A...no back button required/desired.
Of course with our ability to do things in a way which no longer breaks the ability of the back button to go back in the browser history - it just ups the logic to not have a back button to navigate from one page to another.
Edit:
In the case of a "previous" or "cancel" button like those found in surveys or forms, it makes sense. Especially if the button does not actually simply move the browser history back in the stack. For example, we may want clear some data from the form, or add a "jump to where I left off" functionality. Which is not literally the same as "the browser's back function".
If the back button has another function than the browser-side button, it's more user-friendly and a good style.
For example on surveys or registration forms with multiple pages it's very nice to save the data you entered and not delete it when going back. (AJAX)
I don't believe a back button is necessary most of the time, unless the application is more than just reloading the previous page. If back on the browser loads a previous page, but back on the page reloads a previous version of a form or reverts a change in an application then its OK. Or if for some reason browser back breaks the page like on some sites shopping carts. Of course fixing that code is preferable.
I do believe every page that lets you get more than a few pages deep should have bread crumbs though.
Single page applications or applications that rely heavily on ajax, in my experience, can benefit from a back link (which triggers another ajax load or invokes a client-side controller method).
This is because pressing back can sometimes break behaviour of your app if not very carefully designed.
-
1This is true--of course, this is a band-aid solution because the app wasn't designed/programmed properly in the first place.– AndrewCommented Mar 21, 2013 at 12:39
-
@Andrew Well, I would argue that navigating an SPA app user resorting to browser buttons hints at bad design: the interface itself should probably be entirely self-contained. Correctly handling a browser back event is itself a palliative measure to catch people who hit back by reflex instead of using your interface. IMHO.– msanfordCommented Mar 21, 2013 at 18:30
-
@mansford I understand your point, but I am not convinced. Perhaps it all depends on context (e.g. if it appears self-contained or appears like a website). This is a similar topic to whether a mobile site should work well with the device or browser's back buttons (ux.stackexchange.com/questions/7216/…). I guess the only true way to find out is to observe in usability testing and monitor via advanced analytics.– AndrewCommented Mar 22, 2013 at 13:11
My site offers a "back" button. It navigates to the home page from the activity profile page. I don't think it is a bad practice it may depend on the navigation flow of your site.
