Interview: The ESPN.com Redesign

Interviewer: Eric A. Meyer, for Netscape Communications

ESPN.com, the online sister of the ESPN cable networks, serves up more than half a billion page views every month, so when the home page of the site dropped all layout tables in favor of structural markup and CSS-driven layout, the Web design community took notice. To add to the intrigue, the site’s design is (as of this writing) being adjusted over time, so that the site is in effect making the latter stages of its redesign process public. For a personal site to do such a thing is rare enough; for a major commercial site to do it would have been almost unimaginable.

The DevEdge team was as fascinated as everyone else, so we asked Associate Art Director Mike Davidson a series of interview questions via e-mail. We were so thrilled by his detailed answers, we decided to to split the interview into two parts rather than be forced to make major cuts for length. In this first part, Mike talks about the benefits of the new design, selling management on the move, browser testing, the ethics of upgrade requirements, and more.

How much traffic does ESPN.com get, on average? How does that traffic break down in terms of browser versions?

Our traffic fluctuates with popular sports being in or out of season, but throughout the year, we get anywhere from about 1 to 1.3 billion page views per month. This is for all ESPN-owned sites. For just our site on the ESPN.com domain, we average anywhere from about a half a billion to 950 million page views per month.

For the month before our redesign, we calculated that 97.44% of our users were using standards-compliant browsers (IE 5+, Netscape 6+, Mozilla, Opera 6+, Safari, Chimera, and Konqueror), and the rest were either non-detectable or using non-compliant browsers. The only substantial groups among the non-compliant browsers were IE 4.x at 1.32% and Netscape 4.x at 1.17%. The other .05% of our users were either undetectable or were using obscure or masked user agents.

What were the primary factors behind your decision to move away from table-based layout?

The number one factor was forward compatibility, a term I first heard used by Jeffrey Zeldman. For most of the ’90s and the first part of this decade, content providers who wanted to publish online only needed to worry about the graphical web browser. Sure, we had to craft our content so that it presented itself well in many different brands and flavors of browsers, but it never went further than browsers.

Because the competitive landscape of the web is such that the site which looks and works best gets the most traffic, developers and designers put a premium on the presentation of that content and let structural markup take a back seat. Through a dizzying array of table tricks, transparent spacer images, and JavaScript hacks, we found a way to make things look great to the human eye through the window of a graphical web browser without worrying about what everything looked like under the hood. Now that digital lifestyle devices, tablets, wireless phones, and other Internet appliances are beginning to come of age, we need to worry about presenting our content to these devices so that it is optimized for their display capabilities. Do we want to send a 100KB index page full of Flash, images, and tables to a small wireless device or would we rather send them our top story, our top headlines, and essential navigation to get through our site? By separating our content pieces in a logical way rather than a graphical way, we are free to restyle this content for any device which supports open standards.

The second big factor in our decision was staying ahead of the curve. ESPN is the number one online sports property in the world because we do things first. We were the first 24 hour sports channel, we were the first major sports property to go online in any significant way, we are usually first to report breaking sports news, and this was just another example of a way for us to raise the bar and help lead our industry to a higher online publishing standard. For us, embracing open standards and dropping support for proprietary code was clearly the right thing to do… the only question was, was it the right time to do it yet?

Basically, we could have done [the redesign] now, or we could have waited two years until our next redesign. Doing it now keeps us ahead of the curve, while only potentially risking about 2% of our online audience. Doing it in two years may put us behind our competitors. We fully expect our competitors to join us in embracing open standards with their next redesigns. Our spy planes haven’t produced any illuminating photos yet so we can’t say exactly when that will be.

Did you have a tough time selling the move to marketing and management people?

