Proposal File Menu Reorganization

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).

Another potential cause of confusion is that there are many different open/import gestures (choose a menu item, drag-and-drop on the Audacity program icon, drag-and-drop into an open Project window, supply a file name on the command line etc.) with which a user may get data into Audacity. Some of these gestures operate only on Audacity Projects, others only operate on specific types of non-native data, others will operate with Audacity Projects and some non-native audio files. This blurs the distinction between open and import.

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 with 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.
 * The dialogue that follows is renamed to "Export Audio" or "Export Audio File".
 * The "Export Selection..." command to be extended to be "Export Selected Audio..." or "Export Audio Selection..." for clarity of purpose.
 * The dialogue that follows is renamed to "Export Selected Audio" or "Export Audio Selection".
 * Commands that operate on Projects to be clearly separated in the menu from commands that work on audio files.
 * We have a root menu item for straight import, as well as straight export.
 * "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).
 * Peter 8Nov13: Removing "Export" in favor of "Save" would be a regression. Please see my detailed comments on the talk page regarding "Save" versus "Export".

Use Cases

 * Many examples of user confusion in forum postings.

Gale's File Menu proposal
This schema is supported by Peter, Steve and Gale (with proviso noted about the export word).


 *  Peter 07Nov13: One of key things for me is that the item that does "export" has "audio" or "audio files" in the title. 
 *  Gale 07Nov13: That "audio" is included in the command string, yes. But that could and should be done (and the dialogues that follow those commands renamed to suit) even if there is not otherwise agreement about this proposal. 

"Export Multiple..." could become "Export Multiple Audio..." or "Export Multiple Audio Files..." to further clarify, though this proposal does not do that because of the length of the resulting menu and because the user confusion is almost entirely with straight export.



Should choice of import into new project or same project be allowed, whatever the import method?

 *  Gale 12Nov13: My original comment two years ago was that given this proposal does not allow an "Open" menu to open audio files, it would be consistent to also prevent the current behaviour where "Recent Audio", opening audio files in the file manager and dragging audio files to the Audacity icon open new project windows. The suggestion was that instead, those OS methods could always import into an existing project. 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 to have the drag in or file manager operation import into a current window. This could be a new Import / Export Preferences checkbox "File manager Open methods import into new project", default checked, where the last active Audacity window is used if the checkbox is unchecked. Alternatively, project destination could be 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.   

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.