On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona <louigi.verona@email-addr-hidden>
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@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
Received on Wed Oct 1 20:15:02 2014
This archive was generated by hypermail 2.1.8 : Wed Oct 01 2014 - 20:15:02 EEST