GUI Design Guidelines

From Audacity Wiki
Revision as of 16:01, 19 January 2018 by PeterSampson (talk | contribs) (Details: link to new manual>wording page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

General Points

  • Discoverability
    • It should be possible for a user to start using Audacity without a manual, and then gradually discover the features.
  • Attention is a resource: There is a tension in design between uniformity and attention.
    • It is super to treat things the same internally inside Audacity uniformly, as it means less code to do more.
    • User-attention is a scarce resource, and more 'user attention' (colour, screen real estate, dynamic changes) should be spent on the most used features.
    • So our menu items, small buttons and big buttons should all be the same kind of thing inside Audacity. Yet in the GUI, we make just 6 buttons big, 26 small, and the rest are relegated to menu items.
  • Use "coding theory" in your menu layout.
    • The less probable a menu click the more deeply in the menus it should be buried.
    • Coding theory gives a numerical guideline for how deep a menu item should be. If items are used 1/10 the time of others, move them 1 menu item down. If used 1/100 th as much, move two items down.
  • Alt-Green-Meta-Shift-Ctrl-Double-right-click-E is undiscoverable.
    • Please don't expect your users to stumble onto it.
  • Stuck-in-a-mode is evil.
    • Your users won't even know what the mode they are stuck in is, just that what they are used to does not work anymore.
    • You can avoid stuck-in-mode by returning to normal on mouse-up, by observing what the user clicks on next when they do get stuck-in-a-mode (Stuck in snap to was often followed by zooming in to select precisely), or avoiding modes at all by having draggers.
  • Avoid message cascades.
    • Do not ask your user 'are you sure' and then pop up further options and possibilities.
    • For warnings and errors, tell the user what hasn't worked and let them gather more details only if they want to.
    • ToDo.png we have message cascades at start up that should be fixed.
  • Avoid repeating GUI elements.
    • ToDo.png It is a design mistake that we have 3x microphone icon and 3x speaker icon, and two play buttons.
    • ToDo.png It is a design mistake that we have separately a play button and a play at speed button.
  • Re-use rather than reinvent.
    • We have three different kinds of zoomable rulers. This is a mistake. We should have one properly designed kind that is general enough to work well in all three contexts.
    • We have multiple ways of activating scrubbing, rather than one well thought out way.


  • YOU are not the only user.
    • You have to think about it from the point of view of someone who does not already know what you know.
  • YOUR shiny new feature is (probably) not the most important feature in the program.
    • Do not make a flashing neon red pop-up to draw attention to it.


  • Use Dropdowns rather than radio buttons when four or more items?
    • ToDo.png The long list of radio buttons for the FFT size are ugly and should change.
  • Use Words not sentences on buttons.
    • We are too wide on buttons and dialogs 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.
  • Use consistent capitalization.
  • Wording and punctuation
  • Units
    • Units before an input box should be in brackets ().
    • Units are better after an input box. to be reviewed as Gale points out screen readers may only read units if before.
    • ToDo.png fix this for spectrograms.
    • ToDo.png fix this for Nyquist type 3 plugins.
  • We have a general principle of using blues and greys in the Audacity GUI (Light and Classic theme). 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.

Proposed and not Accepted

  • Buttons on toolbars to be styled as for operating system default? JC: I think not. I'd rather we have the flexible themes.


These points belong elsewhere??

  • 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.

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.

  • 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 Completed 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 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.