Building a Dynamic Two-Level Navigation Bar in HTML
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
One of my recent online documentation projects involved a fairly complex navigation scheme combined with a firm requirement concerning ease of maintenance. The complex navigation was partly the result of transferring documents created for a print environment to a hyperlinked HTML environment. The original "book/chapter/paragraph" metaphor resolved into a "major section/minor section/subsection/paragraph" organization. The major and minor sections were to be accessed via corresponding major and minor menus located in the top navigation frame of the application (see Figure 1).
){kind=link}
Figure 1 Example of a major/minor menu with active option highlighting.
The menus had to adjust dynamically whenever a content page was displayed. Generally, this was not a problem, as they would change when the user navigated through the menu hierarchy anyway, but in two cases the menus were not acted upon:
When a link was clicked that was a cross-link from one page to another page in a totally different section (and menu)
When a link for a content page was clicked within the search results page
In these cases, a content page would be displayed without the user having clicked any menu options, thus skirting the typical "onclick" solutions.
The maintenance requirement dictated that new or changed content pages and/or menu options would not require a request for support from the IT department. Instead, an administrator armed with Microsoft FrontPage 2000 would add/change pages and images (produced in the marketing/graphics department), and assign menu hyperlinks. This would be done using FrontPage's Normal (WYSIWYG) mode including the Hotspot image-mapping feature. This prevented most hardcoded script solutions that would require the administrator to enter the HTML mode of FrontPage. In the end, the solution allowed the administrator to change menus by replacing images and reassigning links to menu options. They couldn't add additional menus without affecting the script code underneath. Also, any new page would have to use the same <Body> tag as the page it was replacing, as it invokes a JavaScript function. This was deemed suitable for the frequency and kind of changes anticipated for the system.
The first attempt for the navigation menu involved separate HTML pages for each individual menu. These pages were swapped in and out of the top navigation frame on click of a menu option. Besides the awkwardness of maintaining many similar but distinct HTML pages, this solution often left the previous menu HTML page as the last item in the browser history. Thus, when the user hit the Back button once, expecting to see the previous page, he or she instead saw the menu change back to the previous menu. It took two clicks on the Back button to cause the content page to roll back. This was particularly evident when selecting links from the search page. Since the client's desktop standard specified the IE5+ browser, which provides no visibility to the contents of the browser history, there was no simple hack to resolve this problem.
Preventing the "double back button" issue was another primary requirement of the solution.
Valuable Solution for Broader Applications
The resulting system met these requirements and produced a technique for dynamically changing image-driven menus that should be valuable in various applications. This particular system had the menu as the top frame in a two-frame architecture, but it should be applicable in any situation where menus (or images, for that matter) need to be swapped in and out of a static HTML page as a response to an external event. Once you have the ability to swap menus in and out, the system could be easily be used to produce mouse-over events that allow browsing the various main/submenu options prior to clicking a specific option.