Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

Dynamic Web Menu System Requirements

Rated 3.05 (Ratings: 4) (Add your rating)

Log in to add a comment
(12 comments so far)

Want more?

 
Picture of nicolaasuni

Nicola Asuni

Member info | Full bio

User since: July 14, 2003

Last login: January 21, 2007

Articles written: 3

One of the main things you must determine when designing a Web site is what kind of navigation/menu system you will use to make it easy for your visitors to find their way around the site. At the same time the navigation/menu system must also satisfy other important requirements especially when you have a large Web site driven by a CMS. I will analyze these requirements giving you some references which will help you to better evaluate or design Dynamic Web Menu systems.

When speaking of a Dynamic Web Menu I mean a client-side Web software tool that can get/receive menu data from A CMS/database and display it as a list of options from which a user selects actions to be performed.

Dynamic Web Menu requirements

Platform and Browser Independent

Since the Internet in its entirety is a network composed by a heterogeneous hardware and operating system platforms, and the implementation of browsers on various platforms is so widely different (and change constantly), the Web menu must be independent from these elements. This means that once a Web menu application is created, that same application must run without any modifications on any computer.

I've intentionally used the browser-independent definition instead of cross-browser because the latter means that the developer must design elements that are tailored to each browser and platform combination so that the Web menu always displays properly.

Internationalization (i18n)

Since internet is used in different countries with different spoken languages, the Web menu must be capable to displaying different character sets and Unicode codification using both language directions (left-to-right or right-to-left).

Hierarchical

A hierarchical Web menu is able to represent the entire structure of the site (site map) or a portion of it using different techniques (drop-down, popup, tree).

Although this is not a foundamental requirement, it improves usability because allows visitors to click directly onto the page they are seeking, instead of moving through the site navigation system and down through categories by clicking on links on different pages. Hierarchical menus may also act as simple menus (only one level), while the opposite is not true.

CDL (Content-Display-Logic) paradigm

A Dynamic Web Menu must follow the CDL paradigm where the Content, Display and Logic are maintained separated.

  • The Content is the set of menu data stored in a convenient form (text file, XML, database).
  • The Display is the set of visualization and multimedia settings and files.
  • The Logic is the Web menu software, the glue that holds everything together.

This separation allows one to change the Web menu content or to view it without involving technical resources. This results in lower maintenance costs and much more flexibility. Also the Web menu software could be easily cached by the client system, thereby reducing the downloading time.

Since normally a client-side software does not have the permission to receive data using a direct connection to the server database, the Web menu may receive its content using one the following strategies:

  • The content could be embedded on the page during its composition.
  • The content could be parsed from a real static text or XML file (e.g.: menudata.txt) that must be created before page delivering.
  • The content could be parsed from a virtual text or XML file (e.g.: menudata.php) that will be requested by the client menu software application and generated on-the-fly by a server-side software.
  • The previous two techniques could be combined on a server-side software to cache the results reducing the server load.

Linking Capabilities

Each Web menu item must have the same ability of an HTML anchor/link element to call various URL schemas (http, ftp, mailto, Javascript, ...), support Javascript and target frames.

The Web menu must have also the ability to disable each menu item, so you could temporary disable the access to a specific site section without affecting the entire menu structure aspect.

Accessibility

Accessibility is access to information not being constrained by reasons of deficiency or discapacity. Many people may access the information of a Web site from contexts that are very different to ours, because...

  • they may be visually, hearing or mobility impaired;
  • they may have reading or comprehension problems;
  • they may not be able to use keyboards or mice;
  • they may have an only-text browser, a small screen or a slow connection, etc.

Accessibility is not only interesting for people with a discapacity, but enhances global access to the Web and improve search engine spidering.

For the above reasons accessibility is an important Web menu requirement. However, due to it's nature of client-side software application, Dynamic Web Menu often lacks some accessibility requirements that could be fully recovered including an alternative content. The alternative content generation task could be eventually achieved by a server-side function that will not be discussed here.

An accessible Web menu must also not impede the whole page accessibility. A negative example is offered by some menus that produce markup-language specific code (e.g.: HTML) which cannot be easily ported to other markup-languages (e.g.: XHTML).

Intuitive / Usability

An intuitive Web menu means that it is easy to use and instantly understandable to most visitors of your site. Using an intuitive Web menu will greatly improve the usability of the Web site, and therefore user satisfaction and return rates.

Usability is a quality attribute that assesses how easy user interfaces are to use and it is defined by five quality components:

  • Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
  • Efficiency: Once users have learned the design, how quickly can they perform tasks?
  • Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
  • Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
  • Satisfaction: How pleasant is it to use the design?

