|
|
 |
|
 |
| |
 Tree
Menu Architecture
- 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
Question:
Could I integrate a database into your
tree menu?
Answer:
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:
- Customized User
Portal
- 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.
- CUSTOMIZED USER PORTAL
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 Hotmail.com 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 DATA
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 Amazon.com
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)
|
| |
|
|
|
