Wednesday, April 27, 2005

mp3 and testing

while doing some web research I stumbled across the website of a british usability company. browsing around, i found that they had a page where they give "good" and "bad" awards for products or websites that catch their attention. my interest was piqued when i saw that they had given one of the "good" awards to an mp3-player device. usable mp3-players are something i'm always on the lookout for, and whenever i happen to be in one of these large electronics stores that sell anything from laptops to audio cds and coffeemakers the mp3-aisle is one of the first places i'll go. sadly, not many of the devices have satsified me. so i was really excited.
what they were talking about was the i-bead 100, a player whose button design is remarkably similar to the one that my own player sports. i have one of these small mp3/usb-pen combinations with flash memory:

as you can see, my player has only one wheel-button for play/pause, volume and back/forward (the only other button is the on/off switch).

see, the i-bead seems to work the same. http://www.usability.uk.com/resources_spoon21.htm says: "[...]there are only three actual controls; a scroll wheel, a record button and a play button. I was very pleasantly surprised by the ease of use, especially as only two of those buttons are needed for most actions." and "Move the scroll wheel right (holding it for a second), and the volume goes up. Left and hold, volume goes down. Quick move the wheel right to skip to the next song. Everything is so simple."

this sounds great, except for the fact that this reduced and thus seemingly uncomplicated control design has annoyed me to no end and has made me want to throw the damn thing into the corner numerous times. if i don't hold the wheel long enough when moving it, the volume doesn't increase as expected, instead the next track starts playing. i can't count the number of times this has already happened to me since i have the player. this is especially annoying if you are trying to listen to a very long track of speech. some time ago i was listening to a single-mp3 audiobook on a train. after having listened to it almost an hour (and thus being very close to the finish of a rather exciting murder mystery) i decided i wanted to turn down the volume a bit. but, of course, this didn't happen -- i skipped back to the track before and would have needed to either forward-seek the part where i left off or listen to the whole hour once again! i was too frustrated to do either and gave up. i had to listen to the ending of the story at home using xmms.

so what happened? this is clearly a design flaw and most probably they used the single wheel to save money on multiple buttons. still the usability guy thinks this is good design?
i guess he fell into the trap of not testing (i'm not implying he doesn't to proper testing at work, of course). sure, it looked like a good idea, after all, less clutter is always good, right? i might have thought the same way if i hadn't owned the player for a while and actually tested the "feature".
so my point is: whenever you try something new for an interface, i think it is very important to test it on some users instead of starting a discussion with a bunch of other people where everybody just gives their opinion, argueing the thing to death with no real results in the end.
whenever you are unsure if something might be a good idea in an interface, make a mockup (it can even be on a piece of paper) and let some people really try it.

if you want to know more about the piece of paper stuff, google for "paper prototyping" :).

Tuesday, April 12, 2005

courses and evaluations

I'm currently working on the material for the usability course that Flo and I are preparing for a "courses by students for students" project at our university. Right now I'm trying to make a siplified usability lifecycle (our audience will be comprised of beginners - the software-ergonomics lectures they took were very dry and theoretical, so I don't think much of anything stuck). My goal is to combine Alan Cooper's personas and the usual task analysis that e.g. Mayhew proposes in her last book, which turns out to be harder than it looked initially. The analysis that focuses on the demographic, sociographic and psychopathic profile of the target users is closely intertwined with the persona creation, because you need this information to build your personas, but i'd still like to keep them separate. But I'm pretty sure that incorporating personas is essential because they appear to be really useful to give your target user a face and to prevent an "average" user from creeping in. It focuses usability efforts very well. But ah, so little time, so much to do. I still need to refine the section about conceptual models, which is also an important issue (the most important one, actually). But at least I already know where I can fit it into the lifecycle.
Flo is working on the "heuristic evaluation" part. I collected some notes from the net yesterday that he will use. It wasn't easy to find detailed information on how to really do the evaluation. Everybody talks about heuristics all the time, but what to do with them they seldom mention. The evaluation can either be done by defining a set of tasks that need to be executed with the system and everything that seems to be a problem has to be noted down. Or you just thoroughly go through the interface, scrubbing every single screen and interaction element, noting down problems.
I just hope I will finish the course material stuff soon, because I desparatly want to go on evaluating KDevelop and finally give the developers some results. I've already started to go through KDev-Assistant and write things down, but I'm a bit unsure how I want to present the information. I would love to incorporate screenshots but I'm not sure the developers want some html page instead of a simple report as an email they can easily refer to when citing. I've also been looking into a dedicated usability bug system for that purpose. It looks like nothing open source of the kind exists yet. But since somebody was faster than me in implementing a speed-reading program in j2me for cell phones, I need a new topic for my Studienarbeit. A usability "bugzilla" tailored to the needs of usability issues and is easy to use (!) sounds like a good idea. I still need to check with my potential tutor who knows his way around the database stuff if this can be done in such a short time (3 months).