Navigation Models - Part 1: What is a navigation model?

Navigation models initially confused me.  I mean, I understood that they represented the navigation options on a WCP site, but I couldn't figure out why they were different from page hierarchies.  After reading much documentation, and thinking about it, trying to come up with an example of how these two items would differ, I think I finally got it.  Read on to see my example of why there are two different things.

Summarizing from the Oracle documentation, the technical differences between the two are fairly easy to understand:

• A page hierarchy:
• models parent - child relationship between pages.  For example, you may have one page that displays a list of all items on and order, and a details page that simply displays the details of a single line item.
• applies security policies - permissions can be granted/revoked anywhere along the tree
• makes administration of security easier - Permissions can be set at the top of the tree and will be automatically propagated down the tree, unless overridden.
• consists of only pages
• Does not necessarily model navigation structure - that is how a user will use a site.
• A navigation model:
• defines a navigational structure - that is how a user will typically move around a site.
• keeps track of navigational data - like where the user currently is at in relation to the navigation model, what permissions a user has 
• can consist of pages, page hierarchies, task flows, external links, content items, other navigation models, portlets, external apps, dynamically generated items

Pretty straightforward, right?  But why is the navigational model not the same thing as a page hierarchy?  wouldn't you build the page hierarchies to model how the users would use your site?  Well you can definitely do that (and in fact your navigational model can to page hierarchies).  However, that would only work if you had a single type of user.  In most enterprise web applications and portals, not all of your user types need or would like to navigate the content in the same way.  Even if your users do all navigate the same way, separating the navigational model from a page hierarchy is useful:

• Since the navigational model does not control security, you do not need to revisit it when you move items in the navigation model (if your business is like mine, that is sure to happen).
• Page hierarchies will tend to group pages by a way that makes sense to security and maintenance.  Navigation may not group things in the same way.

If you are like me, you have generally always worked with web applications and made your pages flow from one to the other in only one way.  With a portal this is not always optimal, due to the aforementioned heterogeneous user groups.  Let us say, for example, that we work for a financial institution.  This institution offers three basics types of products:

1. Traditional Banking - these are the typical banking services like savings and chequing accounts, investments and so forth.
2. Insurance - for property, such as homes, cars and recreational vehicles.
3. Lending - borrowing money.

The corporation has already gotten a significant web presence and self-serve capability developed for both the lending and traditional banking portions.  You have been asked to get the skeleton of the Insurance offerings plugged in to the portal.  After analysis you have come up with the following page hierarchy:

• Insurance Overview - General information about the corporation's insurance offerings. All users can see this.
• Product Listing - a page where all insurance products are listed.  The user can then filter this list further. All users can see this.
• Product Details - shows the details of a particular insurance product such as premiums, coverage and options. All users can see this page.
• Purchase Product - allows the user to select the options they want for the product and ensures that they meet all of the qualifications. All users are allowed to see this page (however, certain functions, like the ability to complete the transaction, are limited for anonymous users).
• My Policy Details - If the customer owns a certain policy, this page shows their current rates, the options they choose, when their next payment is due, etc. Only logged in users can see this page.

This hierarchy makes it fairly easy from a maintenance perspective, because all functionality to do with Insurance is in a single place.  In addition, security is easy to apply, because 80% of it is the same (4/5 of the pages are accessible to all users).  We need to only set permissions for all users on the Insurance Overview page (this will flow to the child pages), and then override the automatic permissions on the My Policy Details page.

Now, pretend you are a customer.  Would you really want to have to go through 3 pages (along with filtering products) to get to the details of your insurance policy?  My guess is probably not.  A simpler way is to simply provide links to the user's products and the functions they may be interested in.  Therefore, a navigation menu prototype for a customer may look something like this:

Where the links under My Account would link directly to the My Policy Details page, Apply for / Purchase a Service would link to an apply/purchase task flow and the Insurance Offerings item would link to the page hierarchy above (the Lending and Banking items would link to respective page hierarchies).

If our portal is also used by our internal staff, we could have a different navigation model for them as well.  Perhaps the one for a customer service representative would look like this:

The items under each of the recent customers would operate the same as the items under the My Account heading in the first navigation model. The More Information item would also be the same as the first navigational model (in fact you could split this part out and make it its own model in order to gain more maintainability, but that is a topic for another day).  Finally, the Find a customer and Tools would link to other components that we have not discussed here.

Hopefully, this example makes the concept of a navigational model more concrete.  This is a very flexible and powerful tool that allows a lot of adaptability to user desires without a lot of the pain traditionally associated with navigational models in web applications.