[LAD] Experience driven design and Linux Audio

[tom at trellis.ch]

On Tue, September 30, 2014 15:58, Harry van Haaren wrote:

> https://www.youtube.com/watch?feature=player_detailpage&v=ldhHkVjLe7A#t=16
> 25
>
> Should we improve experience for users?
> Should we design "experience driven open" software?
> Should we forward the UX of Linux Audio to the "age of experiences"?

Every other hip project development model X tries to address UX.

Looking at one of the slides.. i find it a strange idea that a CEO would
do the (software, "UX") design. Of course in small units, multiple
functions can be incorporated in one person, but generally the CEO
represents, executes and does what the ones that provide finance want him
to do. (Just imagine the CEO designing a car for a moment.)
Good software (good in a way every POV is respected) is hard to do and a
good portion of well working symbiosis between developers, users, people
shouting the word are needed. Such an ecosystem can't be created on demand
easily. User experience is just one part, and it's a buzz part for some
years.
It should be easy though for developers to name the *core* functionality
and *critical dependencies* of their software. The best software won't 
unfold it's full potential i.e. if a dependency prevents it from starting
up at all (see the many problems some users have to start JACK).
Hiding behind the term "professional" to describe software, that is in
fact just a cumbersome pile of crap (and thus professional) is another
"strategy" i can observe. "you know, if you're too stupid to dig our silly
model of operation you're just not professional". This has to do with
wrongly understood elitism.
I think without observing users closely it's hard to get a reasonable idea
of their experience with any software. Often users bring expertise in the
domain of interest while developers bring the handcraft and best practices
how that can be translated to a programming model. Ideally, these two
share at least some common ground.
The more "convenient" a software gets, the more it must precisely and
unmistakably know and provide commonly agreed workflows. One of the most
annoying things is software that tries to be smart but fails at being it..
And of course, what is a good UX for one user can be a bad one for
another. Decisions need to be taken. Who takes decisions is a question of
how the project is organized (if at all) and why it's taken is a
consequence of the latter and outcome of a rough common strategy (i.e. "we
don't add a pink pony, because that's not the focus of the program").
The UX topic won't go away so quickly. Every other settop box (is it still
called that way?:) struggles to provide a good UI, it's getting better
though (observe: fonts and widgets get BIGGER). I haven't seen any single
case where an improvement of aspects of the user experience were reached
by making things smaller.
Cheers
Tom