The Forgettable Mister Ruthsarian

Web Of Information: Prologue

I'm rewriting this post.

That probably violates some unwritten blog rule... but for the purposes of what I want to accomplish here, I need some continuity between these posts. Besides, nobody has commented on anything I wrote in the previous version of this, so maybe it doesn't matter.

This started with a conversation among co-workers about some users we support in the development of their web pages. We see a lot of people who want to use lots of color, several different font types, animated images, background music, and a whole host of other, seemingly needless "enhancements".

Why are people doing this? We aren't telling them to do this. We simply provide basic training with a WYSIWYG web page editor. Perhaps the problem is that we aren't telling what they should not do.

I made a comment along the lines that people ought to stick to very basic web pages; they need to learn less is more. Just headings, lists, tables and paragraphs, and that's it. I pointed out that we need to teach people why simple designs are better designs and we need to provide reasons why this is true. So I started to think of some reasons. From there, the idea began to snowball into something a bit bigger.

There are few very good reasons why simple is better. The problem is that the why for each reason is a bit complex, and nobody has to listen to them. I can tell you that strong should be used rather than b because strong provides meaning beyond how the information it contains should be visually represented. But who cares? Why should you care? B gets the job done; it makes text turn bold. I have to make the argument that you need to think about information contained in HTML documents beyond their visual representation. But information on the web (within an HTML document) is probably processed by users in a visual manner 99% of the time it is accessed. Why should you care beyond the visual representation of your HTML documents? I hear it a lot with my work in CSS. "Why create CSS-based layouts when tables will get the job done and in a far easier, more compatible way?" It's obvious, practical logic.

It's a tough argument to make. I think the "obvious, practical" approach is a self-sustaining argument. I think that by focusing on the visual presentation of web pages people have become trained to think of the web only in visual terms. The idea that HTML documents (should) contain structured information, which can be processed, shaped, and changed into new forms for whatever purpose a user may have, and the benefits of that, is lost on a lot of people. So the need to create HTML documents that have good informational structure, rather than visual structure, isn't very big. Without such a base of documents to work upon, the need for applications that process information on the web in a non-visual manner is not very big. Search engines are an example of an application that processes HTML documents outside of a visual means. They're pretty powerful little tools too. But they work around poorly structured HTML documents - because that's the nature of what's out there on the web. There really isn't any reason or motivation for web developers to stop the "obvious, practical" approach; and so it will continue to be the accepted method for developing web pages.

What I want to try and do over my next few posts is to try and convince readers why "obvious, practical logic" needs to be changed. Why you should care about the informational structure of your document. Why visual information, henceforth referred to as "presentation logic", absolutely does not belong in HTML documents; that's what CSS is for. And to open your mind to the possibilities and power of "simple" documents.

By now you should see that when I say "simple" web pages, I'm talking about HTML documents void of any embedded presentation logic. "Simple" is not the right word. When training users new to web development, they see documents without any color or snappy layout as being "simple" or "plain". From a visual sense, they are correct. And since I'm targeting a visually-oriented user base, I might as well provide some means to connect the new approach I want to talk about with the old one.

I'm not entirely sure this post is any more clear than my original.

At some point I need to just move along.