UX Principles

From Audacity Wiki
Revision as of 14:46, 23 September 2016 by Galeandrews (talk | contribs) (Fixed typos. Questions in ednotes.)
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.
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.
Gale 23Sep16: Can you explain what the above means in more detail? What "lower level" do you have in mind for FAQ's?