Difference between revisions of "Completed Proposal File Menu Reorganization"
(fix run on sentence)
(all caps the formats)
|Line 95:||Line 95:|
== Side Issues ==
== Side Issues ==
At this stage we are NOT proposing a mode where Audacity can switch over to using a
At this stage we are NOT proposing a mode where Audacity can switch over to using a file as if it were its project ''(for which there is a Pending Feature Request)'' - much as Microsoft Word can open a 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.
Revision as of 07:31, 8 November 2013
|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.
- "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.
- 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).
- Many examples of user confusion in forum postings.
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.
This schema is supported by Peter, Steve, Ed and Gale (with proviso noted about the export word).
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.
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.