Now that you've "seen" the basic navigation elements, we should discuss some design considerations that you need to take into account when developing your site. At the most basic level, everyone needs to be able to navigate to where they want to either consume, contribute, or generally affect content (such as setting publishing dates). This sounds trivial, but it's actually more difficult to pull off than you would think. Next, you must remember that navigation is dynamic. Dynamic navigation has a number of challenges that are easily accounted for, but not keeping this in mind will lead to disaster. Finally, are there "unique" situations that you have to deal with in your site? For example, are there some cases where the navigation should not render at all? In the following sections, we'll explore each of these issues and discuss techniques for handling them. Our techniques will not be an exhaustive list, but they should help you as you're developing your site.
Users Must Be Able to Navigate to Add Content
One of the most important rules about navigation is that a user must be able to navigate to where they want to add, modify, or delete content. Practically, what this means is that there needs to be some mechanism that allows content contributors to navigate to a channel or posting, switch to Edit mode, and perform an operation. This is especially important in a new site, since there are no real postings that can carry the edit console. To some extent, Microsoft handles a new-site situation by providing a default rendering script. However, the rendering script simply provides a basic page response in the event that no posting exists in a channel. In Figure 14-3, we saw the default rendering script, and in Figure 14-4 we saw the sample provided by the WoodgroveNet Bank site. However, when you create your navigation logic, it is possible not to display navigation to a channel or a posting. For various reasons, you may develop code that assumes that your site only has a certain fixed set of levels. If at some point you decide to add levels and don't change your navigation code, content contributors won't be able to add content they can't navigate to those new channels, so they can't switch to Edit mode and create a new posting. We'll talk a little more about this later, but keep in mind the basic rule: You must be able to navigate to a channel or a posting to perform any action, including content consumption.
Navigation Is Dynamic
It is possible to build a site, using CMS, that isn't dynamic. In other words, it's possible to hardcode links to channels and postings as you might have done historically with static sites. However, this would eliminate one of the advantages of CMS. One of the great powers of CMS is that it allows you to design logic that is relatively generic but allows for all kinds of site structures. For example, if you look at Figure 14-6, you'll see a posting based on one of the BOTS Consulting site's templates, but it's been created in a non-BOTS channel. The left navigation dutifully creates the appropriate links even though it's not in the "right" channel (meaning the BOTS Consulting site). Not only is this convenient from a development standpoint, but it prevents rendering broken links based on content that may not exist.
Figure 14-6. Left navigation in a non-BOTS channel
Now, dynamic navigation is a very good thing, but it could potentially get away from you if you're not careful. Since you're in an environment that changes as content is created and changed, your navigation is constantly dealing with an ever-changing set of data. As a result, you could experience unexpected results when trying to display navigation elements. One unexpected result could be poor formatting, or it could be an exceedingly long page. An example of poor formatting can be found in the BOTS site. In Figure 14-8 you can see the length of the page titles could be considered a little too long for the space provided in the left navigation. Also, if we were to add, say, 10 or 15 more postings to this section, the left navigation would become quite long. These are the kinds of issues (as well as others) that will manifest themselves if you don't properly plan your navigation. To help you account for these elements, try some of the following techniques.
Figure 14-8. The corrected left navigation for the Our Consultants section of BOTS
Once you've gotten the hang of creating dynamic navigation that doesn't get away from you and schemes that can adapt to various structures, remember performance. Dynamically assembling navigation is an expensive transaction. CMS is a very solid performer, but if you don't write your code properly or efficiently, you can easily create a very poorly performing site. To avoid creating a sluggish site, consider the following suggestions.
Dealing with Unique Situations
No matter what site you look at, there are always elements in that site's navigation that require special consideration. For example, in the BOTS site, we always want to display the child channels of the main navigation element on the left side. When we're in one of those child channels, we want to display the postings. However, there are a few cases where we don't want that to happen. Specifically, when a user navigates to a channel with a summary page, it's redundant to display links to summarized postings in the left navigation. In the BOTS In the Press section, there's a summary page as the default posting, so there's no need to repeat that navigation in the left navigation. It's only when we navigate to a specific release that we want to display the other postings in the left navigation. Unfortunately, that rule can't be universally applied. In the Our Consultants section, there isn't a summary page as the default posting, so they do want to list the various consultant profiles in the left navigation; when the site was originally written, that detail escaped the BOTS developers. The result is shown in Figure 14-7.
Figure 14-7. The flawed left navigation in BOTS
At first glance, Figure 14-7 appears to be a perfectly formatted BOTS Consulting default channel page. There's introductory text, and the left navigation points you to all the other channels in the About Us section. However, there are two consultant "Day in the Life" postings that also exist in that channel. Unfortunately, you can't see them because the navigation logic in the left navigation did exactly what it was told: Display the postings in the current channel if you're not on a default page (actually any page called "default"). It just so happens that the left navigation operates this way because BOTS didn't want the navigation to repeat in the In the Press section when they were displaying a summary page (thereby thwarting themselves again!). To fix this situation, they added a custom property to each channel that indicated whether to display postings in the left navigation when the default posting is displayed. Once they did that, they ended up with what you see in Figure 14-8.
To help you appropriately plan your navigation (and avoid these and other pitfalls), we've listed a few techniques to create navigation that can deal with a number of different situations.