Home Page Commentary 24 Mar 1999

Comment of the Fortnight
24 March 1999
Odds and Ends

On the 14 March issue of ABC Evening News, I saw a very wonderful feature about a Y2K problem that doesn't involve computers at all. Apparently, some people have pre-bought cemetery plots with headstones reading like so:

Joe Schmegeggie 1926 - 19

Speaking of deaths, it's with some sadness that I read of the passing of Gershon Legman, who died in France at the age of 81. Mr. Legman was a scholar who collected and analyzed dirty jokes; his book "Rationale of the Dirty Joke" (now sadly out of print) is simply a masterpiece.

A Bicycle Update

The new bicycle is performing nicely; I've set the gears so that it pedals like the one-speed, and I'm happy with that.

Unsettling Thought

Recently, I heard a disco version of Gordon Lightfoot's song, If You Could Read My Mind. It sounded fairly good, actually, although it's not the kind of song I'd associate with a disco beat. I sure hope nobody tries to do a disco version of The Wreck of the Edmund Fitzgerald.

This section is written for people who are not familiar with HTML and how web pages are written. If you know a lot about HTML already, please bear with me.

Web pages consist of text with embedded commands (called tags) that tell the browser how to display the text and where to find images. For example, to make the word tags here boldface, I wrote this text:

...the word <b>tags</b> here...

The <b> is a tag, or command to the browser, telling it to "turn on boldface," and the </b> is a command telling the browser "turn off boldface." Once you know what the tags are and what they do, you can put them into your content, and voilà, you have a web page!

As Jeffrey Zeldman points out in his "Ask Dr. Web" area, all you need is a plain old text editor to get started. On a Macintosh you can use SimpleText; on Linux, there's the vi editor, and on a PC you can use Notepad. While it's the simplest way to go, it also involves the most typing.

At the next level up are programs such as BBEdit on the Macintosh and HomeSite on the PC. These are "editors on steroids," with extra menu options that ease your workload. (For example, in Homesite, you can simply drag the mouse across the word "tag" and click a button marked with a B and the <b> and </b> tags are inserted before and after the word for you.

For those who are put off by the idea of learning tags, or who need to create a lot of pages and don't have time to learn the tags, there are WYSIWYG (What You See Is What You Get) editors. They present you with a blank canvas upon which you can write text as if in a word processor, drag it around, and place your pictures. It's a lot like a page layout program. When you're done, you click a button, and the program creates the HTML for you behind the scenes. (Although you do have the option of looking at it later on and editing it directly.) Examples of this are Macromedia DreamWeaver, Adobe Page Mill, and Microsoft ©®^TM FrontPage.

Although these editors save you a lot of time, they don't always generate HTML as good as that of the best human writers. (Of course, how many "best human writers" do you have working for you?) Also, if you do enter some of your own HTML, some of the WYSIWYG editors will rearrange it for you, sometimes creating stunning, but unwanted, visual effects. FrontPage is especially bad in this area, as it has been designed with the attitude of "I know how to write HTML better than you do. Your code is always wrong. I'll fix it for you." DreamWeaver is the best, leaving your added HTML totally untouched.

The advantage of these WYSIWYG editors is that they free you from having to learn about HTML. The problem with these editors is that they free you from having to learn about HTML and how the web works, and what you don't know can hurt you!

Let me give you an example of how a beginner, ignorant of HTML and using one of these WYSIWYG editors, created a monster. I got an email recently from a gentleman whom I'll call "Paul." Paul asked me to link to his web page. Since his page was relevant to one of the topics on my site, I decided to add the link, after first taking a look at his site.

His page was a simple affair; a bit of explanatory text accompanied by about nine pictures. Two of them were about ¹/₃ the size of the screen; the rest were "thumbnail" pictures of people who were working with Paul on his project. Yet this simple page took over six minutes to download on my modem at home running at 28.8K baud -- and it was over a megabyte of data! How could this be?

I looked at the HTML and saw that Paul had used a WYSIWYG editor to create his page (since most of these editors put a "Created by <name-of-editor>" message in the HTML so that you know who the guilty party is).

I saw tags that looked like this:

<img src="fred.gif" width="50" height="70">

What this tag says to the browser is: "Find an image named fred.gif. Put it on the screen, and make it fit an area that is 50 dots wide and 70 dots tall."

I took a look at the picture of Fred, and it was actually 300 dots wide and 420 dots tall, and it took up 100K bytes of disk space.

Paul was missing two pieces of information: First, pictures can be stored in two different formats for the web. One of them, called GIF (short for Graphics Interchange Format) is best for "line art" or drawings with only a few colors and large areas of a single color, like a company logo. The other one, called JPG (short for Joint Photographic Expert Group) is best for photographic images. The reason the picture of Fred took up so much room on disk was that it was being stored in the wrong format.

The other part of the problem is this: when you tell the browser what width and height to use to display an image, it will reserve that much room on the screen. It will then download the whole original picture (which was 300 by 420), and then scoonch it down to fit into the 50 by 70 area. Even though you see it at the small size, all 50K bytes -- and, in Paul's case of using the wrong format -- 100K bytes have to be transmitted from the server to your browser before it can reisze the picture to fit into the small area.

Why didn't Paul know this? Because his WYSIWYG editor hid this crucial information from him. It just let him drag a picture onto the canvas and shrink it down to fit without giving him advance notice that this may not be the best thing to do. In all fairness, it couldn't have given such a warning -- no editor can cover all the bases.

How come Paul didn't notice how big the page was when he built it and tested it? This problem would have occurred no matter what kind of editor Paul had used. When he tested his page from the hard disk, the pictures loaded in at hard disk speed, so it didn't really matter how large they were. Paul works at a university, so when he sent his files to the server, they went across a high-speed connection and he didn't notice how large they were. When he tested it, again on the high-speed connection, the download time wasn't a factor. Once he had tested it, the pictures were in the browser's cache (see definition), so he never saw the delay again.

Thus, Paul was totally unaware that he had created a web page that staggered across the web like a wounded bull elephant, using up immense amounts of disk space and download time.

The moral of the story:
If you're going to design web pages, it pays to spend a little time learning how they work behind the scenes. Tips and techniques for improving your HTML are widely available on the web. I also highly recommend HTML 4 for the World Wide Web: Visual QuickStart Guide as an introductory text. Spend a few hours learning a few basic HTML tags. Write at least one or two simple web pages from scratch. Then, when you use the WYSIWYG editor to create your website you'll be in a position to work with it rather than being forced to accept whatever it gives you.

By the way -- this story does have a happy ending. It was easy to fix Paul's web page. First, I used a picture editing program (on a PC, I use PaintShop Pro, on a Macintosh, Adobe Photoshop, and on Linux, the GIMP) to change all the GIF files to JPG format. This reduced their disk space usage by about 50%. Then, I reduced the picture of Fred to 50 dots wide by 70 dots high in the picture editing program, and saved it with the name fred2.jpg. This file was now only about 20K bytes rather than 100K bytes. Then I changed the tag in the HTML page to:

<img src="fred2.jpg" width="50" height="70">

Modifying all the pictures and the HTML took a grand total of twenty minutes, and the end result was a total disk space usage of only 144K bytes instead of a megabyte.

Back to top of page