The Web Standards Project is
a grassroots coalition fighting for standards
that ensure simple, affordable access to web technologies
for all.
Todd, we hear you were the one who pushed the PGA toward a standards-based site. What role did you play in their switch?
I was contacted by Turner Sports Interactive—a division of Time Warner—in January of this year to discuss doing some contract Flash work. The project turned out to be PGA.com—the official home of the Professional Golfer's Association—for which Turner Sports Interactive held the online rights. TSI had plans to launch some rich, interactive Flash content alongside a re-launch of the overall PGA web site. But there wasn't enough time, and a more immediate need for someone to manage the coding of the site's many HTML templates, so I shifted gears and picked up that hammer instead.
Fortunately, I didn't have to do any preaching about web standards, the directors of Turner Sports Interactive were already up to speed with the many benefits of going down that road. The new PGA.com was a total overhaul of the previous site, with very little content re-used, so thankfully we avoided the daunting task of ripping out thousands of <font> tags and nested tables from the former site. We were mostly starting from scratch, which meant most of my time was spent working with the graphic designers translating their static Photoshop composites to CSS and XHTML markup.
So here's the thing then. PGA.com doesn't validate. There are a bunch of tables. There are crufty old tags and attributes like MARGINWIDTH and so on. What gives?
Three dirty little letters—CMS.
Three dirty little letters—CMS
To my surprise, the CMS we were using (CommonSpot) allowed virtually zero control over the head of the document. It inserted the wrong DOCTYPE, wrapped my structural elements with its own crud, and bloated the page weight with unnecessary javascript. And to give the knife one extra twist, it locked down the body element with MARGINWIDTH and the rest of its ugly siblings.
To the credit of the CMS developers, they have been listening to our complaints, and have slowly been allowing more control over the aforementioned issues. For now, we have to forsake document purity for the editorial needs of everyone involved. The site may not validate, and is heavier than need-be, but the content is ten-times more malleable than the former PGA.com, or most other large-scale web sites out there.
Even with a transitional half-table, half-CSS approach, Netscape 4.x sure isn't a pretty sight. How did you move them past the NN4.x blockade that stops a lot of people, even today?
It was an interesting experience. Even though the directors were supportive of using web standards, I wanted to make sure they fully understood the ramifications of authorizing that decision. We held open discussions, and online demonstrations, of what a standards-based web site (like ours) would look like in a non-compliant browser (like Netscape 4.7). And as you said, it wasn't pretty.
But a review of our browser stats made the case loud and clear—less than half of 1 percent of PGA.com's traffic used Netscape 4. That sounds small, but the former site received millions of unique visitors every week, which meant the new standards-based site would shut the door on thousands of existing users.
Like everything else in business though, the law of diminishing returns came into play. The extra hours it would have required to both code the initial templates and update the site throughout the year so it rendered in older non-standards supporting browsers wasn't worth the money or time.
So when launch day came, we were expecting to receive at least a handful of emails asking, ”what the #$%@ did you DO!?” But thankfully, there were hardly any complaints. The handful of people who did inquire about the change were pointed in the direction of browsers they could upgrade to, and since then we've never heard anything more.
So why did you feel it was important for PGA.com to make the switch, anyway?
For the same reason that any site should—easier development, leaner markup, and a better overall user experience.
What benefits has PGA.com seen since the switch? Any down-sides?
The most obvious benefit is file size. Even though our CMS tosses in a bunch of its own stuff, our document weight is still smaller than most large public sites. It may not seem like that big of a deal, but when a major tournament like the PGA Championship came around, we received upwards of 5 million uniques per hour. If you multiply that number by the difference in file size had we not used standards-based coding, our server loads would have been higher, with fewer successful impressions for advertising. Which, as we all know, pays the bills.
How big was your team?
Pretty small—three graphic designers, two ColdFusion developers, two creative directors, one editor, one general manager, a handful of writers, and myself. In the days leading up to the launch, we were all pulling 16+ hour days, with the final night before launch finding the web developers staying up all night, drinking Red Bull for breakfast. Everyone on the team has a myriad of talents with very little overlap, so as a group we get a lot done.
Which browsers did you test in?
Thanks to the IT department at Turner, I was outfitted with enough PCs to test just about every standards compliant browser—IE 5, 5.5, 6, Mozilla, Firebird, Opera, and Safari. I used both a PowerMac and a PowerBook for all the development, and only accessed the Windows boxes when I needed to verify cross-browser integrity. It was a lot of fun when the initial templates were presented to the directors, in all the aforementioned browsers, and to see their enthusiasm over the identical presentation in every browser on both Mac and Windows.
What about advertising—how well did that integrate with your use of standards-based code?
Advertising was, and continues to be, a headache.
PGA.com uses DoubleClick for all its ad serving needs, and the code they give developers to copy/paste into their documents is far from XHTML compliant. As a result, I didn't even try to achieve XHTML 1.0 Strict as the site DOCTYPE, and instead downshifted straight to Transitional. Which, as I noted before, didn't exactly work out either.
I later found a workaround to the DoubleClick issue with the help of Douglas Bowman. His team ran into a similar problem when re-launching Wired.com [ed. — as a CSS-based, standards-compliant design], and had written an externally-linked, ad-building JavaScript function that kept all of DoubleClick's nasty code out of the main document. We've been using a similar version with mostly positive results.
Hey, wait a minute here. You're using Flash on the PGA Championship mini-site, and it actually validates as XHTML 1.0 Transitional! How did you pull that off?
Like the aforementioned DoubleClick method, the Flash content on the PGA Championship site is embedded through an externally linked JavaScript file. The file contains some light Flash-player sniffer code, and then writes (document.write) either the Flash object/embed code, or some alternate content for users without the plug-in.
This is also a good time to highlight the differences between the PGA Championship and the “mother” site of PGA.com, since I was able to fully validate the former and not the latter.
The PGA Championship site lived outside of the CMS that drives PGA.com. Thus, I didn't have to wrestle with any of the validation issues and junk-code I talked about earlier. At the time when the PGA Championship site was designed, we had intended to put the site into the CMS, but there simply wasn't enough time. So when the Championship started, we were updating the site the old school way—by hand, editing static HTML documents. It was a pain, but we did have total control over the presentation and document structure.
As for the design, the PGA Championship site was solely my work. PGA.com was designed by a different group of designers, and my role for that site was simply coding. I was fortunate enough to be given the opportunity to both code and design the Championship site, and other “microsites” for PGA.com, which was admittedly a lot of work for one person. But it was a very rewarding experience, and one I hope continues.
You levelled some criticism at Macromedia a while back for their use of Flash-based navigation, with a standards-compliant backup, in which you stated the backup was technically superior to the Flash version. So we have to ask: you did the same thing for the Championship site—what's the difference?
Ah… I wondered if anyone would notice.
Instead of just pushing news and other content out, we thought it would be interesting to have a space that pulled readers in.
Truth is, the original idea for the letterbox area at the top of the PGA Championship web site was to give visitors an immediate, immersive experience with the event. Instead of just pushing news and other content out, we thought it would be interesting to have a space that pulled readers in—hence the inclusion of a “course tour” where visitors can view, read, and watch flyover videos of each hole. A window—if you will—into the Championship.
Now, the best way to create that “look” was to frame the rich content with navigation that dropped down over the space; thus creating an illusion of depth (with the additional help of some light drop shadows). This type of design was only possible with a tool like Flash, and since the entire navigation was dynamically created with a single XML file, adding and removing pages and whole sections was quite easy and could be handled by anyone on the team.
Where we ran into issues was with users who didn't have the Flash Player 6 plug-in. I created a static, flat jpeg of the Flash area and layered a link map on top of it, and that worked pretty well. But after a while it became an arduous task to modify. So I added some Macromedia-style list drop-downs to the non-Flash content. The drop-downs look pretty decent, and are closer to the Flash version than a link map, but they're not preferable.
Using Flash and XML for the site navigation was an interesting experience, but considering how much extra work was involved in duplicating the content for non-Flash users, I'm honestly not sure if we would do it the same way again. Next time I'd likely design with just CSS and save the richer Flash content for a more self-contained project.
I see you're using a table for tabular data on the right. We all know by now this is totally acceptable, and exactly what tables were designed for in the first place. But does the dogma ever go too far? Do you get that slightly naughty feeling some days when using them, even for data like this?
If I'm typing out table code for a leaderboard, a score card, or other data that needs to be presented in a tabular form, tables are the only way to go. Where I really feel silly is if I'm just trying to quickly crank some content out and I put a nested table inside of a table cell. Then I feel like it's 1995 all over again.
Was there anything you couldn't do for one reason or another, that you wish you could have?
Not yet. We have a very enthusiastic, energetic team of people working on PGA.com who are all open to new ideas. We have a lot of exciting projects in the planning stages right now that I'm looking forward to working on.
Thanks for taking the time to respond, Todd!
My pleasure. Thanks for asking me.
Todd Dominey is the founder and creative honcho of the Atlanta based new media design and development studio Dominey Design, and writes about technology and web design at What Do I Know?.