Re: AU interface consistency
Re: AU interface consistency
- Subject: Re: AU interface consistency
- From: Urs Heckmann <email@hidden>
- Date: Wed, 2 Oct 2002 03:17:05 +0200
Am Mittwoch, 02.10.02, um 01:25 Uhr (Europe/Berlin) schrieb
email@hidden:
Hi Urs,
You say many good things, but I think the main problem with it is that
you're viewing the AU interface as independent from the rest of the
operating system. As much as it sounds nice to think of the AU
interface as some audio component not bound to interface design
consistency, we can't forget that this is all on a computer and not an
audio component.
Hi John,
let me clear some things: In my opinion, consistency is good when it
means adding reliable ways of access to the underlaying model of a
control. A fader is a fader no matter what he looks like. If it is not
a fader, he shouldn't pretend to be one.
Consistency is bad when it prevents you from giving controls an
iconographic meaning by support of visual expression.
We have furthermore to decide what is styling and what is design for
usability.
For example, if a plugin (or whatever entity) is complex enough to
sport dozens of controls, the benefits of a "tidied up" and therefore
large interface are almost certainly inferior to a compact design where
many controls live in a narrow space but feature other means of order
or perceivibility (strange word, does it exist?).
For instance, my plugin, More Feedback Machine, sports 111 parameters,
each of which being important for the user. If I had made them
system-style sliders, I would have wasted 2/3 of a usual screen estate.
Instead, I made them knobs in an unconventional yet tidied up layout.
By giving them a certain, "continuous" color code ( red == negative
value, pale brown == zero, green == positive value), the user
recognizes every characteristic aspect of the whole parameter set at a
glance. And I still have a reasonably small window so you have an
overview over the rest of your application.
All I say is, there are certain aspects of behaviour and layout that
are ruled by "law of consistency". There are other aspects, that are
"free" if you want, but are most oftenly better handled in a more
sophisticated way, other than arbitrary. The "how" depends on the sole
unique application. The good design of a user interface isn't just "how
does it match the rules", it is merely "how does it work best" - And
that's not too often standard-like in audio applications.
Another example given, for working on MIDI events I use three views in
Logic for the same data: Score editor for a traditional overview,
matrix editor for overview of exact length and quantized positioning
and list view for microspace fine tuning. These all look and behave
completely different but have certain advantages, each allowing for
fulfilling different needs/tasks. An aspect of consistency is, whenever
I [alt]-drag, I generate a copy of a certain event or selection.
Although I don't find your reasons for why musical software doesn't
need to fall under interface guidelines entirely convincing, I think
you do say some good things there that should be considered.
The difference between music software and other (but surely not all)
tools is:
- You often work intuitively, not scientific this-parameter-that
- You need to have a complete overview and reference of what happens,
otherwise you loose track
- Even in situations concentrating on specific aspects, there can be
dozens of parameters per editor
- There's about no task where one editor acts alone, you always need
contact to several other editors
- Your work isn't "situational coherent", you frequently jump between
tasks
- Therefore, screen estate counts and compact sub-environments offer
advantage against generous layouts
- more things not mentioned (may become a PhD thesis, then)
Speaking in general, this makes it different from word processing (one
main document view, supporting parameters surrounding), digital imaging
(many compactly displayed standard tools, all acting on one document
view, some occasionally used add ons), CAD/3D stuff (quite complex, but
a more situated long-term work on models, animation, details, textures,
etc.) and (not as much) video editing. Latter can be almost as complex
as music, if you think of After Effects. You could mention software
development, but all the different files belonging to one program are
still of same type, text that is.
Because music software may have special needs doesn't mean we throw
all guidelines out the door and have a free-for-all. The design of an
interface needs to take into consideration the conditions in which
it's going to be used - as it doesn't exist in the world by itself.
Even when developing custom interfaces, how it fits in with the rest
of the system is vital.
He he, I used V-reorder on the quotes. Going in danger to repeat
myself: Consistency belongs to how-do-specific-controls-work and how
are aspects of design like mapping or grouping met. Spoken simply: Does
the user get what he expects?
Leaving traditional meaning of consitency (may I say equality?), I
think music is a poor visual actor and we use to deal with conventions,
neatly wrapped in terminology and parameters. Hence graphical
visualization is a higher order abstraction compared to painting or
writing, therefore has poor WYSIWYG and thus needs more specialized
iconography and functionality. If by any means of design or
customization, accessibility and usability are increased, this should
be preferred over copy paste guidelines (i.e. "vintage look"). (Though
I must admit, it is often styling == marketing, not design)
The success of Logic is based on you-can-do-it-if-only-you-know-me, not
on here-it-is-and-that-is-all. Sometimes the trouble of a huge learning
curve gets outpaced by the advantages you get after. (Same seems to
apply to developing AudioUnits vs. VST :-)
Did you realize, software for time-variant media commonly uses more
custom controls than software for static media? (What is a piece of
software then, static or time-variant?)
Now I'm tired and get some sleep. I follow this later, if not everybody
is bored by this.
Cheers,
;) Urs
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.