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

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

current pageTo page 2To page 3To page 4To page 5To page 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 hiermenus1@jupitermedia.com 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.

HM samples without frames
Frame sample with navigation on the top
Frame sample with navigation on the left
Frame sample with navigation on the bottom
Frame sample with navigation on the right

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.

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.

current pageTo page 2To page 3To page 4To page 5To page 6
[next]

Created: August 28, 2003
Revised: August 28, 2003

URL: http://www.webreference.com/dhtml/hiermenus/inprogress/7/

Justtechjobs.comFind a programming school near you






Online Campus Both