Featured Site: AT&T
Posted on 16 May 2005 by James Archer
Disclaimer: This piece was written before the recent SBC / AT&T merger. As a result, the AT&T corporate web site may no longer be in-line with the content of this article.
UPDATE: This article no longer reflects the state of the current AT&T corporate site. Reports claiming that this article reflects the AT&T BlueRoom site are also inaccurate.
Part Two of this series is also available.
Click here to visit the AT&T website, then read on for all the details and behind-the-scenes stories about how it was created.
This piece began as a traditional interview, but when we found how just how much the AT&T crew had to say, we decided to work with them to reorganize it into an article. This gave them the breathing room they needed to share their insights in detail.
We've had a great time with them on this project, and they've set the bar high for whomever is featured next on this site.
You didn't come here to listen to me ramble, though. On with the show...
Table of Contents
- Dramatis Personae
- The AT&T Redesign
- Guest Pundit: Paul Scrivens
These are the crazy kids who not only took on the massive challenge of updating the AT&T website, but went the extra mile and decided to do it the hard (but best) way -- with CSS and standards-compliant code. Each of them brought unique skills to the table, and all of them walked away having learned quite a bit.
Interests: Music, film, theater, family, chess, cycling, anything on Adult Swim. Background: Raised "down the shore" in New Jersey. Survived college in Hoboken. Wrote commercial software for several years. AT&T: Joined Bell Labs in 1995. Currently technical producer for www.att.com. Homestead: Basking Ridge, NJ with wife, son and absolutely no dogs or cats. Favorite Scotch: Tape.
Interests: Gamera movies, comic books, Dr. Pepper and Not Being Photographed For Things. Background: Classified. AT&T: Joined Bell Labs in 1996 and has worked on www.att.com ever since. Homestead: Lives a quiet life with multiple dogs and cats. And a wife. Enjoys reading bad science fiction and watching the Cartoon Network. Favorite Stotch: Butters.
Interests: Cheeses of the world, beers of the world, monkeys, chickens, my husband, my dogs, and a good book. Background: Grew up in San Francisco. Mom and Stepfather ran a gallery South of Market. Saw lots of performance art in the ‘70s. AT&T: Joined AT&T Labs Industry Relations Group in 1999, began work with www.att.com in 2003. Homestead: Carlsbad, CA with husband and two very special canines. Favorite Scotch: Bonnet.
The AT&T Redesign
Our relentless pursuit of a standards-friendly corporate web site was the closest thing to a skunkworks project as any we've ever tackled. The first pass was completed in two parts between November 2003 and October 2004. It has been, without question, a most enterprising, challenging, and rewarding experience.
AT&T's Web Standards Initiative is still in the formative stages, and we aren't sitting still. Thanks in large part to the clean separation of content, style, and behavior, we've been able to make a number of site-wide updates and improvements over the past several months with little muss or fuss. Best of all, other AT&T web sites are starting to take notice and adopt the same techniques. (Huzzah!)
Here's the story so far—how we got from “there” to “here” as told from the front lines, directly to James Archer's inbox. Dim the lights, roll film, and…
Back To the Beginning
“Sherman, set the WAYBAC machine for 19 October 1994.” (“Yes, Mr. Peabody!”)
That's the day att.com debuted—on a Wednesday just over ten years ago. What started out as a modest press release collection quickly exploded with activity, accumulating tens of thousands of pages and spinning off a number of other sites.
With the arrival of WYSIWYG editors, pages could be created quickly, even hastily. We were smitten with single pixel GIFs, minty green backgrounds, tags used for their looks, nested table layouts ad nauseam, browser-specific behavior—all the usual suspects.
Perhaps as a natural consequence, top-level directories became sites unto themselves with their own producer, sometimes even their own design agency. The competition for attention on att.com alone was so intense, it wasn't unusual for these sites to be granted exceptions from the official design system.
As you can imagine, maintaining a consistent brand image and user experience was a never ending challenge. With each successive redesign, coaxing sites to fall in line with the updated design system became increasingly difficult. For some, the mere thought of redesigning was unconscionable. Their site had been built already. Why waste money building it all over again? Slowly but surely, att.com began to show signs of multiple design disorder.
In 1996 we actually tried encouraging well-formed, valid markup. I wanted to use Gerald Oskoboiny's Kinder, Gentler, HTML Validator on our intranet, only the source code wasn't available. So I built a matching version using the same ingredients, plus a few more extras thrown in for good measure. The service continues to be offered on AT&T's intranet and now features the W3C Markup Validation Service, on which KGV is based.
As the ‘90s drew to a close, we joined the burgeoning CMS craze. Our initial foray looked promising, managing our ever-growing collection of press releases as pieces of content and markup. We even tried our hand at NewsML and Dublin Core.
Alas, in a world where content was supposed to be king, it was hard to strike a balance with so much clamoring for form over function. The popular preference rested squarely with managing entire web pages versus content, and the multiple designs persisted.
Making the Leap
Fast forward to October 2003 and another redesign go-round. Sure enough, we got that familiar feeling of Déjà Vu all over again. We prepared to go down another rabbit hole only to emerge with more spacer GIFs, tables within tables of layout, embedded font tags, and all the other gremlins we knew we'd be left to deal with long after the redesign party was over.
This time, however, things were different. By now we had read Zeldman and Meyer. We marveled at the CSS Zen Garden from afar and occasionally caught up with the articles at A List Apart. Moreover, high-profile sites like Wired News and ESPN were taking the plunge, as were companies like Cingular…and then Sprint.
That's when it started to sink in. It wasn't a feeling of defeat or being beaten to the punch. All we knew was we were about to miss out on a golden opportunity for our web site, our customers, and ourselves. Helping to build momentum in the standards space would merely be icing on the cake.
As the saying goes, you can have it fast, cheap, or good—pick any two. The redesign was to launch during the 2004 AT&T Pebble Beach National Pro-Am…in February. The traditional redesign process was well underway, and there was obviously no budget (read: resources) for a company-wide web standards initiative. We had no formal presentations, no official cost savings analysis, nothing but years of in-the-trenches experience and intuition, and here the date and cost were already set. Was there really any chance for success? Should we even bother?
We studied the real-world, standards-friendly sites again. We imagined applying the same techniques to att.com one minute, then snapped back to our present-day reality the next, and so it went. Back, and forth, and back…and forth…until, finally, we made like Howard Beale and issued the proverbial ultimatum. At the end of the day, we were responsible for att.com's long-term health. Something radical had to be done and it had to come from within. We wanted to get off the merry-go-round in the worst possible way.
By this point we had grown so frustrated that we simply wanted to prove—if only for ourselves—that it could be done. With that, in the midst of the redesign effort, Photoshop comps in hand, we followed our gut and set to work by ourselves in private. At lunch, at night, on weekends—it didn't matter. It was time for the Keebler Elves to get busy.
The Origin of the Content Species
We used CSS before, but only in a basic sense—mostly colors and fonts. This time around, we wanted to lay a foundation that had a fighting chance to survive multiple revisions. So—where to begin…
In the beginning, Rebecca was plenty busy creating title images for each page and managing a number of sub-projects, but she also happened to be a driving force in documenting the new design system that was under development. Her design savvy and knowledge of all the “little details” would prove invaluable a few months later when our paths crossed and our projects merged into one.
Our first step was to take a random sampling of pages and focus solely on the content, ignoring disparate style and markup. All those years of coping with multiple exceptions left us extremely sensitive to the value of proper semantics. Thus began our obsession with identifying, organizing and naming everything in sight, like a pair of cautious anthropologists. We posed questions like: “What does X want to be? What is its ultimate purpose in life? Can it be broken down and simplified? What else is X related to?”
A few weeks later we were ready for the markup, and we knew exactly what we wanted in our arsenal: XHTML 1.0 Strict. To be sure, people had their doubts, but then this wasn't meant to be just another “transitional” phase either. We were naturally attracted toward something with less wiggle room than usual. Ultimately, XHTML 1.0 Strict's most valuable role was that of a catalyst for change, a kind of “tough love” for markup gone awry.
Of course if we simply told everyone to “use XHTML” and walked away, we would quickly end up with markup every bit as convoluted as our “HTML 4.01 Transitional” ever was! The cost of entry—and upkeep—still had to be lowered. It was up to us to create markup examples that were easy to understand, useful and devoid of style, thus becoming amenable to CSS restyling many times over. In the blogosphere this is commonplace. Not so in our corner of the world! Almost overnight, that tunnel with the light at the end got a whole lot longer.
Layouts On Parade
Our next stop: Defining the high level parts of the page that would form our page layout. We named six regions: header, title, main, sidebar, index, and footer. Each one had a specific intended usage, no exceptions. The main region was for core content, the sidebar was for supplementary information, the index region was for various forms of site-specific navigation, and the title region was unique to each page (thus considered separate from the header).
This brought us to the first CSS-related task, styling a page layout that matched the new design. It was at this time we had to emerge from the shadows and begin negotiating with the rest of the design team, for we learned there was not one, not two, not three, but several layouts with no strongly defined function or purpose. In fact, we were to accommodate just about any arbitrary arrangement of repeated main, sidebar and index regions across and down the page.
Sounds a lot like using tables for layout, doesn't it? That's exactly what it was. Obviously this was going to be a hard habit to break.
It's not that we were diametrically opposed to the concept of tables for layout, especially for complex forms (although we did try Cameron Adams' accessible, stylish form layout technique). We were not only thinking of screen media, but looking to support print and handheld as well, something the visual designers were not charged with tackling. Not sensing any resolution to the “what is each layout's purpose” question, and eager to keep things moving, we agreed to try supporting up to sixteen primary “region arrangements”…with the added ability to repeat them in any combination down the page, all from one CSS file.
What were we thinking? We had no idea what we were in for. Nevermind all the browser idiosyncrasies, that was just the tip of the iceberg. After an abundance of trial and error…and error…and more error, we finally happened upon Petr Stanicek's (Pixy's) 3-column layout technique—simple yet effective. We took it and ran.
A few modifications later, we had ourselves a serviceable page template factory. Thanks in large part to Pixy's technique, we got as far as supporting ten of the proposed sixteen region arrangements. The downside of this Faustian deal, however, was the document order, namely “index, sidebar, main” vs. “main, sidebar, index.” It wasn't as user-friendly when styled for handheld or even print media, depending on what regions were visible and how they were presented. For the time being, print and handheld style would have to wait.
What became of those sixteen layouts, you might ask? Seven of them became our master page templates. Of those seven, only three are frequently used today. Ouch!
Armed with our page layout CSS, we needed some way to generate different templates automagically. Unfortunately, we didn't sense a good fit between our XHTML and the CMS we were using at the time. With Pebble Beach looming, we pulled a MacGyver and built a makeshift CMS out of shell scripts and symbolic links. Now we had a quick-and-dirty way to rapidly build, test, and deploy the requisite starter set of thirty-odd pages. Even with this effort, we had yet to finish styling our markup, and so we had no choice but to publish the newly redesigned pages as originally delivered.
Meanwhile, as we pursued CSS nirvana, another new (and budgeted) project was underway. att.com was getting a new CMS, one that actually used XML for content and XSLT for rendering markup! By way of transition, the plan called for a hybrid of managing “chunks” of markup alongside pure content. Once we realized those chunks mapped neatly to two of our page regions, we resurfaced once again and asked to meet with the CMS team.
Plan Of Attack
- Existing Pages (HTML 4.01 Transitional)
- Identifying “regions” of like-content (header, title, index, sidebar, main, footer)
- Classifying different kinds of content
- Early page layouts and rough-sketch templates
- Markup (XHTML 1.0 Strict)
- Defaults (p, h1-6, li, dl, etc.)
- Classes (other types of headers, paragraphs, lists, tables)
- Complex constructs (forms, alerts, press releases)
- Images and media (as used in paragraphs, headers, lists, etc.)
- Style (CSS 2.01)
- By content region
- By tag
- By id and class
- Behavior (ECMA-262)
- Common library (browser-independent helper functions)
- 3rd party libraries (web analytics, flash, forms, etc.)
- Behavioral classes (navigation autoselection, table highlighting)
- Metadata (definition and use)
- Evolution (Bugzilla)
- Triage (Design Agency requests, Bug Reports, other feature requests)
We gave them a crash course on web standards, demonstrated our work to date and explained our longer-term plans. While the impromptu demo didn't go as smoothly as we would have liked, the discussion that followed was an eye-opener. The opportunity for synergy, of keeping content and style separate, was a no-brainer to everyone present. With that, they encouraged us to finish the initial templates and styles as soon as we could. If we could deliver within their project timeline, our efforts would be incorporated—simple as that.
It was a perfect match. Each team approached the content/style problem from opposite ends of the same bridge. We now had a fighting chance to meet them in the middle and extend our reach to the rest of att.com in the process…
The Public Library
…but why stop there?
In recent years, AT&T Labs began promoting the Concept of One (“do it once, do it well, do it everywhere”) and Concept of Zero (“automate”). Indeed, our decision to craft a standards-based site was, in part, made in the spirit of these two concepts.
As we worked toward a consistent user experience and brand image, it occurred to us that other AT&T web sites should have the same opportunity to use our work, even help improve it. In a brief detour, we renamed and reorganized all our files and directories into one cohesive “standards library” fit for syndication.
The proposal: Follow the rules of the XHTML road, use appropriate markup and classes, and the library will do all the heavy lifting. Cross-browser support? Not to worry. New features? Get them for free. Future redesigns? Covered.
Land Speed-Style Record
At long last, on to the core CSS! By now we were learning things at a breakneck pace, often times the hard way. A deadline was looming and we intended to meet or beat it. Although we were working on other things during the day, by this time we were claiming 20% of the work week in the name of web standards. Every Wednesday, we would meet in person, behind closed doors, to face the tougher challenges head-on.
We had to navigate some unusually paradoxical waters, writing first for the W3C specs, then compensating for various browsers. In doing so, we had more than a few scary moments, as in “hit a brick wall,” “dead in the water,” “you'll never get out of this maze” scary. Our first attempts at styling markup within the context of all those page layouts were 100% colossal, embarrassing failures. It got so bad that, at one point, we actually had to stop for two weeks and just walk away from it completely.
Then, out of the blue, we had the first of several “a-ha” moments, those bits of clarity that register pleasantly in the frontal lobe. Naturally, we wanted more of that web standards buzz (groan). Before long, we developed an entirely new appreciation for the likes of A List Apart, css-discuss, Position Is Everything, QuirksMode and numerous other founts of standards knowledge. The sheer volume of collected know-how, especially in the blogosphere, was at turns overwhelming, reassuring, and inspiring.
Before long, we were trial ballooning all kinds of techniques. We'd sift through the forensic evidence, learn what we could, and then try something else. After several iterations we'd emerge with a deeper sense of what worked, what didn't, and—most importantly—why. Our “standards common sense” was improving by the day.
It was at this point that Rebecca officially entered the picture. By now she had moved on to devising and filling in various design system gaps, so it seemed like a natural progression for us to start collaborating, not to mention keeping each other in sync.
While the new CMS wouldn't be online until late 2004, we had reached a plateau in late April and decided it was time to launch. With that, we published our modest set of redesigned pages, including a home page retrofitted with semantically meaningful XHTML and CSS. We took an ever-so-brief break to explain how things worked behind the scenes to anyone who would listen. Soon, colleagues started taking notice, affirming that we just might be on to something good. The sense of accomplishment we felt, the recognition and encouragement received—especially from the online community—was priceless.
Nourishing as that experience was, we knew that we were still far away from our first major goal. No att.com “sites” were affected at this point. By our own assessment we were barely scratching the surface. Plenty of groundwork remained to be covered if we expected to make the CMS schedule by summertime.
Time Off For Good Behavior
Leveraging client-side behavior and the DOM was not on our radar at the outset. After all, we had our hands plenty full just with XHTML and CSS. However, as we soon learned, judicious use of the DOM helped simplify a number of things across att.com. One area in particular, the navigation, didn't even start out as a candidate for the DOM treatment. In fact it was completely new territory, as the navigation had yet to be truly designed.
First, we coordinated with the CMS team and agreed to support navigation up to three levels deep. Every att.com “site” was to maintain its very own nav list. While the CMS team worked on managing navigation items as pure content, we worked to organize the markup and style. For a while it looked like we could cover our bases entirely with XHTML and CSS. After all, the CMS would simply generate the appropriate navigation markup for each page…right?
Not so fast. The CMS team expressed concern with the prospect of generating so many different navigation variations. Changing one item could easily imply rewriting several pages, if not an entire site. Walking the navigation and parsing the links in real-time could help, but for all those thousands of pages? We had to keep this simple for everyone involved. What to do?
This is when we decided to stop worrying and love the DOM.
The CMS team agreed to generate one server-side included navigation per site, with all the items already incorporated. They would also specify a new class, “autoselect.” If encountered upon page load, the behavior library would intervene, walk down the navigation, find an exact-matching link, select the item, disable the link, then walk backwards, expanding and revealing each parent level.
For cases where a page was not linked within navigation (for instance, one of many whitepapers), a second revision allowed the use of metadata to forcibly select a reasonable item (e.g., “Whitepapers”). A third update looked for the best-matching link instead, which in turn had the beneficial side effect of encouraging better site organization.
A Plan Comes Together
As fall approached, all that sweat equity in markup, style and behavior began to pay off. We continued spreading the word to other AT&T web developers. We gave an impromptu demo and presentation to the core att.com team, furnishing plenty of links to “why are we doing this” resources for good measure. We were even granted the talents of a technical writer who helped organize all our thoughts into a web developers guide that would explain, step by step, how to prepare for, install, and use the standards library.
As for the CMS…we made the deadline! What followed next was unlike anything we had experienced before, a mammoth effort to take apart all those att.com “sites” and reorganize them in the new CMS, standards libraries at the ready. To us it seemed like an insane kamikaze mission at the time but then, as the saying goes, no pain no gain. There was a lot of tough love going around by this point.
The CMS team was as relentless in tackling each site as we were in pursuing standards enlightenment. Even producers and design agencies pitched in to do their part. While Vincent and I helped field standards library questions and bug reports, Rebecca ran ahead, helping to analyze and direct the trickier surgical transplant maneuvers.
We didn't get every last site converted by the next deadline, but the CMS team was not about to let that stop them. Either you were on the bus or you were off the bus. There was no gray area. The rest would be allowed to follow later.
With that, in late 2004, we flipped the switch and a new, increasingly standards-friendly att.com was on the air!
After stopping briefly to celebrate, the conversion effort resumed at a steady pace. As for us, we soon found ourselves with no shortage of new challenges to tackle and questions to ponder.
This time, however, things were different. The landscape had changed for the better. We knew we could tackle things once, in the standards library, and this time everyone stood to benefit from each and every improvement.
January 2005. Another year, another home page redesign…just in time for Pebble Beach!
Like most redesigns, it started life as a wireframe, then ended up as a series of Photoshop comps. One of our first litmus tests was to draw an imaginary thread through all the content and pull it taut. We wanted to see where everything could possibly wind up along that thread, thinking in terms of pure content and markup. Soon, we had ourselves a document order that everyone could agree upon. We would let the designers work their magic, await the final comp, and then go straight to work.
When the final comp arrived, we found exact dimensions, fixed-size fonts, images for headers, and for a fleeting moment we had an unusually strange craving for tables. But of course we wanted none of that. The hard lessons of the past were not about to be repeated! This time, we were intent on creating a standards-friendly page that captured the design as closely as possible, was scalable, and accessible—across screen, print, and handheld media.
Oh, and we had but a few weeks to build and launch the whole thing. (Right. No pressure.)
The story has already been told elsewhere but, to make a long story short (“too late”), just over two weeks and ten markup/style revisions later, we had a new home page with all of the flavor and none of the guilt.
“Hey! This standards stuff really works!”
Just over a year has passed since we first threw ourselves into the standards pool. So how's the water? Exhilarating.
Our design system is more self-governing than ever before. It crystalizes how to markup content in a way that was previously vague. People tell us over and over again how much easier it is for them to build pages, and that they didn't fully appreciate just how mind-numbingly difficult it used to be.
We have adopted a balanced, triage-style approach to evolving markup, style and behavior. We try not to rush too quickly, nor go at a snails pace. Instead, we favor a healthy trot, even an occasional jog.
Our standards library is being used on the intranet and internet. Several AT&T sites are already in various stages of evaluation or implementation of our libraries and techniques.
Design agencies and content managers are making positive contributions. In some cases we have what we like to call “happy accidents.” Something will be created that doesn't fit the new paradigm, only to give rise to some new class or markup construct to add to our bag of tricks. What starts out as stylistic rationale is distilled to functional motivation, then rebuilt, usually emerging with far greater semantic “sense of self“ and style to match.
People are beginning to talk about the broader web ecology. They are getting involved—and invested—all over again. We find that colleagues new to web standards discuss it with the same interest and intensity previously given to minty green backgrounds and spacer GIFs.
We're teaching others how to fish. All the markup, style and behavior we've developed is online for study, just like any other web site. There are no trade secrets when it comes to web standards. It's an open book, and we're all reading and learning together.
Bottom line: Adopting web standards isn't a magic elixir but, with commitment, careful application and steady evolution, the dividends are unquestionably there for the taking.
If We Had To Do It Over Again
What do you mean we're starting over?! From the “could've would've should've” department, if we had our druthers, we would:
Reach out to more of our colleagues up-front so they could understand more clearly what benefits we hoped to gain, but also the limitations it imposed out the gate. For instance, exceptions are often the bane of cultivating a consistent design, thus we would have done well to formalize and explain our long-term plans more clearly at the outset.
Tackle information architecture beyond the page level. How do we name and organize our navigation? Our directories? Our files? Our domain names? By putting the “reduce, reuse, recycle” maxim into action ourselves, content managers are given more incentive to stop, breathe, and think along the same lines.
Insist that templates be given a specific purpose, not just named based on their screen appearance. By focusing on the functionality first, we would have likely ended up with fewer templates to devise and style, which would have allowed more time to…
Create a more sensible document order, placing the main content region toward the top of the page versus the bottom. This kind of attention to detail helps with styling for print, handheld and other output media where content sequence matters.
Limit the use of <div> to the page scaffolding. A few have settled in around our navigation and sidebar groups. It's not a hard and fast rule to keep them out of the content areas, but it never hurts to think in terms of semantically-rich elements first.
Put more effort into styling images and forms. Thanks to the efforts of our design agency partners, we're now beginning to see new, self-contained combinations of markup and style—many centered on effective image use. The best of the best will be standardized, perhaps even DOM-enhanced, then added to the library for everyone's benefit.
Link to style sheets based on output media instead of linking to one CSS file that includes several others. We expect this situation to improve in our next major revision, plus we'll reduce the number of overall imports.
“Time For A Little Stragety”
Our next question comes from James Archer of Arizona, who writes: “Dear Joe, Vincent, and Rebecca: How does working on a site of this scale and prominence differ from the smaller projects with which most designers and developers are familiar? Signed, Not Strong Bad.”
Dear Not Strong Bad, you should really change your name. Soon. It's so awkward sounding it's painful! Almost like a bad inside joke. Or a sitcom title…or something. Anyway, to answer your question:
The most obvious difference is the sheer amount of content…and people. There are so many personalities involved, and so many meetings: status meetings, scheduling meetings, review meetings, design meetings, technical meetings. The amount of time spent discussing a project can easily exceed the amount of time doing actual work.
Large scale sites are not a “fire and forget” type of project. Designers and agencies need to remember that, once they are gone, someone's got to maintain what they did. Having the people who are ultimately responsible for maintaining the site involved in any redesign is extremely important. They usually know more about the site's history and behind-the-scenes idiosyncrasies.
We feel an enormous sense of responsibility in cultivating our standards library. When someone doesn't understand something, they are more likely to be wary of it, be they a content manager, web developer or end-user. A lot of people are depending on things staying simple. That takes a lot of concerted effort.
It's very easy to come across as being dogmatic about web standards, when instead you're really just forging ahead into new territory. That can be scary, perhaps even threatening to some. It's important to make sure that artistic direction is allowed to flourish, while at the same time insisting on mutual understanding and respect for the web site as a longer-term entity.
At one point we were told that XHTML 1.0 Strict was “too strict and the likelihood of validation is very low”—in short, we'd never be able to create a system that would work effectively enough to be used site-wide, much less company-wide.
We now keep that note on my whiteboard, right next to a successful W3C validation of the home page.
We realize that not all pages are 100% valid, but we'd be crazy to try and make that work “all at once.” That's a surefire way to train wreck things.
It has been said that “Discipline is never an end unto itself. Only a means to an end.” The same goes for web standards.
There is a lot of focus on “savings”—time, dollars, bandwidth, you name it, someone wants to measure it. Whenever faced with this question, we've always responded in terms of using our resources more intelligently instead. To borrow another well-worn cliche, it's all about working smarter, not harder.
Most of the time, people know what they want, not what they need. This isn't a dig. It's simply more natural to be in a mode of discovery-as-you-go. We certainly have been! A careful balance must be maintained in guiding ourselves, content managers, producers and designers toward common web site goals, but without totally compromising our individual and team goals in the process.
The pressure is often high to make snap decisions that may affect a number of sites, only to discover ramifications later on. This is where triage can make all the difference. Even spending time away from things, however briefly, offers much-needed balance and perspective. Patience is always rewarded.
There's a lot of rework happening in parallel: CMS, CSS, XHTML, ECMAScript, Java, and so on. You have to give each a chance to succeed without getting in each other's way. Sometimes that means taking turns as you bring things in-line. In time, you start to work more confidently, without as much fear of collision.
You have to accept that you can't please everyone all of the time. This is certainly true for small to mid-size projects, and it's virtually unavoidable in the corporate world. The most important thing in any event is to keep your ears open. Listen—early and often.
Web Life Lessons
Words we try our level best to live by.
Form follows function, but both are essential for balance. You know the saying “Content is king?” Here are three more: Markup is queen. Style is the castle. Behavior is the messenger…or perhaps the castilian. (OK, that last one needs work.) The point is that the best visual design in the world is far more effective when all the fundamentals are in order and running smoothly.
The limitations are the allure. In the CSS Zen Garden lies a neat little paradox. It works because the underlying structure is consistent and has well-defined boundaries. It's not unlike raising a child and setting reasonable limits.
Strive for an environment that guides people down the correct path as a natural consequence. People should feel confident, not penalized. Maria Montessori's self-correcting teaching materials serve as a good real-world illustration.
Take the time to name things carefully. This can't be overstated. Whether you're naming part of a web page, a class, an ID, an ECMAScript function, a template—anything—it's incredible how much a name can affect everything that follows. Once you name something and let it out into the wild, expect it to take on a life of its own.
Stuff We Wrote On The Whiteboard
- Measure twice, cut once.
- Make it as simple as possible, but no simpler.
- You have to know the rules before you can break them.
- Take care of your customers, and each other.
- When it comes to teams, three is a magic number.
- Trust your gut instinct.
- Maintain a sense of humor.
- Learn to juggle. Lacrosse balls are an excellent choice.
- Go for a walk. Or a jog.
- Resist drowning in process. Learn to swim.
Too many exceptions spoil the soup. With each one comes additional responsibility. Take care not to undermine the consistency in experience you were working toward in the first place, but do have a place to experiment. Cultivate a select few “boutique” pages where you can dive into the really deep end of the pool. (We use our home page. “Fate loves the fearless!”) Just make sure others understand why these pages receive special treatment.
Web standards goes beyond XHTML, CSS and ECMAScript. It reaches clear through to java beans, XSLTs, web server configuration, domain names, URIs, and all the other ingredients that make up a web site.
Don't believe the “internet time” hype. Speed kills. That's not to say move at a snail's pace either. Taking a calculated risk is one thing, but putting too much into production too quickly can turn into a Pandora's Box of hurt. To keep things in perspective, imagine you're turning a flywheel instead.
Maintain an element of humanity in everything you do. It's far too easy to get lost in the day-to-day mechanics. Remember to have a life.
“There's no substitute for the work, not even genius.” ‘nuff said.
The Look-ahead Cache
We close by hazarding a few guesses at where we think web development is headed in the next two to five years. Hopefully sooner.
WYSIWYG editors will make information architecture a natural part of the editing process, all the way down to the humble URI. This will help improve the focus on the bigger picture, not just each page unto itself.
The tyranny of the unescaped ampersand will finally end. Save XMLSpy, XStandard and other notable exceptions, we have to ask: Why do so many CMSs and WYSIWYG editors still have a problem writing & as &? It sure drives us nuts. (As if you didn't know.)
We'll stop using ampersands to separate query string params…and start using the semicolon. Hey, it could happen.
All eligible web browsers will pass the Acid2 test with flying colors, only by then there could be a serious disconnect in trying to pass Acid3. “Plus ca change…”
The reverse-DNS naming style will become de rigeur for behavior libraries, keeping one developer's chocolate out of another's peanut butter once and for all. Add in anonymous functions for a tasty treat!
A formal standard will emerge for fashioning standards-friendly XHTML/CSS/DOM widgets. Think AJAX, only better—not unlike Apple Computer's Dashboard widgets. They'll be skinnable and easily plugged-in to any web site or development environment without adverse side-effects. As with other technologies, the widgets with true staying power will also be the most useful, usable and aesthetically pleasing.
Guest Pundit: Paul Scrivens
Paul "Scrivs" Scrivens is the creator of the world-famous, trend-setting CSS Vault, and more recently the mastermind behind the Internet-changing 9rules Network. We've asked Scrivs to provide an objective analysis of the AT&T website code, based on his extensive experience and knowledge of the subject.
Large corporate sites moving to XHTML/CSS layouts is nothing new, but when you finally see one that uses standards just as well, if not better, than many of the standards sites we visit everyday you tend to take notice. When James asked me to critique the code for their redesign I can't say I was that enthusiastic to look at more CSS code from a corporate site, but after viewing the code I became very interested because right away you can see the work of a team that cares about web standards.
Well-formatted code shows that the developers understand the importance of being able to find code quickly so that changes happen in real-time instead of trying to navigate a labyrinth of code.
Unlike Yahoo's code, AT&T uses common terms to express their <id>s and classes. Again this helps to maintain the usability of the code. The header is actually labeled "header" and the footer is labeled "footer". Keeping it simple goes a long way in improving productivity.
Numerous CSS files
A print stylesheet and handheld stylesheet have been provided to help complement the screen stylesheet. This shows the importance the design team put into allowing the majority of users across all platforms to view the site.
As designers, some of us (myself included) have fallen into the trap of avoiding the use of a print stylesheet simply because CSS does a great job of degrading when no CSS is used. However, this doesn't mean that if the page is printed it will be optimally formatted or look remotely decent.
I am very glad to see the team take the time to create two extra stylesheets because it shows the future thinking approach they were taking.
Internet Explorer used to be quite the burden on CSS developers because while it usually is easy to create a valid, working site in Gecko-based browsers, IE would always seem to throw a curveball. The fixes usually required some use of CSS hacks that would only be applied to versions of IE. I think as developers we have progressed quite a bit in understanding what will work in IE and what will not.
The AT&T team decided to use the
* html #divhack to
get IE to render the code the same as it does in Firefox. Although I
don't like to see hacks in CSS because they can add a bit more code to
your stylesheet and cause a bit of confusion, the development team has
managed to use the hacks while keeping the code extremely readable.
If you do a Google search for CSS and XHTML validation you will see a number of arguments both for and against creating sites that validate. Many of the arguments against validation is that corporate websites have no need for it because it adds extra time to development and therefore requires more money for the project.
I noticed that the developers decided to use XHTML 1.0 Strict and figured they simply did so without any reasoning and that their code would not validate. Imagine my surprise when I ran it through the parser and it came out clean.
The print and handheld stylesheets didn't validate, but only exhibited one error each. Superb job by the development team recognizing the importance of validation in any type of setting, be it corporate or personal.
The forgotten stepchild of XHTML, definition lists can prove themselves to be extremely powerful if used properly. I was extremely excited to see definition lists used within the code and done so with proper semantics in mind.
Very rarely do you get to run across a web standards based site from a large corporation like AT&T. Even more rare is finding such a site that contains code cleaner than many of the designer's blogs we read daily. I have a great deal of respect for the effort put into the coding of the site by the AT&T team and can only hope that other large corporations begin to take notice.
— Paul Scrivens
Read Part Two of this series.