Talk:Completed Proposal Menu Reorganisation

From Audacity Wiki
Revision as of 21:48, 28 April 2011 by Edgar (talk | contribs)
Jump to: navigation, search
Hint: If the issues described here are now adequately reflected in the main page, it would be a good idea to delete that part of this talk. James 12:30, 25 April 2011 (UTC)

Comments by Bill 28-April-2011

File Menu

  • 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.
    • 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)
  • 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"
  • 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"?

Tracks Menu

  • Strong support for "Mix and Render to New Track" getting a place in the menus.
    • Gale: +1, but -1 to the cascade, and to all cascades with only two items in the submenu. The disbenefits outweigh the benefits with only two items.
  • OK with expanded "All Tracks Mute/Solo" fly-out

View Menu

  • OK with "Fit" and "Zoom" fly-outs

Feedback from Vaughan 27-April-2011

  • Vaughan: -1 overall, mainly because of the 10% non-rearrangement changes. Likely impact on 2.0 schedule.
  • Vaughan: Personally, the only menu I think is too long is Effect. I object more strongly to too many too-short menus. For example, moving tools out of Help menu leaves it with exactly 3 commands, afaict. Menu names are visible all the time, so I'm a proponent of fewer menus.
    • Gale: My feeling was there must be an item called "Help". If Tools are inside "Help" (perhaps in their own submenu) this should not force the two items for Manual to almost bottom. But I see a separate "Help" menu as a good move because it could contain new items (like the update check to a web page that I keep going on about).

      Also we don't need to go overboard with menu shortening/grouping if we are still going to have Simplified Menus. "Simplified" could possibly group as well as remove?

  • 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.
  • Vaughan: +1 to "'Check Dependencies...' moves to the Tools menu."

Objections from Gale 26-April-2011

