|
Overview
If you have played with navbars a bit, you’ll probably have noticed the tradeoff. In return for taking care of the HTML behind the navbars, NetObjects restricts you from doing anything really complicated with navbars, e.g. no expandable navbars, no dropdowns on navbars.
With a four tier site (see the site view when in ARDA Website Template), it gets a little difficult to decide what to put in the main navigation bar on the left. The problem arises from what navbars should provide visitors. You want to offer maximum breadth so your visitor can reach any page in the site quickly. You want consistency in the navbar, so your visitor can use it intuitively and with ease. You can’t make the navbar too large, or else the visitor won’t find it useful. And you don’t want to make the navbars a nightmare for you, the web developers, to maintain.
Unfortunately, it seems that when using NetObjects, you can’t accomplish all of these goals. As of July 2002, I (Frederick Lo) traded a bit of the last goal to achieve much of the other three. So the navbar looks good and is pretty easy to use, but it’ll take a bit of work to maintain.
Background for ARDA navbars
Here is the root of the problem: on each page, there may be multiple NetObjects navbar objects forming the full navigation bar on the left. (For the rest of this page, a “navbar object” will refer to the object created by NetObjects, while a “full navigation bar” will refer to the entire set of navbar objects that form the left side navigation bar on a page)
For example, the full navigation bar above comes from the “General Info” page from the ARDA site. It actually consists of four separate navbar objects: (1) ARDA and General Info buttons, (2) children of General Info, the blue buttons, (3) Research through Links buttons, and (4) Org Chart button.
(1), (3), and (4) were all made by using the Custom feature for navbars. The blue buttons of (2), on the other hand, show the Child Level of General Info. For more information on levels and Custom navbars, see the note on hierarchy and the navbars page. In each case, the navbar objects were created normally, then edited with the properties palette. It is also important to note that the navbar objects (and thus the full navigation bar also) belong to a MasterBorder, called Generalinfo.
Now if we go to one of the children of General Info, say Meetings, it would appear that we have an identical full navigation bar composed of four navbar objects. However, the MasterBorder is Generalinfosub. Why couldn’t we just reuse the MasterBorder Generalinfo? The reason is in (2), the navbar showing the children of General Info. On the page General Info, the blue buttons show the Child Level. On the page Meetings, the blue buttons show the Current Level! Remember, we’re on the Meetings page now, and we want to show the children of General Info, which is the level that Meetings is on. So the full navigation bars are different, and we have two separate MasterBorders for apparently identical navigation bars.
Why not make (2) a Custom border as well, and have only one MasterBorder? It is definitely a viable alternative, and may be better than what we have now. When I was rebuilding the navigation bars, it simply never occurred to me to do that.
So what should you take away from this discussion? Every unique full navigation bar has at least one MasterBorder, and perhaps more than one. If you add or remove a page to the site, you will have to edit at least one and up to all of the MasterBorders on the site to reflect the change.
|
