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#section2
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.
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.
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#section3
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#section4
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#section5
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#section6
Brian and I came up with a two-pronged solution:
- If an article has been reformatted, you are seamlessly taken to its new URL.
- 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 beginningold.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#section7
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#section8
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#section9
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.
All common sense stuff, but it’s best to think about this stuff before you redisgn a site so this might save many thousands of web designers sleepless nights.
There are certainly some aspects I hadn’t considered and the “80/20” is always a good one to remember. I need to remember that sometimes…
agreed with the above – all common sense. Sadly though not everyone sits down and plans steps like those until after doing a rm -r 😉
You must get those huge funktastic title graphics back again!
Yeah, I’ve read you’re “consciously breaking past brand associations”, but those titles were unique, no matter how good Trebuchet looks these days…
“Seamless redirects ensured that people following old links would wind up in the right place.”
This is probably a fairly dumb question, but can anyone give me a pointer on how to approach / where to do some reading about these seamless redirects – is it javascript on the old pages or something more intelligent?
There are a number of ways to perform redirects, from using javascript, to custom error pages using server side scripting, to using Apache tools like mod_rewrite.
I can’t speak to what was done for ALA, but the basic theory for using custom error pages involves pointing all requests for pages that don’t exist to a custom error page. That error page usually has some server side scripting that checks what page was requested, checks to see if that content exists currently, redirects if possible, and if not provides a best-guess about what the user was looking for. A good example of this is at php.net, where if you type http://www.php.net/mysql_connect you go directly to a manual page, but if you type http://www.php.net/mysql_c you get a list of functions that might be what you were looking for.
For sites that have as much content as ALA, using a database lookup that correlates old content to new content works very well. This isn’t the only way though. Apache’s mod_rewrite (assuming you have control over your Apache configuration) can be given a correlation chart and be made to do the redirects. This can also allow the web server to send appropriate error codes, letting the client know if the content is missing, has been permanently moved, etc. One issue that then comes into play though is which method is the best use of your resources, as it’s my understanding that mod_rewrite can be a work intensive method for the web server.
The bottom line: there are many ways to achieve the results Zeldman mentions in his article. Using some of the keywords above (custom error pages, mod_rewrite, etc) and google should get you to the resources you need.
In our case it’s done with ASP, but it can be handled many ways. One reason I like working with Brian is that, although his business card says he’s a developer, he thinks like an interaction designer — that is, he considers how people will use online materials and tries to find ways to make usage easier, more convenient, and more intuitive.
In this article I focused on the thinking behind a particular problem rather than the implementation details. But in answer to your question, I’d use JavaScript redirects only as a last resort (i.e., when you have no access to server-level or database-driven tools).
Hi,
Thanks for the quick responses and pointers – I’ll have a look at which options are open to me. I was sure that javascript was a clunky solution, but wasn’t aware of some of the other avenues available to me.
I imagine the custom error page approach will prove to be the most feasable approach.
Thanks again!
We’re going through similar growing pains with my university’s site. There are over a thousand pages of crap HTML with no standard template – all put together by hand over many years – at URLs that sometimes make sense and sometimes don’t. Now we’ve finally got a workable CMS and a small but dedicated staff who care about design and web standards. I feel a little more confident about the journey ahead after reading “Tackling Usability Gotchas.” Thanks, I needed that.
I don’t have much to say about discussing this article, I just wanted to say that it was a good read and I’ll probably be re-reading when/if I ever need to do a redesign like you’ve done.
I would use a customised 404 page to inform the search engines that the page presented is not the correct one and to drop any out of date listings from their index.
Thus, the new page will be spidered and indexed while the old one will disappear.
Course I havn’t checked whether this is the case because its Friday and I’m drunk and Jools Holland is on BBC2 🙂
The problem with dropping a page out like that is a massive loss of search engine popularity. Not many people will update links to point to a new version, and you can bet that some older links will never be updated. If the article itself is fairly old, but still relevant, you can bet that there won’t be new links incoming, so a potentially useful page will have dropped off the search engine radar.
The appropriate error for a page that has been temporarily moved is 302. If a page is temporarily moved, you should have your webserver supply the client with a 302 error, then forward the user to the proper location.
The appropriate error for a permanently moved file [in the case of ALA, and most other sites, I imagine] is a 301 error. If you feed a 301 error to most modern browsers, the browser will update the bookmark used to access the page.
Obviously sending a server error condition to a user-agent requires access to the webserver config files, and not everyone has that. That said, the above is “how you are supposed to do it”
Thanks for an insightful article
Christopher Harrington
manuel razzari wrote:
<<>>
Thanks for the kind words, Manuel. Like the funky color schemes, the funktastic title graphics seemed to belong to an earlier era of web design. Their style expressed ideas and feelings that fit the magazine in 1998–99 but no longer expressed what it was about.
The old look was playful and campy and deliberately rough-edged — appropriate attributes for an aggressively indie site of the 1990s. But over the years, the magazine has become more deliberate and more focused. I wanted ALA’s look and feel to reflect the thoughtfulness of its content. The oldstyle header graphics were a casualty of the need to reposition the visual identity to better match what ALA is really about and how it is actually regarded in the community.
In the future we might use illustrated title graphics again (in a different style that fits the revised identity). Or we might not. After five years of illustrating every headline, it’s kind of nice to simply present text as text — and it seems to help the mind focus on what is being said instead of being distracted by extraneous issues (such as the quality or lack thereof of a particular illustration).
… that was an extremely longwinded way to say: “We think it would be bad to break the old URLs when we redesigned, so we didn’t.”
Why the intermediate page requiring an extra click?
Why not just let the old content stay at the old addresses until it’s been imported into the new design/system, and then – only then – redirect from old, now converted, addresses to new?
<<>>
As explained in the article, the intermediate page is there so readers will know that the content is outdated, that some functions (such as discussion) won’t work, and that the page will soon move.
If we did not present an intermediate page between the reader and the old content, readers would wonder why the discussion forum didn’t work, why some items in the menu bar no longer seemed to point to the right pages, and so on. Forewarned is forearmed.
<<>>
For one thing, the site is now built on a publishing platform whereas formerly it was not. For another, because the intermediate page is needed, and there can’t be an intermediate page if articles are immediately available at their original locations. As to why the intermediate page is needed, please refer to the previous paragraph.
“Content management” has been the bane of my
existence since inheriting a site that was originally created by a team of virtual volunteers. First the directive was “Don’t touch it” so I let it become “archival” since it had some really good stuff on there (but it was really a “cobweb”). I focused most about keeping the home page current. We were chided (gently) even by our good friends for not changing/updating our site in a timely manner, but still heard from others that the look and feel of the original site was “friendly” and inviting” (read: cartoony). It was nothing short of a huge drag.
The issue was, we had no paid or reliable volunteer staff to maintain the site, much less overhaul it. We turned to students and even to web accessibility contests bringing web publishers and nonprofits together. We also turned to interested dotcoms (when they were still expressing an interest in dotorgs), until we landed some funds to
pay someone to re-design the site; some of the student work was very helpful.
Then the issue became since the site was done in Dreamweaver, only 2 people on staff had the skills to maintain the site without fearing the destruction of the site with one wrong move. Real or not, that was the general sentiment, so we’ve gone through the drama of having to get someone with Dreamweaver skills to make changes istead of having key staff make changes/corrections/updates themselves.
We’re now looking forward to a re-design, a custom-built site, and hosting with a company providing open source solutions for nonprofits. After having gotten into exploring blogging just this January February (2003), then exploding into it in March, I know much better what features to ask for, what to negotiate for, what to include in the re-design, and, most importantly, I trust wholeheartedly that we will have staff buy-in because the tool will be tailored to meet their stated needs. Among those tools we’re considering: RSS feeds, internal blogs, and other nice bells and whistles.
When I read of your process, I felt a little vindicated (OK, a lot) because, in a big way, you share some of our trajectory (I still love hand-coding but stopped a while ago). After all, we are not web publishers in the strictest sense of the term; we backed into that role because it was expected of us. Meanwhile, we know that branding, reliable information, and good, accessible design including user-friendly navigation– especially for people new to the Web, or with limited technology resource–are at the very least critical elements, and we want to prioritize these elements and others on our soon to be re-designed web site.
Thanks so much for sharing your experiences with the re-design.
Very nice article. I’m getting to sense that these double+ issues are half logical and half technical. I like that, as it gives me something to read leisurely and professionaly.
What exactly is an intuitive URL? A have always opted for longer, full word urls instead of abreviations. What experience have others had with this?
I can’t think of a good example, as I am certainly biased in this matter.
Thanks for the great article!
Man, I’m glad you wrote this up. I was surprised and pleased by the launch of a new A List Apart site, but was disappointed that we weren’t told any of the how, by-who and where-we-are-now (call me selfish, but hey ;-).
Also a good thing, I was just restructuring my own site this week, and so far ALA articles have been the biggest help. A lost of it is indeed common sense, but most of the problems crop up when you don’t see them coming.
A definite reread piece, and something I was glad to see in the first place.
*thumbs up*
Kiarra
Great article! It’s always interesting to see what sort of unique problems others are facing as they evolve online.
I think that, while I’m sure developers walk away enlightened, sometimes our collective silence and lack of cojones in specification/planning/infrastructure meetings turns all of that goodness into a moot point. Developers have a voice, and it’s up to us to be able to answer honestly in meetings if we feel 100% of the scope can’t be realistically met… sometimes overeager principals, managers and clients can ask and ask and ask and all we do is say yes, yes I can do that, of course. Especially if, because of a prior project (say, the first site rollout), comfort levels are high.
Redesigns – to the uninitiated – appear to be a matter of “replace A with B”. We know it’s rarely that easy.
Something I am wondering about:
Does your CMS generate static HTML files that are written to a directroy tree in the webserver (and thus the tree is managemed by the CMS), or does Brian have some super nifty trick to retrieve content from a database using an ASP page based upon the requested URL?
(in other words: how to avoid something like http://www.alistapart.com/index.asp?article=tacklingusability )
I’m not sure if they are using the same method nowadays, but:
* http://www.alistapart.com/articles/succeed/
* http://www.alistapart.com/articles/urls/
Hi Martijn —
Since I’m using a Microsoft IIS Web server, I use ISAPI Rewrite (http://www.isapirewrite.com/) to map clean URLs like /articles/fir/ and /topics/server-side/ to Active Server Pages with query string parameters. They give you a nice regular expression testing application so you can determine whether your patterns are set up correctly without having to try loading URLs on a live server. (It keeps all of your test URLs out of your traffic logs.)
If you use Apache, mod_rewrite will give you the same regular expression-based URL pre-processing abilities.
PS – I hadn’t seen those two ALA articles on URL-remapping, but they both use the same tactics I use on ALA today.
Thank you for the prompt reply Anne and Brian. It’s an issue that had presented itself to me just this week 😉
For additional ALA coverage of the intersection between usability and URLs, please also see:
http://www.alistapart.com/articles/slashforward/
I myself love what you have done with the redesign. It has a certain shine over the whole site, and the transition from page to page, in usability terms, is seamless. At the moment, I’m redesigning (designing if you consider the fact my site has used PHPNuke for the past few months – I know, shocking) my own site (http://www.cmcore.co.uk/newsite) and the pointers have been very helpful. Keep up the good work.
For my usability is a permanent nightmare. I use to redesign my site every 3-4 month. Wuth the every new version I try to make it better, increase usability, make it more usefull for visitors. But I can’t be shure I succedd each time. There is a very thin line in usability incrieasing. You can redisign your site making it more usefull as you thnik but you are not. And to be shure that new design are more usefull to visitors you have to ask them and make an opinion from their answers.
Peter Bacon
http://www.watch-replica.net
It must be something basic, but I’ve missed it…
I thought background-images were rendered at their dimensions: yet the background-image on this site appears to scale, vertically.
The shaded background gif is 200 pixels high, when downloaded and examined. Yet it appears to scale to the height of the screen, at both 800 x 600, and 1024 x 768.
Could someone set me straight?