This actually proved to be the easiest part of the whole undertaking. I had written a “Jerry Maguire” letter of sorts during the summer of 2002 to management outlining everything I thought we were doing wrong and what could be done to improve each situation. The letter covered things like overzealous advertising placement, popups, indexability, dynamic publishing, and open standards. The section about moving from table-based layouts to standards-based layouts was relatively short and used language like “accessibility”, “load time improvement”, and “economies of scale”. I could have written 10 pages on browsers and standards and bored all of our suits to death, but I found that speaking to them in terms they understood and already appreciated was the best way to educate everyone on why we needed to do this. Everyone agreed that embracing standards was the right thing to do, and the only downside which needed further exploration was how many users of older browsers would be negatively affected by our proposed change. When we saw that only 2% of our users were not equipped with standards-compliant browsers, the decision was a relative slam dunk.

The first important part of this statistic is that the 2% number is only going to go down. Old browsers have been working their way out of the public consciousness for a few years now and we feel there is no risk whatsoever in this number ever going up. All substantial browsers which have been released in the last few years support open standards, and these days, you can’t even release a new browser without it supporting standards or else no one will use it.

The second important part of this statistic is that if you are in this 2% group, it is physically possible to get out of this group by upgrading your browser or petitioning your IT department to upgrade your browser. It’s not the same as the decision some sites make to not support Macintosh users. If you use a Macintosh (like I do), your only solution to get into a non-Macintosh friendly site is to physically buy another machine. The simple fact is that most of our 2% of users who still use Netscape 4 or IE 4 only do so out of upgrade anxiety, naivete, or laziness. As an influential site on the web, we want to help them overcome their inertia on this situation. In fact, we feel we are doing them a favor by getting them up to date.

What are the advantages of the new design, as compared to your old design?

Too many to list, really. Here are several major ones:

1. Less code and faster loading pages. We reduced the size of our front page code by about 50%, and by using absolute positioning, we are able to display important parts of the page before other parts may have fully loaded yet.
2. More modular content display. By separating our content logically, using divs, instead of presentationally, using tables, we can have one piece of content in our CMS [content management system] which is styled differently by every page on which it appears. A good example of this is if we had a content module which contained ten common news headlines, but it needed to fit in a 200 pixel wide blue area on one page and a 400 pixel wide grey area on another page.
3. Greater user control over content display. Although our front page is the only page which has been converted over standards-based code [as of March 2003], our new story pages are on the way. With these new pages, users will have control over font, size, and leading of all body copy and their preference will be cookied and used throughout every other story page. It is amazing to me that more major sites are not already offering this as it makes a clear readability difference for some people. Sometimes I feel like I could read entire phonebook cover-to-cover if it was styled in 11px Verdana with generous leading, but often I lose interest in even the shortest of articles if the type display is sloppy or otherwise bothersome to me. I know I’m probably more hypercritical of stuff like that than the population at large, but the point is that we’d like to put the user in control wherever possible.
4. It’s just the right thing to do. Writing old school HTML code was never very much fun but now it’s getting downright tedious for most people. Furthermore, when the people who are actually writing the code read about open standards and realize what they are currently doing goes against where the industry is moving, they lose motivation to use tables and take an interest in structural markup. Workers in the web development industry are always looking to stay ahead of the development curve so their skills don’t become obsolete. By giving them a way to further their skillsets and write next-generation code on one of the most visited sites in the world, we are helping them become the best designers, developers, and producers they can be.

In which browsers did you test your new design?

Our backbone of browsers to test on during initial design stage was IE 5+ (Mac and PC), Netscape 6+ (Mac and PC), and Mozilla 1+ (Mac and PC). After the newest version of Opera and the Apple Safari beta came out, we tested on these as well and no adjustments whatsoever were needed. The new site simply worked right out of the box. Chad Roberts—our other Associate Art Director, whom I co-wrote the front page with—and I didn’t fully realize the significance of what we had accomplished until we saw a beta product (Safari) render our front page with the same pixel precision as the browsers we had already tested on. Standards purists always recommend that you don’t design with pixel precision, but we have done just that… with no code forking, no alternate stylesheets, and no box model hacks.