Edit hint: As we approach agreement, we can edit this down to the remaining contested issues.

  • 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. This is fairly understood / standard behaviour for apps that support multiple windows. Having to use File > New then Project > Import > Audio is a regression.

    I think "Open project" should be in a "Projects" group, retaining Open for audio files only. Or importing audio into a new project should have an import menu item of its own (which is what File > Open an audio file really does). I do agree the meaning of "open" and "import" is confusing.

    • James: Disagree with your objection to forcing the extra step. When a user opens Audacity they are in a new project, so an import gives them a project with one audio file in it.
      • Steve: The "regression" occurs when a user wants to open another project with a file imported into it. IMO "Open > audio file" is an unacceptably confusing shortcut method, but an Import option, "Import to New Project", would offer an equivalent alternative without the added confusion.
        • Gale: Exactly. Improvements should not generate regressions unless there are considerable outweighing benefits. 2.0 is not a good time IMO to test if users (going to Open because they do not understand "Import") can live with being told you can't "open" audio files.
  • Gale: IMO it is a completely unacceptable regression to have recent files only support .aup. It is a major benefit of 1.3 over 1.2 that Recent Files includes audio files.
    • James: I don't feel that strongly that recent-files should become recent-projects, so I've changed the proposal.
      • Steve: I agree with retaining audio files in the "Recent Files" list, but it would probably be clearer if "Recent Files" was separated from the "Project" options by a divider.
  • Gale: Conflating Export and Export Selection may not be popular, even with shortcuts. Remember how complaints of extra navigation killed off Effect Categories, and the complaints we have about loss of "Export MP3", "Export WAV" etc. There is a tradeoff benefit there, but we are not so short of space in File menu that I think we must have only one Export item.
    • James: I am not conflating. I am putting them in the same submenu. You're conflating 'conflate' with 'grouping'.
      • Gale: Sorry for missing I'd used the wrong word!
  • Gale: Grouping the others export items is more reasonable, except for Export > Metadata Editor which seems a confusion of terms (it is not exporting a file). Unfortunately it can't really go in Tracks as metadata is not yet per track, so I suggest it should move further down File Menu as "Edit Metadata".
    • James: It is really a naming issue. It only applies to exports, so it belongs to exports - or as you suggest perhaps become per track - but that's for another day. The design of meta data editor needs more thought, but since it only applies to exports it belongs here.
      • Steve: Metadata also applies to Projects - arguably more than it does to Export as the metadata is currently per-project. I also think that it would be confusing to have it in the Export sub-menu since all other options export something.
      • Gale: The solution of putting Metadata Editor in the View Menu is quite OK with me. But why the change to "Meta Data Editor"? See .
  • Gale: Same comment about extra navigation where we don't really need to save space. Shortcuts will be needed for cascaded items. How many spare shortcuts do we have?
    • James: The problem of missing shortcuts exists already. If anything this improves it because it opens the way to logically grouped shortcut sequences.
      • Gale: My point is that 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 it to have a shortcut.
  • Gale: Dependencies are intimately related to Projects so do make some sense where they are. I think the real issue in File Menu is not everything to do with projects is together.
    • James: Sure dependencies make some sense where they are, but they 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 the other Project file menu items. The time that you need this tool is when saving projects, so it makes sense to have the tool to hand when you need it.
        • Gale: If we move this item I would suggest View Menu as having greater "visibility" and intuitiveness than "Tools".
  • Gale: These proposals do nothing for the core issue which is having the "export" word in the first place.
    • James: That issue needs something deeper than a menu reorganisation. We need to be able open a wav file and when it comes to saving tell the user 'You will lose your labels, clip boundaries, envelopes, marbles and your first born child - if you save as wav. Please switch to our wonderful project format instead, if you want to keep the smashing non-wav features you are using' (or something less wordy). So we agree this is only a half way house, not a full treatment for the root problem.
      • Gale: It seems to me that much of the justification for removing ability to "Open" audio is that if you are forced to "import" audio then logically you must "export" it, so it becomes more natural to look for "export". I think that argument is fallible on Windows. If the menu item said "Save Audio File" ("Save" being what the button in the Export File window says) then the argument would be weaker still.

        Possibly wording as "Save Audio File" would require a warning analogous to "Save Project", but I see it as a much lesser issue than people saving the .aup file and not being able to play the .aup in Windows Media Player.

  • Gale: +1 to all proposed edit menu changes.
  • Gale: IMO Help really must have its own menu. It's common to have Tools and Help separate. If Tools and Help combined, having the Manual towards the bottom won't increase uptake.
    • James: So I think you're vehemently agreeing with me on splitting tools and help. I've tried to make the proposal clearer - we are creating a new menu item for tools, and taking tools out of help.
      • Steve: +1 for taking tools out of the Help menu and putting them in the "Tools" menu, though it is not really a "new" tools menu - any users of the Nyquist Workbench will already have a "Tools" menu.
  • Gale: +1 for About at the bottom of the list.
  • Gale: I think a formal proposal should have proper mockup images.
    • James: I think it's already pretty clear from the text on the page, and an image is more work and less easily fixed... but if that is a key objection I may be able to address that shortly too.
    • Bill: A bullet list would work for me. We could see the entire proposed menu organization and it would be easy to edit.
  • Gale: Drag and drop should support .aup files. Ed has a patch for that which I like. Removing drag and drop of audio files (if that is what is proposed) would be suicidally stupid IMO.
    • James: OK, so I have changed the text/behaviour around that.
      • Bill: Yes, you can drag an audio file into an open project window and that behaves as the current File > Import > Audio, but on Mac (and Windows?) you can drag an audio file onto the Audacity icon, and it behaves as the current File > Open command. Would that be disabled? C.f. Manual Tutorial - Editing an Existing Recording
      • Gale: Yes on Windows too you can drag an audio file to the Audacity icon to open the file in a new project. Blocking that would be equally unacceptable. But if we let the drag "open" a new window as now that will confuse the "message" that you can't "open" an audio file (if we persist with that). Also "opening" a file from a file manager (when there is already an Audacity project containing an audio track) opens that file in a new window. But we could make file manager opening, file dragging to the Audacity icon and Recent Files (for audio) all import into the same project. I think a majority might even support that change.

Gale's alternative 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.

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

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

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

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

  • Page Setup...
  • Print...

  • Exit
  • Steve: That's remarkably similar to the one that I made up:

File menu proposal
The choice of "New Project" or "New Temporary Project" is not relevant to this discussion - it belongs to another proposal. Similarly "Close and Delete" relates to the same feature.
I have included "Save compressed copy" in "Save Project As..." though I agree it may be better to keep it separate.
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 >" (which are equivalent to "Import >" and "Export >" in my mock-up).
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).

Earlier Discussions

File Menu

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

        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.

        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.

        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.

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

      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.


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

Edit Menu


  • Replace Split/Split-Cut/Split-New/Split-Delete/Paste/Paste-Text-Labels/Copy/Trim/Silence-Audio/Detach-At-Silences/Duplicate/Join/Delete, by Copy/Cut/Paste/Trim/Delete/Duplicate/Join
  • Haven't really worked out exactly how to reduce the menu, but there seem to be way too many options here. For now this is just a placeholder for noting that some simplification is being thought about.

Edgar: maybe some judicious use of subitems?

Help menu

