The Web Standards Project is
a grassroots coalition fighting for standards
that ensure simple, affordable access to web technologies
for all.
So Dan, rumor is you're the man behind the Fast Company and Inc.com switch to standards-based sites. What role did you play during the redesign?
You are correct, sir. My role was handling all of the design and front-end development (XHTML, CSS and XSLT) for each of the redesigns. Fast Company's redesign was launched in March 2003 with Art Direction from Daigo Fujiwara, Inc.com relaunched this past July.
In addition to the front-end, there were many changes on the backend as well. For instance, our CMS was rewritten to include validation routines that keep the code squeaky clean after we had spent months converting it.
A question that we've all asked at one point or another is how in the world do you sell web standards to people who don't get them, and (sometimes) don't need to? Tell us a bit about how you made the case to Fast Company. Was there any friction?
This is often a sticky point — especially within internal web teams. I'm not going to lie to you though, I had it very easy. The convincing went something like this. "Hey, Rob" (Rob Roesler, the Director for both sites). "Go to Wired.com." And then his response, "We need to do this."
So I certainly have Douglas Bowman to thank for paving the way with the Wired redesign in October 2002. It was an important moment for building sites with web standards. We all had something to point to. And by "we", I mean designers and developers working on commercial web teams. Many had been pioneering CSS layouts prior to the Wired launch, but it proved that standards-compliance can work on a commercial site. And that was exciting.
We went to work, and in the process discovered all of the benefits that come from building a site this way. With Fast Company, it was a gigantic learning experience. Once we did it successfully, we knew we had to do the same for Inc.com.
I realize not every web team is going to have it that easy — getting everyone on board to go full-on standards. Because you need everyone to be on board. As a designer, you could create clean-as-a-whistle templates — but if the CMS and other applications behind them aren't standards aware, then all could be lost. I felt very fortunate to have worked with folks who "got it".
Forgive the ridiculous analogy but: we're fat. It's time to go on a diet. It's 6:00pm and we've just gotten off of work. We're hungry so we do what we've always been doing — we go to KFC and order a bucket of fried chicken. It feels good... it's what we've always done. But it's killing us.
There's this fad diet though, that can help. Most are justifiably weary of fad diets, immediately dismissing them. Then there are some who try out every fad diet imaginable. There's always a catch however, not to mention the bad habits that need to be broken.
I see web standards as the fad diet — that actually works. It's the convincing that's the hard part. Everyone thinks they're eating healthy or they don't see the risk. Jeffrey Zeldman is doing a tremendous job at leading the cause. Maybe we need to get someone like Richard Simmons in on the crusade as well.
Alright, so there's this crazy new diet that works. Why was it important for Fast Company to try it out?
…it was important to reach the largest audience possible. Text browsers, screenreaders, phones, PDAs could now all read the content of the magazines just as easy as everyone else.
I think it's important for any site — but it especially made sense for us at the time. We were a very small team, continually shrinking because of cost cutting and layoffs. We were looking for ways to trim the budget in every way possible. By making the switch to web standards, our code was literally cut in half. In addition, our page load time was decreased thereby reducing stress on our servers. These two benefits alone allowed us to lease less rack space with fewer servers, handling the same amount of traffic.
Aside from server improvements, it was important to reach the largest audience possible. FC and Inc. are magazines. Their business is based on content. Getting that content in front of people is the goal, and the accessibility gains by going to structured markup and CSS made this exceptionally easy. Text browsers, screenreaders, phones, PDAs could now all read the content of the magazines just as easy as everyone else.
What other benefits has Fast Company seen since the switch? Any down-sides?
We've seen benefits for both sites. The first being the average reduction in page file size by about 50% (including both home pages). Half the code! The second being the ease of customizing different sections of the site, using an additional CSS file that may override the default styles for the site. For instance, if Microsoft came to us and said, "we'd like to do a co-branded micro site with you, but with our logo and colors", we could whip up a few style rules that overrode the site's defaults and import it after everything else. This section of the site would have an identical structure, but a customized design.
As far as down-sides, probably the biggest is the flexible width constraints I'll touch on in a bit. And layouts within layouts can be tricky in any circumstance. What I mean by that is a multi-column layout within an already CSS-based layout. Those are tricky scenarios to deal with, and certainly ones where the limitations become evident.
So how well did things come together, once the decision was made? What sort of hoops did your team have to jump through, in the way of CMS support and retro-fitting older articles? How big was your team, anyway?
For running both sites, I would say our team was pretty darn small. We had myself, a fearless director (Rob Roesler), two crackerjack developers (David Searson and Bob Joyal), one production maestro (Paul Maiorana) and a couple of interns for helping in the clean up and validation of close to 20,000 articles total. There were also 3 or 4 other web team members who handled editing, business development and advertising tasks.
The beauty of cleaning up old content that doesn’t change, is that once it’s clean, that’s it. It won’t have to be touched again.
One big advantage that we had, was that our CMS was written in-house by the brilliant Aussie, David Searson. He took the redesign opportunity to rewrite the CMS with validation features in mind. It came to the point where an editor could not deploy an article unless it was validated. That forced everyone to get on board, and to learn proper XHTML. Having the CMS to back up everything we were striving for on the front-end was essential.
The hardest part of either redesign was undoubtedly the clean-up of older content. Inc.'s content dates back as far as 1986, and we found some of the nastiest HTML one could ever imagine. It took a small army of two interns to come in every day for several months chipping away at it, article by article. Bless them.
The beauty of cleaning up old content that doesn't change, is that once it's clean, that's it. It won't have to be touched again.
Those are some sexy navigation tabs…
Why thanks! I'm pretty happy with the solution, although it does have its faults. The constraint was that we needed to fit a certain number of top-level items in. Using text just would not work out at a minimum resolution of 800x600. So images it had to be. All I really did was combine Pixy's excellent rollover technique with the image replacement method of the month. For instances where you're forced to use images in navigation — this is an option. Ideally, it's nice to be able to use text of course, letting low-vision users increase font size on those items. We tried to help that problem a bit by referencing a second set of tab images that used a larger font in the existing alternate stylesheets.
Was there anything you couldn't do for one reason or another, that you wish you could have?
The one thing I might have done differently is rethink using a fluid layout as opposed to a fixed one. The main reason we went fluid instead of fixed is to accommodate the massive amount of advertising on article pages. The nasty 336 pixel wide ad in the middle of the page is a real beast to workaround. So, by going flexible on the page width, we thought this would make it an easier read for those users with larger monitors.
The flip-side to this though, is that it can be tough to design custom layouts (like the home page) for that middle column, while still keeping in mind the flexible width. We did a lot with floating blocks to one side, but sometimes it's nice to be able to count on a specific width.
We've read somewhere along the way that since switching, you haven't had a single complaint from a Netscape 4.x user. Since they can obviously access the content (but not the design), what do you think that says about the average user still on older technology?
Crazy, isn't it? Or maybe not. It's true though, that we hadn't received a single complaint from any Netscape 4.x user since we relaunched both sites. I'd like to think it's because they dig the fast-loading, easy to read site, sans style. It could also be that those users wouldn't think of sending feedback to us. But judging from the amount of feedback we received on other issues, it appears that version 4 and below users are either happy, have upgraded or haven't noticed.
This made the decision in going with the @import method of hiding all CSS from those browsers all the easier.
Anything parting thoughts?
There is one other thing I'd like to mention — that there are more and more site redesigns happening everyday that utilize web standards. This is a great thing. These redesigns are proving that the technology can be used today on not only personal weblogs or testbeds — but also in real-world projects. It's exciting to see it become less about the technique and more about the results.
That said, when we see someone announcing a new redesign that was done with web standards, the first thing we should all do is give them a pat on the back for trying to do things a better way. At times this great community can be too critical, too fast, by picking apart every minute detail about a design. My fear is that the harsh criticism may scare some away from using standard-compliant methods. We're all in this together. "Better today" is greater than "perfect tomorrow".
Good advice for us all. Thanks for taking the time to respond, Dan. We're looking forward to your next big launch!
Thanks! It was my pleasure.
Dan Cederholm is a web designer in Salem, Massachusetts. He lives at SimpleBits, where he writes about standards-compliant design and development, his redesigns of Fast Company and Inc.com and his rediscovery of bubblegum.