On Tue, Feb 5, 2013 at 8:34 PM, Devin Anderson <surfacepatterns@gmail.com> wrote:
HI Gabbe,
 
I hadn't considered this.  If I created such a survey, I would be
concerned that my own bias would be injected into the questions
themselves.  Can you suggest a few sample questions that might exist
in such a survey?

Generally, it's all about thinking about what you're actually after. For example, simple open questions can be good (Like: "Do you experience any issues using the interface? Please briefly describe them.") for getting a general knowledge of where problems might lie. Maybe you've been messing around with MIDI for several years and take for granted that your users know that just aswell, when the fact might be that this is one of their first experiences with MIDI. Also, leading questions are to be avoided under any circumstances. For example "Do you like feature X?" is a bad way of trying to find out if your features are good, as it implies you should actually like feature X. If feature X shows up automatically in a question like "Are there features you like in the program? If so, please describe briefly which and why." it's way more accurate. I think the potential "please the experimenter"-bias is a bit bigger here aswell when users might feel they owe you to like the software as it's free, which also leads to more biased answers unless handeled right.

But generally, starting off with fairly open questions to get a general idea of what people have issues with is a good idea, until you have some actual knowledge about what the issues might be.


http://www.nngroup.com/articles/ten-usability-heuristics/ <- that's also something to take a brief look at. Those heuristics are frequently used when doing quick training of evaluators for usability, and might be worth looking into when looking over your own UI. Evaluation using this could be very effective, and easily taught to people. Maybe we should look into having a couple of people getting trained with that (resources available online for free naturally, and training is fairly short) so we can aid developers in Linux Audio if they want the help. I'll look into this, I'd love to get some more experience with evaluation anyway.


 

> c) Provide an easy way to donate. Some people actually have a good income
> and can without a doubt donate money. Nicely asking to donate spare cash if
> you're satisfied could probably generate some donations this way, if people
> also are somewhat frequently reminded of it.

I could add a mechanism like this to (a).

> I have some experience of both UI-design and the principles around that, and
> also constructing good surveys, and I would love to help out in any way I
> can. Like someone else in this thread said, not everyone can code, but that
> shouldn't stop them from being able to contribute.

I can't speak for other developers, but I find your suggestions to be
very helpful.

On a personal note, I would absolutely love feedback on the UI design
of both midisnoop and synthclone.  I don't have a problem with either
UI, but UI design is *not* my forte, and I have a bias about the
intuitiveness of both UIs, given that I built them.

I will for sure try and do some evaluation for you! I think I have enough time for that this weekend even. I'll send you a personal e-mail about this later today =) Love your enthusiasm/openness!.

Cheers

 

Thank you for all your help and feedback. :)

--
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/