Gale: Not ideal -

  • "About Audacity" should be preferably at the bottom of the entire menu, or at the least, at the bottom of the first divider. Positioning it at the top is exceptionally non-standard, so much so that people can't find it or realise what it's for.
    • James: +1.
    • Peter: +1.
    • Edgar 14Feb10 +1
  • I think there is an argument to lose the "Quick Help" item, as users will see that section by clicking "Manual", and wondering which to chose may mean nothing will be chosen, but I don't feel very strongly about it.
  • There may be an argument for combining everything except help into one menu called "Tools" or similar
    • James: +1.
    • Edgar 14Feb10 +1 for removing everything from the Help menu which is not applicable
  • Proposal Update Checking is relevant and would go here if implemented

Edgar: Proposal_Menu_Reorganisation/Layout_Ideas has my ideas for a new Tools menu and changes to the Help menu.

Tracks Menu


  • There is a considerable pressure from some users to have a menu containing track-specific commands, so they can be discovered more easily than the Track Drop-Down Menu
    • James: +1 for a track menu (for discoverability). Thought/care is needed in determining which track(s) it affects. Can we discuss details on talk page?
    • Bill: -1 for a track menu (due to complexity). Once "discovered", the Track Control Panel menu is unambiguous about which track it is operating on.
    • Gale: I'm not convinced by it because of the ambiguity of whether the items would be greyed out or not according to which tracks were selected. I was just noting it, really. However, how about a menu item that just opened the Track Drop-down menu?
  • Gale: Mix and Render to New Track (CTRL + SHIFT + M) should be in the menu. Some users seem to like the option to see some tracks mixed visually while keeping the originals separately available. It's quite often asked for but can't be found.
  • There is debate about current mute/unmute all behaviour. This sets up mute/solo combinations that are unsupported in "Simple" solo button mode and may confuse VI users. Some argue that "Mute All Tracks" should mute all tracks and un-solo any soloed tracks. There seemed a consensus for a new "UnSolo All Tracks" item.
  • The "align" commands are inadequate, confusing and lack shortcut bindings. A command to align tracks end-to-end is sorely needed.
  • When we have very long menus we are doing something wrong (in my opinion). I would like us to group items that are or can be closely related and either have a submenu or call up a dialog with options.

Edgar: We use the phrase "align and move cursor" as well as using the word "cursor" elsewhere but we also use the phrase "add label at selection" to describe a menu command which does different things depending on the situation -- if no audio is selected it adds a label at the cursor but if audio is selected it labels the selection. On the surface this overloading of a menu command seems reasonable but it masks the option of inserting a label at the beginning of the selection without labeling the entire selection.

Steve: "Stereo Track to Mono" has always looked out of place to me, since all of the other mono<->stereo track functions are in the track drop-down menu. Also, "Mono Track to Stereo" is conspicuous by its absence (and regularly asked about on the forum).

  • Gale: Or we could group those functions in the Tracks Menu instead of Track Control Panel for discoverability. I thought the consensus response to "Mono to Stereo" was it's pointless, because it isn't meaningful stereo?

Transport Menu

Edgar: I would like to add some additional items (not necessarily with this menu item text!)

  • "play from beginning to cursor"
    • BillW - hover pointer at start of track and press B
    • Edgar 14 February 2010 all well and good but does not put this in the menu; also makes it more difficult for those of us with physical disabilities -- same comment for the next two
    • Gale: SHIFT + J then Edit > Move Cursor > to Selection End (has a binding and both in menu)
  • "play from cursor to end"
    • BillW - hover pointer at end of track and press B
    • Gale: SHIFT + K then Edit > Move Cursor > to Selection Start (has a binding and both in menu)
  • "preview" (play from cursor preview duration)
    • BillW - hover pointer near the cursor and press B
  • "stop and move cursor to stop point"
    • BillW - press SHIFT + A
    • Edgar 14Feb10 not in menu equals hard to discover

Shortcut Keys

Edgar: Proposal_Menu_Reorganisation/Shortcut_Keys has a sorted list of the current (1.3.11 beta rc1 23 Jan 2010) shortcut keys and items without shortcuts listed at the bottom.

Proposed New Shortcut Keys:

