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.

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@linuxaudiosystems.com> wrote:


On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt <mista.tapas@gmx.net> 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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev




--
Louigi Verona
http://www.louigiverona.ru/