Re: AU interface consistency
Re: AU interface consistency
- Subject: Re: AU interface consistency
- From: Christian Brunschen <email@hidden>
- Date: Wed, 2 Oct 2002 11:10:26 +0100
On Wednesday, Oct 2, 2002, at 06:10 Europe/London, Jim Wintermyre wrote:
I have to say that I agree with Urs on this...
John wrote:
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.
But as a *user* who is trying to *make music*, I would probably rather
have my vintage synth plugin UI look like that vintage synth hardware,
because of what Urs said - I immediately know how to use it. I don't
want to have it look like a prefs panel.
I'll have to disagree in turn :) The above will hold only under two
assumptions:
1) the user in question has previously used the vintage synth in
question
2) the user in question was comfortable with the UI of the vintage synth
I own an Ensoniq VFX-SD - it has a nice UI in general; but I think that
it might very well be possible to present a *better* UI to it in some
ways, given that we escape from the confines of having only a small
display, but a large number of buttons and a couple of sliders. But
yes, I would recognize and could work with a recreation of a VFX-SD UI.
However, if I were to want to recreate sounds from a vintage synth I
had never used, I wouldn't necessarily want to have to use, and more
importantly, *learn* the particular UI of that vintage synth; I would
probably find it a lot easier if all of the different synth plugins I
use, would use similar UIs that were consistent with each other and
with the rest of the software I'm working with - in this case, Mac OS X
and its UI guidelines.
Having said that, there are also cases where it is nice to see all the
parameters laid out in a standard view (but in my work I'd say that's
the exception rather than the rule).
Again, I think this probably depends on your background. If you grew up
with vintage synths, then the sight of a familiar UI will be an
immediate boon to you; but if you didn't, it may just be confusing and
irritating - 'I just want to make music with these cool sounds, but I
*hate* these sligthtly-different UIs with their fiddly buttons!' might
well be the reaction of a user who might then just decidde *not* to buy
synth plugins from that particular company, simply because they don't
offer _that user_ an acceptable UI experience.
Also, don't forget that like it or not, there are a ton of VST plugins
out there that people are already used to, and they're not going to be
happy if the UI changes on them in the AudioUnit versions for no
apparent good reason.
Well, the entire UI experience of Mac OS X is different from Mac OS <=
9 , and AudioUnits _are_ different from VST plugins ... so I'd say that
there's ample apparent reason to change the UI, and I think a
reasonable amount of consistency with the new host environment is a
good reason as well.
That said, *any* UI must be carefully laid-out and designed to perform
its main function. But there is a fair bit of leeway within the Mac OS
X HIG; perhaps it would be a good idea to have a standardized knob
control precisely for use in AudioUnit UIs? But I digress.
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.
I can only agree. Of course, 'how it fits in with the rest of the
system' may include carefully deliberated decisions to *not* follow the
genera guidelines, in order to create a contrast or draw the user's
attention. It just has to be done carefully, and in my opinion the
approach of 'let's just recreate an existing UI that is totally
different from its surroundings' leaves a lot to be desired, unless
that is specifically the main goal; but most music applications are
about recreating the *sounds* of existing instruments, and recreating
their precise UI should perhaps be considered an optional extra.
In an ideal world, such a plugin might offer a choice of two different
UIs - one a faithful reproduction of the original, and one that fits
cleanly into the surrounding system.
I would say that these guidelines should be applied towards the
general "controls" view, a la Logic. Let the user have the best of
both worlds, and make the controls view standardized across different
hosts. Currently every VST host's version of the "controls" view is
different.
This, too, should be addressed, but that doesn't excuse AudioUnits from
presenting a good UI in themselves.
My $.02.
My UK#0.02,
Jim
// Christian Brunschen
_______________________________________________
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.