Journal navigation enables you to utilize "back and forward" metaphors usually seen in web browsers even for your desktop (WPF) applications. As humans, we are often found in positions where we are thinking in a linear way and we tend to associate web page navigation and other UI related concepts with that.
As web browsers do support this kind of navigation by default, more challenging is to achieve this kind of behavior for desktop (WPF) applications. In this recipe, I will show you how to utilize this model and enable users to go back and forth in their navigation history within your WPF application.
Start your Expression Blend 4 and then select New project... From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK..
When you create your new WPF project in Expression Blend, you are presented with the Window object. In order to implement journal navigation pattern, you need to use Page.
For this example, we will add two pages and show how to navigate between them and retain the navigation history.
1. Click on the Project pane and then right-click on the name of your project. From the drop-down menu choose Add New Item....
2. A dialog box will appear showing you your possible choices. Select Page. Leave the name as it is (Page1.xaml) and be sure to have the Include code file option checked.
3. Repeat the procedure and in the same way, add Page2.xaml to your project. Now your project tree should look like the one in the following screenshot:
 |
4. Now right-click on Page1.xaml and from the drop-down menu, select Startup. This will make Page1.xaml a startup object the first one to appear when you start your application.
5. If you now hit F5, you should be able to see your Page1.xaml completely blank, but notice the navigation chrome with back and forward navigation buttons (sometimes also called "travel buttons") added automagically. It is not functional at this moment, but very soon you will be able to use it.
 |
6. Let's change some properties and make our pages look a bit more distinctive so that we can recognize them easily later.
7. We will start with Page1. Under the Objects and Timeline pane, select the Page object. On the Properties pane, locate Common Properties, find the Title and WindowTitle properties, and set them both to First page.
8. Repeat the procedure for Page2, but now set the Title and WindowTitle properties to Second page. (I will explain the difference between Title and WindowTitle properties later on.)
9. Now, let's add a button on Page1. We will use that button for navigating from Page1 to Page2. To add a button, locate it on the toolbox or add it from Asset Library and draw it on your Page1.
10. On the top of the Properties pane set its Name property to btnNavigate. Also, find the Common Properties section and change the Content property to Navigate to other page.
11. Now, we need to add some code that will enable us to really navigate to the second page when a user clicks on this button. Basically, we will define an event handler for the Click event.
12. Under the Properties pane, locate the Events icon and click on it.
 |
13. Under Click, type in btnNavigate_Clicked the name of your event handler. Hit Enter and Visual Studio will enable you to type in the code needed.
14. Add the following code in the event handler:
private void btnNavigate_Clicked(object sender, RoutedEventArgs e) { ((NavigationWindow)(Application.Current.MainWindow)).Navigate( new System.Uri("Page2.xaml", UriKind.RelativeOrAbsolute)); }15. And add the following line at the very beginning of the code:
using System.Windows.Navigation;
16. Note that Page2.xaml is the file name we are navigating to. Now hit F5 and when the application starts, click on Navigate to other page.
17. Note the changes in the navigation chrome. Explore it by clicking on the back and forward buttons or drop-down menu.
 |
We have added two Page items to our project: Page1.xaml and Page2.xaml. The basic idea of this recipe was to show you how to navigate from Page1.xaml to Page2.xaml.
By setting Page1.xaml as the startup page, we have ensured that it will be the first page to be shown when the application starts.
We have added a button and called it btnNavigate and associated the Click event handler.
There is only a single line of code that enables navigation between pages:
((NavigationWindow)(Application.Current.MainWindow)).Navigate( new System.Uri("Page2.xaml", UriKind.RelativeOrAbsolute));
However, first we need to add a simple using directive:
using System.Windows.Navigation;
The great thing about implementation of the journal navigation pattern is that the navigation chrome is automatically being updated. When I say that I am thinking about the fact that the back and forward button and the drop-down menu are being updated based on the current navigation context. This pattern is often seen in applications such as web browsers, Windows Explorer in Windows Vista and Windows 7, or in Microsoft Dynamics NAV and AX line of products.
Journal Navigation pattern is very useful. Sometimes, however, you will want to remove the navigation chrome, or you might be wondering what's the difference between Title and WindowTitle properties. The following section will explain you that and provide you with even more information.
At some point, you might consider removing the navigation chrome and replacing it with your own implementation of the same. Although I won't be going into details and explaining how to replace it with your own, I will show you how easy it is to remove the navigation chrome with just a single line of code.
All you need to do is add this line of code:
this.ShowsNavigationUI = false;
As an example, and for demonstration purposes only, I've added a new button and called it btnRemoveNavigation and attached a new Click event handler called btnRemoveNavigation_Clicked. So my complete code looks like this:
private void btnRemoveNavigation_Clicked(object sender, RoutedEventArgs e)
{
this.ShowsNavigationUI = false;
}
If you now go and hit F5 to start your project and then click on Remove navigation, the navigation chrome will disappear.
 |
