tina_t

Survey reminder: Diagramming Usability

2006-06-29T21:07:00.000+02:00

Some people have already blogged about it (Ellen Reitmayr and Peter Simonsson): Finally, there is a way for users to give valuable and direct input to usability efforts - a survey to improve the usability of diagramming app Kivio)!

If you create any kinds of diagrams - for any purpose and with any tool - please remember to take part in our survey about diagramming tools. There is still a little time left, the survey will run until the first of July.

So please take part in the survey today!

Don't worry - you don't have to be a user of Kivio to answer the questions. You don't even have to be a user of any diagramming app at all. If you use pen and paper for your diagrams, that's fine, too.

Thanks in advance!

Persona slides and other stuff

2005-09-06T00:53:00.000+02:00

I'm back home from Malaga and finally uploaded my material from our personas exercise:
Slides as pdf, 214kb. You can find the rest of the stuff on the kde-wiki page for the personas exercise -- included is the the mindmap of the target user group and of the two personas we created during the exercise in kdissert format, as a png image and as a linear html file. There is also a kdissert file without the actual data that you can use as a skeleton when creating your own personas.
This also means you finally have the end of the persona series that I promised months ago in Personas part 2 -- whoops, it was only supposed to take a few days until part 3 :o...
The whole persona process is on the slides, including an even easier way for getting the info about your target users than the one I blogged about.

KDE's checkboxes for toggleable menu items

2005-07-19T18:56:00.000+02:00

There's a problem with KDE's menus that's been bugging me for a while now, but only recently was I directly confronted with it because it prevented a usability improvement from being made. I just did a usability review of Digikam's tagging functionality in version 0.8 and made the suggestion to put checkmarks in front of the tags which are already assigned to an image (when managing image tags through the image context-menu). It was supposed to look like this:

I already expected it, but lippel told me today that doing it this way is probably not possible in KDE, because the icon and the checkbox of a menu item are drawn together -- on top of each other instead of side by side like in my mockup. This makes for bad visibility in almost every case it is used. Do you have to look twice if you have tree view or something else actived in Konqueror's view menu (view -> view modes)? I already had a chat with annma about the same thing happening in Kalzium, where it's barely visible when the legend is activated:
.
And it also strikes in the development version of Basket, where the tags assigned to an item are indeed checked, but because the "checkmark" is on top of the icon, you can still barely see it:

The problem doesn't seem to be a style specific thing, because I checked all the styles on my system -- keramic, plastik, light 2nd and kde classic all have it. Trolltech obviously knows that having a separate icon and checkmark is better, because QT Designer on the Mac does them that way, but strangely they implemented this differently from platform to platform. Designer on Windows, for example, does not have room for checkmarks to the left of menu item icons, although Windows itself supports this. (Note that "Edit Widgets" is toggled in both of these last screenshots!)
Sadly, I'm not a KDE hacker, so maybe I can convince anybody to do something about this this way ;). It would be a great addition to all the other cool things that are coming for KDE 4.

P.S.: holehan recently also blogged about another similar problem with toggleable menu items -- I bet he would also love to have this solved for KDE 4 :)

Lemmings rock indeed

2005-07-11T12:18:00.000+02:00

Reading Hans Oischinger's last blog entry about Lemmings, I remebered this little movie (19MB, xvid/mp3) I and some friends made in a Uni course a while ago. It's a stop-motion animation of a game of Lemmings with lego men -- it shows how the lemmings themselves see the game.

Some screencaps:

We also programmed an (ahem) nice, (ahem) working java app to produce stop-motion animated films. Strangley, I must have forgotten the link for it ;).

Personas, Part 2

2005-06-12T12:22:00.000+02:00

In my last entry, I wrote that personas are substitute, "fake" users and that they can be useful in focusing development on real users. Now it's time to find out how to write your own personas.

Research

Before writing a persona, you should do some research on who your users are.

Here's what you will want to know about your users:
* work experience (in the task domain of your app)
* education
* age
* gender
* computer literacy
* frequency of use of the app (or how often they do the task the app is for)

Another thing you should look at are the tasks that people will use your app for to find out what their goals in using it are.

But how can an open source developer find out something like this?

