| The text on this page should only be modified by subscribers to Audacity-devel mailing list.
To understand what this page is for and how it is used, please join that list or read the list archives on Sourceforge.
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 do now have Guidelines on capitalization in Audacity dialogs and messages.
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.
Icons, Logos, interface and websites
We often get people offering replacements for our well-known and long-established Audacity icon/logo.
The design of icons/logos is in many ways the cherry on the cake. At this stage in Audacity's development we are less interested in just a new logo. We are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the entire Audacity visual experience (the icons in the application, the logo, the Manual - also developed using MediaWiki - and the other websites). We would like to have a unified appearance rather than a patchwork.
We do want in future for the user to be able to customise the appearance of the Audacity software to some extent, for example to allow greater or lesser contrast in color of the various GUI elements. So when our Theming feature is working well, we would definitely like new skins for Audacity. Some of us feel that a small number of subtly different alternate icons could possibly have a place in non-default skins (without changing the default icon/logo).
Although we sometimes receive offers of help to improve the Audacity interface, we don't currently have developer effort to spare to work with a UX and graphics designer to get Theming or other visual improvements into Audacity. Meantime, a well-argued report on the usability and discoverability of Audacity features would be helpful to us. We have to use our resources wisely, so knowing what causes most users the most UX problems is where we need to start.
If you have any images of suggested new logos or icons please link to them on Proposal New Logo (ideally, upload your image to the Wiki and link to that). It is anticipated that any new logo/icon would retain the current "headphones" idea. A new logo would continue to have the "Audacity" name followed by the ® registered trademark symbol.
Similarly, please link to images of suggested new skins on Proposal New Skins. However, don't expect anything to change in the immediate future.
We also have received offers of help with redesigning or "modernising" our websites, especially the main site http://web.audacityteam.org/. We're always interested in hearing well-argued suggestions for improvements, but we do not want to make change just for the sake of a "new look".
Some other specifics
- We changed "About Audacity" to use use the same smaller logo and higher screen position of the "Welcome Message".
To be considered:
- 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.
SD: If also applied to Nyquist plug-ins it would be impossible for users to input a path or file name.
- [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.