On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona <louigi.verona@gmail.com> wrote:

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.

this isn't universally true. there is a class of user for whom editing the text file is actually the faster, more efficient way to change options, especially if there are a lot of them. whether this group of users is large, and whether it should dominate design models is a separate question.
 

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.

it doesn't have to mean that, but it often does, especially if the program has a lot of options - people get scared of presenting them all and so they hide most of them.

consider the case of all the things you can do with sysctl(1) on OS X that are not represented anywhere in the GUI. they *could* be, but they are not, because doing so conflicts with the experience that apple designers wanted people to have. anyone who needs to do "that stuff" is fine with the command line, they apparently reasoned. 
 
in general, textual presentations of options and parameters *tend* toward showing the user everything; GUI presentations *tend* towared a more structured display of selected options believed to be the most important. these are not hard rules, just tendencies, but important ones, nevertheless.


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.

until you need to use a delay to compensate for a block size delay that you known in samples :)
 


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?

this is a secondary question. until you define what the "things" that are going to get done, you can't begin to ask if or how to help users with those tasks.

 
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".

i think it has a *lot* to do with it. there are a whole bunch of things you can do in a DAW-like tool to reduce the initial confusion and number of things the user has to do and comprehend before they manage their first recording pass or audio import. garageband is a perfect example of how to do this. the cost is that (a) the user learns very little about the underlying concepts of the application (b) you must hide a set of options that would just confuse first time usage but that may be critical one month in (I've watched my son face this curve with garageband, which is partly why he no longer uses it and is on Live instead).

This leads naturally to one of two approaches: more workflow specific tools (e.g. Live/Bitwig, Trackers, audio file editors, traditional DAWs, SuperCollider ...) or "gradual reveal" in which the user gets to control how much of the full set of possibilities are accessible/visible at any point in their use of the tool.

When you give people an app that does one thing (i'm thinking of android/iOS apps here), these considerations don't apply because the "things to be done" are so easily defined and so limited that it really just a presentation/design issue that doesn't have to sacrifice power for experience.

But when you give people an app with the power of (even) audacity (let alone Live or ProTools), there is naturally a learning curve, and it is a critical question how and if the application will try to assist the journey along this curve. First time DAW users are always "dumb", no matter which DAW they sit down in front of. How they get to be less "dumb" is about learning, and the learning is very very dependent on the design and structure and goals of the application.
 



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/