Gale Andrews wrote:
> | From Vaughan Johnson <
vaughan@...>
> | Tue, 03 Jun 2008 18:24:41 -0700
> | Subject: [Audacity-devel] EXPERIMENTAL_MODULES
>
>> Lots of audio apps have a "Transport" menu for the play/record/pause/etc
>> controls. Not sure if that name is clear for noobs.
>>
>
> David B. suggested "Control".
I know, but personally, I don't think that conveys what they are. There
are lots of controls.
> But how about the obvious "Play/Record"?
> To increase discoverability, it must have an intuitive root menu name.
>
Never seen a menu name with punctuation in it... and this is a bit wide.
Moreover, "Transport" is very common (e.g., Nuendo, ProTools,
SoundForge, Ardour, ...) and clear, so I still like it best.
>
>
> ...
> I'll admit
> though I don't personally like a string of menu items to navigate
> through to reach transport controls (or the extra menu item to
> go through horizontally).
It's just an alternative (you can still use the buttons), and a common
menu in other audio apps.
> Also the more specialised record options
> we eventually add, the more cluttered this menu will become.
>
But it's a small list now. We can worry about that if/when it happens.
>
>
> ...
>
>
>
>
>> So I think the Sound Activated Recording menu item should be checkable.
>> It could either open a dialog to select the threshold and on/off (i.e.,
>> not be directly checkable but show the checkmark in the menu if on in
>> the dialog), or the threshold setting could be a separate item, e.g.,
>> Sound Threshold...
>>
>
> I like your first idea better
Me, too.
> - but it might be confusing on the first
> few uses to have a display of checked/unchecked status that looks like
> similar checked menus, but behaves differently.
But it will have the ellipsis to indicate it brings up a dialog. I don't
think it's confusing.
> Maybe the check mark
> could be to right of the menu text to create a distinction?
Distinct but without obvious meaning, and breaks the format of key
command at right. The ellipsis makes it work.
> If the
> threshold needs to be a separate item I hope it will cascade as I worry
> about the length of this menu.
>
It's only 9 (or 10) items so far, among our shortest, but I like it as
one command that brings up a dialog.
>
>
>> And I think it's okay to mirror them in the prefs dialog if we want to
>> keep Channels and Playthrough there as well as put them in the menu.
>>
>
> See above.
>
But they're very natural to the Audio I/O tab, and not hard to mirror.
>
> ...
> Do you agree it should
> be stereo by default, which reduces the need for discoverability?
>
Yes.
>
>
>> So, something like:
>>
>> Play
>> Loop Play
>> Pause
>> Stop
>> -----
>> Record
>> Timer Record...
>> Sound Activated Recording...
>> Channels...
>> Playthrough (checkable menu item)
>> -----
>>
>
> Don't forget append record (and I still say it needs a tooltip) :=)
>
Yes, then 10 items.
> I still feel there will be initial confusion at a mixture of menu
> items, some of which (Record, Timer Record) start a recording
> and others that don't.
Checkmarks and ellipses make them clear, I think. And the "-ing" for
Sound Activated Recording, vs the imperative (Timer) Record, Play,
Pause... nouns vs verbs.
> I would rather have a divider under
> Record and Timer Record, then Recording Options (or similar)
> cascading to Sound Activated, Channels and Playthrough.
Unnecessarily complicated, imo, for 6 items.
> I
> don't know if Widgets supports it, but small red circles in
> Record and Timer Record would help as well. Taking cover
> now.... :=)
>
I think it's possible, there's a wxMenuItem::SetBitmap() but we haven't
used it anywhere yet.
> Don't forget access keys and shortcuts - Timer Record is now
> a longer step down a menu than before.
>
Not by much, and I don't think people repeatedly do Timer Record,
especially in the middle of doing edits (which has a greater need for
shortcuts). But for several, we already have shortcuts (e.g., space for
Play).
>
>> Fast Forward
>> Rewind
>>
>
> Should those be under the Play section? In terms of frequency of
> usage, might there be a case for the "Record" Section above "Play",
> even if it reverses the normal order we describe those two in?
> What I am saying is that once people know the shortcuts, I suspect
> the main use of this menu may well be to acess the "recording
> options".
>
I think people won't change those often, and the out-of-order-ness not
worth it.
>
>> I agree with the renames to TimerRecordDialog and
>> SoundActivatedRecording (or whatever is decided).
>>
>
> It's important we choose an intelligible name for the menu items
> for Timer and Sound Activated Recording. Maybe "Timer Record" is
> not ideal. Some users of this item seemingly think it means another
> way to demarcate a time selection,
That's a *very* weird, confused interpretation, I think.
> but that is partly down to the
> menu it's in. I think "Timed Recording" would be far better,
Disagree with the "-ing", per the noun-verb distinction of settings vs
commands. And "Timed" is only slightly clearer (if at all), and not
worth the effort, I think (translators, etc).
> then
> the last word matches with our choice for Smart Recording.
>
But that's exactly why I made them different, verb/noun.
> If we want to keep the word "Record", how about "Scheduled
> Record"?
>
>
No, that's no clearer.
- V
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
