A List Apart


Tackling Usability Gotchas in Large-scale Site Redesigns

Improving usability is a good motivation for redesigns and was the driving force behind the ALA 3.0 redesign. But redesigns often introduce new usability problems. In this article, I’ll discuss one such problem and the way we addressed it, focusing on the creative dilemma and its solution rather than on the technical implementation details. You may be redesigning a large or mid-sized content site and restructuring it in the process. If so, you might face the same problem ALA did,  and the thinking that went into our solution might help you craft your own.

Initial problems

Article Continues Below

ALA was designed in 1998 and until recently was maintained by hand. Many magazine, library, government, and education sites began life the same way and face similar hurdles as they make the transition to standards-based design powered by database-driven publishing tools.

ALA’s oldest articles existed across multiple pages of quirks-ridden, presentational markup. Its more recent articles (2001–2003) lived in a CSS layout powered by semantic XHTML and were confined to a single page. The CSS layout aped the initial 1998 design and included its flaws as well as its strengths.

A List Apart 1.0, circa 1999
ALA 1.0 circa 1998–99.

The design process since 1998 had been iterative; as new features were added or reader behavior changed, subtle mutations crept into the layout from one issue to the next. Reading the magazine in reverse order of publication date was like participating in an archeological dig: you could watch the layout regress to the Bronze Age. Although the oldest layouts possessed a naive charm, the site would work better once all articles shared a common, up-to-date format powered by semantic markup and lean CSS layout.

A List Apart 1.0, circa 1999
The same site a few months (but many changes) later.

Beneath the surface, ALA’s reliance on hand-maintenance slowed production and decreased the site’s usefulness,  because an editor had to figure out topic and author relationships and manually update appropriate archive category pages each time a new article was published. A database driven by topics, authors, and dates would help readers make connections and find the content they were most interested in while automating many editorial and production tasks.

Initial solution

In August of 2003 I redesigned ALA, consciously breaking past brand associations and making more reader-focused use of familiar ALA conventions such as the right-hand sidebar, which had been with us since 1998. As he has done for our company’s clients, Brian Alvey then built a suite of custom publishing tools to deliver the site and its RSS feeds. (The system is also capable of generating PDFs, print, and newsletters, although we have not implemented those features yet.)

We dumbed-down the content entry fields — or smartened them, depending on your point of view — so authors can enter semantic XHTML instead of WYSIWYG text, add article-specific scripts and styles, and even hack the body element for scripting purposes. When an old article is reformatted, its markup is made semantic, its author is added to the author database, and the article can be found by its topic(s).

We also restructured our URLs, making them more logical and hence more usable. In 1998, I had dumped our articles and tutorials into a directory labeled “stories.” Back issues and hand-coded category views also resided in the “stories” directory. It had made sense to me at the time, but it was not logical and it needed to change. A reader would not think to look for CSS articles at /stories/indexCSS.html. The more logical place to look, and the place we now use, is /topics/css/. Seamless redirects ensured that people following old links would wind up in the right place. But at this point, a few days prior to the soft launch of ALA 3.0, we encountered a usability stumbling block.

A special case

Maintaining old URLs or seamlessly redirecting readers to new, improved URLs is essential for any site, but it’s especially critical for ALA. Visit any major search engine or directory and search on almost any web design or development topic; A List Apart articles consistently show up in the top ten results. Across the web, tens of thousands of hard-coded links to ALA content provide us with a steady stream of traffic. (Traffic remains constant even when we haven’t published anything new for a while.) We respect those links and that traffic. Moreover, there are developers out there who rely on bookmarked ALA articles in order to do their jobs. We had no intention of breaking our old URLs. Yet, midway through the redesign, it looked as if we might have to.

The problem created by the solution

In a perfect world, during the few weeks between design, implementation, and launch, we would have reformatted our hundreds of old articles and entered them into the system. In the real world, while redesigning and implementing, we were able to reformat and systematize about 60 old articles. (The rest are now being reformatted by Tanya Rabourn and Andrew Kirpatrick.)

