decloak logo
Cart cart | sign out  
Template and Menu Hot Sauce
MainFeaturesFLASH MoviesFAQCustomersOverviewDownloadsBuy
 basic product info
    menu types
    basic requirements
    what's included
 in depth product info 
    section 508
    why templates
    include files
versus templates

Extreme Tree Menus
Tree Menu Navigation - Extreme Cross-Browser CompliantTree Menu Architecture
  1. Real Time Database Tree Menu Architecture:
    dynamic menus do's and don't and a common sense solution for real-time critical data and user portals

    Could I integrate a database into your tree menu?


    YES, you could add a database, but do you really need to generate 100% of the menu items via a database? Is that really the best way? Is there a better, faster, more reliable way to do what you are trying to do? Yes, there is.

    Typically, there are two (2) reasons why customers ask us this question:

    1. Customized User Portal

    2. Real Time Data

    In either case, what should really be done is a combination of both a static menu and then add server-side code to connect to a database for only those parts of a web site that need it.

    If you have a portal with different users, you should group your users into different groups or permissions. Then give each group permissions to access to certain web pages. Each special menu button, for example, say the Administration button, will be handled via server side code and can be inserted into the templates that need it right next to the static buttons. This will cause the buttons to be visible for only those users that are given permissions to the groups they belong. This works just like those web sites that have a friendly greeting once the user logs in, e.g. Welcome Mary, So instead of generating the code for say the , Welcome Mary, you will generate the html and image tags for the buttons and text you want to display in the menu.

    Furthermore, a totally dynamic left hand navigation could only confuse the user as everything is always changing and thus users end up searching for stuff when they should already know where to go in the first place. The tree menu should be a familiar and consistent map for both the users who are not logged in and visitors who are not logged in.

    Limiting access is more reliable, faster and simpler than giving users more customization than they really need, or in reality, more than they could even care for. Ease-of-use, reliability, and speed is far more important than 100% menu customization as users want to get things done. Users should not be spending all day customizing a web site for their needs when the web site's developers and designers should have already chosen the best and easiest menu layout to begin with.

    If you look at the big commercial web sites like Yahoo and eBay, you don't a see a fully customizable menu do you? Even their personalized web sites, like MyYahoo and eBay's seller and buyer's web pages don't have a fully customizable menu. What they do have are sections that allow only access to certain users.

    MyYahoo's E-Mail and are good examples of using a static menu and then adding only dynamic items from a database as needed, e.g. customized mail folders to parts of the navigation menu.

    As another example, MyYahoo page list stocks that customizable for each user; however, all the panels, news, sports, weather, travel etc, are cached to begin with, and the menus are very simple anyway, probably no more then 5 buttons. And not to mention, they don't even have a tree menu on that page to begin with. Moreover, the return on investment, ROI, is negative in the short run and the long run, as it adds almost no value whatsoever when compared to the combination method of static and as needed dynamic menus system mentioned above. And, as your web site grows and gets more traffic, you will soon have to get rid of that 100% dynamic tree menu anyway as the load will be too much and reliability will be a number one concern.

    By having parts of the web site grouped in specific sections via group privilege , you can more easily debug problems without having to worry about a massive and dynamic menu generation on each and every web request. Keeping things simple is the key to designing any web site.

    Real-time critical data should use a simple text alert of new data instead of listing all of the data
    A simple single text message or icon alerting the user of something new or changes to the database, such as the MyYahoo Mail's "new mail alert", is far far smarter and common sense solution than having a dynamic data driven navigation menu.

    Never tie a real time tree menu items to files in a folder that you drop stuff in. You should never bog down the navigation tree to constantly look up and see the contents of a folder. The contents of a folder should always be displayed in the center of a single web page; NOT on the left hand tree menu.
    Being alerted by a simple text message or icon of new or changed data is different than dynamically listing all the data
    Thus, auto folder content tie-in should be at the web page level, not the tree menu items level.

    An example of why you should NOT make a 100% menu database
    The CIO or project manager wants to list all daily reports on the left hand side so users have the most current data at their finger tips. Ok, so now when someone clicks on the menu item at the end of the year, it's going to list all 365 daily report menu items on the left hand side of the menu for easy access! As you can tell this would not be a good solution. That folder or database is going to eventually get big really fast and anything over 10 to 20 items is just too much for anything to be really listed on the left hand navigation. Even if you did it by year and month, it's simply not a long term solution for the main navigation system that has the potential to grow out of bounds. And on top of all that, the performance can easily be cut by 50%. A more easily accessible and sophisticated listing of daily reports can easily be accomplished with a traditional database connection to the body of a web page.

    Reason #2 for real time data:
    MyYahoo navigation list of stocks VERSUS getting an alert only if a stock changes a preset amount in price, or volume or news
    It's basically an architectural issue. One should ask, do we really need the dynamic info inside the navigation bar?  Couldn't we just have a simple alert notification message or icon instead? Why couldn't it be on the main part of the page?  eBay has it's auctions on the center of the page, Google and Yahoo have it on the center.  People can easily navigate to any dynamic item in the center and the user will always be instantly alerted of anything new or changed.  Of what real and practical benefit to the user will it be it's on the left instead of the center. Just how much money are we going to make in the first place by having it that way?

    Wasn't the menu system supposed to be familiar, easy-to-use, and easy-to-find things? How is someone going to find things if the menu keeps changing all the time? What happened to consistency and familiarity?

    Imagine how annoying it would be if randomly changed the positions and names of all their familiar tab buttons on their menu bar every hour of the day.

    If the dynamic content is so important, shouldn't an entire page be dedicated to it so users can easily see it like an auction.  If it was on the left hand navigation menu and it's dynamic and it's so important, wouldn't their very next click be on the item itself as opposed to so other part of the menu.

    The only thing that might need it is something like a MyYahoo portal with stocks, airline information, and sports scores. And that is where everything on the left hand and the right hand is dynamic. But then again, a lot of that stuff on MyYahoo is delayed and cached anyway due to the additional load from the dynamic portion.
    Furthermore, even the MyYahoo Mail only displays a"new mail alert" that you have new mail waiting. And It certainly doesn't list every single message you just received on the left hand menu.
    So if only every single menu item and the entire web page is dynamically changing, then you should consider something else and that would be a tremendous hassle anyway. Otherwise, even if only a portion of the menu is dynamic, that dynamic code should only be put on those pages that reference that menu section anyway as the static portions shouldn't suffer. (e.g. number of shopping cart items in your basket)
terms of use | privacy policy
copyright © 2003 - decloak, inc. all rights reserved