Re: AU interface consistency
Re: AU interface consistency
- Subject: Re: AU interface consistency
- From: email@hidden
- Date: Wed, 2 Oct 2002 00:25:08 +0100
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.
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.
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.
-- John
Hi,
this thread starts to bcome interesting, indeed.
From the industrial/graphics designers point of view, the
looks-like-real-vintage-gear approach is not just a marketing value or
eye candy. It is also meant to (if made good, of course) to give
identity. It gives a semantical statement of the character of the
parameter behind the control. And of course the overall appearance
should represent the character of the plugin. Things that provide
analog-like warmth could simply look tube driven. For things we know
from real life can make an icon of virtual functionality.
A classical example are the emulations of real synths which sport
citations of their original appearance. Hence you know what they do
and you know how to use them, even if their features are extended.
Using standard controls with standard appearance (like Aqua) wouldn't
represent anything other than being neutral. This is surely not
desirable, as making music is usually not quite deterministic science
but rather intuition and play.
Another point is that usual Human Interface Guidelines don't exactly
apply to musical software. Guidelines commonly weight all parameters
equally in importance. This derives from the notion that all
parameters displayed in a single context manage a global aspect of a
document (Exception would be a font palette for text where different
font styles could be used). Less important items are banned on
subpages.
In music everything is different. The whole set of parameters, maybe
thousands, apply to just one stream of simple information, samples
over time == musical output that is.
All parameters are interconnected to provide one output. Hierarchical
layers (Notes, Sounds, Mixers etc.) are basically completely borrowed
from reality where these also have physically been entities.
Each entity in itself just contributes a single aspect to the output.
The approaches made to meet this contextual complexity have grown
within the history of say the past twenty years which itself created
new iconongraphy, when you think of waveform editors etc.
This shouldn't be sacrificed to the seemingly ease of standard
controls aka over-interpreted consistency.
I can't go in further detail now (I rather go to an appointment now
where I'm already late ;-), but I think it is clear that non-standard
interface mentality is not just fancy but indeed
functionality/usability.
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.
_______________________________________________
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.