• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AU interface consistency
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU interface consistency


  • Subject: Re: AU interface consistency
  • From: email@hidden
  • Date: Wed, 2 Oct 2002 13:06:02 +0100

Hi Urs,

I'm sure you would agree that if an application had a different UI (visually and functionally) for different operations within the same scope, this would be bad interface design. But this is what's proposed with the idea of different interfaces for AUs. Sure these applications that use custom interfaces (maybe they are warranted, or not, I've seen plenty that don't need them), but if they took the next step and made it different even from within itself the developers are just silly!

Maybe standard controls aren't sufficient in some cases for audio, and as you write I see more of this, but my main concern has always been the idea of a different interface for every AU.

In any case, you have been the only one to give a good reason to use knobs as a control (spatial) - but perhaps something else could have been used for your needs, may even a totally new way of working with it, functionally speaking.

I suggest that basing an computer software audio interface on an audio component is not necessary, since they aren't the same thing, aren't used the same way (with fingers), and aren't limited in the same way. Maybe a new interface should be developed, but all I'm worried about is going from different interface to different interface to different interface all within the same application.

-- John


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.

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.

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.

References: 
 >Re: AU interface consistency (From: Urs Heckmann <email@hidden>)

  • Prev by Date: Re: AU HostCallback - musical location
  • Next by Date: Re: AU interface consistency
  • Previous by thread: Re: AU interface consistency
  • Next by thread: Re: AU interface consistency
  • Index(es):
    • Date
    • Thread