I'm presently involved with the design of the corporate library sites at Lucent -- I work on information architecture, interaction design and development -- and I've been thinking a lot about aspects of the growth and evolution of the site and how this growth affects navigation. A few years ago, I initiated the development of our content publishing system, based on the content inventory work I had done at the onset of the site redesign. Our master template is laid out pretty simply. It is used by our team and the publishing system to indicate where content and navigation will be built. See the wireframe below:

The right portion of the screen makes up the local navigation bar. The idea for this navigation was to expose only the child pages for the current section you were viewing. At some point in the evolution/redesign of the site, decisions were made to expose more of the site heirarchy in the local navigation bar. So we began displaying all of the top-level nodes in this nav. bar and expanded the branch for the section you were currently viewing, showing all its children, but not grandchildren. This drill down method of showing children continues ad infinitum as you navigate deeper into the site hierarchy. This is usable at some level, but we noticed that this didn't scale for some of the sections when you drilled down a few levels. Since our top-level pages function like mini-directories for each section, I've been arguing for the removal of the display of local navigation on those pages and for possibly only showing siblings in local navigation below a top level listing. To add complexity, our system supports polyhierarchy (multiple parents per node), so methods of displaying navigation in a typical hierarchical fashion can be cumbersome.

I need some way of exploring alternatives, but I don't want to change the site too drastically without having some justification for doing so, so about a month ago I asked our systems administrator to come up with ways to track where links are being clicked on the page. The first month of data has arrived and I have some stats to show where people are clicking to get around the site. The wireframe and the charts below show what we're seeing. The numbers for the global navigation are assumed because our sysadmin didn't make an effort to properly capture that data, since that's not our area of concern, but we can can assume with some certainty that the "unknown" clicks are either from the global navigation, from the footer (there's only a link to the home page and for email in the footer) or from pages that uncoventionally display links through the CMS. In the charts shown below, Child List and See Also are links built into the body of the page by the CMS.

This wireframe shows where the percentage of clicks are executed.

These are the charts showing the percentages and raw data in a bar graph.

The findings aren't very dissimilar to what you may have read in Michael Bernard's articles, Where Should You Put the Links" (Usability News 3.2) and Examining User Expectations of the Location of Web Objects" (Internetworking 3.3). What this gives me is some justification, I think, for getting content owners to focus on labelling in order to give links in the body of the page excellent scent, and it allows me to feel more comfortable exploring ways to modify the local navigation and even remove it in some cases. It definitely helps to have this kind of data when exploring UI modifications with your team. I expect to track this data in the coming months to see how changes in the navigation scheme impact use.