Linking the proper way

Admittedly this blog entry might just be seen as another rant but this is meant to be constructive so, hopefully that’s how you’ll see it.

I constantly see people put links in their web pages on words like “here”, “there”, or “this”. It is the wrong way to link to other pages.

For instance, it is wrong to write:

Arnaud posted a blog entry on linking the proper way here.

Although the link does function all right and will achieve the desired effect it violates the basic principle of hypertext linking the web is built on. Indeed, this principle is that the link needs to be placed on the object the page being referenced relates to.

In the above example, clearly the page the link points to is not about “here”. So, instead, you should simply write something like:

Arnaud posted a blog entry on linking the proper way.

In this case the link is set on “linking the proper way” which properly describes what the page being referenced is about.

Alternatively you could do the following:

Arnaud posted a blog entry on linking the proper way.

It is still correct because “a blog entry on linking the proper way” also properly describes what the page is about.

Sometimes, it takes a little effort to get it right. Instead of writing something like:

For more information look at this.

You’ll need to write something like:

For more information look at hyperlinks.

But the extra effort, quite minimal I’d point out, is not wasted. It is not only correct it is also much more informative. It actually provides the reader with a clue of what the linked page is about.

And if that wasn’t enough, linking the proper way has other advantages than informing the reader about what the link is about. The relationship thus established can also be used by search engines in determining what keywords might be relevant to the linked page. It is rather useless for a page to be associated with the word “here”. On the other hand, a search engine might make use of the fact that it is associated with the word “hyperlinks”.

Now, I know that it’s been found that using direct and simple instructions is more effective with some users. That’s what leads to the infamous and omnipresent “click here” but while I’m willing to accept that argument for commercial websites I can’t accept it for other type of content.

I think the reality is that lack of understanding and laziness are responsible for most of the errors made in this regard. Hopefully, this post will help with the former. As for the latter, it’s all up to you but, now that you’ve read this you won’t be able to claim you didn’t know. 😉

Paradigm shifts and tug wars over the web – Part 2/2

In the first part of this discussion I focused on the shift that occurred around who controls the rendering of a page. I will now discuss how control of the user interaction shifted from the user to the page author/developer.

Web pages initially contained no information about how the user would interact with the page or the web browser would behave. It’s by using functions supported by the browser that a user would move back to a previous page, print a page, open a page in a new window, etc. The user was therefore in full control of the interaction.

This simple paradigm was however first challenged with the introduction of the infamous frames and link targets in HTML. These mechanisms let the web author control how the browser should behave when the user clicks on a link. Aside from making it impossible to reliably bookmark a page, this marked an important departure from the original concept of having the user in control.

Yet this was just the beginning, and was nothing compared to what is now done with all the websites full of javascript which make the so called “Web 2.0“.

With javascript, web pages no longer just contain some content to be displayed along with some layout information but they are in effect programs that want to dictate how the browser should behave and how the user should interact with them. And that’s where the problems creep in.

In reality we end up with two separate entities trying to control the same thing. The web author on one end and the user with the browser on the other. Both trying to control how to manipulate and interact with the same information. It’s no wonder there is a clash.

This can take some rather benign forms like the close button I often see on some web pages. I always wonder: who needs that? Why isn’t the close button in the corner of the window enough? I use neither anyway, favoring a quick Alt-F4, but admittedly other than a bit of wasted real estate on the page it doesn’t really hurt.

Equally useless is the print button I often see on web pages. Some websites use that to render the page differently, it’s not truly necessary with proper use of stylesheets but at least it does something useful. More often than not it does nothing different than the print command of my browser though. But, again, it doesn’t really hurt.

What really hurts is when it interferes with other aspects of the basic browser functions like the navigation history or whether the new page should be rendered in a new window or not. The reality is that in the vast majority of cases this is only done for bad reasons – or at least for reasons that serve the web author rather than the web user.

These reasons include: the authors don’t want you to move off their site, they want to force some information onto you (remember those lovely pop-up ads?), they think they know what’s best for you or that you don’t know how to use your browser, etc.

The list of bad web programing practices hidden behind all this is endless. How many times do you see websites that urge you not to use the back button or reload the page, informing you that doing so may lead to multiple charges on your credit card? This one has typically nothing to do with javascript but more with the fact that they didn’t program their state machine well enough to support you going back and forth between pages, or reload them.

In fact, most of this only exists because websites are poorly designed, there are mechanisms to ensure the browser history gets updated so that the back button works for instance but, fundamentally it remains that there is a clash between two different paradigms that are both at play: 1) the user is in control, 2) the web author is in control.

Users have control via their browser, authors have control via the javascript and other techniques they stuff their pages with.

While I enjoy many of the benefits modern websites bring, as a user, I regret the loss of control that often seems to come with them. I hope that we eventually reconcile the two forces at play, and authors/developers get better at designing their websites so that users can get the advantages of modern websites without losing basic functionality and control.

Paradigm shifts and tug wars over the web – Part 1/2

I posted a rant on the fact that many modern websites break some basic browser functionality but as I did so it occurred to me that I should take the time to discuss the paradigm shift that is behind that simple fact.

Indeed, beyond the fact that the back button of my browser is rendered unreliable by some websites, lies a major shift, a kind of tug war between web users, armed with their browser, and web authors/developers, armed with the latest techniques in websites development. This shift or tug war is about how the web fundamentally works and whether the consumer or the content provider has control.

In fact, we’ve already seen several paradigm shifts in how the web works. First, there was a shift in how a web page gets displayed. Then there was a shift in how one interacts with the page. The latter is now intensified by the introduction of the latest web technology.

As I was about to post this entry I realized it was getting really long so to make it more digestible I decided to split in two parts. In this first part I discuss the first shift which is about who controls how a web page is to be displayed. In the second part I will discuss the second shift which is about who controls the interaction with the web page or how the browser behaves.

When Tim Berners-Lee created the web his idea clearly was that what was important was to enable the exchange of information.  How exactly the information would end up being rendered didn’t matter that much.

For this reason the early versions of HTML were very much designed to carry structure and meaning rather than precise rendering. The HTML specification, for instance, doesn’t specify what font a heading should be rendered in. It just has a general notion of different levels of headings (H1, H2, H3, etc.) and it relies on the browser to choose appropriate fonts to represent the different levels in a reasonable way.

When the web picked up and commercial enterprises started developing websites this paradigm quickly flew out the window though. Marketing departments, typically in charge of developing websites and used to developed glossy brochures and the likes, wanted precise control of how their website would appear to the user and tolerated no variations.

This is what brought us the lovely early websites full of tables filled with one pixel wide images that failed to render properly on any screens other than those that had the exact resolution they happened to be designed for.

Thankfully, people learned, and with the introduction of stylesheets and the array of devices in use the situation has greatly improved on that front.

This was also helped by the fact that there is a limit in how much authors can force users to look at their information the way they want because some people just can’t. Accessibility issues indeed come into play, and they mean that, at least to a certain degree, the browser must provide users with a way to override the desires of the web author. This can be to render the text with enough contrast or in a font big enough for instance.

Nevertheless, it remains that the initial paradigm of “I don’t really care how exactly my page gets rendered” seems to be gone for good. For better or for worse.

Read on the second shift in Paradigm shifts and tug wars over the web part 2.

Giving me back my back button!

It is somewhat unfortunate that I start the year on my blog by posting a rant but here I go anyway.

I’m getting tired of all the websites that make the “back button” of my browser useless.

And when I say “button” I really just mean “back function”, because I actually seldom use the mouse and favor key strokes in many cases. So, in reality I typically hit the “page back” button on my keyboard or Alt-left arrow key when I’m on a keyboard that doesn’t have that key.

But that doesn’t really matter, whichever way I actually do it, I expect this action to get me back to the page I was previously on, just before I followed some link that led me to the page I’m looking at now.

Unfortunately, more often than not nowadays this action leads me to the wrong page. That is I typically land on some page I visited before but not the previous one. This obviously makes using the back function of my browser useless.

Sadly this problem seems to be a common characteristic of modern websites, such as Facebook or Picasa just to name a couple, that provide their own navigation mechanism which screws up the history the browser relies on for its back function.

Every time I mention that to my friend Andy who writes javascript for a living he says: “ah, yes, keeping the history straight is tough.” Well, I don’t care whether this is tough or not, website developers need to understand that this is something they need to worry about and get right.