UX Principles

From Audacity Wiki
Revision as of 15:08, 28 September 2016 by Galeandrews (talk | contribs) (Intro, not note for intro divs. Don't use H1 for section headings.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This is a companion page to Visual Consistency. It is a collection of notes about user experience design.


Having principles behind the user experience helps give consistency to the user interface which in turn makes it more discoverable. It also can reduce coding, if we reuse and adapt the same code. This document is a working draft, and none of the principles should be seen as set in stone.

The Principles


  • Try to merge multiple ways of 'doing the same thing'
    • For example, we have a 'play' button and a 'play at speed' button. 'Play' is just 'Play at speed' with the speed set to x1. We should look at making both buttons special cases of the same thing.
    • The icon for record/play on the meters and for record/play on the volume settings are repeated. We could do as LLMS does and put meters and setting on the same control - saving screen real estate, moving closely related functionality together and removing the repetition of the icon.
  • Try to merge closely related functionality.
    • Range labels and point labels are 'the same thing'. The label UI is designed to facilitate using the label markers as boundaries between regions too. Dragging can adjust a left and a right boundary at the same time.
  • Merge multiple dialogs.
    • The Audacity start up sequence can involve a splash screen, recover projects dialog and a welcome screen. These should be merged down into one more flexible dialog.
  • Reuse
    • Envelope curves should be reused for automation.

Flow vs Stuck

  • Avoid Disabling.
    • Users often don't know why functionality is disabled. Select-all-if-none helps get round the problem of effects depending on having a selection first.
  • Avoid 'stuck-in-a-mode'
    • Snap-to was a mode users could get stuck in, not knowing why they could not select at finer granularity. This is only partially solved by making it a more deliberate process to enable the mode.
    • Stuck-in-pause was a mode users could get stuck in. Now pause pops up.
    • Modes like scrubbing/seeking should be consistently exitable via ESC.
  • Observe what users actually do to solve problems, and try to make that actually do so.
    • When stuck in snap-to users would zoom in to select at finer granularity.


  • Interactive vs Batch
    • In loop play the loop boundaries should be adjustable as the loop plays.
    • Effect parameters should be real time adjustable.
  • Speed
    • Make features fast, especially where interaction is required.
  • Scalability
    • Feature design should consider multiple instances of a particular graphic element. e.g. working with multiple labels, multiple clips, multiple selections.


  • Heavily used features should be differentiated from lightly used ones.
    • Large buttons for play and record.
    • Frequent actions get buttons, not just menu items.
    • Frequent items should be higher up in menus than less frequent ones. We can be a bit more precise and use the log of probability as a guide to how high up in the menus a feature should be.
  • Optimise towards new users.
    • Record appends the new recording rather than producing a mix.
    • The default view of a track is as a wave rather than as a spectrogram.
    • Experienced users can customise so defaults can often be set as for new users.
  • Use colours with a purpose.
    • Avoid using red simply to draw attention to a new feature. Red is typically for record or warnings.


  • Avoid 'Anna Karenina' tooltips.
    • Generally a tooltip should NOT list what variants with ctrl-shift-alt modifiers do, or what the key bindings are. There should be other more natural ways to discover these.
    • For example, we currently need tooltips on play and record that mention the action with shift. We would not need these if instead we used multibuttons. Hovering over the button for play would show the tooltip for play AND a downward pointing triangle below the button for other variants of play. Click on that downward triangle and the multibutton expands, showing play, loop play, play-excluding, play half-speed etc. Each tooltip then relates to one function.
    • Keyboard short-cuts for buttons can be avoided by default. Menu items have a mechanism for showing keyboard shortcuts. Any feature that merits a button probably merits a menu item as well. It is not to oonerous to expect users who want to use keyboard shortcuts to learn about those shortcuts from the menus rather than from the buttons.
Gale 23Sep16: Such as? If long established shortcuts or usage changes, established users need some help.
  • Avoid 'Audacity becomes Verbosity'.
    • Use context sensitive help to avoid very long named/explained preferences. Often context sensitive help should be grouped into blocks of related functionality rather than overly fragmenting it down to per-setting.
  • Use sub headings
    • Avoid repeating text by using sub headings to set the context.
  • Be wary of expansion of quick-help / summary / FAQ etc.
    • Each of these can over time expand. Have a criterion for what belongs and what doesn't, and have a 'page limit' after which new material has to 'bump' old material out to a lower level.
    • Quick help and Tour Guide become too long to read if we don't put a page limit. If Audacity did very little apart from noise reduction, it might be appropriate to say a bit more about removing mains hum, coughs, and clicks and limitations of noise reduction in the Tour Guide section, however Audacity is a general purpose audio tool, and other content about what Audacity can do has a stronger claim to be in the tour guide. Without a page limit the tour guide could easily become a reduplication of the manual - and not serve its intended purpose as a guide.
    • FAQ stands for 'frequently asked questions'. Not all questions are asked as frequently as others. If the FAQ were called Q&A then it can be as long as the authors want it to be. The expectation for a FAQ is that if I read the questions in it there is a high likelihood that a good proportion of them will be relevant to me. If Audacity was used mainly for wildlife recordings, an FAQ question "How do I record bats?" might be super. As Audacity is general purpose, such a question should be bumped to a lower level. We could for example have a general Q&A section, or perhaps better have subject specific Q&As. It would be perfectly OK for the FAQ to have a question "What advice do you have for working with Vocals/Music/Wildlife?" and for that to link to tutorials or topic specific Q&As. A wildlife recording Q&A could have the question about bats. If anyone was motivated to write it.
Gale 23Sep16: Can you explain what the above means in more detail? What "lower level" do you have in mind for FAQ's?