Top Usability Issues

From Audacity Wiki
Revision as of 13:47, 21 January 2010 by PeterSampson (talk | contribs) (Copy-in versus aliasfiles for uncompressed audio: I support "Safer" being the default option on Import)
Jump to: navigation, search
This page is for listing issues of usability, mostly those found during writing documentation, where changes in Audacity code would make documenting the behaviour SIGNIFICANTLY easier

Edit Hint: Links to the pages in the manual wiki which show why explaining is tricky could help.

Copy-in versus aliasfiles for uncompressed audio

Warning icon Use of audio by reference (faster) vs copy audio into project (safer) is confusing, and can lead users to lose projects, e.g. by deleting audio they think they no longer need. There's possibly going to be a proposal page about changes in this.
  • BillW 20Jan10: IMO changing the default in Import / Export Preferences to "Make a copy of uncompressed audio files before editing (safer)" would go a long way towards shielding new users from this problem. We could then possibly dispense with "Rule #3" in Audacity for the Impatient (or wherever the "3 rules" are eventually placed).
    • New users are presumably downloading Audacity for the first time, and many are complete novices. Rule #3 may be incomprehensible to them.
    • Seasoned users who prefer this option will have it set in their preferences which will be retained when they upgrade to a new version.
    • Performing an effect on an entire imported track (such as Amplify or Normalize) completely negates the disk space saving nature of the "read directly" preference as Audacity must save (internally) the changed version of the track. It seems to me that if the "Normalize all tracks in project" preference is checked then this will happen automatically.
    • Surely Audacity could check if referenced aliasfiles are available and warn the user rather than blithely playing silence while simultaneously displaying a waveform? This check could be done on opening a project and a comprehensive error message displayed.
    • Perhaps a warning when importing using "read directly"? This could be turned off in the warning dialog or in Warnings Preferences.
    • Is there better wording/description to "read directly"? This confused me initially. What's the opposite? Read INdirectly?
  • Peter 21Jan10: I wholeheatedly support the idea of making the "Safer" option the default. It is mainly inexperienced users (but not always) who fall foul of this. My understanding is that the "faster" option was chosen as the default to make working with Audacity faster for power users. But my contention is that power users are the ones most likely to probe and understand the various settings in Preferences - and in particular understand the import settings there. With Audacity OOTB we should aim to make things as foolproof as possible for the new user.

Save and export confusion

Warning icon Some users don't realise that export is needed to save audio in non .aup formats.
  • BillW 20Jan10: I think this is user error and RTFM. In Warnings Preferences by default this preference is checked: "Saving projects: Every time you save a project, Audacity will warn you that you are saving an Audacity project file that only Audacity can open. Once you understand this, you can turn off this warning from within the warning dialog." If users choose to click through that warning without reading or understanding it, what more can we do?
    • I am not (at this time) in favour of a "Save Special" to replace the export menu items. I think this would just further confuse the issue. Export is technically correct - files are being created for use outside of Audacity. Other multi-track software might call this "Bounce to Disk" or "Mix to Disk". "Save" is reserved for saving the multi-track project.
  • Gale 21Jan10: See Proposal Menu Reorganisation for details and make further detailed comments about a re-organisation solution there.
  • Peter 21Jan10: I tend to favour retaining the Export command. Many software packages use Save when storing data in their internal format - and Export when creating the non-native formats that are intended for use elsewhere - the current structure has a syntactic purity.