squarehappy is Michael Huch is a cynical web developer and designer with more styles than content.

uLink: User-Defined Links

posted by Mike on 06.02.2005 10:58 PM EST | 860 comments

In a large document, finding a specific piece of information can prove difficult. Using a browser's Find function is something the average web surfer is not familiar with, and even so it can be difficult to find what you're looking for when you're not exactly sure what it is. So we must rely on the limited Find function or our own abilities to scan a document to find a specific piece of information.

Fragment identifiers exist as a solution to this problem, albeit a far from perfect one. Fragments allow a site or user to link to specific location of a document, most likely an empty anchor tag with a name attribute, but you can use any element with an id attribute. However these locations must be defined by the creator of the document. These tags and attributes are typically not apparent to anyone other than the creator, as they appear only in the document's source. Furthermore, the incentive to insert anchors in various locations is limited by the creator's own need to link to those specific points in the document. You do not find many sites with non-hyperlink anchors solely for the sake of its users.

There are examples to the contrary. The most notable is purple numbers, which provide permanent, visible links affixed to each paragraph that link directly to that paragraph. This has its downsides and upsides. The main downside is loss of visual appeal. Numbers littering a document creating a sense of chaos and making it look more like a technical document not to be read by the average user. The upside is that it's easy to accidentally discover the purpose of the purple numbers even with no preconceived notion of what they are. Reader comments in blogs are another example of superfluous anchors being left for the user to utilize. Comments are numbered with the number itself being the direct link to the comment.

These are limited solutions. Awhile ago, I envisioned something a bit more open ended: the ability to link to any location on any page without additional HTML and visual elements. It was PHP to the rescue on this one, making this dream a reality in the form of the uLink, or User-Defined Link.

IMPLEMENTATION

I think it would be best to begin by explaining how to construct a uLink URL. To link to step 6 of the middle finger cursor, you would construct a URL like so:

http://squarehappy.com/article/middle_finger_cursor/?YOU ARE SUCCESS#ulink

Go ahead, click on it. What we have is somewhat of a retarded variable string following the question mark, and then the fragment denoted by '#' identifier immediately after. All fragments would be identified as "ulink" as the anchor to be inserted into the text will have that id and name.

When dealing with sites dynamically constructed by various programming languages, content may be processed quite differently from one site to the other. The CMS I built for this site concludes this dynamic construction by dropping a single variable, $content, into the main content area of the site layout. Before that happens, we need to allow the uLink to step in for a second and do its work. Here's the PHP:

if (strstr($_SERVER['REQUEST_URI'], '?')) {
$anchor = explode('?', $_SERVER['REQUEST_URI']);
$anchor = $anchor[ count($anchor) - 1 ];
if (!strstr($anchor, '=')) {
$anchor = stripslashes(str_replace('%20', ' ', $anchor));
$content = str_replace($anchor,"<a id=\"ulink\" name=\"ulink\"></a> $anchor",$content);
}
}

First, the strstr function checks to see if there are any question marks in the requested URI. It's normal for URLs with variables to contain a question mark at the beginning of the variable string. I've taken this into account, and the function's two lines are prepared to handle a situation involving more than one question mark. It turns the REQUEST_URI into an array, exploded at the question marks, and then the following line stores the value of the last member of the $anchor array as the only value of $anchor. View the following example:

http://sh.illusioned.net/article/ulink_user_defined_links/?var=foo&blah=bar?To link to this sentence#ulink

The uLink function will ignore the variables and set the value of $anchor to "To link to this sentence". At this point a URL containing variables and no uLink is doing fine as far as the function is concerned, so I'll have to give their kind the boot with the nested if statement, which simply checks for the presence of an equals sign. If there is none, the str_replace function will insert the named anchor into the content in the appropriate location...

...HOPEFULLY THE APPROPRIATE LOCATION

There are a few flaws in the uLink's functionality. If the end user does not choose a sufficiently unique string, they risk getting a false positive in another location of the document. Also, PHP is processing the raw HTML data, tags and all. The user is forced to be careful not to choose a string containing any HTML tag, as it'll obviously not be included in the user's copied and pasted uLink. I know there are ways around this but I'm not quite up to the task. Feel free to improve on it.

And what if the content changes? If the content being linked to, which could be any and all of the content, changes then the uLink will break. It is up to the webmaster to maintain uLink integrity. My solution is to strike through content that has become outdated, thus preserving the uLink, and helping users to find, that if indeed new information has been brought to light, this information will be available in the immediate vicinity of the uLink. On the flipside, would-be ulinkers would do wise to avoid any obvious spelling or grammatical errors ripe for post-press editing.

USER COMPATIBILITY

uLinks have been fully tested and found completely compatible with Internet Explorer, Firefox, Opera, and Safari (via iCapture). I'm sure uLink will work with any browser but at the moment I don't have the ability to test that and thus I ain't gonna brag.

USER AWARENESS

You may have noticed in the PHP code that I nested the equivalent of a "YOU ARE HERE" pin in the uLink element, but off the top of my head I can think of a few different methods for drawing the user's attention to the the uLink. This attention-grabber can be anything from subliminal to face-slapping, and with an id assigned to it CSS can swoop in and lend a hand as well. Sky's the limit.

The biggest flaw in the uLink is that it's an invisible function. By nature, its existence on a website isn't apparent. So the question becomes, "How do users even become aware of this?" My best solution for other webmasters is a link comparable to the current RSS link style fad. I mention uLink in the main introduction to this site, but that's because I created it.

THE FUTURE OF ULINK

The first step towards any kind of future for the uLink is a browser plugin to streamline the uLink process. Firstly, such a plugin could detect a site's uLink compatibility, probably through some kind of microformat, and display that information as a small icon that lights up or something fairly unobtrusive. The plugin would provide a context-sensitive menu upon the right click of a highlighted string of text. This plugin could check for HTML tags in the way, false positives elsewhere, and automatically create the uLink. I'm not a programmer by trade, but from what I do know this seems like a very simple plugin to write. I probably could, but that would require widespread adoption of the uLink to make such a plugin worthwhile.

CONCLUSION

Maybe I'm fooling myself and this ain't that useful. Conceptually, I think it's pretty neat. We're essentially adding what should be a feature already built into modern browsers. There should be a feature, given a URL of:

http://sh.illusioned.net/article/ulink_user_defined_link/|To link to this sentence

...where a browser would load the URL and automatically feed everything after the pipe into its Find function, taking the user to the first result immediately. This would wipe out the need for uLink, and named anchors for the most part. ids and named anchors will always have a place, as they're the most reliable means for linking to a specified point in a document. But if a user wants to link to an unspecified point, that's when the uLink swoops in to save the day.