HierMenus CENTRAL: HierMenus In Progress. HierMenus 5.2 Release Notes (1/6)

[next]

HierMenus 5.2: Release Notes

D.M Ragle, August 28, 2003

If you're among those who simply need "more power," then you'll be pleased to know our latest HM includes new configuration parameters that allow you to more explicitly control the actual creation of new menus on a page, as well as override the previously automatic "Keep In Window" logic for top level menus. Additionally, we've included stability enhancements for some problematic cross-frames situations in both the Opera 7 and Safari Web browsers.

As a reminder, though our release articles may be useful to all DHTML developers and HierMenus fans, the HierMenus script itself is a licensed product and its use on your site requires a paid license agreement. Contact John Maher at [email protected] or call him at (203) 662-2889 for further information (be sure to let him know how you plan to use HierMenus and tell him a bit about your organization, as well).

Sample Pages

Our sample pages demonstrate both frames and non-frames HierMenus displays. Each sample page opens in a new window.

New Menu Creation Options

In previous 4.x/5.x versions of HierMenus, Webmasters were presented with two basic menu creation choices:

1. Create all defined menus (every menu defined in the HM_Arrays.js file) immediately following the loading of the page. This is HM's default behavior.

2. Create only top level menus (only the first in each menu tree) when the page is loaded.

In the early HM 4.x days, sites with large menu sets often experienced a noticeable delay between the time the HTML page is completely loaded within the browser and the actual display of the menus. Even worse, during this delay the browser is typically unresponsive. Of course the larger the number of menus to be created, the longer this delay was, and older browsers and/or slower machines were especially susceptible to the problem.

The second option above, which is enabled by setting the HM_GL_CreateTopOnly (or the page specific HM_PG_CreateTopOnly) variable to true, was introduced to provide some relief for these folks with large menu sets. Using HM_GL_CreateTopOnly, you could drastically reduce the amount of work HM had to do on page load, by deferring the creation of child menus until the top level menu they belonged to were actually rolled over. In other words, when the page loaded only the topmost menus in each tree were created, the remainder of the menu tree was not created until the user actually rolled over the individual items of the menu itself. While this causes a slight delay in the initial display of the individual child menus, the user benefits from not having to wait for all the menus to be created on page load. Additionally, there is no wait for menus they don't use.

But for some configurations, HM_GL_CreateTopOnly isn't enough. For example, what if your site consists entirely of top level menus, as is often the case when the top level of menu items are built using normal HTML links and HM is used to pop up menus from those links? Or what if you have a relatively small number of top level menus, with the majority of your menus and selections appearing in child menus of those top level choices? In the first example, HM_GL_CreateTopOnly would be unhelpful, since there would be no difference between the situation where the top menus are the only menus created and all menus are created (since all the menus are top level menus). In the second scenario, HM_GL_CreateTopOnly is definitely an improvement, but still leaves a noticeable delay when the user mouses over the menu tree for the first time (as HM builds the entire of the remaining menu tree for that item).

With the release of HierMenus 5.2, we're adding new options that allow you to defer the building of all menus until they're actually called for, including both top level menus and deeply nested child menus of a menu tree. With these options in place, you can set up your site such that the user needn't wait for any menus to build on page load; and when they roll over a menu choice for the first time they need wait only as long as it takes for that exact menu to build--and no more. Since HM can build an individual menu very quickly (usually measured in tenths of seconds, depending on the number of items in the menus, of course) we suspect that both Webmasters and users alike will--for the most part--find the delay before the first appearance of the menus to be preferable to the page load delay where all menus are built.

A quick example should suffice to demonstrate both the problem and the differences in the above approaches. These examples all make use of the same menu configuration, a huge menu set consisting of 209 menus and over 1,000 individual menu items. Additionally, each of the example pages utilizes the same HierMenus code (v5.2) with all differences between the examples controlled via the assignment of page specific parameter variables. Finally, all of the examples load in a new window.

• Example 1: All menus created on load.

  For this example, we simply let HM load using its default behavior; specifically, all of the menus are created on page load. Warning: even on our fastest machines, this page takes a minimum of 15-20 seconds to load. 45 seconds to 2 minutes is more common on typical machines, and 10 minutes or more on the oldest browsers and/or slowest of machines is not uncommon! If that concerns you, take our word for it--it's a slow loading page.

  Mega Menu Example 1

• Example 2: Only top level menus created on load.

  In this example, we add one configuration parameter: HM_PG_CreateTopOnly is set to true. And what a difference that one parameter makes! Now the page load is nearly instantaneous. Our menu set, after all, consists of only one top level menu, thus it is the only menu created when the page loads.

  But before you get too excited, roll your mouse over one of the individual menu options; M_3 is a good choice for this example. After rolling over the menu item, HM creates the remainder of the M_3 menu tree on the fly. And since this choice itself contains dozens of child and grandchild menus, there is (in all but the fastest browsers) a noticeable--and annoying--delay before the initial M_3 menu is displayed.

  Mega Menu Example 2

• Example 3: All child menus created on the fly.

  Our final example makes use of the new parameters in HM 5.2 to create not only the top level menu individually, but each of the child menus as well. In this example, you will get the same initial response as you did from example 2. But this time, when you roll over the M_3 menu choice you will notice that the child menu appears very quickly. This is due to the fact that HM no longer needs to create the entire remaining menu tree when the item is rolled over; it instead creates only the immediate child of M_3. And since that child contains only seven items, it can be created and displayed much faster than it would if HM were forced to create the dozens of menus with hundreds of items in the full M_3 set.

  Mega Menu Example 3

Pages with large numbers of top-level menus will benefit from a similar new option; specifically, the ability to postpone the creation of even the top-level menus themselves until the menu is specifically requested (via an HM_f_PopUp call in a link onmouseover).

Admittedly, this is an extreme example to make a point. But every split second counts, especially with the crucial initial loading of the Web page; and we suspect many HM users will find the new menu creation options to be a welcome change to the page-load-menu-creation blues. Also, though example 3 is a significant improvement over example 2 (and a far cry from example 1) there is still some noticeable delay when child menus are rolled over and created for the first time on each page (a delay that doesn't exist in either of the first two examples, since in those examples the entire menu tree is created before the child menus are first displayed). Unfortunately, some delay is inevitable in the building of the menus, as we found very early in our HM 4.x days that we simply could not reliably and consistently across all setups and configurations absorb the menu creation process within the loading of the HTML page itself (i.e., we must wait for the HTML page load and display to be complete before we can safely build the menus themselves). The menus have to be built sometime before they are displayed, thus we seek to provide additional options allowing you to control when that menu creation delay takes place.

Let's now examine the new menu creation parameters available in HM 5.2 and look at some further example situations where each might be appropriate.

[next]