Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

Main menus and sub menus

The solutions discussed here requires JavaScript. The (too) expensive but very professional solution from http://milonic.com displays a workaround if JavaScript is not enabled, but the solution pointed to by Patrick simply give up: you cannot navigate thru such a website without JavaScript. This is not acceptable I think.

From my point of view, something like JavaScript should not be used for basic things like navigation. Exception is where a JavaScript-free-solution works, but the JavaScript solution looks better.

The CityDesk feature that makes it possible to call an external programm after publishing but before FTPing can be used to solve the problem. At this step keywords could be inspected by acessing the CityDesk database via ODBC.

1. If a top level article does not inlcude the keyword "(nomain)", it is added to the main menu.
2. In every sub folder, as deep as you want, every article with the keyword "(sub)" is added to the submenu of that folder.

Although there are some anoyingly problems when an external program is called from CityDesk, this works. You can see examples here:

http://kai-jaeger.de
http://aplteam.de

Writing this program I realized that some other things could be easily done here:

- Inserting bread crumbs
- Creating a sitemap
- Creating a glossary
- Change "***Level 2 Header***" to "<h2>Level 2 Header</h2>"
- Inserting external files: when a piece of code like "{/ Include 'C:\MyFolder\MySpecialData.txt' /}" is detected, this is replaced by the content of the specified file.

Even nice but not essential things could be done here: links to glossary entries are changed in a special way. See an example at
http://netz-agentur.biz
"CMS" is a link to a glossary entry. If the directory name is "Glossar" (the german word for "glossary"), a special CSS style and cursor is added to the link.

http://kai-jaeger.de offers a special feature; change the design on the fly by selecting a different one from a combobox. Nice but not essential except if you are colorblind. If JavaScript is enabled, the feature could be used. If not, there is simply no combo.

BTW, building a photo gallery this way is easy, without need for php at the server.

Any comments are welcome.

Kai Jäger
Wednesday, June 02, 2004

Interesting post and some really nice examples.

> From my point of view, something like JavaScript
> should not be used for basic things like navigation.

Hhmm... whats the point ? Why not ? I'd rather use Javascript turned-on as 96% of the global web surfing community than install a separate application and manually link it to CityDesk publish options. And how do you provide for browser differences in DHTML handling without Javascript ?

> Exception is where a JavaScript-free-solution works,
> but the JavaScript solution looks better.

Well, they do, I'm afraid... :-)

BTW, the two-level menu examples you show don't need an extra application installed to create; the FORSSA Wizard does that with CityScript alone (others have pointed out code examples in this forum too).

Can you build an unlimited-depth, drop-down menu system without Javascript ?

Cheers

Patrick Thomas
http://www.telepark.de

Patrick Thomas
Wednesday, June 02, 2004

BTW, visiting your website made me realize that I should start running (again)...:-) Thanks.

Patrick

Patrick Thomas
Wednesday, June 02, 2004

Patrick,

you cannot build a menu system with CityScript that is simply driven by a folder hirachie!

But that is not the only topic: in the examples you can see at every depth where you are; the current main menu topic as well as the current sub menu topic is marked (okay, may be marked with CSS) in a special manner. That is not possible with CityScript, since every page differs from every other page here.

DHTML: I simply do not use it. Never. There is no need for such things on the type of websites I am dealing with.

For security reasons there is a really strong need to switch JavaScript off, a least when the Internet Explorer is used. Therefore I  think JavaScript should not be used for navigation. With CSS, navigation could be done in a nice way without JavaScript.

If the result of my posting reboots the jogger Patrick: very good!

Kai Jäger
Wednesday, June 02, 2004

I think you could build an unlimited, drop-down menu site using server-side scripting such as PHP--couldn't you?  That would eliminate the Javascript disabled problem.

David Burch
Wednesday, June 02, 2004

> For security reasons there is a really strong need to
> switch JavaScript off, a least when the Internet Explorer
> is used. Therefore I  think JavaScript should not be used
> for navigation.

Well, either one turns Javascript on or off. If its turned on (only about 4% of the web population has it turned off; for various reasons - which means "literally everybody" has it turned on) one might as well use it for navigation purposes.

On the other hand, as you certainly mean to imply, forcing a user to use Javascript to navigate a site is something one could discuss whether it being appropriate. But, IMHO, its in the same league as discussing support for browsers such as Navigator 4.x or IE4 on the Mac.

And in terms of security issues: same thing here. Practical vs. idealistic. Natural gas is dangerous (some might argue it can be more hazardous than using Javascript) but most people don't mind using it for cooking or heating purposes.