In a large company, which has enough time and money for this kind of stuff, you would be able to talk to the target users in person and watch them do actual work. This is probably not very doable for you -- but if you can somehow manage it, by all means do it, because it is really the best way to find out about your users.
So if you know people who have use for the app you are developing, grab them and ask them some questions. (But don't think you can just ask yourself because you need the program yourself, too. This will not work -- you are not your user and are too much encumbered by technical considerations to be able to think like a normal user in this case.) Also watch them work, either with a previous version of your app or a competing app. If neither exists, watch them do the task without the help of the computer.
The point of this is to make a list of things that people want to achieve by using your app - these will be their goals. You can find goals most easily by looking out for logical connections between actions that users make and thinking about what the goal of the combined actions might have been (you can also ask them, of course).

Another slightly more doable possibility is asking people your questions in a short web or email survey. But again, it's hard to find these people in the first place.

By now, you prabably have noticed that these usual steps that companies may take to research their target users are not really of much use to a regular independent open source developer without help -- so how can you cheaply and as quickly as possible get some information about your users?

I've thought a long time about this. What we did in the end for our project was look around the web to find competing apps and scoured their web forums and any other sources we could lay our hands on (newsgroups, for example) for anything the users were saying about themselves and how they use the app -- examples are stuff like "I'm a design student and I mainly use ... to ..." which yields info about age range (student, so probably in their twenties), (future) profession (designer) and what the app is used for (and also possibly gender, if the person has added it to his forum profile). Another example is "I'm just a hobby designer trying to make my own website".
Another good source are blogs. Look for the names of competing apps and see if you find people who write about them in their blogs -- what they like or dislike about them, for example. Blogs often also have personal info like job, age and location of the blogging person, which is very useful. If you've already released older versions of your app, you can of course search for references to your own app, as well.
Note that you will probably find only users that are web and technology savvy enough to actually have blogs or post to web forums, so depending on your app, they may not represent all possible users -- of course, if you are writing a blogging app, then that's perfectly fine ;). Another thing to remember is that if you want to ask people in the irc-channel of your app, you will probably only find very tech savvy ones (how many "normal" users know irc?) who should definitely not be considered as covering your whole user base.

The reasearch part is all for today, wait for more info on writing the actual personas in a few days if you're interested.

Personas, Part 1

2005-06-08T20:29:00.000+02:00

Holehan and I have been working on our own small QT/KDE app on and off for a while now. In the course of our (not terribly far advanced) progress we've found the so called "persona" technique very helpful to focus our design efforts on the target user audience. And since I've written an article about the very same technique for our previously mentioned usability course (which, sadly, was not meant to be), I decided to translate my article to english and adapt it a bit so it shouldn't go to waste. It's quite a bit longer than your usual blog entry, but I think it's well worth it, because it contains a lot of knowledge I've collected from all over the place and I've not yet found someone who put all this together and fleshed out all parts of the process and not just some of them. I decided to divide the article into several parts so there's not too much text to read at once and also so I won't have to finish the whole article tonight ;). Today I will say a bit about what personas are and why they are useful. If you like this introduction, read how to make and use them in a few days :).

What are personas?

The concept of personas was first widely popularized by Alan Cooper in his book "The inmates are running the asylum" in 1998.
Personas are ficticious users that represent the needs of a larger group of users regarding the goals and personal characteristics they have. They are used as a substitute for real users, helping to make decisions about the design of an application. Personas help you to keep the focus on real users and their goals instead of thinking only in terms of the fuzzy ghost of the "average user" (who doesn't really exist.
To make personas really come alive, they are given plenty of bibliographical information, including a name, age, gender and also, very importantly, a picture.
Personas may not be real people, but they are based on knowledge about them - usually you do a bit of research about the target audience for your app before making the personas. That also means personas can't be reused for another project - they are tailored to the application they are written for and most probably won't fit for another one.

So what's the deal, why are personas so great?

1) They put you into your users' shoes and and help you focus on their goals:

As a developer, you often have a great idea for a feature for your app, but then find out later that your users only see the new functionality as additional distraction and clutter because they don't need it. Personas help you to put yourself into the position of your users and recognize what their goals really are, instead of keeping you guessing and adding random features they'll propably never see or use. Which in turn makes your interfaces less complicated and saves you the time you would have spent implementing a mostly unused feature.

2) They can resolve disagreements among the team:

Often there are disagreements in the development team about which feature is needed and which is not. These can often easily be resolved by refering to your personas - for example when someone in the team says: "What if somebody wants to print this out?" you can argue with "Peter is not interested in printing anything." (It is very important not to say "our persona" in sentences like this, but to at all times use the persona's name, otherwise you will never take it seriously enough. Always talk about "Peter" and resist the urge to generalize him.)

Read on in a few days to find out how to use personas yourself - and don't forget to visit the OpenUsability booth at LinuxTag - read Ellen's blog entry to find out more!

mp3 and testing

2005-04-27T17:50:00.000+02:00

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" :).

courses and evaluations

2005-04-12T13:09:00.000+02:00

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).