Amy Warner has a nice Taxonomy Primer. Worth a read if you're unfamiliar with IA buzzwords like "taxonomy," thesaurus," and "controlled vocabulary."
I read two more articles in Digital Web's ongoing series on User-Centered Design. In the first article, Peter-Paul Koch writes about Client Centered Design. Koch gives an example of a salesman who sold the client with two mutually exclusive promises. Koch suggests that web teams work to manage client expectations. His ideas: "don't promise too much," figure out the client expectations, and "don't try to explain your job to your client." These are decent suggestions, even though the first point is poorly made (it should perhaps focus on being clear with what you can and should deliver to the client). However, I think Koch left out the most important point: designers can best serve the client by designing for the end user. But, as the second article points out, this design process is often a compromise between the client's requirements and the user's needs.
Another point brought up in the article:
Graphic designers think in terms of images, forms and colors. Programmers think in terms of code. Those mindsets aren't wrong - they're the expression of the strengths of each team member. However, the same team members can get carried away by the disadvantages of specialization. When that happens, someone has to put on the brakes and say:
Please think of your users.
This is, I think, a good idea. UCD is not a visual design thing or a programming thing. It should be an everybody thing.
In the second article of the day, Jeff Lash writes about The Myth of User-Centered Information Architecture. Lash presents the very rational argument that information architects (and I'd extend that to include everyone working on a web project) need to consider a number of different perspectives when creating sites. Lash writes: "At its core, information architecture is a balance between user needs and business requirements." Very true. I think the trick is to spend some time early on in the process defining the various perspectives (users, business needs, technical requirements). Blending these perspectives well can lead to a site that works for everyone involved.
Information architecture goes beyond deciding what content should go where and how it should be labeled. It's more than just blindly listening to what users say. It's more than just making the client happy. Giving all of your attention to only one of these three aspects of account service is irrational, irresponsible, and impractical. The key to successful information architecture is understanding all of the variables involved in meeting project goals, and coming up with an appropriate balance.
Two recent court cases regarding accessibility:
In the first case, the Atlanta mass transit agency failed to provide an accessible website. In the second, Southwest Airlines site was impossible to use by the visually impaired.
I don't think building an accessible website is that much harder than building any good website. Granted, it does require some care and thought, but the benefits are there. Making a site that is accessible to all can often improve usability for everyone. And an accessible website is also more valuable to some unexpected categories of users, such as automated search engine "spiders" that crawl the web. Properly marked-up documents can make it easier for these spiders to figure out what your page is all about.
A nice intro into the subject can be found at Dive Into Accessibility. It is aimed at weblog authors, but most of the advice listed on this site can be generalized to all web development activities. There have also been a number of books recently published. I'm hoping to get my hands on them soon...
I've been exploring the concept of User-Centered Design (UCD) a bit recently. Lucky for me, Digital Web magazine has dedicated this month to that very topic. Two new articles popped up yesterday:
Back to the User: Creating User-Focused Websites by Tammy Sachs and Making a Timeless User Experience by David Wertheimer. Sachs spends a good deal of her article encouraging designers to look to the user by involving people at various stages of the process. Good advice.
For the past two weeks, I've been watching a two-part PBS documentary on Frank Lloyd Wright. Wright, probably America's greatest architect, created some beautiful buildings: Fallingwater, Johnson Wax, and the Guggenheim. Two themes kept popping up as commentators discussed Wrights work. If you lived or worked in a Wright creation, you had to subordinate yourself to the architect's vision. Wright's primary concern was often not the needs of the humans who inhabited his structures. And, for all their beauty, these buildings often had a number of flaws: the roofs leaked, cantilevers sagged, and so on.
Can this be a metaphor for web design? We often focus on beauty over the user and the functionality of the site. For all of my appreciation of Wright's work (and other examples of design), I think I come down in the function over form camp. Sarah Horton, author of the Web Style Guide, has more in a Boxes and Arrows article on the subject: Beauty is Only Screen Deep.
Via James Robertson's Column Two: a new weblog describing the installation of a CMS at Network World Fusion. Adam Gaffin, the site's executive editor, details his experience getting Percussion Rhythmyx up and running. Here is an excerpt:
I'd feel like running through the newsroom this morning yelling "it's alive, it's ALIIIIVE!" if I weren't so tired (what is it about complex projects that you always seem to find lots of small things at the last minute that need fixing, and what is it about large projects that something bad always seems to happen toward the end, just when you're furiously working, like hearing a loud "THUD" outside and running out to see that some dolt busy waving at her friends across the street while also parking hadn't noticed my parked car and so ran right into it?).
Content management--unless you're dealing with a tiny bit of paper--is really complex, and you have to bring this stuff in-house for a little while and really test it out so that these things will work the way youíve been promised.
Wired just redesigned their site to use XHTML and CSS. Although plenty of smaller sites have used this combination for a while now, this seems to be the first large site to make the switch.
Why did they do it? Faster page loads, easier updating, more compatibility with non-PC based browsers, less code needed, more accessible.
The down sides: some older browsers (Netscape 4 being the major offender) won't see the site in all its glory. But, they will see all of the content. Plus, it loads quickly and works just fine (I just tried it out in NN4).
For more commentary on the switch, head over to Zeldman's site. Also, CSS guru Eric Meyer interviews the Wired designer behind the change.
For an added bonus, check out the text size switcher in the upper right-hand corner of Wired's site. It provides a way for users to easily resize the text, making the site more accessible for users of browsers that don't allow for easy text-resizing (like IE/win). A List Apart ran two articles describing the techniques behind this widget: 1 and 2. Good stuff.
I've come across three articles worth a read:
An interview with Peter Merholz and Nathan Shedroff on User-Centered Design in Digital Web:
Contrary to common wisdom, user-centered design is not a process, but a philosophy. User-centered design requires the inclusion of a product's end-users throughout the design process.
Ranganathan for IAs in Boxes and Arrows:
We need to plan and build with the expectation that our sites and our users will grow and change over time. Similarly we need to always keep our own skill levels moving forward.
I mention these first two articles not only because they are interesting, but because they touch on two themes central to my coursework at the iSchool. Bonus points to anyone who can correctly pronouce "Ranganathan."
Leaving the Autoroute, also in Boxes and Arrows:
You canít be in expert in everything, obviously. But you can make sure you have enough knowledge to appreciate the craftspeople you work with. So designers, take ìIntroduction to programmingî at the local college. Engineers, attend all the usability sessions and watch what those crazy users do. Usability folks, go read Robin Williams ìThe Non-Designers Design Bookî at least.
There have been a number of good intranet-related articles Iíve come across recently. James Robertsonís ìKeeping your intranet healthy and effectiveî (http://www.steptwo.com.au/papers/kmc_healthyintranet/index.html) is worth a read.
Iíd like to highlight a couple of good points:
Robertson recommends that organizations ìmake the intranet [a] part of daily activities.î This bit of advice is an oldy, but a goody (see my previous entry for another article that says basically the same thing). The most important thing Robertson mentions on this front is that there is no one ìkiller appî for an intranet. The features that will draw users back on a daily basis are going to be unique to an organization. A user-centered requirements gathering process is clearly one of the most important aspects of an intranet project.
Robertson also argues that the intranet should be positioned as a strategic resource. Iíll go him one better and argue that an organizationís information resources (including, but not limited to, the intranet) should be considered a strategic asset. And, like all assets, the organizationís information should be managed and directed to ensure that these resources match up with the organizationís goals.
One cultural shift that can help promote this idea of information-as-asset is to, as Robertson mentions, ìprovide authors with sufficient time and resources.î Activities like adding content to an intranet, an internet site, or a weblog should be a part of a staff-memberís regular responsibilities.
There are a number of other good points in this article, but I'll leave those up to the reader to discover.