An Interview With Douglas Bowman of Wired News

One of the Web's oldest news sites, Wired News draws between 20 and 25 million page views every month. On October 11, 2002, Wired launched a brand-new site design that uses validating XHTML for its structure and a small collection of CSS files for its layout. The new design clearly shows what some experts have been saying: that standards-based design can be visually compelling and preserve the interface conventions we've come to expect from Web pages.

The brains and primary driving force behind this compelling new design is Douglas Bowman, Network Design Manager for Terra Lycos, who graciously agreed to an interview and in the process shed a lot of light on what goes into a standards-based redesign.

Wired News Redesign in a Nutshell

• Driven by XHTML 1.0 Transitional and CSS;
• Allows centralized control over layout and appearance for thousands of pages;
• Simple markup allows for rapid changes to templates;
• Average page weight dropped by almost half;
• Page layout accomplished with simple CSS positioning;
• Vastly increased accessibility without special coding or user agent detection.

Why did you pursue a standards-based redesign of Wired News?

As Network Design Manager at Lycos for the last two years, I've been creating and documenting design standards for our network of sites. This includes rules and guidelines applying to everything from headers, footers, page hierarchy, titles, typography, iconography, navigation, and others. So I'm very familiar with standards and the benefits of using them. With the Wired News design process, the scenario was reversed. As I was designing the product, I began discovering a broader set of Web standards, and was quickly swayed by the advantages I could see if we were to adopt them.

It was a no-brainer to us that Wired News was a perfect candidate for the total conversion to XHTML and CSS. The content of the site tells the story of how technology affects our daily lives, especially in the realms of business, culture, and politics. Why not attempt to use technology standards for the Web to live out that story? The visual design of Wired News and the Vignette templates were all sorely stale, and we had no significant effort invested into either for more than two years. I think that fact played a critical role in our team's willingness to try out something completely new. Our engineering team actually needed the least convincing to convert over to a standards-based design, because they could also immediately envision the benefits to their workload and maintenance of the site.

How is the site styled now that you've ripped out all the HTML-based presentation?

Technically, there are 13 total stylesheets used at any one time. The breakdown:

• 1 master screen media file which imports 4 files:
  • a base file (bulk of formatting)
  • a file for finance/table formatting
  • color file (override colors and background images for specific color scheme)
  • temp file (used for styles associated with temporary features and ad-related pages)
• 1 print media file
• 1 aural media file
• 3 master alternate style sheets which import 1 file each
  • the 3 imported files set alternate font sizes (small, large, larger)

How much did the size of a typical Wired News page shrink?

The HTML went from 32 KB down to 19 KB, but images increased from 8 to 13 KB. We've noted that some of the file size comparison's aren't necessarily fair, because we're not comparing apples to apples-- we're comparing an old design using html, tables, and spacer GIFs to a new design much richer in imagery and style.

What made you decide to drop tables as a layout mechanism? It seems like most designers think that you have to have at least some tables for layout.

I've been manually writing sample code for my own design prototypes for 4 or 5 years now. I used to pride myself in knowing how to reproduce any interface design down to a pixel-perfect level. A developer would tell me something wasn't possible, and I could prove otherwise every time. Like other designers and html whizzes, I became a master at manipulating and troubleshooting tables, nesting them in intricate ways to produce any layout or effect that could be imagined.

I remember one project for Lycos where we had nested tables 10 levels deep. I counted them myself. It wasn't that every level was absolutely necessary to reproduce the intended design effects. But each table ensured the flexibility we needed if certain modules and pieces of content appeared or disappeared. When you get to that point, the amount of markup you have to sift through to find anything becomes ridiculous. Until this redesign, Wired News wasn't even using CSS to style the content inside tables. The sheer amount [sic] of redundant <font> tags inside every cell was probably enough to double file size.

My initial attempts at the markup and CSS for the Wired News design eliminated the majority of our tables, but left one master table to control the primary columns of each page. That approach meant that the content of every column would have to be loaded and calculated before it would be rendered in the browser window. That wasn't good enough. Around that time, I started discovering great sites like glish.com and bluerobot.com. Both presented and documented viable means of producing multi-column layouts without a single table. Despite some initial setbacks with those approaches due to our own unique scenarios, it wasn't long before I discovered a variation of one of their methods that worked for the Wired News design.

By eliminating tables that were strictly used for layout, we significantly cut back on the amount of markup and useless tags in our html, and gained a structure that is much easier to maintain. Now that the content is not locked into a specific table structure, we have much more flexibility in how we present that content. A few changes to the CSS can completely alter the presentation of thousands of pages. As a very welcome side benefit, we also believe the accessibility of Wired News will dramatically improve without the clutter of nested layout tables.

Are you setting up your columns with floats or positioning?

In trying to eliminate that last table I was using to set the column structure of our pages, I took a close look at both floated divs and positioned divs. I went back and forth between each one for two weeks, and finally narrowed in on positioned divs as the choice for Wired News.

Why did you choose positioning over floats?

Floats had a few disadvantages from my perspective. One was the required order of content within generic markup. For Wired News, the center (or main) column usually contains the most important content for each page. I wanted center column content to appear first in browsers that got the un-styled version. With floats, either the left column or the right column always had to be drawn first. For sites that rely on a left or right column for primary navigation, this content order requirement of float usage may produce desired and advantageous behavior.

I also found a lot of trouble ensuring a consistent vertical start position of columns using floats. Two column layouts using floats seemed easy. But adding a third column to the mix created too many width variables for some browsers to dynamically calculate a total. Resizing the browser window often resulted in one column getting pushed to the bottom of another.

Using absolute positioning for left and right columns allowed the markup for each column to fall in any order. There are some technicalities in the order of our markup and some ad units that would require too much to cover here. But positioning did allow the center column to fall first in the markup. It also guarantees each column will start in the same vertical position.

To be fair, I did note two disadvantages of positioning. When one or more columns is positioned absolutely, there is no way to ensure a footer would always appear at the bottom of the longest column. We ended up confining the footer to the width of the center column to avoid any possible overlap. The other disadvantage comes into play at small browser window sizes. While floats automatically reconfigure if they don't fit within the window width, absolute positioned columns always remain in the same place, even if it means content in one column begins to overlap another column. Both of these put together weren't enough to dissuade me from the advantages of positioning over floats.

How does the new design perform when the pages are printed?

We have one CSS file specifically set up to cover most of the content throughout our pages for print media. By default, all links to screen media CSS files are explicitly declared as "screen" media instead of "all" media. By doing this, we don't have to override any of the screen styles, giving us a blank slate to start with for print styles. The print styles present the page content in one column, rather than splitting content up into two or three columns. It also eliminates most of the background colors and images to save on printer ink. Fonts are sized in point (pt) units and use serif faces for improved legibility on a printed page.

Our stories are logically the most printed pages of the site. Technically, with the print media CSS file, we didn't have to generate a separate print template for stories. However, since some of our stories are broken up into 2 or 3 pages, we created a slightly altered template for print versions which pulls the entire text of the story into one (Web) page. Since we had a separate template to work with, we changed the media attribute of the linked print style sheet to "all", and eliminated the links to normal screen media files. This allows us to temporarily display on screen the same formatting to be used for printing that page.

So what advantages does this redesign give you as a site administrator?

You mean besides the fact that as designer, I can control design details on thousands of news pages with just a few files? Besides the fact that the engineers can finally focus on building out the working functionality of the site rather than worrying about appearance or where the next spacer.gif is supposed to go? Besides the five minutes it recently took for one of our developers to rearrange a module when he thought it would take him an hour or two? Besides the idea that we're changing our entire color scheme every day of the week by merely pointing to a different CSS file and altering an image variable? Hmmm. I'm having a tough time thinking of any advantages...

What disadvantages did you encounter?