File>Export... X (Edgar)
File> Open Metadata Editor... M (Edgar)
  • David B.: I think there are a couple of reasons for not using single letter keystrokes for opening these dialogs:
    1. They won't work if the focus is a label track
    2. It might be best to keep the remaining available single letter shortcuts for actions that are very repetitive.
    Alternative shortcuts for these dialogs might be ctrl+shift+E for export, and ctrl+shift+d for metadata. ctrl+h and ctrl+g are also available, but the letters don't work very well.
  • Gale: To clarify, unmodified shortcuts won't work if you have a label open, or if you have the cursor in the label track (unless the cursor is at the same place as an existing label). If the focus is in the label track in other circumstances, they will. I'm surprised there is no shortcut for export. CTRL + SHIFT + E is a bit of a fingerfull, but it does match with current CTRL + SHIFT + I for import. +1 for CTRL + SHIFT + E for Export "if" we retain that word, which is not a given in my book.

    Export and Metadata Editor are commonly used, but I agree may not be the most repetitive tasks within a project workflow. We probably should use unmodified shortcuts more for those cases. I would strongly favour for example "S" for solo/unsolo focused track and "M" for mute/unmute focused track, if only people could discover it. Can tooltips be dynamic to show the current shortcut even if user changes them?. That would greatly aid discovery for mute/solo and for say the Tools Toolbar tools.

    There could be a preference to force use of CTRL + B to add a label, to resolve part of your objection to use of single key shortcuts.

  • David: I don't understand what you mean by "if you have the cursor in the label track" - surely the cursor is at a time, not in a track.
    • GA: Generate a tone, CTRL + B, type a label, ENTER, then click in the label track to right of the label (so that typing unmodified characters would then create a label immediately).
      • David: A vertical line is drawn in a track at the cursor position if the track is selected and/or the focus. Is this what you mean by the cursor being in a track? Because this line is a secondary effect of the selection/focus of a track, I think it easy to describe the state of the tracks in terms of selection and focus, rather than the presence/absence of the vertical lines indicating the position of the cursor.
        • GA: Yes that is what I mean. And clearly, having the cursor in free space in the label track (not per se the fact of a label track having selectedness or focus) is a case that prevents unmodified shortcuts working (they type a label instead).
  • David: Also, could you give examples of the "other circumstances".
    • GA: As far as I can see, any other case than "label open" or "cursor in label track". Example: Create a label, confirm it with ENTER, then R will record and P will pause.
      • David: As far as I can see, if the label track is the focus, then unmodified shortcuts won't work unless you've just pressed enter to confirm a label. Are there any other exceptions?
        • GA:Already said. Cursor at the same position as a pre-existing label (which is the case when you have just hit ENTER to confirm a label).
  • David: It has been suggested in the past that there should be a preference to force the use of CTRL+B to add a label, and that is one of a number of changes needed to allow blind users to fully use the label tracks. However, I think that the shortcuts for these two dialogs should be expected to work with the focus anywhere in the audacity window, whatever the preferences, and whatever controls are added to the window in the future, and the only way to ensure that this is the case is for them to include a modifier, and not be single letters.
    • GA: Well, a VI user wouldn't click to put the cursor in the label track, and if they are editing a label (by tabbing into it), I don't think they (or anyone else) can expect unmodified shortcuts to work. What other cases are there where a VI user with focus in the label track would find an unmodified shortcut wouldn't work?

      What other changes are needed to make label tracks fully accessible? F2 to edit a selected label?

      • David: I wasn't specifically considering VI users. As I said above, I think that shortcuts to those dialogs should work wherever the user is in the window - they shouldn't have to think about it. Like the ctrl+o and ctrl+s shortcuts, they should just work. Other changes to make the label tracks accessible are: that unless you are currently editing a label, pressing tab to move to the next label shouldn't automatically open the label for editing (to edit press f2 as you said); and screen readers need to be able to read the labels in a label track.
        • GA: I've already said that I favour CTRL + SHIFT + E for export, and leave Metadata Editor without a default binding. All I wanted to do was clarify that unmodified shortcuts do work in two specific cases even when the label track has focus. We definitely should consider how "fundamental" an action is before giving it an unmodified shortcut. But if the action is not fundamental but repetitive, then I think we should not shy away from using unmodified shortcuts just because they won't always work when the label track has focus. Users can always change the binding if their workflow sets up cases where label track has focus, or force CTRL + B in label tracks via a Preference if we have one.

          Screen readers not reading labels is already a P3 as you know. Perhaps you may want to start a Category:Proposal page for various ways to improve accessibility (make label tracks more fully accessible, add accessibility to those parts like Meter Toolbar that aren't accessible).


Gale: Give the users visual clues that are in their face. Look at GIMP. Every menu item has a hover tooltip which is duplicated in the Status Bar. It would have to have a Preference to turn it off (as it does in GIMP).

Edgar: +1

Warning icon 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:
  • 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.
    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.
  • 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.

    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.

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.

      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.

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.