View source for Talk:Completed Proposal File Menu Reorganization

== Summary ==
'''Peter 7Nov13:''' Much of the material on this page is now fairly old and has been raked over many times, it is included on this page for completeness and historical perspective (if required).

I would suggest that attention is focused on the 2013 discussions as they are the latest distillations of all the thinking and discussion that has gone into this proposal


== The "E-word" (Export versus Save) 8Nov13 ==
'''Peter 8Nov13:''' Much discussion has been expended over the years on whether or not we should drop the "E-word" i.e. the "Export" command.  There are basically two camps on this - one group would prefer to retain the "Export" others would prefer to discard it in favor of using "Save" for both Projects and audio files etc.  There are a number of reasons why I believe that it would be better to retain "Export":

===Regression===
Removing "Export" could be viewed as a serious regression. this is the primary reason - we have had "Export" in Audacity for all time.

"Export" for non-native format files has been a part of Audacity from its earliest days (and I'm assuming that Dominic under Roger's guidance designed or crafted it that way.  The earliest Audacity that I can get from SF is 0.8 and that has File>Export as does that last v0, v0.98b which from the File menu has "Export as Wav..." and "Export as MP3...", along with a "Save Project.  

Version 1.0.0 retained that and added Export as OGG..." and this continued all through the 1.x series up to and including the final 1.2.6.

Version 2.0.0 made things somewhat more confusing for the users as, somewhere in the long 1.3-Beta development cycle, we introduced a pared-back  plain "Export" command in the File Menu that shows no indication of the format of the target file format and thus no properly discoverable command for making an audio file from a project.  It's only really when you invoke the command and then see the dialog is titled "Export File" do you maybe realize that this is the way of making an audio file.

===Avoidance of confusion===
Gale wrote on the main page of this proposal ''"I and Koz would be happier to have "Save" replace "Export" because "Export" is the fundamental problem word for novice users"''

I admit there is some attraction here to using a command with the same name to both store a project and to create an audio file - but doing so you potentially increase the chance for confusion, by having similar commands that do fundamentally different things.

The command strings would read something like "Save Audio File", "Save Selection as an Audio File" and "Save Multiple Audio Files", I'm guessing. 

===My current thinking===
Given that Gale's proposed menu structure neatly separates the set of commands that operate on Projects from the set of commands that operate on non-native files, I could probably live with these - but it is the regression involved in removing "export" that is currently swaying my thinking on this.  

The "Save" versus "Export" has the elements of a "religious war" - and I do not want to be over-zealous in this - so in the interests of promoting consensus I would prepared to accept the dual use of Save if that is the only way that we can move this proposal forward with consensus. But it will be with heavy heart as it goes hard against the grain to accept regression of a command of such long-standing; changing this now could easily upset a lot of long-term Audacity users.

=== The E-word (Gale 08Nov13) === 
I think few existing users would be confused by renaming export as save. It may cause some temporary thought amongst those who understand the word, but those are not the users that cause concern. 

I believe OS'es open and save files. Using import and export words for those actions causes its own confusions, especially at the point of saving the exported file to disk. 

The code and even the app have many references to open when it means import and save when it means export. See for example the log after "importing" a file and Extended "Import" Preferences.

*'''Peter 9Nov:''' Yes I agree that the OS in its terminology is "saving" a file - but the user is operating in the milieu of Audacity here and not the OS - so what is happening is that Audacity is "exporting" a non-native file format - and in the process of so doing rendering it into that format - then passing it over to the OS, invisible to the user at this juncture, for the OS to store the file away.
**And yes I know that currently there are inconsistencies in the usage of open/import and save/export in the app (and in the manual) - but that is no reason not to strive to remove at least those that are visible to the user (in the app's GUI, the Manual and Wiki).  That is in part what the thrust of this proposal is about, consistency and clarity for the user.
* '''Gale 09Nov13:''' The Export or Save button (the act that causes the OS to save the exported file) is very visible to the user. If the button on straight export said "Export", you would get support requests "There is no way to save. HELP!!!!". I believe this doesn't happen for Export Multiple (nor do users ask how to change the MP3 bit rate) because Export Multiple users are a bit more sophisticated (or if not, have probably been forced to read the Manual to see how to save the tracks from their USB gizmo).

== Notes from recent (Oct/Nov 2013) [http://forum.audacityteam.org/viewtopic.php?f=40&t=75376 forum thread] ==
'''Peter 8Oct13:''' We don't actually edit WAV/MP3/any audio format, rather we edit Projects. Even if you use the Open command on an audio file what happen is the Audacity opens and then Imports the audio for editing and subsequent Export. As we know from many past discussions this loose usage of terminology like this causes confusion among our uses many of whom think Audacity is a "WAV editor" or an "MP3 editor". For my money only native format i.e. Audacity Projects should be openable and saveable - non native formats should only be importable and exportable for clarity of purpose.

'''Peter 28Oct13:''' I really believe that there is a truly fundamental difference between native format (Projects in Audacity's case) and non-native formats (i.e. audio files) and we need to respect and observe this distinction and make it as clear as possible for our users. Only Projects should be capable of being Opened and Saved and audio files should only be capable of being imported or exported. Simple, straightforward, accurate - "does what it says on the tin"

We do not and cannot work directly on any audio file (WAV, MP3, whatever) so for my money this means that users should not be able to "Open" such non-native format files. When all's said and done Audacity is *not* opening an audio file for editing. Rather when the user invokes the current "Open WAV" command what Audacity is doing is a) Opening a new Audacity project and b) then Importing the audio file. I do not like this at all (in fact I hate it) because it hides the import from the user and leads them falsely into thinking that we are operating directly on an audio file: Open <audio file>, edit <audio file>, Save <audio File> - it ain't like that, it really isn't.


'''Peter 31Oct13:''' I note from the existing proposal that it states clearly on the main page:  ''" 'Open' will be renamed 'Open Project' and ONLY open an Audacity project."''.

and on the Talk page Gale wrote on 26Apr2011: ''"Yes but we are all agreed I think to restrict File > Open to projects. "''

So we do seem to have consensus, and mostly always have had, on the basic underlying precept here.


'''Steve 3Nov13:''' I'm sure there will be some complaints ''[from some]'' users because it is a change, but the weight of argument (from everyone) for why this is the right thing to do is overwhelming.


== Comments re Gale's alternative File Menu proposal - Oct/Nov2013 ==
* '''Gale 31Oct13:''' I've added Check Dependencies and Edit Metadata. I'm not sure Edit Metadata belongs in the File Menu. I think it could be in Edit or View Menu, and if forced to a decision I would put it in Edit Menu. And when metadata becomes per track (feature request), it should go in Tracks Menu. <p>"Delete Project" is more than a menu reorganization so it lies outside my proposal. "Save Project As" is so misunderstood (and not used for what it should be - backups and renames) that I would think of having some kind of Project Manager interface where you could delete or rename projects, backup every <n> minutes to a new project name etc.  </p>
**'''Peter 1Nov13:''' Fair point about "Delete Project" being out of scope, I will not make that part of the proposed focussed proposal on File menu reorganization.  ''But on a related note. not for here and now though, do we need to think about a "Rename Project" facility - "Save As ..." is all well and good to make a rename but it still leaves the user with the original project to deal with (delete).''
**'''Gale 01Nov13:''' I think Backups, Renames (removing the original project) and project Deletions are all issues. In most programs Save As... can do a format change as well as make a copy with another name. If we could have "Save Project..." active on opening a new empty project, and with Rename and Backup options, I could see just getting rid of "Save Project As..." Having "Save Project" greyed on opening a new empty project reinforces the idea that you've opened the file (just as "Save" is greyed on opening the file in programs that do that). But with the paradigm you're pushing, I think you actually have an unsaved project when opening a new empty window, so Save Project should be active. But this is not for now.  
* '''Steve:''' 
*#The choice of "New Project" or "New Temporary Project" is not relevant to this discussion - it belongs to [http://wiki.audacityteam.org/wiki/Proposal_Project_Folder another proposal]. Similarly "Close and Delete" relates to the same feature.<br>
*#Personally I'd still prefer to keep "Check Dependencies" in the File menu, but I guess I can get used to it being right over on the other end of the menu bar.
*#I like "Import Special >" and "Export Special >" (
*#On reflection, +1 for "Recent Audio" being separate from "Recent Projects", though I'm not sure about the placement. Isn't it more usual for the order to be: New, Recent, Open, Save, Close? In which case it may be more obvious to have "Recent Audio" at the top of the "Import/Export" section.
* '''Gale:''' The rationale was that "Recent" was in both groups was the last item in that group that brought material in. Suggesting that we cleanly separate "Projects" from "Audio" already breaks New, Recent, Open, Save, Close. If we want to keep that more orthodox idea, as in James's plan, we must group projects and audio together (twice).


==Historical Discussions==

===Comments by Bill 28-April-2011===
<b>File Menu</b><br>
* I support "Open" becoming "Open Project" and opening only Audacity projects. Some users may complain of the 'regression' that they can no longer create a new project and import audio in one step, but the advantage in clarity (separating projects from imported audio files) outweighs this IMO.
**'''Peter 1May11:''' +1 for this - I too like the clarity to the UI that this would bring
** '''Gale:''' The regression can be handled by having an import menu item that opens in a new window. I believe not being able to use "Open" to import files will be a wrench/seem odd to novice users, though given the increased clarity I would support it if the regression is covered.  I think the clarity will be diminished a) unless non-dialogue import methods import into the same project window b) if the File Menu structure has imports grouped with opening projects and exports grouped with saving projects.    
* I don't see any real advantage to the fly-out for "Save Project As", but do not object to it.
* Suggestion: "Recent files" becomes "Recent Projects", then in the "Import" fly-out, "Recent Imports".
** '''Gale:''' +1. My idea includes that, though I call it "Recent Audio". 
** '''Ed''' +1 (either terminology is fine by me)
**'''Peter 1May11:''' +1 and as with Ed, I'd be happy with either terminology
**'''Bruno 4Oct11:''' +1. If a user imports dozens of audio files into a project, then the Recent Files menu will only show the imported audio files and not the project file. Therefore I think there should be two separate submenus: one for Recent Projects and another one for Recent Audio/Imports.

* No objection to "Check Dependencies" moving to "Tools"
** '''Gale:''' I'm firming up my vote for View Menu. Not only is it closer to the File menu where it used to be, we could lose the word "Check" from the menu item. It's just View > Dependencies... 
**'''Ed''' +1 > View & del "Check"
**'''Peter 1May11:''' +1
* I'd prefer "Open Metadata Editor" remain in the top level of the menu, just above the "Export" fly-out.
**'''Ed''' as with Dependencies, move it to View --same reasoning as Gale's
* Would "Export All Audio" be better named "Export Mix"?


===Feedback from Vaughan 27-April-2011===
* '''Vaughan:''' -1 overall, mainly because of the 10% non-rearrangement changes.  Likely impact on 2.0 schedule.
**'''Peter 7Nov13: the move from 1.3.x-beta to 2.0.0 release is long behind us now. 
* '''Vaughan:''' "Compressed Project" needs to stay "Save as Compressed *Copy* of Project" as it's not affecting the currently open project -- not even clear how it would. "Save as" is basically Save plus Rename in situ, so I think Compressed Copy needs to be distinguished from that -- it's not in situ.
**'''Peter 7Nov13: this is as it is in Gale's proposed menu structure 
* '''Vaughan:''' +1 to "'Check Dependencies...' moves to the Tools menu."



===Resolutions to Gale's objections on 26-April-2011===
* '''Gale:''' I think making clear the distinction between projects and audio files is important, but being able to "open" an audio file in a new window in one step is popular too. Having to use File > New then Project > Import > Audio is a regression. Importing audio into a new project should have an import menu item of its own.
** '''Gale:''' Currently James has "New Project from..." which covers the regression and "Add" instead of "Import". "Add" would I think reduce the problem with "Open" being tried due to misunderstanding "Import". 
**'''Bill 01May11:''' Currently "Open" supports audio files and project files, so I'm not convinced of the need for a fly-out that includes Labels, MIDI and Raw Data. 
*** '''Gale:''' Yes but we are all agreed I think to restrict File > Open to projects. And people do want to open RAW and MIDI in new windows.   
* '''Gale:''' IMO it is completely unacceptable to have Recent Files regress to only support .aup as in 1.2. Steve agreed and James now allows Recent Files to import audio. Steve and I think Recent Audio should be distinguished from Recent Projects. I think Recent Audio should be "added" not "opened". Maybe "Add Recent Audio" is viable as a separate root item. Maybe "New Project From > Recent Audio" is viable, maybe not.
* '''Gale:''' Grouping Export and Export Selection may not be popular, even with shortcuts. If an item is in the root of the menu it can often manage without a shortcut. If it is in a submenu there will be much more demand for shortcuts. Remember how complaints of extra navigation killed off Effect Categories, and the complaints we have about loss of "Export MP3", "Export WAV" etc. Grouping the others export items is more reasonable, except for Export > Metadata Editor. Steve agrees. James now has View > Metadata Editor. 
** '''James:''' Dependencies make more sense in a tools menu.
*** '''Steve:''' I agree with James' logic, but I think "Check Dependencies" is too important for safe Project management to move away from File menu. The time that you need this tool is when saving projects. 
**** '''Gale:''' If we move this item I would suggest View Menu as having greater "visibility" and intuitiveness than "Tools". Ed +1.
* '''Gale:''' These proposals do nothing for the core issue which is having the "export" word in the first place. 
** '''James:''' What's really needed is something deeper than a menu reorganization.  We should aim to be more word-like, where you open any file in any format, and it is only when you come to save that you get a warning 'You will lose your labels, clip boundaries, envelopes..." - if you save as wav.  In discussing solutions that maintain an open/import and save/export distinction, whatever the actual naming, through having four (or more) menu items we are at best discussing a half way house.
*** '''Gale:''' Possibly wording as "Save Audio File" would require a warning analogous to "Save Project", but it's a much lesser issue than people saving the .aup file and not being able to "play" it in Windows Media Player. Think this is "nice" rather than "really needed". Has potential to confuse novices, leaving them unsure how to save at all. Don't think .aup yet has the currency of .doc that would support doing this intuitively.
**** '''Gale:''' James currently suggests "Save Copy Of" as a possible replacement for "Export". I don't think "Copy" is a good choice for lossy formats. Also it suggests envelopes etc. will be retained (yes I know, that's why we have "export"). So for that reason I still like "Save Audio" and "Save Selected Audio" as root then all else grouped. Save "Audio by Track" seems confusing if you want to export a selected track. "Audio Mixed Down" is confusing if you only have one track. I could yet be persuaded by a single "Save <something>" root item for exporting, but I think just "Save" would be better than "Save Copy of".  
**** '''Bill 01May11:''' I ''like'' the Open/Import, Save/Export distinction, since to my mind that accurately describes what is being done. However it seems like most want to get away from Import and Export, and if that is the case I won't block consensus. In another discussion James made the point that a closer analogy is image editors such as the GIMP, where if you save as JPEG you are warned that you will lose your layers, text will be rendered, etc.<br>I, too, am not convinced that "Save Copy of" works, but I think a simple "Save" would be worse, inviting more confusion than it might remove.
**** '''Gale:''' My take is different. A novice will jump at "Save" because it is exactly what they are looking for. Power users can figure what is going on. But we make the wording choice harder by putting every conceivable format in the same cascade. "Save Other Format" is all I can come up with ATM for "Save Copy Of".      
* Gale, James and Steve agreed on Splitting "Help" and "Tools".<br>
**'''Ed''' +1 There may be other non-Help items which could populate Tools
*** '''Gale:''' Nyquist Workbench (although you currently have to compile it) should IMO be in Tools, not in View Menu. 
***'''Steve:''' +1 for Nyquist Workbench in Tools menu rather than View menu.
* Everyone ended up agreeing that images or bulleted Wiki text were needed.  
* '''Gale:''' Removing drag n drop of audio files would be suicidally stupid IMO. By which I mean (more diplomatically) that we would have a P1/P2 if a bug ever stopped us dragging in audio files. James agreed to keep audio drag n drop. Bill and Gale point out there are also drags onto the Audacity icon and opening from file managers. These actions currently open new projects. Gale thinks they should "add" to the current project. This maintains the distinction that only projects "open". If people want file manager openings to open new projects, I suggest a new Preference pane where you can also set audio file associations with Audacity.


===James' comments 01May11 re. Import and Export===
* '''James 01May11:''' To clarify, in 'import' we have at least two concepts.
** You are opening something that is NOT a .aup file.  Import for wav, mp3, MIDI, raw audio, Labels.  'Open Project' for a .aup.
** You are adding something into an existing project (possibly it's an empty project, but you can see that).  Import is to include or add, whereas with 'Open' you definitely expect a new project all on its own.



===Earlier Discussions 2010===
* '''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).

* '''James''' I'm noticing that the list Save-Project|Save-Project-As|Save-Compressed-Project-As|Export|Export-Selection|Export-Multiple is rather long, and as an experienced user am not keen on that.  I also think it contributes to the Save-Export confusion since it moves export away from Save Project.  I propose replacing them by Save-Project|Save-As|Export.  As a power user I only actually need Save-Project and Save-As, with the Save-As expanded to allow more options as to how and what I save.  However I'd retain Export to help less experienced users.  Export guides you through setting the right options.  It doesn't rely on you calling up the options but opens the options dialogs right away.  You then have to choose what format you are writing to, mp3 and wav are given prominence, rather than the format being inferred from the filename extension.  Your choice sets the default extension.  You have to choose whether you are exporting the whole project or just a selection.  You have to choose whether you're writing just one file or one file for each label.
**'''BillW 22Jan10:''' James, are you proposing just one "Export ..." menu item that leads to a dialog where you choose whether to export the entire project, selection, or multiple? I think I'd be more comfortable with "Export >" leading to a fly-out menu with "Entire Project / Selection / Multiple". From a purely selfish standpoint, I use Export Multiple all the time and it is convenient to be able to get to it directly.
**'''James 22Jan10:''' I was, but on mature reflection I prefer the fly-out.  We can come back and edit the proposal down (and the comments) later.
** Peter/BillW/Gale preferred 'Export' over a proposed naming the item 'Save-Special'.
** Gale pointed to a deeper issue, which I see as this: In Word you can treat a .txt file as your document and Word is smart enough to tell you 'you have changes that cannot be saved in .txt format'.  To fully fix the issue we would need to allow users to use .wav or even .mp3 files 'as their projects' and if they have labels or clips warn them that 'If you save this in wav file format you will lose some features that can only be saved in Audacity project format'.  This is not part of the current proposal, and possibly merits a proposal for "projects in native format".  
***'''BillW 22Jan10:''' I'm not sure that the analogy is appropriate. In Word you would be changing from a .txt document to a .doc document, but in Audacity you would be changing from a .wav document to a .aup document (which does not hold audio) and its _data folder. This may cause more problems than it solves. This sounds like "Audacity lite" that supports one stereo track only, no labels, no clips etc. - everything that makes Audacity powerful and flexible.
***'''James:''' I wouldn't use the feature myself either.  The Word analogy is valuable because it helps make clearer what it is that we are not doing that is word-like.  I prefer 'Save' to 'Save Project', but I understand the point of view that argues it must be 'Save Project' unless we can treat a .wav as if it were a project.  Note that GIMP has a similar issue to address when saving .xcf to .png format.  Layers have to be flattened, which is just like mixing down.
*** '''Gale:''' I agree with Bill. I wasn't really suggesting a feature for "projects in native formats". I was merely pointing out that if the user has no experience of a program that works with projects (let's face it, not even all video and audio editors use projects), they will expect a menu item starting with "Save" (especially one called exactly "Save") to *produce a file suitable for reading in other apps*. This is what we have to grasp, I think. <p>The only time I can think "native formats" concerns (novice) users is where they expect a single exported file will contain the track breaks they have carefully labelled up (or less commonly, they think it should contain "cue" or "loop" markers, which is a Feature Request). I tend to think this is more a matter of education via the Manual and possibly a FAQ. </p><p>James, your "Save As" does "Export" and "Save Project As" does it? I'm not sure about this, if so - isn't it a mixture of terms with an Export item as well? I'm not hugely in favour of "Export", I only preferred it to "Save Special" because I think that is even less clear. If we keep the "E" word I really think it needs more than that one word. Novices won't know what it means. I suspect they will be most likely to go for "Save Project" or "Save As" (which I assume to be the most complex routing of all). I kind of like the idea of the "Export" item (if not called that) as a "quick export" where you need to do nothing except click the menu item because all the choices are preset. If it doesn't do then I'm not sure if the distinction between that and "Save As" is clear enough.</p><p>On another issue there is a I think a good case backed by user votes that export (at least export with minimal choices) goes to the directory from which the original .aup or audio file was loaded (like Save Project does), rather than last used. As another factor to toss in, some users want the project save and export directory to be fixed by a preference.  </p>

* '''Steve:''' '''"Open" should open Audacity Projects only ("Import" opens audio files).''' Users look for "Open" to open audio files because this is more understandable than "Import", but then can't find "Save" to save an audio file. If only projects were available in "Open", it "might" educate them to find "Import". This has some votes on [[Feature Requests]]. 
** '''Gale:''' One disadvantage is that there is then an extra step to open files in a new project, which is one point of "Open".
**''' Steve:''' but it's not actually "Opening" the audio file - it's "Importing" the audio file into a new project. So if it is important to retain this short-cut, wouldn't it be more logical and consistent to have an option in the Import menu to "Import audio into New Project"?
**'''Gale:''' I largely agree that using "open" to "import" into a new project (except when the existing one is empty) yet you can also "import" into an empty existing project is confusing. I think "import" is just as misunderstood as "export" (the confusion just does not have such bad results). So I'd say it's asking for trouble to have File > Open only open projects. Personally I would rather have "Project" as a submenu of File (or better, a separate menu), the let File > Open  open audio files only, and Project > Open open projects only.  "Import" or "Open Special"  could be kept for labels, midi and raw. <p>Moving projects out of the File menu would shorten it and help user confusion. I think there is a reasonable consensus that longer term a "project management" utility would be desirable, so a "Project" menu could fit in with that.I think it's important a one-step way to "import" files in a new project window is retained.  One way to do it could be a checkbox in the open file dialogue.
** '''Peter 11Apr11:''' I strongly support Steve's Open/Import propsosal.  I am a great believer in the simplicity and clarity of one command for one function, it leads to a purer UI; I therefore believe that the behaviour of the Open command should be changed so that all it can ever do is open an Audacity project. It should not be possible to "open" a WAV/AIFF file which in current Audacity behaviour is actually an Open Audacity project coupled with an implied and hidden "import compressed audio" command.  This leads users wrongly to believe that, in opening a WAV file or an MP3 file say, they are operating directly on that file.   We could still give the users the ability to attempt to Open an audio file, but then warn them that this cannot be done directly but offer them a chance in the dialog to let Audacity open a project and import the audio file. This should make the Audacity mechanisms clearer to the user.   '''Dragging audio files in:''' this should invoke an Import (for uncompressed audio - faster or safer, depending on the users Preferences settings). It should not be a mechanism to open an Audacity project by dragging in an aup file.  On the "Proposal User Safe Alias Files" page, Bill recently supported and extended this idea:  '''''Bill 07Dec10: +1 Rename to "File > Open Project..."'''. Users can curretly use this to "open" a WAV file, leading to the conclusion that Audacity is a WAV editor. When they then "Save", what they see doesn't make sense given that assumption.'' 

</p> 

'''Edgar:'''
*The two "Chain" menu items seem to me to be better placed in the Edit menu.
**'''BillW 22Jan10:''' A typical chain imports a file, applies effects to it then exports the modified file. So I think there's a case for the chain items being in File or Effect, but not Edit. I'm OK with them staying in File, but within their own divided section.
*The "Open Metadata Editor..." item might be more appropriately placed in the View menu.
**'''BillW 22Jan10:''' Metadata applies to exported files, and as such I think it is appropriate in the file menu, right above "Export".
**'''-- Ed 24 January 2010''' if Metadata only applies to exported files, in the interest of shortening the menu, make it a sub item of Export.
----

{{advice|Some users don't realise that export is needed to save audio in non .aup formats.}}
*'''BillW 20Jan10:''' I think this is user error and RTFM. In Warnings Preferences by default this preference is checked: "Saving projects: Every time you save a project, Audacity will warn you that you are saving an Audacity project file that only Audacity can open. Once you understand this, you can turn off this warning from within the warning dialog." If users choose to click through that warning without reading or understanding it, what more can we do?
**I am '''not''' (at this time) in favour of a "Save Special" to replace the export menu items. I think this would just further confuse the issue. Export is technically correct - files are being created for use outside of Audacity. Other multi-track software might call this "Bounce to Disk" or "Mix to Disk". "Save" is reserved for saving the multi-track project.
* '''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.<br>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.
* '''[[User:James|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.<p> 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.   </p>  


''' Gale, 13Jan10:''' 
* If you use Save-As, you say the audio type is defaulted from the name. How does that work for first time user who made a recording?   
* My first reaction is there may be insufficient distinction between the "Save" items. The differentiation between save and export is quite good, except that "export" isn't understood. If you can get consensus to drop the "E" word, I'd tend to think of Save as the lowest class of export, and Save As as something with more customisation. "Save Special" though it's not the right phrase, is the project save.
* The lowest class of export could also be considered as a route that allows no customisation once you enter it and a customisation has been set (first time or in preferences) - click the menu and the next you see is the progress dialogue. This accords with quite a few explicit and implied user suggestions. File name is date/time if no other rule such as an imported file to deduce it from. 
* Generally, until I see it, I'm a bit wary of an "extended custom save dialogue". Does the "save project" choice lead into it for people who actually intended to export?

'''Peter 13Jan10:'''
* Losing the E-word may be a good idea - the difference between Save and Export does seem to cause some confusion amongst some posters on the forum - so I would probably vote +0.5 for '''Save''' being Save Project (in Audacity format) and '''Save As''' invoking a dialog box (the currect Export dialog box).
* I do note however that Audacity is not the only software product that uses Save for creating/updating data in the native format of the product*  - and Export for creating/updating non-native exports.
* Note that this will also require changes in the Wiki and the Manual - and will probably impact some of the external tutorials that we link to from the Wiki.
** '''Gale:''' Clearly the basic users that we are trying to help see "Save" as the process of producing the exported file. Thus my feeling is that if the menu items are "Save", "Save As" and "Save Special" then "Save" should be the export. Instead of using the "E" word, we could also make the distinction with "Save as Project" and "Save as audio file" or similar. If we want the "E" word, "Save as audio file" could be "Export audio file" instead. Those could be the only two relevant root items in the File Menu (or you might perhaps have "Save multiple audio files" as well depending on the structure of the dialogues that follow). All other relevant menu items cascade from there. <p>Generally, the philosophical case for the "E" word is weakened by then having the button that does the job called "Save", but if it was called "Export" I think some users would just stop there like they used to stop on the Metadata Window when it came before export. This makes me think we should drop the "E" word.</p>

'''Peter 14Jan10:'''
* Introducing a '''Save As''' to replace the E-word may end up confusing may of our Windows users, of whom there are many.  I note that in Microsoft products, '''Save''' is used to save under the existing project name ''(or create a new project if none has yet been created)'' - and they use '''Save As''' to save the current version of the file under a new filename.
*I also assume we would need a '''Save Multiple''' command, or similar for multiple exports.