Variety in Web Access is Increasing, Not Decreasing
It's probably tempting for many web publishers to declare that most users are staying fairly current with their browser installation, and that more and more are downloading suites complete with popular plug-ins. Thus, if you design for a fairly recent level of Netscape Navigator and Internet Explorer, using only popular plug-in formats, you won't lose many customers. (Or so goes the reasoning.)
But what about the many new kinds of devices that are coming on stream? Will WebTV handle every format you throw at it? What about the Spectravision browser being installed in many major hotels, or the web kiosks going into some airports?
What about handheld devices, such as the Nokia 9000 cell phone with its 200 character display? Nokia's marketing seems to call for consumers to connect to special-purpose sites that are geared specifically to the limitations of the device. Wouldn't it be far better if every web site could re-gear itself towards the device automatically through format negotiations and smart database-enabled server software? Should the device be useful surfing a few dozen places, or a few million places?
Adapting Content to Meet Client Desires
What your client is capable of handling is one issue. What you want it to handle may be another. For instance, one person I know has a fast PC, sound capabilities, and a 20 inch monitor. Yet he runs special software to filter out banner ads as he surfs the Web.
It's not that he's bothered so much by the real estate the ads consume. It's the animations. Most banner ads exploit animated GIFs in one form or another, and my colleague finds that he cannot read the non-advertisement content on the screen with so much flashing going on.
His PC is capable of handling the ads, and he's even willing to see the ads, but he'd rather see them as static content. There's no browser option he can set that indicates "my preferred presentation for ads is static."
Others may prefer not to see banner ads at all. Carried to an extreme, of course, if banner ads were no longer delivered, wonderful information resources like webreference.com would either have to move to a for-pay model, or they'd wither and die. But David Seuss, CEO of Northern Light, thinks people actually would like to be able to turn banner ads on and off. He notes that when reading a magazine one sometimes explicitly chooses to look at the ads; other times not. He suggests a mechanism allowing the user to say "For the next couple of hours I'm doing some really serious reading. Please turn off the ads altogether." On a later occasion, when you're feeling ad-friendly, turn them back on. Advertisers might actually like such a world, because they'd know the folks downloading ads had affirmed their interest in seeing them.
There are other, subtler, switches a user on the Web might like to set:
- Please don't use sounds just for background purposes. (But do use sounds when I click on the All Things Considered broadcast I missed).
- Please downsample any window dressing graphics when my connection is slow.
A "Java not preferred" and "No unnnecessary noise" option would require explicit switches and negotiation mechanisms. Adapting to slow connections could be accomplished today with no extensions required at all; a Web server could simply measure how long the HTTP session is requiring to send a page, and take into account the end-to-end speed (thus accounting for congestion as well as link speeds). That LL Bean page takes 28 seconds to download over a dialup modem; do I really want to see a picture of cross country skiers, or maybe do I just want to make my purchase of lined jeans?
But these sorts of adaptations would require a more fundamental adaptation: the web design community would have to let go of its collective "we know what formats you should use" attitude, and adopt an ethic that says the user's needs and desires are more important than those of the Web developer.
In fact, the W3 Consortium has been hard at work providing tools to empower web site
designers to build adaptable sites. HTML 4.0 and XML promise to move us towards
the world that HTML's roots in SGML promised, where markup concentrates on
logical elements, and where presentation can be adapted easily. We'll explore
possible solutions in more detail in a future column.
What do you make of all this?
Will the web community build the tools necessary to support all consumers
no matter what appliance they use, no matter what link speed? Or will
the Web continue to splinter across incompatible formats and access methods?