>> > particularly the whole issue of user interface consistency across >> > multiple apps. >> >> In the audio world there is quite a string move away from this. Witness all >> the cool custom GUI plugins on Win32 and Mac. > >You're right, and frankly, I hate it. It's plain silly to have to spend time >teaching production people how to use the new whatever-it-is-whizbang-thing >because it's author chose to use a "cool custom GUI" instead of the stylebook >standard. It might be boring, but there is a reason why stylebooks exist.
Yes, there is. Its to provide uniformity across a range of applications whose fundamental user interface metaphors are the same. Audio apps are not in the same class as office productivity apps, IMHO. Their UI metaphors are quite different. If you compare the number of widgets in a typical audio app, you will find 2-10 times the number in a typical window than in the typical office productivity app. This is partly a function of the UI metaphor, and partly a necessary consequence of the apps' functionalities. This alone breaks several "stylebook" ideas, the most obvious being focus traversal, which becomes completely pointless with 200 widgets in a window. When you present a pro audio app user with a widget that looks like a gain fader, the user knows what to do with it because they have seen a gain fader on a physical console. If you substitute a default toolkit "slider", the instant association with the function of the element vanishes for a large part of the near-term user community. They have to mess around to find out what does what. The use of icons is similarly problematic. Its bad enough with office apps; what icons do you use to convey the fact that button turns on "auto input"? Finally, the issue of data entry rears its head. Most GUI audio apps feature incredibly low amounts of data entry via the keyboard or mouse. Instead, these input devices are used to control the ongoing (realtime) operation of the program. This is in marked contrast to word processors, spreadsheets, calendar programs, MUAs and most other "desktop" programs, where the primary use of the program is to enter and manage textual data from the keyboard and/or mouse. This is not an exhaustive list of the differences in UI metaphors, but its enough of a start to begin a discussion :) >One of the main roles of DEs is to enforce those stylebooks. Perhaps the >strange UIs have a place in the consumer world, but I like to think that the >pro audio people can avoid that. I disagree. Its the pro-audio world, filled with people with hands-on experience of physical audio controllers, and almost no usage of Word, Outlook or Emacs, that is best suited to custom GUIs. The consumer market, filled with people used to the "Windows/MacOS" GUI model, would likely feel more comfortable with audio apps that adhered to the "stylebooks". --p
