Aaah, the tarpit of UI discussions. :-)
Shane Mueller wrote:
>>BTW, I shortened the names of the "Set Left/Right Selection at Playback
>>Position" commands and made them menu commands, in the Edit "Select..."
>>submenu, for the sake of discoverability.
>I intentionally left these out of the menus, because they only work
>while playback is occurring, and it is pretty near impossible to time
>you navigation through a menu system to work well during playback.
>Also, like a number of keyboard shortcuts, they are only discoverable
>through the preferences.
Well, they work during recording and pause, too. Absolutely, you can't
negotiate the menu fast enough to accurately change the cursor while
it's playing/recording, but can easily with pause. With the commands in
the menu, you can discover the keyboard shortcuts, and those work great
while playing/recording. I believe (from recent discussion on
audacity-users) these are commands that lots of users will want, and
should be very discoverable.
I think the seventh tab in the Prefs dialog is at best the distant
outskirts of discoverability, and this is supported by all the questions
on audacity-help about keyboard shortcuts. Also, that prefs tab doesn't
show which are menu commands and which are hidden, so you have to look
through the whole list to see what commands are not in menus. I don't
think many people would guess that's a possibility. I didn't, at first
-- I thought that tab was just for setting shortcuts for menu commands,
and I didn't know there were any non-menu commands.
I fully understand that huge and complicated menus can be a problem, but
I'd rather have everything visible somewhere the average user would
think to look. We talked previously about different ~skins of levels of
sophistication, so beginners aren't overwhelmed. I don't think
Microsoft's "Personalized Menus", showing only most recently used
commands, is a good solution. Frankly, I don't like hidden commands in
general and for my skin, I'd have all commands in menus.
>By adding them to the 'select' submenu, it
>increases the size of the menu by 66%, which probably at a increases the
>time to use anything in that menu by up to the same amount. By the same
>token, I find the 'Align' submenus impossible to use because there are
>so many options--I just know that I always choose the first one in the
>submenu and it does what I want. It seems that many/all could be
>removed from the menu if were to make the drag tool 'magnetic' toward
>selection bounds, for instance. Although these functions are probably
>most useful for blind users, so it would be nice to keep the shortcuts
I very much doubt that going from 3 to 5 commands in the submenu
increases the search time by 66%, and more importantly, who ever uses,
e.g., Select All from the menu once they know the keyboard shortcut? My
point being, you learn the shortcuts for commands that you use, and the
more you know, the less you use the menus at all.
I rarely use the Align commands (thanks to Matt's latency-correction
code I don't usually have to!), but don't find them intrusive because
they're mostly in submenus, which I guess is my favorite solution to
long menus. However, they do cost extra time to navigate, so I think the
threshold for gathering into a submenu should be more like 5 subitems
rather than 3.
BTW, I believe the standard is to use ellipsis for a menu command that
invokes a dialog box, and the right-pointing triangle for submenus, so
we should remove the ellipsis from submenu headers. Right?
>For the record, here is a list of menu options I think could stand
>eliminating/reducing/rethinking. This is just my opinion, and don't be
>offended if I suggest your favorite menu item should disappear, but an
>abundance of menu options really does disorient beginners and gets in
>the way of even experienced users. If there are any candidates people
>concur with, I might find time to implement them. Seriously, some of
>the menu options have probably never been used by anyone, even with a
Likewise, Shane, I hope you're not & please don't be offended. I think
there are lots of different workstyles and I'm just expressing my
opinion. I don't find the current menus over-populated, except
potentially Effect, because of numerous plug-ins.
>File Menu: All Export and Export as... options. I would like to see a
>single export dialog which handles all of this. I realize this is not
>an opinion shared by all, as I had once worked on a new export system
>based on this idea that didn't generate much excitement amongst
Makes sense to me, but isn't important to me. A quicker fix would be
(guess what?) submenus:
[submenu of different formats]
Export Selection >
[submenu of different formats]
But I think there could be a couple of more formats before this would be
a good idea.
>File Menu: Dump 'Page setup' (already exists in the print dialog)
I never print from Audacity, so I don't care, but isn't it typical that
'Page Setup' from the Print dialog is for that print job only and from
the File menu sets the page setup for the app, to apply to all future
>Edit Menu: Possibly move all selection based stuff into a 'select' menu
>as seen in other programs; move them out of submenus, and get rid of the
>ones that are not too useful.
Actually, I think for blind/VI users, and for shortcut discoverability,
a Transport menu is more valuable, but when I suggested it a year or so
ago, there was great distaste for adding another menu. Also, Select
commands are usually in Edit menus, & it's only 5 lines in the Edit menu.
>Edit Menu: Snap-to|Snap-to on/Snap-to off. This just seems wrong to be
>a menu option. Maybe it could be moved to a check box on the selection
It definitely shouldn't be a submenu, just a wxITEM_CHECK.
>View Menu: Reduce the zoom options by 2 or 3. These are already
>keyboard shortcuts, plus there are three additional zooming methods
>available (the zoom tool, the zoom buttons, and ctrl-scrollbar). Do we
>really need five ways to zoom? (I'd also be in favor of getting rid of
>the zoom tool, but there is probably little harm in keeping it there,
>and I'm sure people do use it in some situations).
I disagree on the basis of discoverability. Yes, I use the buttons and
shortcuts, but I didn't know about the shortcuts until I saw them in the
menu. And there's no button for Zoom Normal.
>View Menu: Float Meter toolbar. This needs to be fixed to reflect the
>state of the toolbar, and if possible removed entirely.
Yes, and what happened to the other Float commands? They should all be
consistent. Double-clicking the handle works, except for the meters, and
frankly, that's obvious enough for me. However, it's a drag (pun
intended) that you can't rearrange the docked toolbars except by
floating then re-docking them in the order you want.
>View Menu: History. Move to Edit menu near undo/redo and call it 'Undo
Didn't it get changed from "Undo History" a while ago, for the Orwellian
reason Alexandre pointed out? It should remain "History", IMHO.
I agree that it makes sense to locate it next to Undo & Redo.
>Project Menu: Import options: Consider moving to or duplicate in File
Duplicate? You want more commands in menus when they're accessible
I agree they make more sense moved to the File menu. Then maybe add
Transport commands to the Project menu (!).
>Project Menu: Import MIDI: Remove until we support real midi.
>Project Menu: Remove Tracks: Change to 'Remove Track'
>Project Menu: Align. Reduce to 1 or two options (to zero and with
>cursor). There are too many to think about, and the reasonable
>multi-clip support gets rid of many of the reasons to have them there.
>Project Menu: Align and Move Cursor. Get rid of them them all. The
>concept of moving a clip without moving the selection might be useful,
>but why not just make those samples a different clip? If truly deemed
>necessary, we might be able to devise a 'lock selection to clip' mode or
>markers that are bound to sample positions rather than timeline
>Generate/Effect/Analyze. I think these need serious reworking, although
>I think the current version is logical, it is difficult to use
>(something I take partial blame for). The 'analyze' menu has only ever
>had two plugins for me, and one is a demo. This, at least, should be
>folded into the 'effect' menu. I also think that there should either be
>a strong comprehensible hierarchy, or we should just load a few popular
>effects in the effects menu with another option 'Other effects...' that
>launches a dialog effects browser that possibly gives descriptions of
>effects and allows one to set keyboard shortcuts and add select
>favorites to add to the menu. Given that this is a complex undertaking,
>I would settle for getting rid of Analyze.
Yes, when people objected to my Transport menu suggestion (which is
totally unimportant to my usage now, btw), this was discussed a little
-- 3 menus for effects and only one has more than a few items. I agree
the current distinction is logical, but not difficult to use, just
unbalanced, with too few in Generate and Analyze, and too many in
Effect. We could distinguish them as Effect (built-ins) and Plug-ins. I
expect most of our users don't add plugins, but there are some (like
Tony) who have vast quantities. Hard to cover both cases.
But, yes, for now, I'd say just put Analyze's Beat Finder in Effect.
>Help: Run benchmark. Get rid of it. Hide it. If necessary, move it to
>a preferences dialog. I suppose it isn't in the released compiled
>versions, so this is just me nitpicking.
Thanks for all the thought you've put into this.