Confusing Sites, Bewildering Labels
Behold the CSS2 specification as presented by the W3C [3.11]. CSS2 is a powerful standard presentation language created to facilitate the needs of designers, but you wouldn't know it from gazing at this page. It's about as uninspiring a presentation as you've seen since your Uncle Carl showed you the personal site he threw together one afternoon using Microsoft FrontPage and a $50 image editor.
none 3.11 The CSS 2 specification per W3C (www.w3.org/TR/REC-CSS2/): An inspiring presentation language whose presentation here is anything but.
Ignoring a gnawing feeling of dread, you attempt to read and comprehend the spec in spite of its unappealing appearance. After all, the W3C is made up of scientists, not graphic designers. All that matters are the words, right? Twenty minutes into your reading experience, cross-eyed and weeping, you surf to an online computer store and buy Macromedia Flash.
To be fair, not only is the W3C not in the business of graphic design, usability consulting, or information architecture, but it's also not in the business of writing designer-friendly tutorials. The W3C site is a series of accurate technical documents created by leading thinkers and expert technologists—and that's all it was ever supposed to be.
In "How to Read W3C Specs" (www.alistapart.com/stories/readspec/), O'Reilly author and WaSP steering committee member (and one of this book's technical editors) J. David Eisenberg explains it this way: "When you seek answers, you're looking for a user manual or user reference guide; you want to use the technology. That's not the purpose of a W3C specification. The purpose of a 'spec' is to tell programmers who will implement the technology, what features it must have, and how they are to be implemented. It's the difference between the owner's manual for your car and the repair manuals."
By definition, the W3C speaks to engineers, not the public. It's not trying to explain or sell the standards it creates. As noted earlier, it doesn't even call them "standards," although that's what they are. (Actually, in recent press materials and on parts of the W3C site, the Consortium has begun using the "s" word instead of the more passive "recommendations." This is a good thing.)
Unlike a corporation, the W3C is not reimbursed for its efforts when you use a web standard, and it discourages its member companies from patenting (http://www.w3.org/TR/2002/WD-patent-policy-20021114/) or charging royalties for web standards or components thereof.
Academics Versus Economics
Detached from the dog-eat-dog, dog-buys-other-dog's-company-only-to-put-it-out-of-business world, the W3C inhabits a contemplative space where it can focus on the web's potential instead of its competitive pressures. W3C activities are of geeks, by geeks, and for geeks, and its site reflects the group's emphasis on science over style or consumer-friendly ease of use.
The trouble is, designers, developers, and site owners care greatly about style and care even more about consumer-friendly ease of use. On their own sites, they would never intentionally publish difficult, arcane text that confuses readers; never willfully stick their most important content in out-of-the-way places; and never deliberately present their content in an unaesthetic, non-branded setting that encourages visitors to click the Back button.
Psychologically, people who care about branding, aesthetics, clarity, and ease of use and who spend their day struggling to bring these attributes to their own web projects are unlikely to believe that an amateurish-looking site filled with arcane technical documents holds the key to their future. So what do these people trust? They trust slick presentations from corporate giants.
Consortia Suggest, Companies Sell
In the West, when we face a business or creative problem, we tackle it by opening a software application, and we look to market-leading corporations to deliver the products we need. Site owners check the health of their business by opening Microsoft Excel-formatted spreadsheets. Designers create logos in Adobe Illustrator and animations in Macromedia Flash, and they prepare images and web layouts in Adobe Photoshop. For every problem, there's a software category, for every category, a leader.
Although pioneering web designers and developers learned to create pages in Notepad and SimpleText, many who came later relied on visual editing products (WYSIWYG tools) to handle their authoring chores. As proprietary scripting languages and incompatible Object Models made development ever more complex, products like Macromedia Dreamweaver and Adobe GoLive helped many pros create sites that worked while hiding the underlying complexities. How would you support multiple browsers? Push the right button, and the software would do it for you.
These category-leading visual editors were sophisticated and powerful. But until recently, the code and markup they generated had little to do with web standards. Like developers, Dreamweaver and GoLive wrote browser-specific scripts and nonsemantic markup structures.
Dreamweaver MX and GoLive 6 are far more compliant than previous versions (see "Web Standards and Authoring Tools" in Chapter 4), although they still require developer knowledge. And where do their users turn for knowledge? They turn to the attractive, well-written product sites that serve as online user manuals and foster the development of Dreamweaver and GoLive communities. We'll have more to say about such sites in just a moment.
Product Awareness Versus Standards Awareness
As companies were striving to deliver "push-button easy" solutions to the problems of front-end design, the same thing was happening on the back end and in the middle. Proprietary publishing tools and database products from big brands like IBM, Sun, Lotus, and Microsoft and tough little companies such as Allaire (now part of Macromedia) offered needed functionality at a time when standards like XML and the DOM were still being hammered out in committee.
You don't build your car from scratch. Why build your website that way? Sign here, buy now, and if anything doesn't work, we'll fix it in the next upgrade. To deadline-driven developers, the pitch made sense, for the same reason it had once made sense to treat HTML as a design tool: namely, meeting client needs right now.
Thus, product awareness rather than standards awareness dominated the thinking of many web developers and especially of many web designers. For every designer or developer who checked out W3C specs, there were 10 who got their information from the websites of Netscape, Microsoft, Macromedia [3.12], Adobe [3.13], and other major (and smart) companies.
none 3.12 Like the W3C, Macromedia creates invaluable tools for designers and developers (www.macromedia.com). MacromediawebsitesMacromediaUnlike the W3C, Macromedia sells these tools and works hard to foster engagement with the design community and to speak that community's language on its website.
none 3.13 Like its rival Macromedia, Adobe (www.adobe.com) continually interacts with its users, finding out AdobewebsitesAdobewhat they want most and changing its products accordingly. Also like its rival, Adobe works hard to "speak designers' language" on its website. Contrast this figure with Figures 3.3 and 3.11.
Unlike w3.org, these sites are created to serve consumers (professional designers and developers), to deepen the bond between company and customer, and to enhance the corporate brand. Thus, these sites tend to be well (or at least adequately) designed per corporate branding specs, and their tutorials are written and edited for easy comprehension by a professional audience.
Needless to say, such tutorials emphasize the efficacy of the company's products. When these companies mention web standards, it's likely to be in passing or in connection with claims that their product is more compliant than a competitor's. After all, the goal of such sites is to make you value the product you just bought and be willing to buy next year's upgrade.
In short, many web professionals—designers and developers as well as their clients and employers—know quite a lot about proprietary solutions and quite a bit less about web standards. Nor do many realize, except perhaps tangentially, that aligning themselves exclusively with any single company or product line might lock them into an ever-increasing cycle of expense: from necessary upgrades to costly customization to training, consulting, and beyond. After all, that's simply how business works.
One particular product deserves special mention, and it gets it directly below.