The Clayton’s Web
What’s the single most important feature of any book? You’d be right if you answered: the reader, the human being who reads what’s on the page.
Book = (paper + ink) + (reader)
OK. That question was easy; now let’s try a slightly harder question. What’s the single most important feature of a Web site?
Did you get it? The answer is: the visitor.
Web site = (server hardware + software) + Internet + (visitor)
However, let’s just break that down a bit more. Here’s the reader of the book:
Reader = (eyes + brain)
Here’s the Web site visitor:
Visitor = (client hardware + software) + (eyes + brain)
Visitor = (client hardware + software) + (ears + brain)
Visitor = (client hardware + software) + (fingers + brain)
Visitor = (search engine hardware + software)
The visitor to your Web site will in all cases be some computer-powered hardware and software, such as a cellphone, new or old computer, PDA or search engine, and will often, but not always, have a human being behind it.
That human being will interact with the computer hardware and software in various ways, including receiving output by reading things from a screen or paper, listening to a screen reader, reading Braille, and providing input with any one or more of a pointing device such as a mouse or trackpad, keyboard, or other mechanism.
Once you understand the Visitor, it’s easy to notice that some visitors will see what’s on your Web site, while many will see and interpret only the coding behind it. And that’s why the coding is so important. Which is why Apple’s iWeb is such very disappointing software.
Sound and Fury Signifying Nothing
My experiments with iWeb have produced some quite pretty results. Pages look good, and they are certainly easy to produce. There’s nice integration with iPhoto and so on, and the Inspector makes it easy to change fonts and colors and whatnot. Layout’s a breeze: just drag and drop. iWeb even uses those nifty little guides that pop objects right into a suitable alignment.
Once you’re done, you can press a button or choose a menu command to Publish or Export your files and, heck, they even pass the World Wide Web Consortium’s Validator test. The code is valid—it follows the grammar laid down for Web pages.
But what you’ve created is a pit of seething ugliness, overlaid with the thinnest patina of gorgeous gloss and glitz: proof positive that what’s syntactically correct may still be meaningless. It’s no more than a Hollywood illusion: it looks like the Starship Enterprise, it sounds like the Starship Enterprise, but it sure isn’t capable of lifting off planet Earth, let alone traveling at warp speed.
iWeb Is Not For Web Sites
If all you want to do is create a Web site to show off photos of your dog to your immediate family, and they all have decent computers, decent Internet connections, good eyesight, and are able bodied, then iWeb will do a reasonable job for you.
If you’re a professional of some kind then using iWeb to create a Web site is rather like letting a five-year-old nephew design your brochure, letterhead, and Annual Report.
The problem is not only that the code behind the scenes is a mess, but that iWeb provides no way (that I could find) within the interface, to apply some of the most basic rules for making a Web site. And those rules aren’t just pedantic puffery; they exist for good, practical reasons.
Headings Allow Skim Reading
You’ll see this article is broken up into sections, each with a heading. Headings let the sighted visitor skim through to pick up the gist and zero in on any particularly interesting sections. A blind person using screen reader software can press a key and the software assembles a list of headings so she can skim through and zero in on interesting content. A search engine, such as Google, is like a blind visitor as it doesn’t see the finished page—it looks at the coding, just like a screen reader does. Google thinks headings are pretty important.
Headings Aren’t Big and Bold
Let’s just be clear: making text big and bold doesn’t make a heading on a Web page—it just makes text big and bold. A sighted visitor sees a short stretch of big, bold text with a certain amount of white space around it and leaps to a conclusion that it’s a heading. For software such as a screen reader or a search engine to “see” a heading, the code behind the scenes must specify it’s a heading, by using h tags, like this:
<h2>A fairly important heading</h2>
There’s no way in iWeb to apply a “heading” style to text with h tags—the only option is to make text bigger and bolder, and that isn’t a heading; it just looks like one to some visitors.
When Images Go Walkabout
Even more fundamental than headings is alternate text, also known as alt text. It’s a basic rule of Web coding that when you include an image (and certain other things) you must also put in some text that can replace the image if it goes missing for some reason. There are some comprehensive guidelines about how to choose good alternate text for certain circumstances, but the basic principle is easy: include some text that can replace the picture.
The reason behind this rule is that blind people, search engine software, and those who use equipment that can’t or won’t display images need some words to tell them what they’re missing. Without those words to replace the pictures a Web site can become a nightmare maze of meaningless meanderings. One New Zealand bus company’s Web site invites you to click on the link for timetables in your area. If you can’t see the pictures they’ve used for the area names there is no way to know what to click on. In 2000, the Sydney Olympic Committee failed to provide alternate text for the Web site for the games. They were found guilty of discrimination and fined.
Well, iWeb gives us no way at all to add or edit the alternate text for photos we may include.
Getting Your Hands Dirty
The only way you can possibly add correct headings or alternate text is to go in to the coding itself, outside of iWeb, and using a text editor. If you know how to do that, then you wouldn’t want to wade through the tangled mess iWeb creates. And you’d have to do it over every time you changed something on the page.
iWeb For Fun, But Not For Profit
iWeb’s a fun product. It’s easy to drag and drop text and photos into places on the page. If it had an export-to-PDF function it would probably be pretty good for creating printed materials.
If you have a clearly-defined audience and know their capabilities, if you don’t care about search engines, if you don’t need to consider those on slow connections or who might have any kind of special needs, if you’re creating a small family-type Web site, then iWeb may be fun to play with.
If you are in any way publishing to a wider, largely unknown audience, or have any kind of even slightly professional texture to your site, then iWeb is most definitely not for you. The software doesn’t just create extremely poor coding, but it prevents you from implementing some of the most fundamental principles of an acceptable Web site.
It’s not like the notions of headings or alternate text are in some way new—they’ve been there in the rules of HTML since the beginning. As a Web designer and Mac user I feel so disappointed in Apple. This software is gorgeous, and shallow. It’s likely to set back what we’re trying to achieve with the modern Web: access for all to fun, information, people, and community.
The Clayton’s Web
In New Zealand in the 1980s there was a lot of concern about drinking and driving. A company produced a non-alcoholic beverage called Clayton’s that resembled Scotch. There was a big advertising campaign that backfired: “Clayton’s—the drink you have when you’re not having a drink.” Clayton’s came to be a catchphrase for something that wasn’t what it purported to be, a sham, a fake.
The real Web is a realm of freely available information: the coding behind the scenes caters to all equipment, all visitors. The Clayton’s Web looks good, maybe even looks fantastic, but in fact it’s a sham, a disappointment.
iWeb: it’s the Web software you don’t use when you’re making the Web.
- Web Accessibility, Part 1, ATPM 10.01, January 2004.
- Putting Curb Cuts and Wider Doors on the Internet: Toward Web Site Accessibility, ATPM 8.11, November 2002.
Also in This Series
- What Browsers Can Do, Part 2 · May 2007
- What Browsers Can Do · April 2007
- The Flip Side of the Coin · March 2007
- SeaMonkey 1.0.6 · December 2006
- PageSpinner 4.6.3: Quirky and Erratic · November 2006
- Nvu: Impressive and Powerful · October 2006
- RapidWeaver: A Useful Tool in Need of Sharpening · September 2006
- Sandvox: Sand in the Eyes · August 2006
- The Clayton’s Web · July 2006
- Complete Archive