kchayka said:
I think one of us is confused.
Maybe it's me, maybe I didn't quote
enough of the previous post, or maybe we have two different ideas about
what DHTML menus are.
No confusion. I'm talking in general terms not about a specific site.
At any rate, if it's a navigation page, like a site map or section TOC,
then we might not _need_ a DHTML menu. The page content _is_ the
navigation menu, after all.
How about a home page? Definitely a navigation page, but not good to
overwhelm the user with many, many links. That's the sort of page I'd
use a dynamic menu on.
The usual draw of DHTML menus is to have links to pretty much everywhere
at the site available on every page, including (nested) submenu links.
But does it offer any real benefits for real users?
The usability problems of drop down menus are well documented. To name
just two - the (sighted) user can't see all the links initially and
has to hunt around through the menus to see if what they want is
there; and as these menus are all custom creations thay all act in
slightly different ways (different time delays; some popup on
mouseover, others on clicking; etc.).
Would the time and effort be better spent on information architecture
so that the site is better structured with appropriate links tied into
the content?
Simple example - an an e-commerce site instead having a DHTML menu
with links from every product to every other product put the effort
into well thought out cross-selling.
But not always visible, or even always immediately accessible. Just
imagine a screen reader trying to access a (nested) submenu link,
several layers down. How many links does it have to read before it gets
to the one the user wants? How many times does that user have to go
through this long list before they are done at the site?
Put the links list at the end of the page.
Use headings to break up and structure the list.
Or are you saying that users of screen readers shouldn't have access
to the same range if navigation options that users of visual browsers
do? I don't think you are.
You make a bold assumption on how the HTML is structured, methinks.
You're making the links appear and disappear with JS.
Why not reposition them with JS as well?
Besides, who wants to download an extra 10k on every page if they don't
have JS and won't get the kewlness of a DHTML menu?
The users who want to have a link to every page from every page. Those
are presumably the people this is all done in aid of. Whether they get
those links presented in a kewl (but really, DHTML menus are so year
before last) fashion or not is secondary to the fact that presumably
the users want the links to be there.
It's excess, and
something you have to hunt-and-peck your way through to use. Just give
them the links to the site map and section TOCs. That's KISS, no?
Yes. Bingo. That's why it's a bad idea to have lots of navigation
links on content pages. Regardless of how they are presented.
At least with JS on, the menu can be cached so it becomes a one-time
download. BTW, I picked that 10k number out of the air, but I suspect
the list markup for a large navigation menu could easily be that big,
depending on link text and such.
The cost of the JS code can be much more than the cost of the actual
links. And the download time for the first page a visitor comes to is
the most important one .
Does it matter? If by DOM manipulation you mean creating/adding nodes
and such, it is perhaps the more elegant method, but perhaps also less
well supported than document.write, but I'm not certain of that.
Whichever uses less code and most widely supported, thus is quicker to
download, run, and maintain, would be my preference.
The advantage of creating DOM nodes over document.write is that you
don't need any <script> elements in the body of the page. Which I will
admit largely appeals on grounds of elegance but which can have
maintenance and flexibility advantages as well.
As for support, we're talking IE5+ and NN6+ (and others). If you want
to support NN4 and IE4 as well you have to go ye olde route but you
also have to write branched code anyway to cover the custom
document.all and document.layers models that they use, which just adds
to the file size. Having three versions of the code for what is only
an enhancement is overkill.
Steve