And David, I agree, using server-side scripting in conjunction with CD could do part of the job but, IMHO, it still would not create the cross-browser drop-down mechanics w/o Javascript. I actually believe CD + server-side scripting being one of the most under-explored (or discussed) areas of using CD - great pity actually.

On a side note: does anybody out there remember GLPRO ? Just curious...

Patrick Thomas
http://www.telepark.de

Patrick Thomas
Wednesday, June 02, 2004

Patrick, do your JavaScript menus work for people who can't use the mouse, and have to rely on keyboard navigation? Or for blind people, using screen-readers?

There are often very real and valid reasons publishers don't use JavaScript, especially for navigation. For me, JS is OK for the little extra things that aren't essential to using a site, but my view is that you always need some fallback form of navigation for those who won't or can't use JS solutions, for whatever reason. Some organisations have legal obligations to make their sites accessible to the disabled, others just think it's a good idea.

By the way, you mean "practically everybody", not "literally everybody" :-). The latter means that there are *no* exceptions, the former means that the exceptions are minor enough to be ignored.

I agree with David - I think PHP would be a good way to implement a solution (assuming the publisher has PHP enabled on their server, which most do nowadays). You could embed a PHP script into your template, and populate a PHP array using a loop. The PHP script would then be able to process the array and build a menu out of it, with however many levels of depth are required. It could also generate breadcrumbs etc. If I had time, I'd do it :-).

Darren Collins
Wednesday, June 02, 2004

Darren,

but CityDesk is a desktop CMS. I prefer to see working pages in my PC - before publiching! So I think it is a good idea to create pages with a working navigation at my own PC, isn't it?

Kai Jäger
Thursday, June 03, 2004

> Patrick, do your JavaScript menus work for people who
> can't use the mouse, and have to rely on keyboard
> navigation? Or for blind people, using screen-readers?

Well put. Accessability is a valid concern as for example government regulations in Germany require a site's content to be accessible to the visually impaired for example (most don't comply 100% but its still a valid goal).

But this does not imply to adhere to the lowest common denominator in terms of design but rather to have the same content reformatted again in a "parallel" site for specific target groups. If not, how would you deal with mobile access using PDAs and SmartPhones ? Design your website so that its adequate for a 320x240 PDA screen as well as your 1280x1024 browser screen as well as for screenreaders ?

Reformatting content for different target groups is what CMS is all about and does not exclude the use of Javascript, including for navigation IMHO...

> By the way, you mean "practically everybody",
> not "literally everybody" :-). The latter means that there
> are *no* exceptions, the former means that the
> exceptions are minor enough to be ignored.

Thanks :-)

> You could embed a PHP script into your template, and
> populate a PHP array using a loop. The PHP script would
> then be able to process the array and build a menu out
> of it, with however many levels of depth are required. It

Thats, of course, part of what VANTAA does with Javascript (and what we hope CD3 might do in the future). But its only part of the story: if you want drop-down navigation as the visual front-end (as most are conditioned by Mac/Windows GUIs to use), I still don't see how you can provide that without Javascript / DHTML.

> If I had time, I'd do it :-).

Can I rephrase it to: "If I could make money with it, I'd do it" :-) ? I am saying this because CD in some aspects reminds me of GLPRO, a really clever multimedia scripting language, for stopping short of providing a business platform and market environment for third-parties to earn money with it. Yes, we (and others) did a lot of lucrative projects *based on* GLPRO (same with CD) but that was not enough to keep it alive in the long run in the face of competition. I sincerely believe it to be important to build an ecosystem around it to sustain growth in market share. And this ecosystem can only be filled with third-party offerings. And most third parties only invest the time if its worth it, hence the very understandable statements such as "if I had time to...do it / document it properly / clean it up for others to use...etc" which popped up in the GLPRO community every so often. Just some thoughts...

Cheers

Patrick Thomas
http://www.telepark.de

PS: For those interested, there is a kind of successor to GLPRO (www.aftergrasp.com - horrible website through :-)...

Patrick Thomas
Thursday, June 03, 2004

U.S. Government web sites, including those of public universities, must comply with accessibility guidelines.

David Burch
Thursday, June 03, 2004

I don't want drop-down navigation windows for my web sites:  1) It would get too cluttered and unusable for extremely large web sites--large in breadth as well as depth, 2) I think most web users have been conditioned by popular web sites, not Windows or Mac interfaces, and I think users are smart enough to know the difference.  I think people want information from a web site, that they want the quickest path to that information, and that they do not have time to "Play" with fancy gadgets.

David Burch
Thursday, June 03, 2004

