Re: [LAD] Experience driven design and Linux Audio

On Thu, October 2, 2014 1:01 am, Louigi Verona wrote:
> Discussion often focuses on "thinking for the user" or about users that
> "don't want to learn".
>
> I don't think that this is what the guy in the video was talking about.
> And
> this is certainly not what I mean when talking about "usability" of Linux
> software.
>

Usability usually requires a designers eye. Most good UX designers spend
almost all their time on design/usability issues. In fact most UX
designers are paid to only deign the UX and they look to developers to
advise on functional viability of their creations. In most cases in a
professional context UX designers will win over developers if there is a
decision to be made between form over function. Developers are usually
left to fill in all the gaps that UX designers have left in the
functionality of their design and In my experience developers are often
considered to be skilled labour while a designer is considered to be a
working artiste or in some way superior.

In open source development most developers are not designers or
particularly visually motivated. The exception being graphics/games
developers and a few very talented people who cover both disciplines with
expert delivery. In Linux Audio Development there is a clear majority of
audio focused developers who prioritise function over form. Considering
that even software like Blender has a major learning curve for the
uninitiated and those guys are expert visually oriented developers it's no
surprise that Audio focused developers are less successful at achieving
visually beautiful and highly polished usability.

IMO, in nearly all LAD applications the developers have tried to achieve
usability with the limited skills/expertise that they have in UX design
and GUI development.

The main problem in this regard is the lack of
interest/motivation/time/resources to make things more usable. The idea
behind open source is that anyone can pitch in but it seems in Linux Audio
Development there are less people pitching in these days than say 10 years
ago and there are more individually run projects

That's seems to be the main reason why many developers choose to use bog
standard gtk/kde to let the user define their own version of usability and
steer clear of visually challenging API's like Cairo/Clutter/OpenGL which
often require as much effort or more to achieve results than just writing
good clean efficient functional and bugfree code.

A way to enhance usability across the board might be to have an "app of
the week" where everyone in the Linux Audio community is encouraged to run
it and provide any feedback they can think of on mass to the LAU list.
That might give developers some incentive to forge ahead with the ideas
presented by the community.

> Experience-driven design, as I understood him, is about convenience and
> being able to make a tool that is easy to use. But "easy to use" does not
> mean "dumb usage". It rather means "pleasant" to use.
>
> There is a huge difference between having options in a text file that you
> have to edit or having them in a GUI. And the difference is not in "having
> to learn" - most users know how to edit a text file. The difference is in
> convenience. There is an inherent difference between going to a folder,
> locating a config text file and editing it and just seeing all options
> laid
> out in a GUI, right within the program.
>
> GUI does not have to dumb you down. It economizes your time and effort by
> showing you all the options and letting you tweak them more quickly and
> get
> the information from your options in a more pleasant way. Having a GUI
> does
> not mean reducing your options.
>
> *---*
>
> As an example, when I need to write using a text field the amount of delay
> in milliseconds, this is not "advanced". This just takes up my time,
> because I need to figure out the amount of ms required for my bpm and then
> input numbers into the field with a keyboard.
>
> One can, of course, argue, that you can learn the formula, but this is
> arbitrary. As Harry very correctly pointed out, this has little to do with
> composing.
>
> If instead of inputting numbers I get a knob - this is better. But if I
> get
> a knob that will tweak delay time in actual bpm-multiple values - this
> will
> be much more pleasant. Not because I am "not able to learn", but because
> this helps me get my task done faster.
>
> One can, of course, argue that having ms allows you "more functionality"
> and this is where the argument often lies - that Linux software allows you
> "more options". But in my view the price of implementing those options
> (and
> not implementing easy to use GUI) far outweighs the actual need of those
> options. How many times in your life have you needed to set delay time to
> like 123.7863218 ms or other weird time?
>
> ---
>
> So I think a developer should ask himself - would he want his software to
> look better and to have a GUI that would help users get things done faster
> and in a more pleasant manner? If yes, but he has no time - sure, it is
> clear. If no - then this is a different position altogether. And this then
> has nothing to do with "learning" or "dumb users".
>
>
>
> Louigi.
>
>
>
>
> On Wed, Oct 1, 2014 at 5:20 PM, Paul Davis <paul@email-addr-hidden>
> wrote:
>
>>
>>
>> On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt
>> <mista.tapas@email-addr-hidden>
>> wrote:
>>
>>>
>>> The important point was though that left to their own devices the
>>> non-enthusiasts will be slaughtered by the software they use and maybe
>>> we have a responsibility to protect them from themselves.
>>>
>>
>> "slaughter" is perhaps a strong term.
>>
>> perhaps a more nuanced description might run something like this (taking
>> a
>> little inspiration from the video):
>>
>> creating and maintaining **consumer** software with a very good user
>> experience is expensive (relative to other tasks that people do) and
>> takes
>> a significant amount of time. therefore the creation and maintainance of
>> this sort of software requires resources that are not clearly available
>> to
>> most open source efforts. the proprietary software that manages to do
>> this
>> is influenced at some level by where its creators and maintainers get
>> their
>> income from, and the development of the "free" model used in particular
>> by
>> google points in a direction where the software must
>> allow/empower/enable
>> behaviour by the software developers that are not in the users' best
>> interest (e.g. selling data about the users).
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev@email-addr-hidden
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>>
>
>
> --
> Louigi Verona
> http://www.louigiverona.ru/
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev