Mike Industries

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, naiveté, 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.