Featured Site: Chevrolet
In August, the web professional community was pleasantly surprised with one of the larger CSS-driven redesigns of the year; the site of international car manufacturer, Chevrolet. A few days after the launch Dave Linabury, who works at Campbell-Ewald and has one of the funnier sites on the web in Davezilla, sent me an email asking if I wanted to feature the site. I asked him if, instead of doing just a feature he wouldn’t mind doing an in-depth email interview. He said yes and a month or so later — after their lawyers, developers, clients, public relations and local Boy Scout troop all had a look over it — they sent me this. In it he discusses the site’s development timeline, how to convince a client that usability and Standards work, proving ROI with CSS design and how to stop worrying and love the DOM. If I do say so myself, it’s a great, inspiring read — if a ginormous corporation can pull this off, why can’t we all? Enjoy.
1. First a little about yourself, but also about Campbell-Edward as a company and how Chevrolet came to approach you with this herculean redesign.
My name’s Dave Linabury and I’ve been a web developer since late 1994. My first real gig professionally was webmaster for the City of Royal Oak, in Michigan, where I hand-coded 32 city-sponsored sub-sites in addition to being the city newspaper’s art director. I didn’t sleep much back then. I became an Information Architect for General Motors in 1999 and stayed there several years.
I was approached by a Campbell-Ewald developer, long-time friend Tami Urban, to join their web team. When she mentioned how the entire team was pushing for web standards and accessibility, not just the programmers but all the way to account and upper management, I knew this was going to be huge and that Ken Burbary, the web development director, had the right vision.
Campbell-Ewald is one of the top ten advertising agencies in the world and has had the Chevy account since day one; about 90 years or so. We recently redesigned Navy.com; the first accessible military site. I love the Navy site — it retains its coolness factor without sacrificing accessibility. With so many companies being sued over 508 and ADA issues, it’s great to work for a firm that is ahead of the curve and actually has a corporate directive to promote accessibility and web standards for its clients.
2. I know that Matt Dertinger, Chris Moritz and yourself worked on this — who else? How big was the team and what were all your roles?
Chris is a brilliant Information Architect. Anyone who’s read his postings on various development sites will instantly be floored by his breadth of knowledge on a plethora of subjects. Matt is an extremely gifted programmer. He’s literate in JSP, XSLT and XML and loves pushing CSS farther than humans should be allowed. He’s also one of the most pleasant people you’ll ever meet. Tami Urban is simply the fastest coder I’ve ever met. She’s also really good at figuring out the proper solution for the amount of time allotted by the client. Chad Priest is a rock solid code-monkey with a strong knowledge of back-end solutions and search engine workings. Rounding out the team is programmer Robin Wylie who, along with our witty team manager Beatrice Manzella, has the most experience working with Chevrolet. We cannot forget art directors Shirley McGrath and Jason Walker for the overall look. Jason also did the subtle Flash transitions that you see on the Colors pages.
I was there for the coffee.
3. What was the timeline of the project and could you outline the stages of a huge project like this?
We began this redesign of the site at the beginning of April; we launched the new site on August 17th. Our process (with some overlaps) was more or less the following:
- 1. Strategy/Objectives
For the beginning months a core team of Account reps, Art Directors, Digital Programmers, the Creative Director, and the Information Architect met daily to discuss the feature set and direction for the redesign.
We based our approach on a number of inputs:
- Nielsen Norman Group Heuristic Analysis
- Vividence research
- Omniture SiteCatalyst server log analysis
- Competitive review of other automotive sites
- 2. Wireframing
Towards the tail end of the strategy phase, we moved into interface design. After a week of paper prototyping and internal review, the Information Architect and Art Directors began wireframing out the major sections of the site in rapid iterations. Internal review and revision of the wireframes took place over a few weeks. In the future we intend to spend more time on this phase; adding in more sections and in general fleshing the prototyping out for better insight during usability testing.
- 3. Usability testing
After completing the wireframes, we worked with an outside vendor to do two rounds of user testing. Members of the Strategy team sat in the observer room with our primary client representatives to watch the testing. Our testing vendor helped us out greatly in coming up with a script that dealt with our labeling conventions, navigation metaphors and user path determination.
We found this exercise to be extremely insightful; we made a number of revisions to the wireframes based on the results of the testing. In the future we’ll be conducting more rounds of testing on more sections of the site. We were able to build upon the testing that had already been conducted on the buying tools we integrated into our site from GM Buy Power.
- 4. Creative comping
Our art directors faced a nigh-impossible deadline for the graphic design/comping phase, but managed in good form to pull it off. In previous years the Art Directors had to lay out each and every page in Photoshop with content, to accommodate a legal “in context” review. This year we were fortunate in that a majority of our content wasn’t going through major revision; we placed our new site header and navigation bar around the “old” content for the first legal review.
- 5. Coding
Our chief coder, Matt Dertinger, killed himself translating the approved creative comps into the impeccable coding we see on the site today. Consulting with the rest of our team, he made sure there was an exacting division between the structure, presentation, and behavior of the site. It wasn’t enough to simply use <div>s and proper heading tags; each section of the site was painstakingly deliberated over in terms of semantics, logic, and meaning. In our daily status meeting, the coders covered topics from accessibility theory to markup technique to the principles of DOM node addition; it was our own mini-Simple Quiz roundtable.
As a result, the technological base of the site is now rock-solid; in the years to come we’ll be able to do re-skins instead of wholesale rebuilds; allowing for a greater attentiveness to marketing, branding, and integration with our shopping tools. That’s not to say we don’t have areas to improve! You’ll be seeing our reworking of the Build Your Chevy pages soon.
- 6. QA
QA efforts were harried and rushed (as is to be expected). Anyone and everyone who could be put in front of a computer ran through the site over and over, looking for bugs, typos, anything that could be fixed, all well into the night during the days before live launch. Next year we’re going to have a more structured QA process, theoretically with “lock-down” dates, though I’m sure a few things will sneak in (again, something to be expected and accepted).
- 7. Prep for post-launch fixes/enhancements
After launch, we took a five or six second breather before starting into the post-launch effort. All the things we couldn’t get to by our live date came front and center. In the time since our live launch date we’ve been doing monthly mini-“refreshes” with new content, features, and fixes to various points and sections of the site. This “rolling redesign” technique certainly keeps us busy, but allows us to continually add value, improvement, and refinement to our product.
We’re currently moving into planning for the 2006 “refresh.” We’re going to capitalize on the coding groundwork (bolstered by the praise we’ve been getting from the web design community — thanks everybody!) and focus on enhancing the cool factor of the site, to reiterate the lesson that web standards-based sites don’t have to be boring. We’re also going to improve our shopping tools integration and improve our success metrics mapping so we can prove to ourselves and to our clients what kind of ROI they can see from our design and development philosophy.
4. What did Chevy have in mind that they wanted when they came to you? Did they say, “We want CSS and Standards goshdarnit!” or did you say, “The best way to achieve these things you want would be through CSS and Standards, goshdarnit.”?
Automotive sites go through at least a yearly revision, as new makes and models appear and need to be promoted. The agency wanted to incorporate a number of best practices principles we’ve developed in the last two years vis a vis web standards, usability, and accessibility. We lent a copy of Don’t Make Me Think to our main client liaison, and gave a presentation on web standards, which went over well. Between these two inputs, our client was completely onboard the “do it the right way” bandwagon.
Both the Krug book and the Nielsen/Norman Group report gave everyone involved in the project a common vocabulary for dealing with the user experience; the book has since become required reading for everyone involved in our Digital group (needless to say, this is paying off huge dividends).
5. What was your official approach to non-compliant browsers? How did this play into using the upgrade redirect?
We went for 5.0 browsers and above. This does not mean the site will not gracefully degrade for older browsers. Turn off the CSS and images and you’ll have a solid structure that any PDA can handle with aplomb. No rollovers. Flash is minimal, and all the XML information presented in Flash is redundantly available as plain text in the specifications sections, just as God intended it.
6. Do you have before and after numbers on things like page size, bandwidth savings and server calls?
I can tell you the homepage alone dropped from a modem-choking 1MB to a mere 135k — close to an 80% reduction. We’d like to continue with the weight-watchers program and trim any redundant CSS classes, pare down the scripts and nip and tuck things as we find more solutions. We’re looking into the numbers on bandwidth, but they haven’t been made available yet.
The nav was the big one. Accessibility was the primary concern and Matt took great pains to work out a logical system for the access keys, labels and ordering. Many designers just throw in access keys without taking the time to really consider what it’s like to rely on them. We are strong proponents of cross-browser testing and that includes JAWS. Apart from that, we used proper DOM methods, such as rel="external" for launching new windows. We refused to skimp on the alt and title tags and sent a few back to the writers to ensure a good experience for anyone, regardless of their browsing preferences.
8. What parts of the development process were improved by your use of CSS and Standards? What glitches did you find you had to overcome during development?
When it’s a few hours to site launch and a producer notices that a section needs to be temporarily removed pending approval or legal changes, you need to be able to simply hide an ID and have that global change applied instantly. Includes of course make site maintenance a cake walk. The biggest glitches I suppose were in the few sections of legacy code that we have little control over. That’s primarily back end. As a user, you’d probably never notice it.
9. Now that Campbell-Ewald has exploded onto the CSS and Standards scene, are there any plans to redesign your own site and practice what you preach?
I hope you mean the corporate site and not my personal site which has been XHTML for years and as of a month ago, 508 compliant as well! We are discussing strategies for a corporate redesign. It’s an older site and yes, we’d like to try a radical departure that will drop a few jaws.