[LAD] [LAU] So what do you think sucks about Linux audio ?

Gabbe Nord gabbe.nord at gmail.com
Wed Feb 6 10:51:36 UTC 2013


On Tue, Feb 5, 2013 at 8:34 PM, Devin Anderson <surfacepatterns at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130206/4c621fa6/attachment.html>


More information about the Linux-audio-dev mailing list