Netscape DevEdge

Skip to: [content] [navigation]

An Interview With Mike Davidson of ESPN (Part 2)

In the second part of a two-part interview, Mike Davidson of ESPN.com gets into the nuts and bolts of standards-based redesign as he talks about code changes, points out the limitations of CSS-driven layout, discusses ways to gather intelligent redesign feedback, shares advice for designers, and much more.

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.

"By starting with our front page, we were able to provide an example for all pages going forward."

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."

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.

"We are constantly working towards the highest level of compliance possible."

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.

"Blogs are a great way to monitor and even participate in the chatter about your new site."

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.

<< Part 1

A+R