Completed Proposal File Menu Reorganization

From Audacity Wiki
Revision as of 00:51, 8 November 2013 by Edgar (talk | contribs) (clarification of non-native file types)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This page is a proposal to reorganize the File menu to provide distinct clarity between Audacity Projects and audio files, separating them in the menu. It originally formed part of the extensive Proposal Menu Reorganisation but moved here to provide focus on the File Menu.
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.

The Problem

Users, new users in particular, are confused about what 'export' and 'save' mean - a distinction made less clear as users can currently "open" an audio file with Audacity leading them to think that Audacity is a direct editor of WAV, MP3 or other files. Admittedly this problem (normally) diminishes as the user learns Audacity - but many postings on the forum indicate that this remains a problem for folk starting out with Audacity

This proposal argues that we need to make clear the distinction between native and non-native formats, using "Open" / "Save" only for native format (Audacity Projects) and "Import" / "Export" for non-native formats (currently: audio, MIDI, labels and raw data files).

Aside: and as Vaughan quoted in an unrelated email thread: "As the saying goes, "Confusion on our enemies" -- not on us!" "

Additionally, many users fail to recognize/discover that "Chains" is Audacity nomenclature for Batch processing.

Proposed Feature

We should take the split between "projects" and "audio" to its logical conclusion and completely separate them in the menu structure. Better use of fly-out submenus.

  • 'Open' will be renamed 'Open Project' and ONLY open an Audacity project. If you try to open a wav file it will tell you about projects and tell you to import instead. This will help reduce the risk of users thinking they are genuinely opening and working on a wav file directly.
    • Gale: 07 Nov13: Wouldn't the "Files of type" filter only offer AUP? Otherwise "Open Project... makes no sense
  • The "Export..." command to be extended to be "Export Audio..." or "Export Audio File..." for clarity of purpose.
    • "Export Multiple..." could become "Export Multiple Audio..." or "Export Multiple Audio Files..." to maintain that clarity
  • Commands that operate on Projects to be clearly separated in the menu from commands that work on audio files.
  • "Import Special" groups MIDI, Raw Data and Labels, but also includes "Audio in New Project..." . This avoids a regression where user who wants to import into a new project would have to first File > New, making one step into two steps.
  • Recent Files split into "Recent Project" and "Recent Audio". If you import an audio file it will be added to the "Recent Audio" list. Recent Audio has a cascade into "Import" and "Import in New Project", both of which access the same list. This fixes the problem that a new project is forced on user when choosing a recent file, but allows those who want a new project to do so in one step.
  • Drag-and-drop opening of a .wav file will import the dragged audio into your current project as now.
  • "Apply Chain..." moved below "Edit Chains..." and renamed to "Run Chain...". "Run" would make the feature more understandable to complete novices. The "Apply Chain" dialog would be renamed to "Run Chain" and the buttons would be "Run on Current Project" and "Run on Files". Gale could live with just the "move down" if the rename is objected to. See also a more radical redesign of Chains below.
  • Access keys for the menu have not been finalised but they can be so once the exact menu name and location has been agreed.

Developer/QA Backing

  • Peter
  • Gale (though I and Koz would be happier to have "Save" replace "Export" because "Export" is the fundamental problem word for novice users. The OS still explicitly saves the file, it does not export it because it would not know what to do. Most users who just record or drag in an MP3 will be oblivious of import, so won't see the import/export connection).

Use Cases

  • Many examples of user confusion in forum postings.


Details

Gale's File Menu proposal

This assumes we do not allow an "Open" menu to open audio files. If we do this we should probably stop "Recent Audio", opening audio files in the file manager and dragging audio files to the Audacity icon opening new project windows.

  • Gale 07Nov13: On the other hand, the file manager command is "Open with". Stopping "Recent Audio" importing into a new project creates a regression. Perhaps the key problem (which the Recent Audio menu in this Proposal addresses) is choice. Currently, the user cannot choose whether the drag in or file manager operation imports into the current or into a new project. These non-menu methods could be a new preference, or project destination is determined by left- or right-drag, but "Open with" always imports into a new project.

    IMO it will ultimately be too restrictive to force all import methods to import into the current project. If the user wanted the song in a new project using Open with, they would have to Edit > Cut, File > New then Edit > Paste. Given that, we should IMO allow Import and Recent Audio the option to open a new project window and import into that.

The key thing for me is that the item that does "export" has "audio" or "audio files" in the title.

  • Gale 07 Nov13: That "audio" is included in the command string, yes. But that could and should be done even if there is not otherwise agreement about this proposal.

This scheme lets us have a root menu item for straight export and import.

  • New Project
  • Open Project...
  • Recent Projects >
  • Check Dependencies...
  • Save Project
  • Save Project As...
  • Save Compressed Copy of Project...
  • Close Project

  • Edit Metadata...

  • Import Audio...
  • Import Special > | Audio in New Project... | MIDI... | Raw Data... | Labels...
  • Recent Audio > | Import | Import in New Project
  • Export Audio...
  • Export Selection...
  • Export Multiple...
  • Export Special > | MIDI... | Labels...

  • Edit Chains...
  • Run Chain...

  • Page Setup...
  • Print...

  • Exit

This schema is supported by Peter, Steve, Ed and Gale (with proviso noted about the export word).

Chains

Although not part of this proposal, in the original proposal it was also suggested that the two existing chains commands be consolidated in a single menu item called "Batch Chains" with a fly-out menu containing 'Edit|Run' or 'Edit Chain|Run Chain', as many users did not realize that "Chains" is Audacity nomenclature for Batch Processing.

  • Gale 07Nov13: I support one interface to edit and save or run the Chain, or as a minimum, a way to edit the Chain from the Run dialogue. But the Manual makes the distinction that "Chain" is appropriate terminology for applying to the project, and "Batch" appropriate for applying to files. So calling it only "Batch" seems dubious.

Check Dependencies

It was previously suggested that 'Check Dependencies...' should move to the proposed Tools menu, as it is a diagnostic tool. However although it isn't directly a "file" operation, it is intimately associated with saving projects. Moving it out to the Tools menu would potentially discourage its usage.

GUI Examples

Implicit in Gale's proposed menu structure above.


Previous Feature Requests relating to this proposal

There don't appear to be any.


Side Issues

At this stage we are NOT proposing a mode where Audacity can switch over to using a wav file as if it were its project (for which there is a Pending Feature Request) - much as Microsoft Word can open a txt file, but then warns when you try to save it that 'some features/formatting can't be saved in text format'. It's not that hard to add, but it would go outside the scope of this proposal. This could be a good feature though and solve a lot of user confusion. If we were to do it, we'd list in the warning dialog what would be lost.