14 Oct
2010
14 Oct
'10
2:13 a.m.
On Thu, Oct 14, 2010 at 3:45 AM, <fons(a)kokkinizita.net> wrote:
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.
On Thu, Oct 14, 2010 at 12:52:50AM +0200, Arnold
Krille wrote:
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.
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.
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'. 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. 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?
Ciao,
--
FA
There are three of them, and Alleline.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org