Son of Web Pages That Suck

Chapter 4
Design Issues Even Martians Should Know

Home  Page 1   Page 2  Page 3  Page 4   Page 5  Page 6

BrowserCam

I had a whole section on coding for different browsers that has become irrelevant because of a product called BrowserCam. As it says on their site:

BrowserCam's Screen Capture Service lets you submit multiple URL's, choose the browsers and operating systems you want to see, and in about a minute returns screen captures of your webpage loaded in the different browsers and operating systems you selected.

I'm upset that BrowserCam came out after I spent a lot of money on a Macintosh — a lot of money. Check out their web site.

Connection Speed—If the Bits Don’t Flow, People Will Go

As you’ll discover in Chapter 10 “Grrraphics,” many sites don’t optimize their graphics to make the pages load faster. Optimizing the file size of your graphics is probably the most important thing you can do to help your page load faster. Why is that important? Zona Research estimates that fat Web pages—any pages that take longer than 8 seconds to download at 56K—cost businesses a lot of money: $362 million in 2000.

If you’re looking for more articles than you ever imagined existed on the topic of testing your Web site for speed and responsiveness, go to Keynote.

With apologies to the late Johnny Cochran, I like to say, “If the bits don’t flow, people will go.” Quickly loading Web sites are important because:

• As we learned last chapter, visitors want their problems solved now!
• Most people are not connecting to the Internet with high-speed modems.
• More and more international users are accessing the Web, and many don’t have high-speed connections.
• Just as the thin, athletic guy steals the girl from the fat guy, sites that load quickly will steal customers away from their bloated competitors.
• Sites that load quickly and conform to standards are easier to maintain and change, and they eat up less bandwidth—saving your company money.

Too many of us forget that when we design a site and then load it into our browser, it’s coming directly from our hard disk. We also forget that even when we test a live site, we probably are connecting to the Internet via a T1, cable modem, or DSL, which isn’t the best measure of real-world speed. How can we get an accurate representation of what people will see when they dial up using real-world equipment?

The obvious solution is to get a dial-up connection. But if you can’t justify the time and expense, there’s an easier way. Macromedia’s Dreamweaver tool—or just about any decent Web editor—will tell you the weight of the page. For example, when I see this display at the bottom of my screen:

it means Dreamweaver is telling me that the page is 236KB in size and will take 34 seconds to load at 56Kbs (the setting I chose). What’s nice about Dreamweaver is that you can set the speed of the connection to 14.4, 28.8, 33.6, 56, 65, 128, and 1500 kilobits per second—or you can type in another speed and see how long the page will take to load. I find the only problem is that this information resides down at the status bar, where it is easy to ignore.

Note: The rest of the chapter is about a product I no longer use.