Talk:Proposal Menu Reorganisation

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

Edit Menu
James:


 * 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
Gale:
 * 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?

Bill 28Apr11
 * Strong support for "Mix and Render to New Track" getting a place in the menus.
 * Peter 1May11: +1
 * 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

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

View Menu
Bill 28Apr11
 * OK with "Fit" and "Zoom" fly-outs
 * Peter 1May11: +1

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)

 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.
 * David B.: I think there are a couple of reasons for not using single letter keystrokes for opening these dialogs:
 * They won't work if the focus is a label track
 * It might be best to keep the remaining available single letter shortcuts for actions that are very repetitive.


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

Signposting
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