Site Navigation: Self Links and Onstate
posted by DL Byron on May 06, 2004
Various Design Sites
I’ve noticed a design trend of onstates or no onstates in nav systems and the occurrence of self links in navs — check a related ALA article on creating current tabs. By onstate, I mean an indicator that you’re on a page. By self link, I mean a link that points to itself. When you click a self link, it reloads the page you’re on. I think the navigation on the various design sites is not changing to an onstate or the link is linking to itself (self link) because the page is served by a template or include. Open for debate is whether or not an onstate, or no onstate, with self links confuse the users. I’d expect usability experts to argue for no self links and onstates to help the user know where they are in the site.
Click around various design sites and you’ll see:
Self Links with Onstate
Self Links with no Onstate:
No Self Links with Onstate
New, even harder to navigate
While I was updating this post, a colleague sent me an instant message about his new site. I said, “Cool, nice, not down with the wood grain so much, and where’s the onstate?” He replied, “Well, I’m working on it. See it’s all includes.”
That confirms what I thought was happening. Designers aren’t purposefully making their sites harder to navigate (note, this site isn’t that easy to navigate either - a redesign is in progress…). It’s just much easier to use templates and includes. Coding a site with includes to indicate what page a user is on requires a bit more work with CSS and PHP
The CSS conclusion
After several emails, one argument, chats, and the urging of Scott Benish, our Brand Manager and Designer, the conclusion is to use "Self Links with Onstate." I’m no CSS Zen Garden master and it gets tricky with the sub nav, but here’s how I do it on Clip-n-Seal:
- IDs are applied to the body and list item tags that add a bullet image and changes the style of the link.
- The style is over ridden for the parent of the sub nav inline.
<!--Inline style for onstate-->
<style type="text/css">
<!-- body#about li#aboutnav a:visited { color: #336699; }
body#about li#aboutnav ul#subnav
li#businessnav a:hover{ text-decoration: none; }
body#about li#aboutnav a:hover{ text-decoration: underline; color: #333; }
-->
</style>
A Lil' PHP
You can't apply more than one ID to the body tag. So, for the subnavs, I use PHP code that I tweaked from the Keeping Current ALA article. The PHP identifies the subnav and writes the id for the subnav page.
<!--Identifies the subnav page-->
<?php $thisPage="purchase_satisfy"; ?>
<!--Writes the subnav ID-->
<ul id="subnav">
<li<?php if ($thisPage=="purchase_satisfy")
echo " id=\"satisfynav\""; ?>><a href="/html/satisfy.htm"
title="Satisfaction Guaranteed">Satisfaction Guaranteed</a></li>
<li<?php if ($thisPage=="purchase_retail")
echo " id=\"retailnav\""; ?>><a href="/html/retail.htm"
title="Retail">Retail/Wholesale</a></li>
<li<?php if ($thisPage=="purchase_industrial")
echo " id=\"industrialnav\""; ?>><a href="/html/industrial.htm"
title="Industrial">Industrial</a></li>
</ul>
It works
With CSS and PHP, I can use includes, indicate what page a user is on, and make the site more usable.
other posts tagged:
Comments
May 06 | benishs said:
for the record, my preference is actually “no self link and onstate”. but apparently taking off the self links is difficult because of the Movable Type templates we are using in some areas.
May 06 | -b- said:
Noted. I think it’s a balance. For example, I consult on this huge-ass intranet for a client and there’s includes everywhere, no one state and self lnks. That’s just how it’s built.
May 08 | Paul Ingram said:
Hmmm. It looks like this is fine IF you’re using it with separate pages on a site. I’m looking at one reloaded PHP template where I’d have to grab the actual id from the server to indicate which link should be “on”. I’m no PHP Zen Garden master, so this will take some time.
I’m not sure the syntax for dynamically inserting an id value inline. Here’s what I’m currently stuck with (not working):
<style type="text/css"> <!-- #topNav #<?php the_category() ?> { color: #ffffff; } --> </style>Help?
May 08 | Paul Ingram said:
Got it. Simple PHP:
<style type="text/css"> <!-- #topNav #cat<?php echo($cat); ?> { color: #ffffff; } --> </style>Pulling the query strting, inserting it into the right spot in the CSS, and wamo.
BTW, I’m using WordPress (yeah, I know it’s not as popular).
May 10 | -b- said:
That’s great! The point is, cool, cool, use the blogging app, then spend a little more time and make sure that the users knows where they are in your site.
May 10 | ppk said:
Are self links and onstates Need-To-Have or Nice-To-Have functionalities?
If the latter, the very simplest solution is to use JavaScript. Go through all links on the page, and if the href is equal to the page location, add a class name.
var x = document.getElementsByTagName(‘a’); for (var i=0;i
May 10 | -b- said:
For a navigation system, they’re a must-have. Self links are a compromise with an include file.
May 11 | Tim Gross said:
Well taking the JavaScript that - b - posted could you not extend it further by just setting the onClick event to return false. Granted JavaScript isn’t the greatest solution but it’s a good compromise if the hosting serves that the web page is being hosted on don’t allow php or asp.
May 11 | bruno said:
ppk,
that’s a nifty little piece of script you got there - threw that into a page I just did and it works great!
May 11 | Tim Gross said:
oops I meant the javascript that ppk posted.
May 13 | benishs said:
I think ppk’s JS and/or Byron’s tricked-out on state CSS gets the job done about 95% of the time. Most visitors are going to be visiting with a modern graphical browser, and with either of those techniques (and intelligently designed CSS) they probably won’t get confused.
So, I think it’s a matter of deciding whether or not that other 5% (or whatever it is) are worth the effort it takes to remove the links. The people served by actually removing the links: text readers, screen readers and maybe some phones or PocketPCs with lousy CSS/JS support (not sure about those).
Fringe cases to be sure, but I’m the type of person who likes to accomodate such situations whenever possible.
Of course, if the budget/schedule/motivation-level doesn’t allow it, then so be it. It’s a design decision and is therefore subject to a number of factors.
Just make sure you understand the consequences of the decision for each particular site.