Usability Survey

Rick Schaut — Tue, 29 Mar 2005 21:50:00 GMT

The University of Maryland, Baltimore County has an online usability survey of GNOME. The timing is rather serendipitous in light of my earlier remarks on user feedback and GNOME.

It's entirely likely that more than a few people who commented on that post will point to this survey as an example of how open source development projects can obtain useful information about usability and user's needs. I'd argue, however, this makes my case more than augurs against it.

Take a close look at the two surveys. Try to figure out how the task-based questions will provide insight into real-world user problems. Then take a look at the "Guidelines" questions. Even after reading the "more info" link for "GNOME designs dialog to yield closure," it's not at all clear what they're asking for--particularly if you're not well-versed in the terminology of software usability.

Folks, this is an example of how not to conduct a usability study. If you really want useful information, you plunk real users down in front of your product, preferably an instrumented version of the product, and you ask them to perform a number of high-level tasks.

And that's the easy part. Before you even get to the point of plunking real users down in front of your software, you have to figure out whether the tasks you're asking them to perform have anything to do with what most users will need to do in order to get their work done. In order to have that information, you need a well-done market segmentation that identifies your major groups of users, and what their jobs are. You need to understand why they'll even want to use your program in the first place.

Now, anyone who does any kind of work in human-computer interactions knows all of this, which makes me wonder what the UMBC hopes to achieve with this survey. Perhaps they're seeking to demonstrate the inefficacy of usability surveys compared to other methods of studying usability?

Rick

Currently playing in iTunes: Rockin' Horse by The Allman Brothers Band

Selection Behavior

Rick Schaut — Sat, 12 Mar 2005 14:08:00 GMT

I'm absolutely certain that something like this has happened to you. I was putting together some quick and dirty play lists in iTunes based on a random shuffle smart playlist I'd created (basically, a random list of 100 songs that I hadn't listed to in more than two weeks). I'd start on a song, and use <shift>-<up-arrow> to extend the selection to include the songs I want in the playlist.

From time to time, however, I'd go one song too far, and switch to <shift>-<down-arrow> to back off that one song. Only iTunes interprets that action to extend the selection at the song where I started.

I call this "unanchored" selection behavior. In this behavior, <shift> plus any cursor movement always extends the selection regardless of how or where you started selecting using the cursor keys.

And I hate it. I much prefer anchored selections. With an anchored selection, the item or location that was selected when you began extending the selection using a <shift>-<cursor-key> combination is pinned, and never moves. Only the "end" of the selection that you moved using the cursor keys moves.

Note that TextEdit uses anchored selections, as do most other text editors (though not MarsEdit, much to my chagrin). It would seem, though, that the data browser control doesn't "out of the box" as it were. This is really an annoying inconsistency.

So, consider this my personal plea to all software developers (including folks at Apple), please give us anchored selections. Not only would this make all of our applications more consistent, it also gives us fat-fingered users a way to correct our error when we've gone one character, or word or list item, too far.

Rick

Currently playing in iTunes: Passion, Grace, And Fire (Version I) by Al DiMeola

Buggin' My Life Away : UI Design

Usability Survey

Selection Behavior