Visual and Multimedia features

Visual and multimedia presentation aspects are often overlooked by many developers but, since the Web is a communication medium, they must be taken in serious consideration. The presentation aspects stimulate instinctive emotional responses that could improve the Web experience.

A Dynamic Web Menu system must be able to adapt its visual/multimedia presentation to the needs of the Web site where it's used. This may include the ability to change colors, fonts, images and also give some interaction to user using graphic and sounds effects.

Final Remarks

Web navigation/menu system still remains one of the key components of a Web site. Nowadays the Dynamic Menu Systems used on the Web are largely based on hierarchical unordered HTML lists (that's <ul> and <li> tags) modelled using CSS (Cascade Style Sheets). This technique allows to displays the simple hierarchy in a more complex form such as a set of dropdown menus or - with client-side JavaScript applications (ECMAScript) - an expandable/collapsable tree. Even if the Web browser is not able to execute the JavaScript code or render the CSS, the user may continue browsing using the hierarchical structure composed by the unordered list.

The alternative Web menu client solutions based upon specific browser plugins (e.g.: Java, Flash, etc.) normally offer better and richest multimedia experience but lacks some of the above requirements. For this reason, these last must always include an alternative version based on unordered HTML list.

Bibliography and Reference

Editor's Note

This article was revised by its author on 27th October 2005.

Nicola Asuni is the founder and president of Tecnick.com S.r.l., a leading provider of award-winning Web Software.
He has been a freelance programmer since 1993 and he actively contributed to several web-related Open-Source Projects.
He is the founder of Technick.net site website, since 1998 the largest connector and cable pinout archive on the web.
He is also member and co-founder of Java User Group Sardegna Onlus, and a member of GULCh - Gruppo Utenti Linux Cagliari.

For a complete Curriculum Vitae please browse: http://nicolaasuni.tecnick.com

java usage

Submitted by dusoft on October 9, 2003 - 00:06.

I checked your site and although Java is good technology, since it's platform independent, I wouldn't use it for menu navigation at the webpage - why?
  • Java doesn't have to be installed on the machine (older browsers, older computers)
  • Java virtual machine is quite hardware-demanding (it's slow on older computers)
  • Java menu used at your webpage looks good (graphically) at a first glance, but sub-levels are only ugly grey (from the graphical point of view)
  • Javascript crossbrowser compatible menus (tree-menus etc.) are available and widely tested (and could be generated either from DB or text file) as for the other points - JavaScript is much better - since it's also accessible, can display international character sets, design can be set in CSS etc. I don't see Java as some perfect technology, as it is sometimes described. Yes, Java is platform-independent, but I doubt some of Java programs could be run in my Java-enabled mobile phone. And since JavaScript is widely supported in browsers and widely tested, I would go for JS-driven menus.

    login or register to post comments

  • Re: java usage

    Submitted by nicolaasuni on October 9, 2003 - 03:03.

    The scope of this article was to talk about Dynamic Web Menu System Requirements regardless the used technology.
    Naturally the comparison between the most used technologies, Java and JavaScript, has been inevitable.
    Currently there isn't a technology that perfectly fits all the above requirements, but Java 1.1 based solutions seems to have more advantages versus JavaScript based solutions.

    > dusoft : "Java doesn't have to be installed on the machine (older browsers, older computers)"

    Java 1.1 is well supported starting from the oldest Netscape 4.06 and Internet Explorer 4.0.
    This means that is better supported than JavaScript that has been changed during years for each browser release.
    Java 1.1 based solution must not be updated for each new browser release.
    Java based menus may work or not, and in this last case you are able to display an alternative content. This is not true with JavaScript because it may also work badly on some browser/platform combinations eliminating you the option to automatically display an alternative content.

    > dusoft : "Java virtual machine is quite hardware-demanding (it's slow on older computers)"

    I don't know how much is old your computer but Java 1.1 based menus are small enough to work smoothly on a 486 PC!
    Modern JavaScript based menus don't seems to be lighter than Java based solutions.

    > dusoft : "Java menu used at your webpage looks good (graphically) at a first glance, but sub-levels are only ugly grey (from the graphical point of view)"

    The graphical aspect of JDDM submenus is client-system dependent because they are real system menus and could be opened out of the browser window. This behaviour could not be achieved using JavaScript.
    In any case JDDM menu is only an example, another different example could be JWTM - Java Web Tree Menu.

    > dusoft : "Javascript crossbrowser compatible menus (tree-menus etc.) are available and widely tested..."

    Yes, it's true but the main problem is that these solution are not future-proof as Java 1.1 based solutions and also they couldn't offer the same compatibility of Java.

    > dusoft : "Yes, Java is platform-independent, but I doubt some of Java programs could be run in my Java-enabled mobile phone."

    Some Java applications (including menus) could be easily ported to your mobile phone using the J2ME platform. The same thing could not be done using JavaScript.

    login or register to post comments

    Flash

    Submitted by sehryan on October 9, 2003 - 04:44.

    At the risk of getting flamed, I am a little disappointed that Flash wasn't also considered. Flash is fast, small, attractive, can be set up so it works dynamically off of an xml file, and the plugin is installed, according to Macromedia, in 98% of browsers today.

    login or register to post comments

    DHTML and JavaScript

    Submitted by julwh on October 9, 2003 - 21:09.

    I think the DHTML and JavaScript is more convenient and popular way for websites developers today

    login or register to post comments

    Unobtrusive DHTML

    Submitted by starvingartist on October 10, 2003 - 09:56.

    Unobtrusive DHTML is one of the safer bets and meets the requirements listed. Check out Kryogenix's aqlists or any other menus referenced on his site. This isn't the old cross-browser-type of dirty DHTML, and as the site says "DHTML of this kind should just drop into place, providing a better user experience for people whose browsers can support it, and not affecting those whose browsers cannot."

    They're merely plain HTML unordered lists with external CSS and JS files to control display and logic respectively. And we can look at how it fits the requirements outlined in this article.

    • Platform and browser independent: It's HTML. If the browser doesn't support or disables CSS or JS, they'll see a plain UL list. If it supports CSS, it'll look nicer. If it supports JS, then you get the cleaner, dynamic part.

    • Internationalization: Again, it's HTML and you can specify your charset encoding there. And all you need is to modify the UL lists. You don't need to touch the CSS or JS.

    • Hierarchical: Using the same HTML list, you just change the class name for the UL to switch between various display methods such as drop down lists or a tree. You can nest them as well.

    • CDL (Content-Display-Logic) paradigm: Content-HTML, Display-CSS, Logic-JS. It's clean separation of all three. All three gets cached unless it is updated.

    • Linking capabilities: It's HTML, so you can make regular hyperlinks or comment stuff out.

    • Accessibility: Plain HTML is as accessible as you can probably get. Text-readers, and text-only browsers can benefit from this, as the menu is structured as an unordered list. And the code is XHTML compliant already, as the UL and LI tags are closed and in lowercase.

    • Intuitive/Usability: It works similarly to common UI. It loads quick and fast as well.

    • Visual and Multimedia features: CSS controls all the styles such as color and fonts. Helper images (such as arrows or +/- tree symbols) can also be used.

    The new generations of proper, Unobtrusive DHTML menus don't have the limitations that previous spaghetti-code DHTML/Javascript veriety had. I would have to personally say that it's even better than Java applet technology in almost every category.

    login or register to post comments

    Re: Unobtrusive DHTML

    Submitted by nicolaasuni on October 10, 2003 - 11:07.

    I've already considered nested unordered lists in my article when I talk about alternative content, they are my favourite accessible menus.
    In fact I use these menus as alternative content to my Java applets menus.

    Even if they could be a valid menu system, they could not be compared with the power of dynamic menus we are talking about. The Dynamic effect and multimedia presentation obtained combining JavaScript and CSS is very trivial and has all of disavantages of JavaScript technology, also they are hard to setup and maintain.

    Please consider that menus such as JDDM or JWTM may handle dinamically and easily more than 40 parameters for each menu item!
    This allows you to have a kind of polymorphic menu sytem that could change it's presentation to virtually fit any graphic/multimedia needs.

    login or register to post comments

    JWTM -> treeeview.net

    Submitted by dusoft on October 12, 2003 - 23:32.

    I checked the JWTM menu, but I don't see a big deal about it. I agree that it is compatible etc., but so is the Javascript treeview menu (as an example). I tried the JS treeview menu and the speed of rendering is unbelievable - just try the example with years, months and days - it could also easily handle plenty of items. This menu could be rendered dynamically from DB or you can make it static if required. In any case it's easy to configure (one separate file for confirguration and except the fact you have to pay for it, if you don't want to see small treeview.net link at your site, it's really useful).

    Also I guess accessibility with Java menus is quite low (what about text browsers?) in comparison with menus shown in Unobtrusive DHTML... CSS and HTML (+add little bit of JS spice) and you got it.

    login or register to post comments

    Software Qualities

    Submitted by nicolaasuni on October 13, 2003 - 01:12.

    > dusoft: "Also I guess accessibility with Java menus is quite low (what about text browsers?)"

    To avoid the Java accessibility issues I suggest to use alternative menus using unordered nested lists. In this way you'll get all the Java advantages and the best possible accessibility (even with text browsers).

    I wish to remark that the scope of this article was to talk about Dynamic Web Menu System Requirements, regardless the used technology. This means that any current and future technology that best fit these requirements is welcome.

    Anyway, in the general technologies comparison, software programmers and system itegrators may not overlook the software engineering principles qualities of software (robustness, adaptability, reusability, interoperability, correctness, maintainability, usability, scalability, abstraction, encapsulation, modularity, ...). These qualities means that you will waste less time and money.

    Considering the above principles, Java offers an uncomparable number of advantages over JavaScript and similar languages.

    Another Java Applet advantage over other current technologies is that it may overlap all HTML content, form elements, flash animations, frames and even jump outside the browser window. Wrong overlapping is one of the most common problem for JavaScript-based menus.

    login or register to post comments

    Does'nt work in Safari

    Submitted by benjer on October 16, 2003 - 06:20.

    Both of those examples do not work or are INCREDIBLY slow in safari. Accessibility is of prime importance these days and the use of css is growing exponentially. Personally the days of supplying alternate content - flash/print etc - are gladly gone. Im all for CSS menu's, if the user has JS switched on all the better, if not then the content is available to everyone. The flexibility of CSS lists far outway any requirements for using Java. Can Search engines index/follow Applets? (serious question).

    login or register to post comments

    Re: Does'nt work in Safari

    Submitted by nicolaasuni on October 17, 2003 - 06:18.

    > benjer:"...those examples do not work or are INCREDIBLY slow in safari..."

    I don't use Macs but as stated on official Apple site, Safari support Java 1.4.1 Plug-in and the Java rendering is faster than competitors. So, who said the truth?

    > benjer:"Can Search engines index/follow Applets? (serious question)"

    This is not a serious question, it's a rhetoric question. Anyway, the search engines may index the applets if you provide an alternative content (as you MUST always do when design with accessibility in mind).

    Accessibility is a very important thing and I've never overlooked it (also using applets).
    I'm open to all solutions and I don't want defend the applets menus over another technology, but at the same time you must understand that internet is more than a black text on a white background. The Web is a communication medium and the visual/multimedia presentations must not be overlooked.

    login or register to post comments

    It may have been a rhetorical question..

    Submitted by brothercake on December 31, 2003 - 19:56.

    .. but it still begs an answer. Can an applet be indexed by SE robots? Well no, obviously not.

    I know you don't want a technology discussion, but that's inevitably what this will be - technology consideration is the primary subject of your article - you're suggesting criteria, and technology choices is how those criteria are addressed.

    Personally, I would never even consider having Java based navigation on a website, just as I would never consider Flash or any other plugin for such a vital function. Navigation should be made from HTML, which can be transformed dynamically in modern browsers to provide a richer interface, but which nonetheless remains accessible in some form to all user agents, all the way back to plain text. Neither Java nor Flash can claim anything like that level of accessibility.

    login or register to post comments

    Re: It may have been a rhetorical question..

    Submitted by ihilliard on September 13, 2005 - 06:58.

    I am a JAVA Developer and although this is my primary technology I would have to agree with 'brothercake'. When it comes to accessibility I would NEVER use any plugin for vital functions. Flash has its place and so do JAVA Applets and that's not in menus and welcome pages.

    I run LINUX and have Firefox, Netscape and Konquer browsers each with thier own advantages and disadvantages. Netscape is slower and is easily agrivated by bad or poor coding, Firefox is my preference but I can't view pages properly with JAVA applets in them and the plugin won't install, and Konquer does a pretty average job of it all and seems to have some problems with Javascript now and again.

    Menus and Home pages are vital, if the visitor can even get onto your first page properly he/she will just move on to the next site.

    So, in the interest of accessibility use technologies on the server side to create dynamic menus and vital parts of your site in plain HTML and style them up with CSS. You will have a more accessible site this way - even for text only browsers and as suggested no plug-in on the planet can offer this level of accessibility.

    Using JavaScript to support major functions such as form submission may also render you site usless, I can't transfer funds in my bank account because the form won't submit if you are using anything but IE6 - how bad is that!

    All in all my experience says: Do yourself a favor and learn a server-side technology to do much of the work and move away from relying on the browser too heavily. CSS and HTML are the better options. Get flash and other plugins off the front page but give users the option to have that version if they preffer to. Your accessibility will be much higher.

    login or register to post comments

    The access keys for this page are: ALT (Control on a Mac) plus:

    evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.