Design Considerations

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

graphics/14fig06.jpg

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.

  • Properly plan how your navigation will appear in your site. Make sure you know how much space is going to be devoted to the various navigation elements. When the BOTS site was created, the developers didn't account for the long display names their authors added. In a "real" production environment, this may be unacceptable. If you have constraints with regard to title size because of your design or page weight, consider setting limits for your content contributors or enforcing limits by developing a mechanism to programmatically check the length of the page title through workflow.

  • Set some practical limits on how many elements you can display in your navigation. In traditional Web development, you can always go back and modify the design to accommodate more content or simply remove elements that aren't necessary. With CMS, you still have this opportunity, but since you're no longer in charge of adding content, you may be unaware of what's happening on the site. A little planning about how long pages can be and how many navigation elements your design can support will go a long way. When you create your navigation logic, build in some constraints as to how many elements or levels you'll display. This is definitely easier than it sounds, since it's not a technical problem but a business process issue; getting your contributors to agree to this constraint isn't always easy. Having a complete, detailed information architecture diagram of your site will help you appropriately plan your navigation (a simple site map probably isn't sufficient). Take a look at Chapter 37 for more suggestions about site migration and planning.

  • Don't underestimate the potential for someone to break the rules if you don't enforce them. Given the opportunity, a content contributor will ultimately find a way to "break" your site. Consider programmatically enforcing any "unbreakable" rules you establish. This can be done by adding a "wizard" to your site that walks the contributor through the process of creating the posting and places some validation on things like display name to ensure they conform to a certain size. Creating wizards does take more development time, but it may eliminate a whole host of potential problems.

Figure 14-8. The corrected left navigation for the Our Consultants section of BOTS

graphics/14fig08.jpg

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.

  • Use .NET output caching. Output caching can significantly improve the performance of your site by reducing the processing required for rendering your pages. Given the nature of CMS, implementing an appropriate caching scheme is not a trivial effort; but if done properly, it can yield tremendous benefits.

  • Use recursion sparingly. We'll show you an example, later in the chapter, of how to create a recursive navigation function. Recursion can be a very useful programming technique, but it tends to consume a fair amount of resources. If you use recursion to build navigation, you should strongly consider implementing some sort of caching scheme.

  • Don't use custom properties to build navigation. As temping as it may be to use the Searches class to find postings and channels via a custom property value, it's a very expensive transaction. CMS will literally search the entire repository for the object you're looking for (there's no way to constrain the search). Custom properties are good for a lot of things, but building navigation is not one of them.

  • Do performance testing on your site. The performance of your site will be based on a number of factors. Don't underestimate the value of properly testing your site. We encourage you to set some basic and reasonable performance metrics and use a testing tool to help establish whether your new site meets the criteria. Visual Studio .NET provides Application Center Test in the Enterprise Architect version for just this reason.

  • Consider turning off control view state for controls that don't need it. .NET can potentially add a tremendous amount of data to your page. Generally, this isn't a problem. However, in some situations, when you're using a number of controls to build various navigation elements on a page, the property bag could get out of hand. At the very least, consider turning off view state for the live site if it's not necessary. This will greatly reduce the size of your pages.

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

graphics/14fig07.jpg

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.

  • Plan, plan, plan. We can't stress this enough. It's often difficult to have all the requirements for your site up front. However, trying to gather, solidify, and document as much as you can before you write any code will save you a lot of time.

  • Use custom properties to help you set attributes on navigation elements. Now, we're not suggesting you use custom properties to search for channels, but use them as additional attributes to a collection you've already gotten from the PAPI. As you iterate through the collection (or use a .NET control such as a datalist), you can read a custom property to determine how to handle certain conditions. We're also not saying that custom properties will solve every problem. Custom properties, used judiciously, can be a huge help. BOTS was able to implement one custom property to help with the left navigation situation. However, if you find that you're adding custom property after custom property to account for exceptions, you should probably refer back to our first bullet.

  • Use naming conventions to help. It may sound like a "hack" to use a channel naming convention, but often the simplest solution is the one you should use. A very common technique with CMS 2001 was to prefix an object name with an underscore character (_). This underscore would let the navigation code know to ignore that object and not list it in the navigation, thereby creating a "hidden" object.



Microsoft Content Management Server 2002. A Complete Guide
Microsoft Content Management Server 2002: A Complete Guide
ISBN: 0321194446
EAN: 2147483647
Year: 2003
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net