The browser Back button is a fundamental navigation control that users are accustomed to using for web site navigation and for browser-based application navigation, such as booking, e-commerce, and social applications. The Forward button shares the same functions and its inclusion is implied.
Browser Back button support (3BS) doesn't come "for free" with single-page applications that rely upon Ajax calls to simulate page navigation. 3BS requires a UI design choice and specific implementation in this case.
Browser Back button support could prove cost prohibitive and detract from the user experience if implemented for every partial page rendering (PPR). Therefore, teams should carefully evaluate where this support is needed.
It's necessary to identify PPRs within a single page application that should receive browser Back button support. Following is a list of the situations to consider.
- Consider 3BS for any PPR that the user would interpret as page navigation.
- Consider 3BS for any intra-page navigation (such as, tabs, info tiles, or wizard steps) which the user would interpret as navigation.
- Protect users from unintentional loss of unsaved user data when using the Back button.
- For example, when users navigate to a data entry page and provide user data, a warning dialog should remind them of unsaved data changes if they opt to use the browser Back button instead of a UI Save button. This provides users an opportunity to either explicitly save or abandon changes.
- Exclude 3BS for any PPR that simply presents a UI state change.
- For example, a page that hides or shows elements of the UI based upon the state of a radio control or check box is not a candidate for 3BS.
- Exclude 3BS for any PPR that results in a persistent data storage change.
- Neither the browser Back or Forward buttons should function as an implicit rollback or commit of any user data.
- Exclude 3BS for any PPR when the user would expect a change in persistent data storage.
- For example, it is not recommended to implement 3BS to return to a wizard, if it's possible that users could erroneously conclude that their submitted data is now reverted.
- Don't couple an Undo stack with 3BS. Present the browser Back button and Undo as independent UI features.
Following is an illustration of navigation paths that could use browser Back button support.
Implementing browser Back button support includes properly implementing a complementary browser history. Make browser history entries distinguishable from one another as much as possible; a browser history that lists identical entries is frustrating and ineffective. The following image is an example of entries that would leave users to adopt a "hunt and peck" strategy in attempts to navigate directly to a desired page.
To provide the best user experience with browser history entries, create distinguishable history entries using the following format:
- [favicon] pagetitle: data
- [favicon] is an optional icon that can identify the application or suite.
- pagetitle is the UI title of the visited page. It is important that the string for the page header and pagetitle match.
- data is the principle artifact of the page. For example, if the page title reads, "Employee: Mark Willslip", then pagetitle = "Employee" and data = "Mark Willslip."
This short syntax relies on the temporal context to further distinguish visited pages, as well as on the longer URL provided by the browser history feature. The following image illustrates good browser history entries.