On Thu, Oct 14, 2010 at 3:45 AM, <fons@xxxxxxxxxxxxxxx> wrote: > On Thu, Oct 14, 2010 at 12:52:50AM +0200, Arnold Krille wrote: > >> On Wednesday 13 October 2010 22:21:04 you wrote: >> > On Wed, Oct 13, 2010 at 07:52:29PM +0200, Arnold Krille wrote: > >> > > [*] No, I don't have references at hand. I just look at the big projects >> > > with their usability experts and their guide-lines. Which they create so >> > > that developers like you and me don't have to worry about colors, >> > > knob-behavior, widget movement and key shortcuts... >> > >> > A few comments: >> > >> > "Usability experts" in big projects are more often than not just >> > market researchers. Which means that whatever they produce amounts >> > to the desires of a population whose preferences are in most cases >> > not the result of any rational process but of commercial manipulation >> > combined with ignorance. And in any case what they turn up would be >> > completely irrelevant in the context of any specialised application >> > domain. I'll let audio engineers tell me how an audio app should >> > look on screen, not any of those 'experts'. >> >> That is not very fair to the usability experts working in universities, doing >> usability-studies on free software and for free software. Yes, they try to >> sell something. Free software for example... > > I'm pretty sure that none of them is evaluating audio software from the > perspective of an audio engineer. > >> Ok, so my suggestion of using CTRL+Q for 'quit' is bad. Probably my suggestion >> for using 'whatever the user wants as shortcut for quit' is also bad. > > Of all actions a program may perform, quitting is probably the one that > *least* of all needs a shortcut. If you quit, your work is finished. Compared > to all others it's a very infrequent action and there is nothing urgent about > it. Your window manager will provide a 'Quit' button, and that's really all > it takes. It doesn't even depend on the application. > > Things that require shortcuts (in audio) are editing actions as in Ardour, > actions that change the visual presentation in a live context (e.g. opening > a window with plugins in a mixer), triggering real-time actions (e.g. start > recording), etc. Instruments implemented in software require them as well, > but I wouldn't include them as general-purpose audio apps - they are really > a class apart. > > There are no sensible shortcuts for 'Aux send 4 on channel 23 on/off' or > similar actions you would perform on a mixer. And even less for changing > values of continuous controls. The only function shorcuts can have in an > app that may have hundreds if not thousands of controls is to help you > reach them as fast as possible. And that will always be specific to the > particular application. There is a solution for this, but it's outside the regular box. Split the app into zones. (navigate to a zone then have a generic set of shortcuts for the component in that zone) Mixer strips are an ideal candidate for this, as they usually present as the same per strip. (So each strip is a zone, containing shortcuts for each of the elements in that zone/strip) The problem is, as always, navigating to that strip in the first place, and that's usually the missing link in smooth navigation, unless of course you use the........mouse. Contrary to the perception that reaching the place you want to be is as "fast as possible", this is a big gap in most apps, and i'd suggest a careful review of linux audio apps will reveal that this "common" function is missing in most. I'd also respectfully suggest that directly translating hardware based functions to software isn't always the end of the story, and that additional thought needs to be given when setting up a shortcut based workflow in software for user flow that isn't present in hardware use, with navigation being at the top of the list. And a simple example of this is trying to get around any app without using the mouse. When you add up the number of navigation based actions a user will get through in a reasonable session, it makes sense to consider smarter, maybe software unique workflow design. You may be right for most audio functions Fons, but i would argue that only using a mouse for some basic navigation actions is not exactly hardware based workflow based. Changing the values for continuous controllers is relatively easy to do with the qwerty arrow set, provided those actions are coded, and the means to navigate to them is present in the first place. Using hundred of midi tracks constitutes thousands of controls with multiple CC controllers per track, and many apps get most of this fairly right, by using the method described above for zones. (poor navigation and poor multiple track management not withstanding) Having the choice to use or not use shortcuts is the most ideal of choices. > >> And using the colors the user wants (or needs!) instead of inforcing ones own >> ideas is also bad. > > I'm currently working on an app that could easily have more than a > hundred functions (some unique, some replicated over many instances) > a particular rotary control could have. The color scheme and layout > will be designed to help the user find the control he/she needs as > easily as possible. Not by thinking but by following hints he/she > will in many cases not even be aware of. Do you really think a user > would be prepared to organise that on his/her own ? > >> > As an example, the typical GUI toolkit slider is a *joke* for pro >> > audio. It's just good enough to control the volume of a media player. >> > One could expect it to be useful as well for e.g. controlling the >> > gains of a soundcard, but even in that modest role it fails (see a >> > recent thread about an improved envy24control). >> >> I agree on the typical slider. The typical rotary knobs are bad too. >> But that doesn't really mean that every app should use its own invention >> with own graphics and own use-method, does it? > > Why not ? If it does the job its OK. And if it's designed by someone with > real-life experience in the particular field of application it is probably > close to what another designer with the same background would provide, and > to what an experienced user would expect. And anyway, what is the alternative ? Good point, but again, only once choice of user interaction (mouse), not only directly, but in a chain of actions the user might use constituting a wider workflow set. (I call them "klunk" moments, when the user has to abandon the qwerty to use the mouse, then back again. Not conducive to speedy use.) I'm looking forward to seeing your colour coded intuitive process, but i still don't understand why the idea of qwerty options for as much as possible is argued so enthusiastically against for workflow. Is it harder to code? Will someone come hunting me with a pitchfork and a torch if i, as a user, decide to use the keyboard instead? :) Alex. > > Ciao, > > -- > FA > > There are three of them, and Alleline. > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user > -- www.openoctave.org midi-subscribe@xxxxxxxxxxxxxx development-subscribe@xxxxxxxxxxxxxx _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
