This chapter is from the book
This chapter is from the book
This chapter is from the book
Confusing Sites, Bewildering Labels
Behold the CSS2 specification as presented by the W3C [3.12]. CSS2 is a powerful presentation language created to facilitate the needs of designers, but you wouldn't know it from gazing at this page. It's about as inspiring as Fashion Week in the old Soviet Union.
)
3.12 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 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/articles/readspec), O'Reilly author 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.
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 (www.w3.org/Consortium/Patent-Policy-20040205) 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, nonbranded 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 big corporations. (Hey, that rhymes.)
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 Adobe (formerly 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 (probably Adobe).
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 web design ever more complex, products like Dreamweaver and 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.
Today GoLive and especially Dreamweaver 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 like Allaire (later part of Macromedia, which is now part of Adobe) 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.13], Adobe [3.14], and other major (and smart) companies.
)
3.13 Like the W3C, Macromedia created invaluable tools for designers. Unlike the W3C, Macromedia sold these tools and worked hard to foster engagement with the design community and to speak that community's language on its website. In 2005, Macromedia was absorbed by its former arch-rival, Adobe.
)
3.14 Adobe (www.adobe.com) continually interacts with its users, finding out what they want most and changing its products accordingly. Like the rival it consumed, Adobe works hard to "speak designers' language" on its website. Contrast this figure with Figures 3.4 and 3.12.
){kind=link}
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 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 eager 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.