You’ve chosen to block old browsers from accessing the site. Why is that?

Before I answer that, I want to make the distinction that there is a huge difference between those who won’t use a standards-compliant graphical browser and those who can’t use one. An example of someone in the first group is a dogged Netscape/IE 4 user who is just so used to his or her browser that they feel no need to upgrade. An example of someone in the second group is a visually-impaired person.

For better or for worse, we have every right to not consider the non-upgrader person in our design decisions. ESPN.com allows customers, free-of-charge, to use our vast online sports resource in exchange for one thing: exposure to advertising and sponsorships. This is how TV works, and this is also basically how newspapers and magazines work as well. By embracing standards as we have done, and dropping support for those who choose not to support standards, we are free to produce pages with leaner code, better advertising opportunities, and an overall better user experience. To the extent that we can put our limited resources to work producing a greater quantity of pages, which load faster, and look better to 98% of our viewers, we feel we have the right to make that choice.

Now, with regards to the second group of people, which includes the disabled, we feel a strong social responsibility to support this group. Our old site did not have very good support for the disabled, but our new site should soon have much better support. With all of our content in divs now, we can hide all but the relevant chunks of content and navigation with a simple alternate CSS file. This benefit alone is enough to make up for irking our tiny percentage of upgradophobic Netscape/IE 4 users.

There is a third group worth mentioning and that is the group of people on machines which are “locked down” by IT staff and thus not upgradeable. This group poses the toughest question for us because we know they want to upgrade, but they really can’t. Though we obviously don’t feel any ill will towards these people, we feel that as an hugely influential site, we are doing these people a favor in the long run by insisting on standards. Once other media sites follow and then smaller sites after that, it will really be a requirement that IT departments supply their workers with standards-compliant browsers.

It really should be a requirement already, but it’s not, because web sites have always held out that little corner of the security blanket and said, “We still support you! We still love you!” Well, in our mind, this is just a little tough love, that’s all. We have a saying here at ESPN when something goes wrong or a server goes down.. It goes something like this: “This is not a hospital, we are not doctors here… people aren’t dying. The worst thing that is going to happen is that people won’t get their sports.” For the tiny percentage of people who are negatively affected by our embracing of standards, they can just get their sports somewhere else in the meantime. It’s not like we’re denying them hospital care.

The decision to redirect proprietary non-compliant browsers to our upgrade page has always been primarily about education. The fact is, most people who are still using these browsers are simply unaware of their deficiencies. No one has ever told them otherwise, so they figure the rest of the world uses the same browser they do. In fact, some of these people, judging from the e-mails we get, don’t even really know what a browser is… and that’s fine. If we can do them a favor by telling them how to improve their experience on the ESPN and the rest of the Internet, then why shouldn’t we? We are a bit cocky over here so we feel that people should of course invest the 5 or 10 minutes it takes to upgrade in order to view our site, but hey, if worse comes to worst, there are several other places they can get sports information from. We hope they don’t go elsewhere, but if they do, we just want them to realize that eventually these same sites will begin to look bad in their current browser.

Why not just let the older browsers see less styled (or unstyled) content?

There are other technical reasons why we don’t offer an unstyled page to Netscape 4.x users, mostly related to dynamically written out content, but a lot also comes down to the fact that the success of our site depends largely on the presentation of our content. We’d rather assertively tell you why your browser needs to be updated than show you an ugly shadow of our front page and have you assume we did something wrong. Dan Benshoff, our top creative brass, and John Skipper, our senior executive VP, have always put a premium on presentation of content, and anything short of best in our industry will not fly. Sometimes people just won’t upgrade unless they feel they really need to. We feel honored to help create this need.

How did you plan this change at the code-and-markup level?

Our site is so big that it’s really hard to have a “master plan” which encompasses everything. I loudly applaud what the folks over at Wired have been able to do with their site in one fell swoop, but for better or for worse, ESPN is a much bigger beast. For one, our presentation style is on the complete opposite side of the spectrum as Wired’s. Wired’s site, even before the redesign, has always existed as a nice clean layout of headlines and subheads leading to stories which are formatted in the same way. This no-nonsense approach is popular among Wired’s user base and it seems to serve its purpose well.

