User Interface Engineering

• Home
• About Us
• Events
• Services
• Research Articles
• UIE Reports
• Cart

Lately, it seems like everyone is talking about migrating to web standards, like XHTML and Cascading Style Sheets (CSS). What's the big deal about these standards? Why should web teams invest the effort to learn new coding techniques and convert all their legacy sites over to standards-compliant sites?

Time and Money, that's why.

Let's say you want to change the colors or rearrange the layout for a site built with templates that use a table-based design. "It's a nightmare," says Eric A. Meyer, author of the books, Cascading Style Sheets: The Definitive Guide and Eric Meyer on CSS. "It can take days just to finish. With a standards-designed site, you have simple markup and centralized CSS, and changing the colors and even the layout can be a matter of an hour's work." Eric says that no matter whom you pay to do the updating on the website, be it an in-house admin or an expensive consultant, the additional time it takes to make these changes will cost you money. The time required to update a CSS-driven site is a tiny fraction of that required for a table-based site.

Molly E. Holzschlag, author of Special Edition Using HTML and XHTML, agrees. "Early case studies suggest that compliance probably saves money for everyone in the web site food chain - from site owner to developer to ISP. Those are the immediate advantages. Longer term, working with standards addresses many technical, creative, and even social concerns. Technically, web sites will be more easily maintained and readily available for many platforms beyond the web. Creatively, we can apply style sheets that will easily make a site look good on a computer screen, on a PDA screen, even in print. Socially, we remove barriers to access by cleaning up our hacked markup and paying attention to accessibility concerns."

One of the best things about the standards is the features that support accessibility concerns. For instance, CSS provides for a set of properties that support voice-synthesizer devices, frequently used by vision-impaired users. With simple coding techniques, designers can switch between styles to support the broadest ranges of users.

Once a web team has decided that they are ready for standards, they need to know when they should start making the move. "The best time is now, and not a moment later," according to Eric. "If you don't know the first thing about the topic, then start learning. If you're familiar with the subject, then start planning for a conversion. If you already have a plan, then launch it as soon as is feasible."

Eric says that building websites using old standards is like "putting a steam engine in an automobile. The technology was great for the day, but the state-of-the-art has moved on."

Molly is careful to stress the long-term benefits of switching to standards. "Learning web standards on a professional level is a commitment that will take effort now and require years of study to maintain and grow. Being a web designer or developer is no longer novel. We have very complex jobs to do and standards are a means of doing that job with maturity and excellence. When your team has a good overall understanding of and long-term commitment to standards, that's when you can consider a switch."

After web teams convince themselves, their clients, and their management that they should switch to standards, they need a plan. Both Molly and Eric recommend integrating standards gradually. They suggest starting at a redesign point or when you're building a new web site. That way, the pain of change or additional learning is partly expected, and the change able to be folded into the expected budget.

What about all the content that's already out there? Should you plan to convert it right away? "Not necessarily," says Molly, who has been here before. "If the cost to make all legacy documents compliant is prohibitive, then begin to move forward from this point using standards. If, at some point in the future, you can address the legacy concerns, do so then." There's no rule that says that the site has to be 100% standards-compliant on the first day.

As for techniques to help you switch, Molly suggests teams put together a style guide for new coding practices and content, such as corporate logos and colors. "Add sections for specific clients where necessary. Research and try out development tools, such as very highly flexible and affordable content management systems and visual editors that are standards-savvy. Study your browsers-this may be the toughest part, because the platform and versioning differences are vast." She also suggests checking out standards validators, such as Dave Raggett's HTML-Tidy, the World Wide Web Consortium (W3C) validators, and accessibility validators like Bobby.

Eric suggests an approach that he calls a support matrix. Teams should identify different levels of user experience, and what needs drive each one. "For example, the top matrix level could be the bells-and-whistles site with flyout menus and juggling bears and everything. Then next level down is the same site, but without the flyout menus and such; it's still navigable and useful, but it doesn't have all the frosting. And so on. Then you determine what level of standards support is necessary for each level, and go from there."

Even with a lot of enthusiasm for standards, developing for them can still involve a steep learning curve. You can avoid some common pitfalls. Eric says a common problem occurs when teams have unreasonable expectations. Web standards are not a cure all, and won't make all problems go away. Some browsers have better support than others do. He notes, "I see lots of teams run aground on nitpicky details that aren't quite consistent between browsers, and that's a shame. There are much bigger fish to fry than whether or not the page title has 10 or 14 pixels of space under it. Remember the whole forest, and that standards offer you the best path through it."

Molly urges teams to continue doing those things that have worked in the past, like a solid client needs analysis. It's important to know if your users have different needs that you must address in your choice of supported browsers and standards. For example, you might still have to code for 4.0 browsers because your users are on an intranet where the technology support hasn't yet upgraded. Molly promises, though, that most problems are solvable following standards. "It just takes an understanding of the standards," she maintains, "to know how they can be applied to each problem."

Because standards are always growing and changing, Molly is a big advocate of standards education. Teams must continue to learn about evolving standards, so they can implement effective plans for the future. She suggests going right to the source, the W3C. However, Molly warns that "much of the W3C's material is very complex and exhausting for the busy web professional to go through. The Web Standards Project (WaSP) is an excellent place to get information. They're providing an early but growing resource for learning more about standards." Molly also says book publishers New Riders and glasshaus are "paying sincere attention to these concerns". Eric agrees, adding O'Reilly as a publisher. He also points to newsgroups and mailing lists as a valuable resource because "no book or specification will cover every question you might have."

The acronym-filled world of standards can be frightening, if you let it. However, the promise of saving time and money, while making everyone's job easier in the long run makes it worth investigating. •

©1997-2006, User Interface Engineering.
510 Turnpike St., Suite 102, North Andover, MA 01845
800-588-9855 (within U.S. and Canada) or 978 327-5561

Questions or Comments? Talk to Us.