Completed Proposal Menu Reorganisation

From Audacity Wiki
Revision as of 21:56, 21 January 2010 by Galeandrews (talk | contribs) (Having just "Save" as the phrase for saving a project won't work if you want to stem the tide of people trying to export through save...)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal page is about reorganising the menus.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

Proposed Feature

One driver for reorganising the menus is to avoid the problems that arise from having 'export' and 'save' as different functions. The options there can with care be merged so that there are fewer menu items.

The Audacity menus have also become rather complex with numerous options, especially when label linking is enabled.


Developer Backing

  • James Crook - In favour of certain changes suggested here.


Use Cases

  • New users of Audacity who are confused about export and save, or what the menu items actually mean
  • Experienced users of Audacity who feel the menus are too long or verbose


Details

Subject to discussion. Some options to choose from below:


Discussion

  • Gale: I'd prefer ... menu changes clarifying save and export (e.g. moving "save" down), adding a line to the project save warning about keeping .aup and _data together, and warning every time you import an aliased file (either until you turn the warning off, or a one-time warning).

Save Simplification

  • Replace Save-Project|Save-Project-As|Save-Compressed-Project-As|Export|Export-Selection|Export-Multiple by Save|Save-As|Save-Special.

Save is only for saving in .aup format. Save-As and Save-Special would actually both allow the full range of saving options through an extended custom save dialog. The Save-Special however is more-in-your-face about showing you the options. With Save-Special before you get to the save-as dialog you get an options dialog to select whether you are saving just the selection or the whole project. You'll also be told what sample rate you are saving at, and be given the option of changing that. If you use Save-Special you will see the options for the choice you have made and you get a radio button choice for the audio type, with wav and mp3 given prominence - the file extension is then defaulted from the type. If instead you use Save-As you don't automatically get shown that choice, and the audio type is defaulted from the name.

  • 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. I do know that some users (particularly newbies) find it to understand - but as BillW points out elsewhere this is a RTFM issue and that Audacity could be more informative when users ar Saving/Exporting. See: http://wiki.audacityteam.org/wiki/Top_Usability_Issues
  • BillW 21Jan10: Just to amplify what Peter has said above, there seems to be an unwritten agreement across apps for the structure of the File menu: Open / Close / Save / Import / Export / Print. I would not want to emphasize Export over Save, and I think we're better off sticking with the standard presentation of the File menu.
    I would support a minor change, moving "Export Multiple" up under "Export Selection" - it seems odd to me that it's stuck between Export Labels and Export Midi.
  • James Revised proposal - instead of 'Save-Special' we have 'Export'. Other than that it is the same idea as before.
  • Gale: If the proposal for the dialogue is essentially the same then why not leave it open as to whether you have "Export" or some other phrase? I agree "Save Special" is probably too non-standard/unclear, and I too like a clear distinction between saving (projects) and exporting. And I think keeping the "E" word may make your changes easier to "sell". But if we want to solve this, just "Save" as the phrase for project save will *not* cure the problem.

    People who do not understand a program that has projects expect "Save" to save an external file for use elsewhere (like a word processor does). Having "Save" as the "project save" phrase means we'll have to work far harder at other ancillary explanations to try and make it work . I think we've made the problem worse by having "Export" instead of "Export as WAV" etc. Either the Save and Export phrases in the menus must use more words to make it clearer that export is for an audio file, or the "E" word has to go, if we're serious about solving this. As another alternative, consider open and save applying to audio files only. "Projects" in the File menu is for opening and saving projects.


Edit Simplification

  • Replace Split/Split-Cut/Split-New/Split-Delete/Paste/Paste-Text-Labels/Copy/Trim/Silence-Audio/Detach-At-Silences/Duplicate/Join/Delete, by Copy/Cut/Paste/Trim/Delete/Duplicate/Join

Haven't really worked out exactly how to reduce the menu, but there seem to be way too many options here. For now this is just a placeholder for noting that some simplification is being thought about.

Signposting

Gale: Give the users visual clues that are in their face. Look at GIMP. Every menu item has a hover tooltip which is duplicated in the Status Bar. It would have to have a Preference to turn it off (as it does in GIMP).

Not sure if this should be here or as an alternative solution to Save vs Export on Top Usability Issues. I think it belongs here. It is a possible way of avoiding the need to use a longer menu wording than needed, and the text is driven by the menus.