ESPN, on the other hand, always seeks to present a unique looking front page through the use of typographically styled headlines, large photos, video embedded directly into the page, and interactive Flash features like our new Flash 6 photo gallery. We even design a brand new subset of pages for every event which goes on throughout the year. So for instance, our Masters golf package looks completely different than our NFL Draft package… from the visual design right down to the underlying code. At times I am jealous of the templatized simplicity of the Wired site but at other times I am glad that we add personality to pages and constantly launch new designs.

Our basic strategy for this redesign was to just start with our big mamma-jamma, the ESPN.com front page, and then work outward from there. By starting with our front page, we were able to provide an example for all pages going forward. One of the hardest things about changing the way we write code at ESPN is that there are so many different types of people actually writing code for the site. It starts with the creative department designing new pages and passing off code and graphics, then the production department templatizing elements and making everything pull dynamically from our CMS, and then when new content needs to be added, our editors often find themselves adding simple HTML like <p> tags and <font> tags to unstyled content.

It’s easy to convince the production and design teams why they should write standards-compliant code, but to everyone else who might be involved, new coding procedures are sometimes viewed as just another complicated thing to remember. Ideally, non technical people would not have to use any tags at all and we are moving in that direction with changes to our CMS.

What CMS do you use, and was it tough to get it to produce standards markup?

We use our own homegrown CMS, which is called “GoPublish”. As for getting it to produce valid markup, the CMS doesn’t really produce any markup at all. It’s a servlet-driven system where all content it produces comes from templates that our producers write. As long as they write valid markup, the CMS writes valid markup. That said, however, it is very hard to get everybody thinking in divs. There are just so many people who need to learn this new way of coding.

What are some specific markup or code changes you made, and why?

Well, we pretty much redesigned and recoded the front page from the ground up. Everything is new. There are zero font tags on the page and only two tables—one to display our ad banner at the top (which will be reworked into a div) and one to display a small chunk of tabular data in our Fantasy Sports tab (a legitimate use of a table). Probably the biggest decision to be made in this redesign was whether to use predominantly floated divs or absolutely positioned ones.

While the concept of floated divs is a good one, we found that there were too many major differences, even among standards-compliant browsers, in how floats are displayed that it would require plenty of code forking to get it just right. With absolute positioning, we were able to achieve a pixel-perfect layout which looked identical in all standards-compliant browsers. We do have a few small floated elements on the front page but these are more of a paragraph-by-paragraph thing than a page structure thing.

We also had the unfortunate problem of dealing with partner-sponsored elements on our front page which are largely outside of our control. We cannot change the look or size of these elements (mainly the header and footer) but we took it upon ourselves to rewrite the code to display these elements so that they are now div-based. Our partner did not have a problem with this because the change is unnoticeable to viewers.

One other unique aspect of ESPN.com is that we have built in the ability to lay our front page out differently depending on how big any piece of breaking news is. Essentially, we have four publishing modes: regular, twin-top, skirmish, and war. “Regular” is pretty much how you see the page 90% of the time—a big top story and a group of headlines on the right. “Twin-Top” is when we have two major stories of interest. In this case, we have our big top story and then a smaller top story box on the right.

“Skirmish” is where it starts to get interesting. If there is a big trade in the NBA for instance, like the recent Gary Payton for Ray Allen deal, we can display a very large photo with typography set over in Photoshop by our design department. The effect is much like an eye-catching magazine cover. The most dramatic publishing mode is “War” which we reserve for when a team wins a national championship, there is a major sports tragedy, or if there is otherwise spectacular sports news to report. In this mode, we can cover almost the entire front page (above the fold) with a large photo once again professionally typeset by our design department. Since we have abandoned tables and gone with all divs, we are able to publish in these four modes effortlessly. It’s just a question of showing and hiding divs via the DOM.

