Difference between revisions of "Completed Proposal Menu Reorganisation"
(Mix and Render to New track in Tracks menu?)
(Proposal M for Open Metadata Editor)
|Line 112:||Line 112:|
'''Proposed New Shortcut Keys:'''<BR>
'''Proposed New Shortcut Keys:'''<BR>
: File>Export... '''X''' (Edgar)
: File>Export... '''X
Revision as of 21:27, 5 February 2010
|Proposal pages help us get from feature requests into actual plans. This proposal page is about reorganising the menus.|
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.
One driver for reorganising the menus is to avoid the problems that arise from having 'export' and 'save' as different functions. The options there can with care be merged so that there are fewer menu items.
The Audacity menus have also become rather complex with numerous options, especially when label linking is enabled.
- James Crook - In favour of certain changes suggested here.
- New users of Audacity who are confused about export and save, or what the menu items actually mean
- Experienced users of Audacity who feel the menus are too long or verbose
Subject to discussion. Some options to choose from below:
- 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.
- 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.
- 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?
- 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 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: 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
- "play from cursor to end" BillW - hover pointer at end of track and press B
- "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
On the Tracks menu 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.
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.
- 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.
- 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.
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: 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)