GUI Design Guidelines
JC has suggested this page where we propose and discuss 'visual standards'. Should we write a "Style Guide" for visual appearance? This could cover examples such as:
- When to use a dropdown menu and when radio buttons? JC: Drop down when four or more items? I find the long list of radio buttons for the FFT size ugly.
- Buttons on toolbars to be styled as for operating system default? JC: I think not. I'd rather we have the flexible themes.
- Use of same kind of sliders throughout? JC: Sliders need improving so that we can easily enter precise values. If we use different kinds we should at least have an excuse or reason, e.g. I'm OK with a different slider in preferences to in the track, but I think overall output level and per track level should use the same visual design.
- Are dialogues too wide and buttons too large (look at Tracks > Resample as an example, where the text box is about eight times longer than needed to accommodate the text input). Is there any consistency now in why dialogues with little text are as wide as they are? JC: Yes, we are too wide in places. Let's never have sentences on buttons, instead single words, e.g. [Download] Lame installer, with the 'Lame Installer' text that's alongside the button.
- Whether we put units in brackets or not, if so "( )" or "[ ]"? JC: If we have units on the left, then we need brackets.
- Whether units go after text boxes or before. We are inconsistent about this in Preferences (see Audio I/O where text is after the box, Quality where it's in the text in the box, and Spectrograms where it's before the box inside circular brackets). We also have a consistency problem that the style of recent type 3 Nyquist plug-ins has moved the units value to left of the entry box. Also, these values are in square brackets. GA thinks if we want to be consistent this implies units to left (or above) boxes, as some boxes/controls are simply too long to reasonably have units after the box. Additionally, screen readers can't read the units unless they are before/above the box. JC: Not keen on units on the left, but I do buy into the argument, so yes, labels on the left.
- Quotations - should these be " " or ' ' (applies to documentation also). JC: Depends on context.
- Menu paths - should they use " > " , "->" or what? (mainly applies to documentation) JC: Mild preference for '->'
- Capitalisation of all words, or nouns only? JC: Other. I think style guide is that important words get capitalised, words like 'and', 'for', 'of' don't. It also depends on context, e.g. maybe different rules for wiki titles. Don't have a strong opinion.
We have a general principle of using blues and greys in the Audacity GUI. New developers tend to like using red to make their new features stand out. However, we try to curb this tendency and tone it down to get a quieter look.
We often get people offering replacements for our already well established Audacity icon/logo. The icon/logo is in many ways the cherry on the cake. At this stage in Audacity's development we are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the wiki, the manual, icons in the program and so on, rather than just a new logo. We would like to have a unified appearance rather than a patchwork and, when we have theming working well, we would definitely like new skins for Audacity.
Some other specifics
- Suggested we should use the same smaller logo and higher screen position of Welcome Message for About Audacity JC: After having seen the About box again, yes, would be better.
- Disallow alphabetic characters in text input fields in plug-ins, so that you can get to Preview in any effect by just pressing "V" (as you currently can in Equalization) JC: Needs more thought, e.g. plug ins that allow frequency change from C# to A, very convenient to have alphabetic entry.
- [LL] Greater consistency of '...' in History list (Does this belong in this group? What does it mean?) JC: I think this indicates condensed entries, and if so we do want to be consistent there. It's a programming issue.