A good old rule of usability says you should never break a URL — and I’ve already explained why we agree. Another rule says you should use URLs that are intuitive (i.e., /topics/css/). It was a simple matter to redirect bad old topic URLs to good, new, intuitive ones. But how should we handle old articles that had not yet been reformatted?

Suppose you bookmarked David Eisenberg’s DOM Design Tricks II when it resided at /stories/domtricks2/. No problem: the article has been reformatted and the system knows that its new location is /articles/domtricks2/. When you follow an old link, the system queries its database and takes you to the reformatted version at its approved URL.

Now suppose you bookmarked Fear of Style Sheets 4, a much-read (if outdated) piece that advised using pixels to spec type sizes in CSS because of the maddening inconsistencies and bugs in then-dominant browsers such as IE5/Win and Netscape 4. As this issue goes to press, Fear of Style Sheets 4 has not yet been reformatted, hence it does not appear in ALA’s database. Should readers be prevented from finding old articles? Surely not. What’s a mother to do?

An interim page for an interim period

Brian and I came up with a two-pronged solution:

  1. If an article has been reformatted, you are seamlessly taken to its new URL.
  2. If an article has not  yet been reformatted (if the system cannot find it at /articles/), you are taken to an interim page from which, with one click, you can read the old article in its original format at a slightly modified URL beginning old.alistapart.com.

We chose the interim page device to alert readers to the dated nature of the content, to advise them that the URL would soon change, and to let them know that certain old features might no longer work. (For instance, the discussion forum associated with a very old article will not work.)

Once an old article like Fear of Style Sheets 4 has been reformatted and put into the system, that article and its readers will benefit from the new system’s functionality and usability benefits. Until then, the content remains available and the URL has not broken.

Other methods: not as nice

I’ve seen this problem handled another way at other largish sites: namely, the URL disappears and the reader is told “We’ve moved some things around. Please go to our archived site [or please use Search] to see if the content is available somewhere or other.”

That method is guaranteed to frustrate readers. It might also anger the authors of the content that “moved around,” who may be linking to the missing material from their online resumes.

As bad as that is, it’s better than what happens at other biggish content sites, where old content is moved with no redirect, or can even be taken offline without explanation.

Our method beat the pants off those approaches, but it was imperfect for 72 hours.

Taking exception

ALA 3.0 was a “soft” launch in that we announced it while the world’s Domain Name Servers were still making the transition between our old and new DNS information. We were able to soft-launch thanks to the kindness of Bruce Livingstone of Webcore Labs, who had hosted ALA from 2000 through most of 2003, and who temporarily changed his DNS information to point to our new server. Until the DNS changes finished making their way through the network, a process that can take up to 72 hours, our subdomain-based interim solution did not work. Within 72 hours, the DNS finished rolling over and the problem solved itself.

Designing usability, daring to do less

Usability is like love. You have to care, you have to listen, and you have to be willing to change. You’ll make mistakes along the way, but that’s where growth and forgiveness come in.

The usability problem discussed in this article was one of many we addressed or are in the process of resolving. In the life cycle of most large projects there comes a point where you have to downsize your expectations, prioritizing deliverables in order to launch on time. Think 80/20 rule. Think “dare to do less.” If producing 100% of your desired features will delay your launch by six months, maybe you need to scale back, build what you can, take the site live, and then continue to improve it in the months ahead. That is what we’re doing with ALA.

When ALA 3.0 premiered with issue 160, some readers asked, where was our search engine? The answer is, it’s coming soon. We were unwilling to launch until we had solved the bookmark usability issue discussed in this article. But if implementing Search would delay the launch by months, it made more sense to launch sans Search (and add Search later).


ALA is more user-focused than before, but we still have a ways to go. That is the iterative nature of interactive media, and it also the mystery of life itself.

28 Reader Comments

Load Comments