8 Ways to Sunday

A week ago today, I woke up to find that during the night my cat had vomited at least five times in different places around the house. He saw the vet that morning, and she sent him home with some food for cats with irritable stomachs. That night, he started vomiting blood. He was admitted to the vet again at about 11:30 PM. By Friday morning, he was gone.

On an overcast evening last July, I was leaving the local Asian food market when I heard a tiny but insistent meowing from the vicinity of my feet. There lay an emaciated tabby kitten, looking up at me with big golden eyes. I reached down to pet him, and this simple act set him purring loudly. Clearly he was starved for attention as well as food. When he tried to come closer, I noticed that one of his hind legs was injured. He could barely stand on it, let alone walk in his weakened condition. I’ve never been a cat person, but I took him home and gave him food and water. He ate and drank until his little belly was bulging, then slept soundly.

For about a week I wasn’t sure that I would keep him, but he won me over little by little. He was uncommonly devoted and loving for a cat, and as he regained his strength he began to show more of his playful personality. I started visiting baby name web sites to look for a fitting name for him. I decided on Riley when I read that it meant “valiant” in Gaelic. That seemed appropriate for a kitten who had been through such an ordeal, yet still showed such indomitable spirit. He stayed in my bathroom for a short time, since I was afraid he’d get into something dangerous in the rest of the house. The kitchen was the first room to be “cat-proofed,” and he soon moved into there. He earned his middle name, Houdini, by displaying his uncanny ability to overcome all the makeshift barriers I put up to try and keep him confined to the kitchen. His injured leg didn’t slow him down a bit as he found his way under, around, and even over every obstacle I could put in his way. Needless to say, the rest of the house became cat-proof sooner rather than later.   (more…)

Garrett Dimon has made some good comments on software documentation and usability, but the maxim he sets out is a little too fuzzy: “The length of your instructional text is almost always inversely proportionate to the usability of your product.” To truly quantify the usability of a piece of software, you have to consider the opposite scenario — a generally good interface with poor documentation.

Using Garrett’s idea as a starting point, and applying fifteen minutes of my own deep thought and extensive research, I have arrived at the following formula to unfailingly and scientifically measure the usability and/or documentation adequacy of any piece of software. This should work for web applications, desktop applications, and web sites:

In this equation u is the usability ratio of a program, d is the length of the documentation in words, and n is the number of features implemented. Basic UI conventions, like toolbars with clickable buttons, should not be counted toward n.

Software teams can judge the results of the calculation according to the following criteria:

• 7.6 and higher: The application is too complicated or confusing for the number of things it’s trying to do. Simplify the user interface for the application’s features and remove features that are rarely used. Create a user interface bible that dictates standards, conventions, and metaphors for the application’s interface. Make UI designers and programmers stick to the bible under penalty of death. If you have the budget, conduct a usability study.
• 5.7 to 7.5: The application may be suffering from feature creep or a poorly implemented user interface. The problem is not yet so far out of hand that huge efforts are needed to fix it. Applications with scores in this range may be facing growing pains associated with increased popularity and an expanding user base. Alternatively, the documentation may be bloated and over-written.
• 3 to 5.6: Congratulations, you have a good documentation-to-feature ratio. Chances are pretty good that your user interface doesn’t require too much head-scratching to figure out, and that users who do have problems will be able to solve them by reading the documentation.
• 1 to 2.9: Either the documentation is inadequate or the user interface is too complicated.
• 0-0.9: Little or no documentation provided. Bad developers! No cookie!

The basic idea here is that each major feature of a software application probably needs at least 300 words of documentation, on average. Any less, and your documentation may be inadequate for your users’ needs. Conversely, if you really need more than that your user interface could probably use some work.

Programmers and designers struggling with usability problems for web sites or web applications might benefit from reading some of the better books on the subject. For usability issues in general, the seminal work on the subject is Donald Norman’s The Design of Everyday Things. It’s technological references are a little dated now, but the core principles still hold true.

(Props: Garrett Dimon)

A web developer’s blog called as simple as possible, but no simpler has a look behind the scenes at what makes Google Maps tick. The author is not himself a member of the Google Maps development team, but taking a look at the code has given him some informative insights.

(Props: The Wikipedia entry on AJAX web technologies)

This past Saturday, my friend Mickey turned twenty-nine years old. Happy belated birthday!

The Grokker visual search tool, formerly available only as a $50 desktop application, now has a free, web-accessible version.

Grokker presents search engine results as a clickable “map” of information, separated by topic area. The web version uses results from Yahoo, whereas the desktop version (still available for a price) can be configured to use a number of different search engines. The results you get from either version look something like this:

If you’re having trouble thinking of a working example, check out this Grokker search for “8 Ways to Sunday.”

I did a trial of the desktop product a couple of months back, so Groxis (the company behind Grokker) sent me an e-mail when the web site went live. I gave it a spin this morning, and it’s very similar to the desktop app. I don’t see myself using it very often, but it’s nice to know it’s there. I use search frequently in my job, so new tools are always a plus.

To use the web version of Grokker, you’ll need Sun’s Java plug-in and a browser that supports inline frames.