Journal Navigation

Problem

People tend to think linearly and often like to be able to navigate that way.

Solution

Give people a mechanism that they can use to go back and forth in their navigation history.

Context

• You are building a Web application.
• You have a desktop or RIA application that involves changing the main view (i.e., it has the feel of moving from one view/page/screen to another).
• Enabling this kind of navigation can be done without negatively impacting the state of the application or people’s data.
• You are not trying to ensure a forward-only navigational experience, such as in a controlled task flow.

Rationale

Despite our multitasking lifestyle, we’re still linear beings that operate on a more or less single thread/timeline. We experience software in that way, and when the main views of some software change, it feels like we are navigating from one view to another. On the Web, this is very explicit and expressed in terms of pages and navigation links taking people from one page to the next. Early on, the need was recognized to enable people to easily go back and forth along their navigation history, so back and forward buttons were created and are now a staple of browser usage.

Because so many people use the browsers as their primary software experiences and experience many applications (as more and more applications moved online), it has almost come to be expected that there will be the ability to move back and forth if the application has a sense of navigation (i.e., changing the main view). So if you can support it and don’t have a reason to keep people from navigating in that way, you should do it. Ajax apps, in particular, have found creative ways to take advantage of the back and forward navigation even w/o literally having new pages, so they’re a good source of ideas for how to do this sort of navigation in a non-traditional Web interface.

Implementation

When implementing journal navigation, you have three main areas to focus on. First, you need a way to keep a record—a journal—of the navigation history. If you’re in a browser, you have this built in and can use the hash (#)-based URLs for tracking with the browser’s history journal. Otherwise, you can build some sort of view host that automatically tracks when its view changes and/or you can create a mechanism that can be explicitly invoked through code to add, remove, and track through view history.

The second area of focus is on surfacing this capability to people. The tried and true way is to mimic the browser’s back and forward buttons, but you could also use other affordances such as arrows on each side of the view. Just make sure it is obvious to users that it is a navigation mechanism. You should also consider supporting, if you can, the back and forward platform commands that can be triggered through mouse buttons, keyboard, and other input devices.

The last main area is contextual to your solution content. If you have situations where enabling a person to go back and forth would be bad, you may want to modify the UI to disable or remove the back and forward affordances or launch them into a new, separate modal dialog kind of experience that does not afford journal navigation. If most of your application fits these constraints, you probably shouldn’t use journal navigation.

Another consideration along these lines is if a view can be visited again when clicking the back button or not. For example, if people click the “Delete Blog Post” button, and the application takes them to a different view after that, clicking the back button should not take them to the “Delete Blog Post” view again. It should take them to the view before that one. This is not easy to achieve in Web applications, though there are libraries available that can help with intelligent history usage. Desktop and RIA technologies generally give you a little more control over this.

Never use the back button as an Undo operation. Undo operations need to be triggered by a command that clearly specifies it.

Help Me Get There

Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.

ASP.NET

You can implement this pattern using the History features of the ASP.NET AJAX extensions with all of our ASP.NET controls to allow users to go back any operation they performed that was served up via AJAX. Regular page navigation will be handled by the browser itself.

Tags

Navigation.