Completed Proposal File Menu Reorganization
|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.
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.
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 dialog that follows is renamed to "Export Audio" or "Export Audio File".
- The dialog that follows is renamed to "Export Selected Audio" or "Export Audio Selection".
- Peter 26Jul14: both the above two changes have been implemented, we have "Export Audio" and "Export Selected Audio.
- 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".
- 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 dialogs 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.
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 dialog. 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.
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.
Implicit in Gale's proposed menu structure above.
Previous Feature Requests relating to this proposal
There don't appear to be any.
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.