I've just finished reading "Don't Make Me Think" by Steve Krug, which claims to be some sort of a web usability classic.
What I liked most about it was the chapter about user testing. The short summary is - test early, test often, 3 randomly selected people with one hour per person is the best cost to benefit ratio for a round of testing, don't bother with detailed written reports, just fix the worst problems and do another round later.
Other than that I didn't like the book that much. I see how it might have been useful in the Web 1.0 days, but its focus just feels wrong. It seems to think that the most important part of a website is its navigation and so spends most of the pages discussing it, but how relevant is navigation when vast majority of users come from Google, or some other kind of search, or direct links, or RSS, or even bookmarks, and people reaching your content by patiently clicking their way though from your homepage are a tiny minority?
Most blogs, wikis, and web apps don't even have real navigation structure, and they're the part of the Web that's growing fastest. Even Amazon which the book glorifies as The Paragon Of Web Usability seems to have mostly given up hierarchical navigation and now exposes search and personalized recommendations as the most prominent means of getting around.
So the book has some useful content but is hopelessly outdated and unfocused. 3 stars out of 5 if you numbers.
Usability
As the review made a rather short blog post I'm going to conclude it with somewhat controversial remarks on Web usability. By the way if what you're saying doesn't cause any controversy then
- you've just discovered some new universal truth (only happens in maths),
- or you're just repeating some nicely sounding but ultimately meaningless slogan like "use the best tool for the job",
- or most likely - nobody reads your blog.
So controversy and exaggeration to get the point across are good.
First, accessibility is overrated. I've seen so many people performing magic rituals supposed to make their websites "accessible", like anal adherence to "web standards" even to the point of using XHTML, making sure the website works without Javascript and/or CSS, making unique text in headers and so on. Two things they never do are measuring how many users are actually going to use accessibility features, and testing accessibility in realistic settings (like with a screen reader or Braille terminal), and these two things seem to me to be the only ones that would matter.
Accessibility zealots also often claim that:
- websites done in some "right" way are somehow magically accessible,
- making a website Google-friendly is somehow the same as making it accessible,
- and that you're legally required to spend as much effort making your website accessible as necessary.
All of which are bollocks.
I think this misguided thinking is caused by a combination of two reasons. The first is the good old web standards zealotry. Seriously, why people get so emotional over some badly written documents without even a reference implementation or a serious test suite? Even FreeBSD vs Gentoo and Emacs vs vim (by the way correct answers are Ubuntu and TextMate, and 2 spaces) flamewars aren't as heated as the ones about web standards.
The second reason is a certain kind of a reality distortion field. There are many kinds of web sites on the Internet. The kind that used to be most popular are "text-based content sites", where users come to read static stuff. The reality distortion field makes people think this kind of websites is still dominant, but it's not. Looking at Alexa's top list it's difficult to find a single text content site other than Wikipedia. Everything is some sort of a web app, or video site, or social networking site, or anything but text content.
Now I mostly agree on one point - making text content site reasonably "accessible" is not very difficult, and to some extend correlates with things you need to do anyway to support Google, mobiles and so on. I will still laugh at people who think they can get "accessible" without genuine testing (if accessibility checklists worked, why won't they write IE6 accessibility checklist, wouldn't that be so much easier?). But the problem is something else - only reality distortion field of epic proportions can make you think most websites are still text content.
In a way it's similar to DBAs being deluded that most SQL databases serve as integration point between multiple independent codebases (and so need stored procedures, triggers, complex constraint enforcement and business logic on database side etc.) when in reality 99% of them are little more than persistent store for a single app and these features are more harmful than helpful.
So how about the vast majority of web sites that are not just about text content? Oh sure, you can make them accessible. It's just going to be long and painful process with very little payoff, and which won't ever end in a full experience parity unless your application is very very simple. And you know what - screw the blind people! The largest discriminated group are people who don't speak English as their first language. It's about 95% of all people, a lot more than 0.6% who are blind. Why don't they care adequate attention? It's an insane misallocation of resources if you care about the blind but don't even have a German version of your website (and versions in at least 50 other languages). Blind people are more or less as important as Welsh localization, and you're probably not caring much about that, are you?
Forget about experience parity, no mater what technology. Vision is the most important of human senses and the only way to make non-visual interface work as well as a visual interface is by horribly dumbing down the visual one, hurting 99.4% of your users who can see. Try getting somewhere with a spoken Wikipedia article about London instead of a map. Or reading long lists of numbers instead of a graph. Or playing Portal with a screen reader. Or for more relevant example using "basic html" version of Gmail instead of the real thing.
My second point, video websites should not autostart their videos. Haven't they heard of tabbed browsing? To open multiple tabs with YouTube videos you need to:
- open the tabs,
- go to first tab,
- wait until the video partially loads and starts playing,
- click pause (you cannot click pause earlier),
- then do the same for the all other tabs,
- and finally go to the tab you want, rewind the video and click play.
Couldn't they at least detect they're in an inactive tab somehow? Firefox seems to be sending onfocus when a new page is opened in a new tab or when you first switch to an inactive tab - not autostarting until you get onfocus sounds like a good start. Making pause button work before the video loads would also help a lot. Or are there perhaps some Firefox plugins or Greasemonkey scripts to get rid of video autostarting? The only thing it's good for is rickrolling people.
The third thing, stop using lowest common denominator fixed width layout. CSS lets you do many things that weren't possible with tables, but some of them are just stupid. More and more people have widescreen these days. Widescreen means wide but short. OS and browser usually take a lot of space on top and bottom of the screen, but not on the left and right, making screen aspect ratios even more extreme. So there's lot of space on the screen but it's mostly horizontal, and what do so many designers do? Completely ignore half of the available space, and then fill the rest with ads and other crap so the useful content is taking a tiny fraction of what it could take. I know making "design" work in multiple sizes is harder, but design isn't what users are interested in. They came to your website for the content, not to revere your mad design skills.
And the last thing, CSS compatibility with IE6 is a waste of time. JS compatibility became an almost non-issue thanks to jQuery and other JS frameworks. So why not use a JavaScript solution like ie7-js and be mostly done with IE6 CSS too? Some people won't like the suggestion of depending on JavaScript, but IE6 does run JavaScript just fine, and no other browser (Google spider, mobiles, text browsers etc.) is going to be affected in any way, so what's the big deal?
OK, if JavaScript dependency on ie7-js still makes you feel uneasy, couldn't we at least somehow use for automated testing? Run the website with and without it, get a list of differences and suggestions based on how ie7-js fixed them. Seems like a lot better way than manual debugging. But I'm not a Windows guy, so don't expect me to code that.