It's taken a while, but by now, 4 years after I originally published this paper, users can have LINK support on every major platform. We've come a long way. There now even is a LINK Toolbar for the Windows version of Explorer. (This is a third-party tool. I don't use Windows myself, so I have no idea how well it works. Give it a try and let me know.) Hopefully also Apple's very promising new web browser, Safari, will grow LINK support.
It's a maze out there
Ask any WWW newbie; ask any experienced Web surfer; ask any Web site developer "what are the biggest problems with Web sites?" and chances are "navigation" will rank in their top 3.
People get lost. Before they realise it, they're ten Web sites away from where they thought they were. Or they're in one section of a Web site looking for something in vain because it is actually in another section of the site.
As a result, visitors often are not only 'lost in cyberspace', they're also 'lost' to the owner of the Web site. Either simply because the visitor can't find his way back to the site, or because they give up in frustration. They might try elsewhere. Or they might give up their search completely.
Creating a Web site that is easy to navigate is one of the hardest things. The bigger the site, the sooner visitors will become confused about where they are. The reason for that, I believe, is twofold:
Every Web site looks and navigates differently.
If you would compare Web sites' navigation systems with traffic signs, the problem with this is easily explained: although traffic signs aren't globally universal, at least on a national level they mostly are. If you know the sign, you will recognise it in every street and every city it is used in. Just imagine if every city, neighbourhood, or even every street would be using its own unique system of traffic signs. People would be at a loss all the time.
Yet on the Web, this is reality. On the Web, people need to get used to each and every Web site's unique navigational system.
A Web site's structure can't be seen. It cannot be touched. It is abstract. Even to the author of the Web site this often is hard to deal with. Imagine how hard it must be for a visitor who doesn't know yet what a Web site contains nor how it is structured.
In order to ease a Web site's navigation, authors try all kinds of things. Like making every page 'look' the same, so at least visitors will (hopefully) recognise it when they followed an outside link. Authors may offer the user a 'site-map'. Many authors choose to use
FRAMES (ignoring the problems many browsers have with
FRAMES - ever tried bookmarking a set of frames?).
Some sites try to use signs/icons that are hoped to be understood more or less universally. We've all seen icons showing a house to indicate a link to a site's homepage for instance. However, most Web authors are either 'techies', or 'graphic designers', both of whom are often tempted to forget that iconography is a specialty in itself. As a result, many of the icons you encounter aren't very useful at best, or utterly confusing at worst. In part, that's because most Web publishers aren't iconographers. In part it is because Web publishers tend to insist on making their site look unique.
And although it makes sense to present your content in a unique way, both to support the uniqueness of your content and to stand out inbetween potential competitors, if you've read the previous section you've learned that that same uniqueness is what causes navigational problems.
Wouldn't it be great if the Web would have some form of universal 'traffic signs'? A scheme that would allow visitors to easily and quickly navigate through Web sites. Wouldn't it be great if browsers would have some kind of build-in sensor, that would be able to tell visitors where to find the homepage to a site, where to find an index, where to find a help page, or a search page? No matter what Web site is being visited? A system capable of visualising a Web site's structure. A system where, no matter how deep a visitor has travelled inside a Web site, he can still find his way without a blink.
And wouldn't it be great if such a system would not stand in the way of a Web site's unique presentation of content? Surely that would be the best of both worlds: to have both universally understood navigation and unique presentation of content at the same time.
Well, have I got news for you: there is such a system. And it has been around for quite a while now. The HTML 2.0 standard, which dates back to November 1995, already included the
LINK element offers WWW authors a way to define a few 'standard links' - links to the kind of places that most Web site's structures use, such as a homepage, a help page, the next or previous page, the parent document, a page offering contact information, etc. Almost every Web site uses at least some of those pages. And they're usually the most essential pages.
Surprised? You ask yourself,
if there was a solution all this time, why have I never encountered it?. Well, one of the reasons you may have not seen this yet is because most Web authors don't use it. And probably one of the main reasons they don't use it is that most Web browsers don't support it. Yet.
Up untill recently, the only Web browser (that I know of) that supports the
LINK element was Lynx. Below is a snapshot of how a page that makes use of
LINK may look in Lynx.
I bet you're not impressed. Sure, obviously the
LINK element makes navigation much easier, but Lynx is a text-based browser and as such can handle only text for in-line presentation. (Lynx can handle other content, such as images, movies, etc., very well - just not in-line.)
So what we really want is a 'graphical' browser that supports
LINK. Well, there is no reason why that should be a problem. All browser vendors need to do is add support for it. Considering all the great gizmos they've been able to toss at us in the past few years, it can't be hard for them to add support for something as simple and straightforward as
In fact, a little while ago, a 'graphical' browser that does support
LINK entered the WWW stage. And it does this very well. This browser's name is iCab and it's a remarkable piece of beauty. It leaves 'The BIG 2' far behind in many areas. Even though iCab is still in development and the versions that are currently available are considered "previews", I could write a book about how iCab gave me back the fun of surfing the Web. But I won't do that now and here. For now we'll stick with the issue at hand: Navigating the WWW, and the
So what does
LINK look like? Well, like all HTML, that depends on the Web browser (and the user's settings of it). And that's very much the point of it! Because the browser decides how to convey a
Here's how iCab displays the
LINK elements (in a tiny "Special Links toolbar", just below the URL field, taking up far less screen space than your average navigation frame does):
LINK element that isn't specified, iCab will 'gray-out' the icon to protect the user from selecting an option that's not available.
From left to right, these icons represent the following LINK elements:
TITLEattributes of the 12 above mentioned
LINKelements, as well as of any additional
I can hear you say: "Yeah, well... cool. But iCab is Mac OS-only". That is true. But 2 other things are also true:
LINK will help people who use LINK-capable browsers such as Mozilla, Firefox with its LINK toolbar installed, Opera, iCab, Lynx or WinIE with its LINK Toolbar installed, and it won't hurt users of other browsers.
By using iCab as an example and presenting its capabilities, not in yet another Mac-vs-PC advocacy or a 'which browser is best' debate, but in the much broader setting of the very real problem of WWW navigation, I'm hoping to encourage both Web publishers and browser vendors to start using
LINK. Call me naive if you want, but I like to think that the more sites use
LINK, the more browser vendors will be inclined to implement support for it.
LINK is not a complete solution for every conceivable situation. Don't mistake
LINK for the Holy Grail of WWW navigation. Individual Web sites may need to offer visitors additional clues. But using
LINK can help a lot. And perhaps there are possibilities of even extending the current definition of
LINK in the future.
LINKelement at "The 'link'-Element in (X)HTML".
<LINK>- screenshots included.
Safari is now the only major browsers left that does not offer support for LINK. Let's hope Apple will catch up soon.