Tuesday, November 01, 2011

Navigation on Public Facing SharePoint Sites

One thing that all sites (SharePoint or not) need is some form of navigation. This is true for all sites, not just public sites. There are plenty of types of navigation elements, but if we stick to public sites, there tend to be the following few types:

  1. Main navigation. This is almost always a horizontal list of links across the top of the page. These links do not change regardless of where on the site the user is. Sometimes each link will have a sub-navigation that is shown using JavaScript when the user hovers over a link.
  2. Contextual navigation. This navigation can manifest itself in many ways, sometimes as a tree view, sometimes as a flat list. In any case, the content of this navigation is usually different per page, or at least per section of the site.
  3. Reverse Navigation (Bread crumb). This is some type of path allowing the user to see where in the site they are, and to navigate back the way they came from.

In SharePoint, we have out of the box elements that provide all three types of navigation mentioned. They may not work exactly how we need them, but they are there for the most part.



On projects I was involved in, we never ended up using any of the built in navigation controls. Even thought they have been improved for SharePoint 2010, they still render html that never happened to fit the html we needed for the site. So how did we solve our navigation needs? There are a few options that I have used, I’m sure there are others out there:

  1. Static, hard coded links. This scares the crap out of some people, but I argue there are still plenty of scenarios where hard coded navigation is perfectly acceptable. As an example, take the apple.com website. How often do those links across the top change? Almost never. And when they do change, it is likely due to a very rigorous change management process. This is a case where I would advocate a hard coded solution. On the rare occasion the links change, update the master page.

    Advantage: Best performance, Easy

    Disadvantage: Potential for dead links

  2. Custom navigation controls based on SharePoint navigation providers. Just because the web controls that SharePoint delivers may not suit your needs, the navigation information they contain may be just what you want. In this case, use one of the providers that SharePoint offers. See MSDN on how to get started. http://msdn.microsoft.com/en-us/library/bb897657.aspx

    Advantage: Dynamic, Flexible

    Disadvantage: Can be hard to get right, Usually lots of work

  3. Navigation that has nothing to do with navigation. What do I mean? Show a list of the published pages from the pages library of the current site. That has served us as a viable navigation strategy on a number of sites. Usually best suited for the contextual navigation category. There is a strong potential downside of using this approach. It is very simplistic and doesn’t implement any performance optimizations or security trimming. So if used in an incorrect scenario, it can have nasty side effects. For me this method has generally been useful when there are a number of content pages that need to be shown for a certain category, etc, and if a page was published, it should be visible for everyone.

    Advantage: Relatively easy to build, Dynamic

    Disadvantage: Only suitable for simple cases

  4. Search. Yes, you can use search as a viable navigation method. There are ways that you can prepopulate a search result set and display this as navigation. We used this on a project for a “Related Items” type of navigation.

    Advantage: Very dynamic

    Disadvantage: Depends on good search results, Can’t always know what will be in there
So as usual with SharePoint the right answer for whatever you are doing is “it depends”. I would however stress that whatever your choice of navigation solution for a public site, don’t forget that you are building for the end user and make sure you are sending friendly HTML, etc to the client.

No comments: