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.
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.
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.
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.
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.