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. Try to provide extra value over what the back button alone represents, both to yourself and the people using your application. 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). 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.
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. 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. While the back button should simply work, this control is then present if someone opens the page two months later. Moreover, this gives you extra behavior beyond what is necessarily available in just the back button. 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.
(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)
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). (Well, that's nice, it is functional and not a concern for failing toīe deterministic, but should probably be represented elsewhere) Listings? if I come here from a bookmark, do I have any clue what I The web app, and people don't know what your app will do until they Back (Back to where? also applies to the browser's back button,īecause we all know it doesn't always do what we expect, depending on. 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.įor example, consider whether someone would have any uncertainty over what the following might do: 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. What if the person browsing the site bookmarks an individual product, then closes that session. Using your example, say the list was a static sale page (instead of a dynamic search). 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. Secondly, if the page was spawned from a new tab (or a bookmark!), there may not be a back button. 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. Option? However, a web application should generally not rely solely on the browser's back button for all navigation that might be considered related. Your Results", leaving the browser back button as an alternative The web site provide a link or button that allows users to "Go back to Should the UI assume a user will use the browser back button or should To go back to the list to click another product and view its details. Then after viewing the details, they would like That is, using the back button should have deterministic results within that application that match expected behavior (global consistency).Ī common scenario that comes to mind with this is an eCommerce site A web application should always strive to be compatible with the browser's back button.
0 kommentar(er)
