The back button is a great "get out of a flow's dead end" option that browsers provide. Should a UI rely on the back button as the only method to allow a user to get to the previous page or should the UI provide an additional, site-specific button to return to the previous screen?
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 products to view a details page. Then after viewing the details, they would like to go back to the list to click another product and view its details. Should the UI assume a user will use the browser back button or should the web site provide a link or button that allows users to "Go back to Your Results", leaving the browser back button as an alternative option?
Answer
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 products to view a details page. Then after viewing the details, they would like to go back to the list to click another product and view its details. Should the UI assume a user will use the browser back button or should the web site provide a link or button that allows users to "Go back to Your Results", leaving the browser back button as an alternative option?
However, a web application should generally not rely solely on the browser's back button for all navigation that might be considered related.
Sadly, one of the top reasons for this is that some people are afraid of hitting their back button within certain web applications due to broken or inconsistent browser control/state related behavior found in many AJAX heavy web apps, where using the back button may not result in the effect the person using it anticipated.
Secondly, if the page was spawned from a new tab (or a bookmark!), there may not be a back button. While the person using the app should ideally still have the original tab open, if you want them to be able to access the page they came from, make sure to give them a way to do so from the context of the page they are currently on.
Using your example, say the list was a static sale page (instead of a dynamic search). What if the person browsing the site bookmarks an individual product, then closes that session. When they load that bookmark, what navigation options do you want available to them? What navigation options do you think they will want at hand? It's a good idea to make these a consistent component of your UI, hence not worth solely relying on the back button in other instances.
To expand slightly on this, providing back-navigation options within your UI gives you control over their presentation: this means you can assuage anxiety over what an action result will be by clearly delineating what using the control will do.
For example, consider whether someone would have any uncertainty over what the following might do:
Back(Back to where? also applies to the browser's back button, because we all know it doesn't always do what we expect, depending on the web app, and people don't know what your app will do until they try, which can be a hesitation point)Back to listings(which listings? if I come here from a bookmark, do I have any clue what I was doing that got me here?)Back to [associated product category](Well, that's nice, it is functional and not a concern for failing to be deterministic, but should probably be represented elsewhere)Back to the January Sale Event(hey! that's what I was looking at when I came here! it's specific enough that I can expect to end up… where I would expect to go) (aka it matches the navigation context map that brought me to this page)
(and you probably want to use a wording such as "More of" rather than "Back to," depending on the context you end up using such a control in, and when the navigation from it clearly ties to specifically cross-related results)
That last example gives you what you want to strive for: a reduction of anxiety for people using your application by making clear what the related outcome will be.
Moreover, this gives you extra behavior beyond what is necessarily available in just the back button. While the back button should simply work, this control is then present if someone opens the page two months later. If they do click on it, you can present the related page for the "January Sale Event" but with a message at the top saying the event is now over, we're sorry you missed the amazing deals we were having, but see [these new events/products/etc].
These navigation points are an opportunity not only to have a backup back-navigation control that you know the person using the application will feel comfortable interacting with, but also one where you control where it goes, and which provides you an opportunity to communicate with the user under a fairly tightly managed context. They can, if managed correctly, provide more functionality than the browser's back button alone does, enhancing the experience rather than simply cluttering the screen with directly duplicated controls/functionality.
If you are going to implement back-navigation controls, make them clear, consistent, and consistently available (at least on the page types where they make sense). Try to provide extra value over what the back button alone represents, both to yourself and the people using your application.
If you are just going to literally duplicate the browser's back button functionality with a control that says back or has some similarly representative icon… don't bother. Just make sure the browser back button behavior works properly. (which you should always be doing anyway)
No comments:
Post a Comment