Note: This is a fairly large essay explaining quite a lot about a menu like mine as well as giving insight into how I work and what priorities I have. There is currently no short version available.
I first started working on a tree menu system sometime in September 1998. Since that time I've probably seen over a dozen different menus. Some were only an outline of a working system, done by its author to learn how things work. Most of the menus I've seen have been finished products with downloadable files, manual pages, and lists of sites using them. The quality of these menus have ranged from what I would call a buggy beta release to high quality scripts.
Since I've spent a huge amount of time on my own menu as well as looking at other menus I've seen the menu systems from both the coder's perspective and from the visitor's perspective. Visitors and creators have different priorities and therefore it's nearly impossible to create a menu that satisfies both. I try hard to do so myself, and find it always difficult. The visitors want things to load fast, look great and work flawlessly. Those working "behind the scenes" want code that's easy to maintain, frequent updates and good support from the creator.
There's generally two types of menus. One is based on what's known as "layers" where what is shown to the user is done by showing, hiding and moving layers. The other type is based on re-creating a document every time the user does something. My menu works in the latter fashion. Menus that work with layers are webreference.com's HierMenus, Microsoft's menu system on their web-site, and the Joust Outliner by Alchemy Computing.
All menu systems are controlled in real time by the user's input. They have the ability to group elements into containers (sub-menus/folders) which makes one able to have a large amount of links without showing them all to the user at any given time. Giving the user access to too many links is said to be confusing for the user and probably make him/her choose the incorrect link.
One thing I find useful with my menu is that it gives the users an interface they are familiar with. Most users have encountered the hierarchial organisation of elements with the interface I use. They intuitively know the different between a sub-menu and an item and also know that the plus/minus sign is used for opening or closing a sub-menu. A system like HierMenus that opens/closes when the user moves the mouse pointer over a link can in my opinion be slightly tricky to use since it requires a larger amount of motor-skill. I'm not saying HierMenus is useless, only that I find it a bit less user-friendly.
My system is maybe also slightly less user-friendly than Joust, because mine doesn't come with a help system. The owner of a web site can freely ad a link to a document explaining the menu if he wishes, but it's not a built-in feature.
The concept of frames on a web-site isn't new, but it's a controversial subject in many communities. Some people endore the technology, others think it's totally useless. In my opinion using frames in a menu system is also debatable, just as the usage of frames on a regular site is. I've chosen to use frames for my menu since I believe it works nicely, makes me able to write code easily, and I am able to give the user a consistent interface throughout the navigation of a site. The user has the ability to change the content in the menu, but the content doesn't disappear between pages. The concept of one frame being changed while the rest stays put is one of the reasons why frames at times is used, and here I'm able to make it useful.
HierMenus is a system that works without frames. It does its job very well, and if I wanted a menu system for a frameless site I'd chosen it. The downside of using a frameless site is that the menu has to be created for each page, and that you can't show the user where he/she is easily. If one wanted to show one document's relation to another one wouldn't use the menu system at all for navigation, but instead choose other approaches. With my menu and the tracking system I keep the interface unchanged between pages and the tracking shows the user where he/she is.
Speed is, and will be, an important issue. The user wants quick access to information and therefore the script has to be as small as possible and show the content to the user as quickly as possible. This isn't an easy task since you also want features and configurability. Features add size, making the script load more slowly. One things that's important is also that once the script is loaded it has to provide the output to the user without too much delay.
One of the main differences between layer-based menus and one re-creating a document is the speed. A layer-based menu is slow on startup since it has to write the whole menu to the document. If you have a large menu, and the script is not optmized well you can end up with a huge delay on startup. Once the menu is up'n'running a layer-based menu has instant-action though.
A menu system like mine will be quicker upon startup since it only writes to the document what is needed. If a sub-menu is closed we don't write the contents of it. On the other hand, the menu system updates the menu document by re-creating it every time a sub-menu is opened or closed. Therefore it's doesn't provide instant action like a layer-based system. It's a trade-off where one has to decide whether one wants the menu to load fast or have instant action. I've decided to stick with my re-creation system, but I'm planning on adding a layer-based system. This is to make the user able to choose what he/she wants. I've also noticed that Microsoft Internet Explorer v5.0 has a script speed that's so quick that the re-creation of the document happens nearly instantainously, making the drawbacks of my system disappear (it ends up being faster on startup and nearly as fast in use).
Features are important. They should help the visitor navigate the site as well as making the site author able to tweak the output to match the rest of the site. Adding features to a script always adds to the script's size, and therefore I find it a question of priorities. It's also a question of coming up with the good ideas, and that the features are found useful by others.
I've already talked about the interface, frames & speed, now it's time to look at some other features.
To me, tracking is an important feature. It gives a visitor a visual presentation of where he/she is on a web-site. One thing that is difficult with web-design is to always make the visitor able to easily spot where he/she is, and where links go relative to the current location. The tracking system I have knows where the visitor is and shows this to him/her. It also keeps track when the visitor uses the back/forward-buttons in the browser. That ability is something that most menu systems lack. Once you hit the back-button they tell you that you're looking at a whole different document. This can be confusing.
This is something that many web-site owners care very little about. At the present time there's something like 800 different "user agents" (browsers, search engine robots, custom programs, etc) available. Making the content of a site available to everyone is in theory very simple, but in practice it's a skill that's difficult to master. Usually one wants to add nifty features to a site and it most often means excluding groups of users. In the end the site is maybe available to a handful of user agents.
I try to create sites that include rather than exclude. The features I add are carefully selected and tested with several browsers and test software. This menu site is also done that way. I've found a setup that I believe includes as many as possible, giving everyone access to the content the site has to offer. I've seen other menu systems with descriptions that say "cross-browser compatible" but greet the user with "This site only supports JavaScript-enabled browsers" when I drop by. I want my site to be different and show that I'm able to give everyone access regardless of what they choose as their favourite browser.
There are other features that one can want to have too. Tooltips for menu items, images instead of text, decriptions in the browser's status bar, configurable icons, and probably a couple of things I've forgotten to mention. The configurable icons my menu has is a feature I'm very proud of. Each item has the possibility of having an associated icon (image), and they can also get icons based on a configurable list. It's simple, yet powerful.
The menu system should be useful for the web-site owner. It should be easy to get to work in a variety of environments. One issue that I found important when I chose Mike Hall's menu as a basis was that the menu code itself was easy to understand and it looked easy to generate automatically. I've gotten several mails from users that generate the menu on-the-fly using ASP (Active Server Pages) and it should also be easy to create using other solutions (Perl, CGI, PHP, etc). As sites get more complex one has to have the ability to do things automatically to reduce the workload. Being able to create the menu automatically as well as being easily able to determine how the menu will look when it's on the web is to me something that I want. I try to make my menu continue to follow that approach so the site owner does not have to use programs to create the menu, and is unable to edit it easily.
The menu should also be easy to configure. I've got plans for a configuration script (written in JavaScript) that can be used for setting the menu systems options. As it is now they're fairly easy to figure out given the comments in the code, but it would still be easier if one could do it with a script. The key here is to make the site owner able to edit the menu's options easily, not requiring anything but a text editor.
When I want a script I also want to see that the person (or persons) behind it is determined to support it. I like to see an updated web-site, with some feedback from the author. Of course I also like to get quick responses if I send e-mail. I try to respond quickly to the mail I get, but at times it's difficult to keep up. That's one of the reasons why I created a mailing list for my menu, hoping that it would make users able to help each other when they had problems. So far it hasn't happened, but I keep on hoping.
Problems related to the menu, as well as any bugs is also an issue. I try to let people know about any problem related to the menu system I know of, and I also keep a page with the current bugs. Not only do I want to show that I'm not flawless and that there's things that need fixing, but I also want to show that I'm able to fix the bugs I find. I try to ship updates with not-too-long intervals, most often to fix bugs. I also try to incorporate features that users suggest so that the menu system becomes as good as it can be.
This web-site is my showroom. It's where visitors can see the menu system in action, read the latest information about it, download it to try it out themselves, and get in contact with me if they have questions or comments. I try to make sure things are as good as they can be, and that noone feels left out when they visit here. I'm always available through my e-mail address, even though I may not respond immediately. Not surprisingly I'm not perfect, but given some time and input from others I've seen that improvements can be done. In the end my goal is that the menu system I once started working on will be the best that's available to the public. I'm getting there one step at a time.
Morten!
Here are links to some of the menu systems mentioned: