The Weekly Standards

Followup Q&A: AT&T

Posted on 20 November 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.

Part One of this series is also available.

Due to the great response we received from our behind-the-scenes look at the AT&T website, the team has been kind enough to give an encore presentation.

You've Got Questions?

Hello! Joe here. Rebecca, Vincent and I appreciate everyone taking the time to weigh in with their questions and comments. Here, at long last, is our followup. We hope it was worth the wait!

For context, you're invited to read the original article first. Already caught up? Great, let's get started.

Screen Shots

Tom writes:

"Screen shots please!"

We've actually had screen shots waiting in the wings for some time, but they lacked supporting material. Not anymore. Here they are at last, complete with director's commentary.

Home Page

We begin with the corporate home page, www.att.com circa 2005. Aside from the header (1), footer (5) and common scaffolding, this is completely different from our other pages. (The header is slightly different but largely equivalent.)

Home Page

Markup

The first half includes one "featured" promotion (2) plus three "text" promotions (3) written as an unordered list. Promos are managed through our CMS and include a title, text teaser and link. Featured promos up the ante with a Flash teaser and a static image variant, should Flash or JavaScript be unavailable.

The second half includes four groups of links and descriptions (4), written as a series of definition lists. These same links also make up our header navigation (the corporate home page in miniature) featured everywhere else.

Class Names

It's often said that content and style should be kept separate. The same goes for content and the semantics that surround it. For example, rather than give the link groups redundant class names like "networking_solutions", "order_online" and so on, we chose short, one word, singular names: "segment", "purchase", "account" and "about".

Sure enough, the headers did change a few times, yet the class names never stopped making sense.

Style

This is the only page that includes completely separate screen, print and handheld styles. All other pages use one master style file that includes all others in turn. (For more on how this evolved, read "Layouts On Parade".)

With a hat-tip to Dan Cederholm, the lower half uses a top, middle and bottom background image that stretches the entire width vs. across each column. Combining them helps ensure that all three columns maintain the same height regardless of text size. The horizontal line dividing the third column is actually a border and not part of the middle image.

The text promotions proved tough to keep at equal minimum height across a variety of browsers. We were most fortunate to learn of GreyWyvern's min-height technique, which suits our home page just fine.

Behavior

Our Flash helper library swaps in the Flash teaser if possible, otherwise the static image is shown by default. We also tried sIFR-izing all the headers plus the featured promotion (sIFR isn't just for text!), but the plan was eventually nixed. However, sIFR is about to make a long overdue appearance on every other page. (Keep reading.)

Going Regional

We now move on to the standard page. In our first installment (see "You Gotta Keep 'Em Separated") we identified six major "regions" of content: header, title, index, sidebar, main, and footer. Let's have a closer look.

Title Region

Title Region

Markup

Nothing more than an <h1> with plain text, plus optional <meta> data tucked away in the <head> (more on why in a moment).

Style

By default, this is simply white text on a blue background. However, what we've illustrated above is something completely different ...

Behavior

If JavaScript and Flash are present and accounted for, we go the progressive enhancement route once again, just as we did for the featured promo, swapping the header text for a Flash movie. Created by Justin Bird, it uses the original text, replacing what used to be hundreds of title images. One file does it all, rendering each title as prescribed by our design agency.

Although we have used our own sIFR-like logic for a while, I'm pleased to report we're finally moving to true-blue sIFR. The Flash won't have to change though, as it's already sIFR compatible.

Titles can include an optional photo or drawing, and this is where the metadata comes in. Because the image must be loaded by Flash after the fact we opted for a fade-in effect. (Reverse dampening!) The image contains no trace of the title design. That transparent overlap in the final frame is courtesy of Justin, matching the original images. Should the design ever change, we'll just update the Flash.

While we've always recommended that headers be short and to the point, it doesn't always work out that way. However, the title is bottom-aligned, and we wanted to ensure that the text always begins on the same line. That's why the Flash also shrinks the text should it be too long. I've taken to calling this "The Nokia Effect" after observing how their phones (and others) shrink text to fit only if necessary.

Index Region

Index Region

Markup

Here we have a nested, unordered list up to three levels deep, surrounded by a <div>. For the eagle-eyed sensing some divitis herein, yes, we aim to phase out this rather nutritionless <div> at some point. More on that later.

Class Names

We put "navigation" on the outermost <div>. We then apply "expanded" to the appropriate nested <ul>s and "selected" to the <li> with the best matching link.

Style

The top level list has a dark blue background. Increasingly lighter shades of blue are used on the lower levels. The lowest level is also indented. Only expanded lists reveal their nested contents (if necessary). The selected item always gets a white background, connecting it with the rest of the page. Hovered items are underlined and adorned with an arrow.

Behavior

Classes can be applied on the server side when navigation markup is generated. Alternatively, by adding the "autoselect" class to the mix, expansion and selection can be performed client side as well. The autoselect technique is used all over www.att.com (see "Time Off For Good Behavior").

In response to Ken Krista's inquiry, a more extensive treatment of navigation autoselection is forthcoming. Stay tuned to Joe's Apt. for details.

Observations

At first we applied "selected" to both ul and li, but it proved confusing. Once we realized that selection made more sense for a list item, we began using "expanded" in the ul case.

As organized as the navigation CSS is, there's an awful lot of it. To be fair, it was also one of the trickier things to pull off. Perhaps, with the benefit of hindsight and lessons learned, we may be able to simplify it in the future. At least it's cached!

About the only other ick factor is our use of <div class="navigation"> vs. <ul class="navigation">. Probably not that tough to remedy, but then we must be mindful of those already using the style library, expecting it to work one way vs. another. Thus, we treat the CSS with the same respect we'd afford any other software project, deprecating the less favored bits and phasing them out for better ones over time.

As for why we used "expanded" and "selected" with an -ed ending, here's the logic. In cases like this, we clarify by asking if the word represents a command (implying behavior) or a final visual state (implying style). Since it was the latter, we added the -ed.

Sidebar Region

Sidebar Region

Markup

Here we have our RSS-friendly Newsroom page featuring a sidebar. All sidebars consist of one or more logical groups. A <div> surrounds an <h2>, followed by a combination of forms, lists and/or paragraphs.

Class Names

We assign "group" to the surrounding <div> and, in the case of sidebars, "vertical" to each <form>. That's it.

Behavior

Many forms on www.att.com borrow from Cameron Adams' Accessible, stylish form layout efforts.

Images

Just like our page titles, it's not uncommon for folks to want images adorning their sidebar groups. The AT&T Government Solutions site (below) is one notable example.

Sidebar Images

Alerts

It's also possible to subclass a group as an "alert" in one of three flavors: "information," "warning" or "critical". In this ever so slightly doctored example from Networking Exchange we can see all three variations at work.

Sidebar Alerts

Alerts are used sparingly and always located at the start of the Sidebar or Main Regions (never simultaneously). Most importantly, they are never used for a purely visual effect.

Main Region

The main region contains just about everything else. Here we focus on the one element that, more than any other, has been returned to its originally intended role.

Table, Main Region

Markup

A <table> containing data actually befitting a table! Imagine that.

Class Names

In this example we've applied two classes: "ledger" and "highlight". They can be used separately or in tandem.

Style

This demonstrates a technique we first learned from David F. Miller's Zebra Tables article at A List Apart. As much as we liked "zebra" we got hooked on "ledger" even more and so it stuck.

Behavior

Thanks to the "ledger" and "highlight" classes kicking off some DOM magic, we gain alternating row colors plus a bit of feedback while hovering over table rows. There is still some debate as to whether or not this is appropriate when rows are not linked to anything. (Your mileage may vary.)

That's it for the screenshots! Now on to more questions and comments ...

Visual Design

lee writes:

"... the site is ugly as hell on a bad hair-day ... put some people on the design and usability! ... pick a style and ride it through ..."

That last bit of sound advice sums up why we pursued web standards techniques in the first place. We wanted to stop reinventing the wheel every few years, not to mention breaking the car in a hundred places while removing the old wheels.

My team focuses primarily on the Corporate and Business sites. Both follow our markup conventions and use our style and behavior libraries, as do other sites like the AT&T Phone Store. As a result, these are all semantically and visually consistent.

Meanwhile, other AT&T sites do not use the libraries. For Residential Services, AT&T BusinessDirect(SM), AT&T Worldnet Service(SM) and others, this is a conscious decision, so they maintain their own independent markup and design conventions.

A few sites opted to apply the latest redesign on their own instead. Some, like AT&T Asia-Pacific, came fairly close visually. Some used only a portion of the libraries like the AT&T Business Center. For others like AT&T Labs Research, the design and behavior ended up being markedly different.

The point is that, while we do our best to enforce things when we're able, we aren't the "AT&T web standards tribunal" either. Our mode of operation has always been to lead by example and invite others to join in. Even within our own corner of the corporate world, it's not uncommon to get requests for one-off, isolated design changes.

Exhibit A: We were once asked to remove the icons from the alerts on one page. Why? To keep the background color and still have "more space" for the header text.

In our design system, colors are used for specific reasons in specific places. In the case of alerts, we want those colors to maintain their importance, so they aren't really used elsewhere. Also, color alone is not used to indicate an alert. That's where the icons come in. They're not used to give "more space" around the header text.

Exhibit B: We've also been asked how many letters can fit in a sidebar header without wrapping, and "can we make sure header text never wraps" on a page.

When we demonstrated how text size can be adjusted, the response was "No, I just don't want it to wrap at the default font size." Yes, there really are people concerned with content that doesn't wrap vs. the content itself.

I've come to realize that these requests, left unchecked, can lead down a very slippery slope. Although we've separated content, style and behavior, it is quite natural for content authors to continue thinking in terms of all three combined. The need for triage and education is both never-ending and essential.

On the other hand, others have zoned in on the content and discovered they now have more time to focus on actually writing it!

Library Structure

aliotsy writes:

"Is there any way that we can see a breakdown of the files in the 'standards library?'"

But of course! This was originally left on the cutting room floor. The library lives under /library/ and contains the following structure and primary files:

behavior/
att.js       Common behaviors
flash.js     Flash helper (includes sIFR)
metrics.js   Web metrics helper
(etc.)
include/
header.html  The common header ...
footer.html  ... and footer
(etc.)
media/
button/      Button images
logo/        Logos logos logos!
style/
att.css      The main style library
footer.css   The footer region
form.css     Form style
global.css   Common style
header.css   The header region
index.css    The index region
main.css     The main region
print.css    Print media
screen.css   Screen media
sidebar.css  The sidebar region
title.css    The title region
image/       Style-related images
home/        Home page style (screen, print, handheld)
template/
Example templates and markup for a variety of situations.

Naming Conventions

mlp writes:

"The reason why Yahoo and others don't name divs [header and footer] is because that implies position. What happens if sometime in the future you actually want to move what is currently displayed in to the left or right side."

We actually debated the merits of using ids (not classes) named "header" and "footer". While they can imply placement, for us they also imply order. In our case, they will always be used at the start and end of every page, at least for screen and handheld media. For print media they could very well be the start and end of every printed page.

Ryan Latham weighs in:

"In the end it is just names. They are what you make of them. However, they are a far lot easier to deal with than names such as 'block1,' 'block2,' and so on."

Exactly. Because "sidebar1" and "sidebar2" imply order, we named one of our sidebars "sidebar" and the other one "index" instead, further cementing their purpose.

Since we run our content through XSLT, moving or changing regions is a matter of adjusting templates and regenerating pages be they static, dynamic or a combination. Even without templates, XSLT comes in handy when remixing well-formed, valid markup en masse. Speaking of which ...

Valid Markup

Mike writes:

"The cms is far from xhtml compatible though. ... The webside story script tags should have type="text/javascript" not language="javascript" ... I'm looking on the enterprise business page. under div class="navigation" it seems to be putting in extra opening and closing unordered list tags. ... Hopefully someday you'll get the cms team to fix the ampersand issue. You guys are doing a killer job so far, I know the headaches of having to answer to a few people, I can only imagine having to deal with soooo many more."

Mike, thanks for the kind words! We've been acutely aware of all these issues. That you've taken the time to spot them only strengthens our resolve to work with our colleagues to get things like this fixed at the source.

We shared this (and other) feedback with the AT&T Business site and challenged them to improve their validation scores. Sure enough, they have made terrific progress and the results of their efforts should be online soon. One page in particular plummeted from an embarrasing 2,000+ validation errors to a mere five, and I expect the rest to disappear as well. Good for them!

Jesper Rønn-Jensen writes:

" ... unfortunately the site does not validate to XHTML Strict 1.0. That's pretty disappointing, especially when the errors popping up are no closing tags, and simple ampersands, easy to fix errors, even in dynamic driven sites."

It is frustrating, to be sure. Although "web standards" is not simply "well-formed, valid markup" (there's a lot more to it than that), validation against a DTD is a measurement anyone can take for instant feedback. It's a kind of behind-the-scenes fit and finish that we encourage everyone to be aware of.

Of course, if we're supposed to be leading by example, it's reasonable to expect the corporate site to have truly outstanding marks across the board, right? We'd like to think we come very close! However, there have been gotchas here and there.

For example, we've had one long-standing mystery: Some ampersands aren't converted to &amp; as we expect. They emerge as & in the final markup! (Accent on some. That's the problem.)

This puzzled us for quite a while but, at last, we've recently cracked the case. Was it the CMS? The content editors? The phase of the moon? "The answer may surprise you!"

These days, we are generating well-formed and valid markup almost every time and without ampersand hiccups. As we rebuild various pages on www.att.com, this should increasingly become the norm.

Bandwidth

Jesper Rønn-Jensen also writes:

"Any metrics on saved bandwidth costs. I suppose the new markup is cleaner and smaller. ...

The markup is definitely smaller. However, we could have done a better job measuring the overall bandwidth savings. We were so heads-down just getting things working, we figured "this is bound to be an improvement no matter what."

More importantly, though, the markup is a lot cleaner. Editors faced with markup changes have observed time and again how they can now understand the markup without having to ask a lot of questions, thus they are more confident when making changes.

Learning Curves

Michael Switzer writes:

"It just seems very apparent viewing the design and code that they were learning on the fly. While it's the best way to learn, getting your hands dirty, perhaps learning might be better done on a lower profile site. And a "learning site" might not be worthy of touting so much."

Nick Toye writes:

"... examples of work should be valid standard code. I don't think it is a case of validation is only for the purists, I think it benefits all in the long term, so if a site does not validate then don't feature it. Also on a side note have you noticed the date of the featured site on the home page, 2004???

As for www.att.com, "2005" does appear in the copyright. Perhaps it was a different AT&T-related site? Contact us with the specific home page and we'll be glad to investigate. In fact, if anyone has web standards related critiques or suggestions regarding specific parts of www.att.com, please don't hesitate to send details to wsi at att dot com.

To recap, while we have made our standards library available for other AT&T sites to use, we can't force-feed web standards company-wide. There are a lot of differing points of view out there and not everyone favors a standards-based approach. To this day we still encounter those who consider web standards to be impractical at best and an inflexible, purist attitude at worst. To us, web standards represents a forward-thinking, disciplined approach to building and evolving web sites, applications and services, and the future's open wide.

Yes indeed, guilty as charged. We're on a learning curve, and I trust we'll continue riding it, for semantic markup, CSS, XSLT, RSS, DOM scripting or whatever else comes our way. There will always be something new to learn. Always.

Read Part One of this series.