Were there any things you tried, but had to back out due to browser limitations?

There were really only three things we couldn’t do with this redesign: properly position our partner-specific footer at the bottom of the page, use vertical alignment within divs, and achieve validation.

Positioning footers is a huge Achilles heel of absolute positioning. It is ridiculous that you cannot embed three absolutely positioned columns within a master div and then position a footer below that master div. This is a well known problem of absolute positioning and there are a few workarounds, none of which are very elegant. The workaround we settled on for the front page was simply positioning our partner’s footer a concrete pixel value from the top of the screen. Since our front page is always roughly the same length, we don’t need to worry about any of our columns creeping down into the footer. This solution works fine for now but it does not exactly put a smile on my face. We’ve tried using height-detection on columns to dynamically position our footer div but our complex and vertically flexible advertising module at the top of the page keeps this detection from being accurate across all browsers. Moving forward, we may look at shrinking the size of this footer so that it fits in one column, but that is not an ideal solution either. Oh well, at least no one pays any attention to footers!

Vertical alignment within divs is probably the single biggest oversight by the W3C when they created standards for div-based layouts. It is simply unbelievable to me that with all the groups overseeing the development of new standards, nobody raised a flag and asked about vertical alignment. I vertically center things in tables a lot, and the fact that there is no way to control vertical positioning in divs affects the way we do things across the board. There are a few ways to fake vertical alignment that seem to work adequately, but it is really a little disconcerting to have to resort to this.

Then there’s validation. Telling me my site needs to validate in order to be standards-compliant is like telling me I need a flag in my lawn to call myself an American. For a simple, small, text-heavy site like a blog, validation may come relatively easily, but when you have a site like ours which dynamically writes out a lot of content, uses third-party statistical tracking, makes liberal use of Flash, and offers complex and flexible advertising modules, validation is simply a pie in the sky. When I ran our new site through the W3C validator, here are the bulk of the things which didn’t validate:

1. Sometimes we dynamically open divs and other tags with document.write and the validator can’t figure out why we’re closing a tag which appears not to be open.
2. Our ad server requires us to send ampersand-delimited variables to it which are not URL-encoded and the validator treats any ampersands in your code as invalid.
3. Our statistical tracking code puts id attributes to certain script tags, which the validator claims is not valid.
4. We sometimes do not include alt tags for images which aren’t important unless they are physically seen. Some people will say “Just include alt=''“, but I simply don’t agree with including alt tags for the heck of it. I guess I’ll just have to be a conscientious objector on that policy. If I somehow felt like having a site which strictly validates was an indication of my manhood, maybe I’d do it, but it really means very little to me. We’re mavericks over here, what can we say?
5. We display all of our Flash elements using a home-spun JavaScript delivery method which is way more flexible and compatible than even the method Macromedia recommends. We can add all sorts of dynamic parameters through our CMS, display rich alternative content, and do many other things we couldn’t otherwise do. The only downside is that it doesn’t validate. Boohoo. I recently read an article about the “Flash Satay” method of embedding Flash so that it validates, and while it was a great exercise in standards, it’s not practical in the least bit for large sites which use Flash frequently and in various ways.

It is probably smarter to view validation as a ideal and not as a requirement when it comes to working on presentation-heavy, Flash-heavy, and JavaScript-heavy sites like ours. Since the redesign, it seems like we have gotten praise from our users as well as most web developers and designers, but a couple prominent members of the “standards purists” community have taken jabs at what we’ve done, particularly since our stuff doesn’t validate. Well guess what? I typed both of these people’s own sites into the W3C validator and they didn’t validate either. I don’t mention this as a negative thing about these people’s sites… only as an example of why validation is often something more preached than necessarily practiced.

