Re: [LAD] Experience driven design and Linux Audio

On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona <louigi.verona(a)gmail.com> wrote: 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. 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. until you need to use a delay to compensate for a block size delay that you known in samples :) 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. 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.