Honestly, there were several challenges and glitches we ran into along the way. First of all, since Wired News is a heavily ad-supported site, our advertising units were the cause of several important decisions. Our ad-serving partner basically requires that we use iframes to dynamically pull in ads from available inventory. Because of the iframe, we backed off of the idea that we'd be able to adhere to XHTML Strict rules, and settled for using the XHTML Transitional DTD. We were hoping to go all the way with the XHTML conversion, but our ad units and some other third-party content prevent us from doing so.

Our engineers also faced a huge archive of content that wasn't entered into our CMS with XHTML in mind. It's true that our stories exist in a database, separated from page templates and peripheral formatting. But writers, editors, and producers have been inserting stories into Vignette for years sans closing paragraph (</p>) tags. Unquoted attributes and uppercase html tags? We've got them in spades, and they're embedded in all past stories of the database. Fortunately, our chief engineer was able to write some code that scraped through the database looking for errors like this which would invalidate our markup. We don't make any claims about past archived content, but we've taken many efforts to make sure even stories from a few years ago are as valid as possible.

While conversion to XHTML and CSS definitely shaved off development time that would have normally been spent manipulating the code, it didn't come entirely easy or without cost. Our engineer, Aaron Jones, actually ended up rebuilding the majority of our Vignette templates from scratch. I ran into a steep learning curve, not with the Web standards themselves, but with the quirky rendering behaviors and inconsistencies in various browsers. Our writers and editors must get used to some new rules when generating the day's stories. Our management also has to accept the fact that some older or smaller browsers may be getting an un-styled version of our content. We know that some users may prefer getting an un-styled version, because they'll finally be able to read our content in the browser they use. But some users may write in, frustrated and complaining about the horrible design decisions we've made. Those feedback loops will have to be managed appropriately.

For Wired News, we analyzed the traffic reports to get a picture of our user base. From looking at our data, we predict there could be as much as 14% of our users who will get the un-styled version of our content. That's a significant percentage when we're used to our pages looking the same in every browser.

Were there any other lessons you learned during the conversion process?

As many times as I heard the message that design of content should be addressable separately from the content itself, I don't think I realized the full benefits of doing so until we actually went through the process of separating them. We're now set up to propagate small design changes instantly across the entire site, without touching one bit of html markup. And if we need to make a template change, or add in a piece of content, our data is now structured in a way that surprises our developers in how easy it is to make a change.

Wired News is also dramatically more accessible, without much concentrated effort at making it so. Sure, we now pay more attention to our image alt attributes, and try to use heading tags appropriately. But a huge decrease in the amount [sic] of presentation markup tags also plays a big role too. Since all of our content is also completely accessible sans style sheets, I think we get the best of both worlds: a well-designed, highly stylized, true-to-our-brand website which adapts in different browsing environments.

What would you say to a site developer considering a similar conversion to standards-based layout, either with simple tables or no tables at all?

I think the conversion is a matter of taking into account several considerations. Are you tired of the maintenance headaches caused by the glut of extra tables and presentation tags in your markup? Can you see an advantage to reducing file size and speeding up download time? Do you have the resources to invest in making some significant changes up front which can save time and money in the long run? Is it important that your documents be backward-compatible with older or specialized browsing environments? And forward-compatible with browser applications of the future? Are you comfortable with the idea that your documents may not look exactly the same in every browser?

If the answer to one or more of those questions is "yes," chances are, you could be ripe to make the leap. Keep in mind the last disadvantage I just mentioned. Not every browser will be able to support the CSS used to replace table layouts. In those cases, the browser will either render your documents with many bugs, or you'll have to consciously choose to hide certain bits of style information from browsers that can't support CSS adequately enough. What are the browser percentages of your current user base, and what about your target user base (which may be different)? Will the majority of your users be viewing your pages with a newer, standards-compliant browser?

Going through the initial conversion may take longer for some sites, depending on the organization and complexity of the data. Pages which draw their content from a database will probably require less labor to convert than sorting through hundreds of flat html files that have mixed structures. Whatever the situation, if the conversion is something deemed worthwhile, it's an excellent opportunity to restructure your data the right way, so it can ultimately be as flexible as you need it to be.