Neither of these hypocritical validation evangelisms lower my opinion of the evangelists themselves.. They are clearly very intelligent and they do excellent work. They only lower my opinion on the necessity of strict validation. Is it something you should try to do if possible? Sure. Is it something you should sacrifice certain features and interactivity for? Probably not. I read on Zeldman.com a couple of weeks ago that only 6% of W3C member sites validate right now. Purists might say that these people aren’t being true to their cause. I would say many are just exercising discretion, and it is their right to do so.

I’m sure many people who will be reading this interview favor strict standards-compliance more than we do, but just keep in mind that we are constantly working towards the highest level of compliance possible. It’s just that complete compliance often isn’t possible without making unacceptable sacrifices. I’d say that if a site is 95% compliant and it uses the other 5% to create a better user experience, then that’s just fine.

What would you say to a site developer who’s thinking about following in your footsteps?

There’s only one big piece of advice I can provide and that is to know your audience. We would have never gone to a tableless layout if we thought a significant amount of our audience used non-compliant browsers. Within a couple of years, this will not be an issue to anyone, but for now, there are certain subsets of people who still use older browsers and you must try and figure out what percentage of your audience includes these people.

If I was designing a web site for elementary school children, I might have a much higher percentage of older computers with outdated browsers since keeping up with browser and hardware technology has not traditionally been a strong point of most elementary schools. But at ESPN, we are blessed with a user base that is about 98% standards-compliant. Some of this might be because a large part of our audience is young savvy Internet users, and some might be because the majority of our traffic comes from the workplace, where companies seem to have settled on IE 5 and 6 in a pretty overwhelming way.

After our relaunch, I read a post on a blog from someone who made the argument to his company that “supporting Netscape 4 posed a business risk” and shouldn’t be opted for because the upside was not worth the risk. That’s definitely a profound concept worth using if you’re trying to justify a standards-based redesign at your company. The “business risk” is that you’re creating code which is not forward-compatible, not repurposable, and not modular enough to scale to different media. The “lack of upside” refers to the fact that you may only be alienating such a small percentage of your audience, most of which can upgrade if they want to.

Were there any other lessons you learned during the process?

We learned the importance of soliciting feedback before and after a relaunch and making any appropriate improvements as quickly as possible. The most important example of this was our browser upgrade page and the feedback form on it. Since the relaunch, I have personally read every single piece of feedback from that page and I generally send individual replies to anyone who has taken the time to write at least a few intelligent sentences. Of course I’m not going to respond to things like “You suck, ESPN, let me in,” but if someone’s having legitimate problems upgrading, or wants to sound off positively or negatively about our standards policy, I generally send them a reply. It validates our cause when we are able to take someone who has blindly been using Netscape 4 all these years and turn them on to using a better browser through our upgrade page or through personal correspondence.

One of the things our feedback form helped us do as well was to improve the browser upgrade page itself. By examining where our users were breaking the intended user flow chain of actually upgrading their browser, we were able to simplify verbiage, reposition elements, soften our tone of voice, and lead users along more efficiently to the end result.

Another useful way of gathering feedback from our redesign was checking blogs. Blogs are a great way to monitor and even participate in the chatter about your new site. Posts on blogs tend to be more insightful than posts on traditional bulletin boards because the idea of a blog is that the user reads the original post by the blogger first (which is generally already insightful), then all of the resulting comments, and then he/she posts their own comment. Bulletin boards tend to be just a bunch of people posting random comments… it can be very noisy and tough to follow. We ended up defending some of our positions on various blogs, but we also took a lot of the good advice we received to heart in improving the upgrade page and even the new front page itself.

Anything else you’d like to say?

Well, I would like to give a shout out to the other key people involved in this project if that’s okay. They are (in alphabetical order): Lance Anderson, Nisha Barochia, Dan Benshoff, Frank Conway, Thomas Coyle, Ed Davis, Aaron Laberge, Danny Mavromatis, Zach Putnam, Chad Roberts, John Skipper, and Joe Specht.

Thanks for your time!

You’re very welcome.