Designing Your Navigation
Tuesday, October 4th, 2011 at 3:30pm -- Kat Liendgens
One of the key components of every website is the navigation, which is why it is important to dedicate sufficient time to designing it in a way that makes your site user-friendly. While it does not seem very difficult to create a snazzy-looking navigation, there are many things that require additional consideration. In this blog, I will focus on some of the factors to keep in mind when designing a navigation for your site that are of particular importance when leveraging the power of a content management system.
Primary Navigation Considerations
One of the more obvious design considerations is that if you intend to make your navigation dynamic, which means having the content management system automatically update the menus when folders and files are added, renamed, or deleted, it has to be text-based instead of Flash- or image-based. You can certainly use JavaScript for fly-outs or drop-down menus, though.
Another decision you have to make is which navigation items you want to be dynamic. For instance, if your navigation is horizontal across your page, having this first level be dynamic may not be the best idea. Depending on how your HTML and CSS are coded, you will run the risk of your navigation expanding to the point of necessitating horizontal scrolling or quite often falling to a second line. Either way will generally cause your site to look broken. In this situation, it would be best to identify what your top level navigation items are and make those static, while allowing for dynamic second-level navigation to either drop down vertically from the horizontal navigation or position it vertically elsewhere on the page.
Form Follows Function
I cannot stress enough how crucial it is to map out the structure of your website prior to designing the navigation, especially if you are implementing one of the most powerful capabilities of a content management system, namely content reuse in the form of dynamic navigation. Since the navigation will be page- and folder-driven, it is paramount to plan your information architecture carefully. For instance, you need to know how many levels deep your navigation needs to be. This is of particular importance when you hand the templates over to your Cascade developers, as they will need to have the JavaScript that handles all of the navigation levels before they start writing the formats that automatically generate your navigation menus and items. If you only provide designs that handle two levels of navigation, you need to communicate to the developer how you would like to see a scenario handled in which the user creates a new sub-folder with pages. Should the navigation “start over”? If so, should the top level folder be included? What would this particular scenario look like? How would you handle a situation in which the user creates ten nested folders? How much of a drill-down effect do you want to allow?
It is crucial to ensure that the Cascade developer knows how to handle those types of scenarios. In addition, make sure that you discuss how to handle folders that do not have an index page. We recommend excluding them from the navigation, so that the user does not get a "page not found" error when clicking on the name of the folder in the navigation. Finally, do you foresee a need to have your developer add a metadata field that enables the user to exclude certain pages or even folders from the navigation? When it comes to these details, an ounce of prevention is worth a pound of cure. In other words, plan ahead.
By planning your information architecture prior to your integration, you can ensure that the directory structure in your content management system matches your navigation structure. Furthermore, it will facilitate the QA process, since you would simply have to follow the outlined folder and file organization when creating assets in your content management system to see if the navigation works as designed.
You Might Also Enjoy
Category
- Resources
- Commentary