Though you can remove the navigation chrome and navigation functionality will stay intact (one that you have implemented by adding event handlers), your users will suffer immensely if you don't implement some sort of navigation UI (that is, if your application is based on this pattern).
You must ensure that simple, easy-to-use, and noticeable navigation chromes exist at all times while your users are using an application based on this pattern.
In Step 8 of this recipe, I've mentioned that there is a difference between Title and WindowTitle properties. So, what's the deal?
Both Title and WindowTitle are Page properties located under the Properties pane, in the Common properties section.
The Title property sets a title for a specific page. What you enter here will be displayed in the navigation chrome (including a drop-down menu).
WindowTitle sets the title for a specific Window object. Basically, this means that whatever you enter for the WindowTitle property will be displayed at the top of the window in the title bar.
 |
As people tend to think linearly (probably based on their everyday experiences with time flow and similar concepts), we also appreciate the ability to navigate through our applications in the same way. Journal navigation is a good pattern that provides us with a mechanism that can be used to go back and forth in the navigation history of our application.
We experience software in the same, more or less single thread, single timeline manner. For example, recall using the web browser of your choice when you are navigating from one page to another, you have the impression that the main view is being changed. Implementation of journal navigation enables us to track and revert to those views or pages in a pretty simple and straightforward manner.
Journal navigation is not only good (or should I say mandatory) for web browsers but it is also a good choice for a number of different needs. Wizards, desktop, or RIAs (Rich Interactive Applications) are just some of the typical, potentially good candidates for this pattern. Windows Explorer in Windows Vista and Windows 7 uses this same pattern. Microsoft Dynamics NAV and Microsoft Dynamics AX are also great examples; they are combining journal navigation with breadcrumb bars.
 |
So, the basic principle about when to use journal navigation as a pattern is a situation where you want to enable the no forward-only navigational experience, and instead, you are to utilize abilities to go back and forth, thus enhancing the experience of moving from one page to another.
Good practice suggests that you concentrate on three main areas when dealing with the journal navigation implementation. Luckily, when you are using WPF Page and the recipe described here, they are (mostly) all being taken care of, but just for your reference, I will describe them.
The first field is surfacing the navigation chrome (user interface). It has to be obvious to the end user that they are dealing with the navigation UI. I've explained how easy it is to remove the default navigation chrome, but you must use some sort of navigation UI. Good practice is also to enable users to get access to back and forward buttons via the keyboard and not just by clicking with the mouse.
As you can say by your own intuition or from your personal experience, when interacting with different applications, having a consistent, clear, and easy-to-use navigation system is crucial. It certainly enables users to feel more in control and empowered when using your application.
Second important thing is to have some sort of history so that users can easily see where they have been previously and navigate through their history. In our recipe, that list is easily available by clicking on an arrow pointing downwards, which exposes a drop-down menu with the list of visited pages.
The third and probably most important thing to take care of is the context of your application. Do you want to enable users to navigate back and forth or do you require a one-way task flow? What happens if your users navigate back while some action is still in progress: will you cancel the action, continue the action, or do something else? How will you notify your users?
Never, and I mean never, use the Back button as an undo operation! Use a specific, single, understandable command for an undo operation. I've seen too many applications trying to use the Back button as a replacement for the undo command, and bluntly said, they "suck". You don't want your application to be characterized as the one that "sucks", do you?