SharePoint Managed Navigation, Part 1

SharePoint 2013 introduces the navigation option “Managed Navigation: The navigation items will be represented using a Managed Metadata term set.” In Site Settings -> Look and Feel -> Navigation for both Global and Current Navigation. When using this setting you choose a term set that has been specified to have the intended uses include Available for Navigation and the hierarchy of the metadata becomes the site’s navigation. The Publishing Portal template actually is setup with Managed Navigation from the get go:

 

This isn’t exclusive to publishing, but for these articles I will carry on the theme.

The “Intended Use” for a term set is its own tab when the term set node is selected in the left hand side of the Term Store Management Tool UI, and in order to investigate the rest of this you need to make sure the term set has enabled use for navigation. I’ll be looking at the site collection term set that is already in place for managed navigation from a newly provisioned Publishing Portal.

Most of the fun playing with Managed Navigation is actually going to come from some new tabs for terms in the Term Store Management Tool, Navigation and Term-Driven Pages. In this article I’d like to draw the line between the two faces Term-Driven Pages tab might have; so we will center on the local property Navigation Node Type and see why it’s so special.

 

 

Managed Navigation can play out terms and URLs in two very different ways, and they don’t need to be used exclusive of each other either. They map to the Navigation Node Type setting on the Navigation tab. This choice changes what will appear in the other tab. To use Term-Driven with Friendly URL (FURL) means making the term hierarchy only appear in the URL, after the site structure leading into the site which has this managed navigation applied. The site or folder structure based navigation that would come from finding the target page can be hidden. Term-Driven with Friendly URL doesn’t just leverage a term set for navigation nodes on the site UI but also rewrites URLs to represent that same hierarchy from an experience perspective.

Here is an example of Term-Driven with FURL if we have a Home term in our term set assigned to a site for navigation, it is presenting the default.aspx but notice the URL:

 

 

Here is an example of Simple Link Navigation Node Type presenting the same target as before:

 

 

All I did from the first screen shot to the second is switch the navigation node type for the same term. As you can see the first experience is much more “friendly.” So while the distinction between structured and managed navigation should be pretty obvious and is covered a bit elsewhere, Navigation Node Type property is immediately the next best thing to understand and proves a critical differentiation in how you choose to use managed navigation or individual terms in a navigation term set. Even if you fall head over heels for FURLs you still may need the simple link option for external links.

Next time we’ll take a closer look at the plethora of new term properties available through these two tabs in the term store management tool including what’s still on the Term-Driven Pages tab even when using Simple Link Navigation Node Type, and why.

Comments

• Anonymous
  January 25, 2013
  Are you able to clarify why the decision to manage navigation in the Term Store was a better choice than improving the old navigation management? What is the advantage of now having navigation spread across 2 areas. What do metatadate terms have to do with navigation?

• Anonymous
  January 29, 2013
  "why the decision to manage navigation in the Term Store was a better choice than improving the old navigation management?" - It is not necessarily better. It would be based on the scenario, structured remains available. The benefits are clear from FURLs and the ability to flex navigation look and actions around a fixed site structure. If you have a situation where managing nav from the term store isn't something you want to do, and you also are not going to partake of any of the pros for managed navigation then you wouldn't use it. "What is the advantage of now having navigation spread across 2 areas" - If I'm understanding your question correctly, that is I assume you mean advantages of having both structured and managed, then that's essentially covered in details of the previous answer. There are pros and cons to each that vary widely per unique situation, and they are not the same set either contrasted plainly with each other as options nor when contrasted in light and context of a pending implementation etc. "What do metadata terms have to do with navigation?" - In managed navigation they become the hierarchy of physical nodes, right: Whether or not in a certain cases they conceptually map to something more significant and less technical isn't some kind of guarantee. But there seems to be a tendency for site structure to correlate to information architecture which clearly maps into managed metadata. So in short, they may easily have a relationship to each other through IA. This is especially demonstrated with a new publishing capability or architecture done through the combination of managed navigation and cross site collection publishing in an early post of mine where managed navigation is absolutely required. The benefits of the general architecture are elicited, and then of course a core benefit from cross site collection publishing in general is content reuse. The way that reuse happens typically can benefit from managed navigation delivering context to search based web parts.