Concerning Accessibility and DHTML menus, see here from the WebAIM project (from the Center for Persons with Disabilities and Utah State):

http://www.wac.ohio-state.edu/webaim/kbrdaxs.htm

Quote: "The [DHTML] menus are slick ways of keeping the interface simple and uncluttered, while also allowing the user to quickly locate the desired content with a minimum of clicks."

In response to Davids "playing with fancy gadgets"...

But WebAIM also states "The down side is that none of the functionality is available without a mouse. The DHTML menus can't be made directly accessible with current technologies..."

Then they add "...but there are workarounds."

Its a well-rounded article, worth reading.

Yes, we should extend VANTAA to also generate simple text link navigations (with unlimited depth)...there is no reason it cannot do that. Keyboard acceleration for DHTML menu Accessibility is a second avenue to explore in parallel.

Thank you for the lively discussion.

Patrick Thomas
http://www.telepark.de

PS: See also www.borland.com and www.microsoft.com for examples of DHTML menu use.

Patrick Thomas
Thursday, June 03, 2004

I think I might have looked a bit sarcastic with the question about JS menus for disabled people. I honestly didn't know if they had accessibility issues or not, as I haven't played with them at all.

Patrick's workaround of providing alternate sites for accessibility, PDAs, etc is workable. CityDesk template families really make this pretty easy, once you've designed each set of templates.

I agree with David. I really don't like drop-down menus on web sites. I don't like 'hiding' anything in places where users need to mouse-over to find it. For example, if I'm looking for particular information on a site, I hate having to mouse-over my way through all their multi-level menus trying to find the most likely section of the site. I'd rather have an index page where everything is visible at once, and I can just click on the one that looks most likely to lead me to my answer.

The point about a PHP solution being hard to preview is a valid one. I have a server I use to preview, so I don't have that problem, but not everyone has that luxury. PHP is only a workaround anyway, until CityScript has a little more flexibility to do these types of things itself.

Darren Collins
Thursday, June 03, 2004

The DHTML menus on Microsoft's home page only go two levels deep.  Borland's home pae uses multiple levels and it seems much clunkier to me (Microsoft's site once used mulltiple levels and must have changed for a reason).

Notice how google.com, yahoo.com, and amazon.com don't use DHTML menus.

David Burch
Friday, June 04, 2004

This is a "me too" post.

For me, a navigation system which relies completely on JavaScript is completely unacceptable, for two reasons:

(1) Security-conscious people might not even see the navigation because they're surfing with JS/Active Scripting disabled.

Since security conscious people tend to be intelligent, I want them to be able to enjoy their visit to my site and not get stuck somewhere.

(2) Disabled people rely on screen readers which don't interpret JavaScript at all. They also can't handle mouseover dropdown/pullout menus.

Since disabled people should always be treated well, I want them to be able to enjoy my site.

Of course, somebody can argue that these people are minorities. To which I have to respond: That may well be, but these minorities are very important to me.

GeraldH
Monday, June 07, 2004

Javascript, the webs oldest and most popular scripting language, is neither a significant security risk nor evil.

DHTML menus and lots-of-links approches on homepages are not mutually exclusive, a fact conveniently overlooked. They fit very well together and cater to different user groups (aka the recurring and the occasional / new visitor).

Regards

Patrick Thomas
http://www.telepark.de

Patrick Thomas
Monday, June 07, 2004

Don't get me wrong, browser bugs exploited with the use of javascript involve security risks. No question about that. So does emailing and connecting one's computer to the internet.

Regards

Patrick

(see the rather nasty IE6 exploit at http://62.131.86.111/analysis.htm)

Patrick Thomas
Monday, June 07, 2004

Oh yes, Patrick, let's argue semantics. :-)

From a browsing perspective, it's the same whether JavaScript has a security flaw or whether the implementation in MSIE has a security flaw.

GeraldH
Tuesday, June 08, 2004

So don't use javascript. Most sites have alternate menu navigation links along with their js menus. Don't villify us for choosing to use js.

I couldn't imagine designing my site for people without a mouse. Never even thought of it. No mouse, no js? I'd like to see that site!

Maybe CD3 will have an easy to use, kludge-less way of creating menus via CityScript (in conjunction with js??). Then, it will be easier to use different menus for each section of my site, instead of having all parts of my site on one big multi-levelled dhtml js menu.

Keep the discussion technical. No ad-hominum comments...

Bob Bloom
Tuesday, June 08, 2004

WebTV is mouseless, irritating and for an aged, infirm friend of mine, a lifeline.

tk
Wednesday, June 09, 2004

*  Recent Topics

*  Fog Creek Home