Latest Selection Toolbar iterations

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Latest Selection Toolbar iterations

Gale
Administrator
Just FYI, I started a thread about the latest Selection Toolbar
iterations but misposted to the -manual list.

If anyone wants to view it whole they can do so here, but you
apparently need to be logged into SF to do so:

https://sourceforge.net/p/audacity/mailman/audacity-manual/thread/CANSFOvD5NYN3A1nx6etEaW9_cmz7wAAUj-y9rN%2BvMYOzonrELA%40mail.gmail.com/#msg35870503

Or the gist is below.


Gale


On 1 June 2017 at 11:49, Peter Sampson <[hidden email]> wrote:

> On Thu, Jun 1, 2017 at 11:24 AM, Steve the Fiddle <[hidden email]>
> wrote:
>
>> My "first impression" of the new multi-choice dropdown above the time
>> controls:
>>
>> Coming from Audacity 2.1.3, it looks comfortingly familiar. On first
>> look, it looks no different other than that it is a dropdown choice
>> rather than radio buttons. If anything it seems slightly clearer to me
>> than the 3.1.4 version. On clicking the menu button, the new choices
>> are obvious and it becomes clear why the change from radio buttons to
>> menu.
>>
>
> Like Steve I'm finfing myself liking the latest iteration of these controls.
> I'm finding this easy to understand and use
>
> I agree that users who are used to clicking in the radio buttons should
> mostly
> readily figure that the can click on the down-chevron to open up the
> dropdown
> menu which is clear and "discoverable" in its purpose and effect.
>
> The span of the menu box over both time data/selection boxes also makes
> it clear wht the entry in the menu box is talking about.
>
>
> This thread, though, is another example of something that should be being
> discussed on the quality list, not restricted to the low-readership manual
> list
> as this is not a documentation issue until the UI design is finalized.
> I thought we agreed that we would not do this ...
>
> Peter
>
>
>>
>> It also resolves a problem that I was about to report, that in the
>> previous version, the height difference made it impossible to place
>> the Spectral Selection toolbar on the same row after the normal
>> Selection toolbar.
>>
>> I've not tested for accessibility, and that is of course very
>> important for this feature.
>>
>> I note that it is still possible to type into the "Audio position"
>> time control, which is a bit weird as it then it resets itself when I
>> do anything else. I can live with this if the intention is that typing
>> into the Audio position control will eventually do something (could be
>> very handy when looping a long selection).
>>
>> Steve
>>
>>
>> On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
>> > Gale, do you think the previous version, IF it was on three buttons (left
>> > chevron, title, right chevron) would be better for sighted users than
>> what
>> > we have right now?
>> >
>> > On 6/1/2017 5:34 AM, Gale Andrews wrote:
>> >>
>> >> James,
>> >>
>> >> My first reaction is that I'm not sure this works as well in Selection
>> >> Toolbar as Spectral Selection Toolbar, because of the varying length
>> >> of Selection Toolbar according to the chosen format.
>> >
>> > Having the button full width does though show that the start-end (or
>> > whatever) fields belong together.
>> >
>> > I think if the text were centered above the hyphen that would be an
>> > improvement.  Do you?
>> > (unfortunately that is relatively hard to do without hacks based on
>> spaces
>> > that make assumptions about font).
>> >
>> >> The educational value of both toolbars looking the same is probably
>> >> watered down by the fact that most users won't have Spectral
>> >> Selection Toolbar on.
>> >
>> > Yes.  Spectral selection is a pro feature.
>> >
>> >> Both toolbars should either have the hyphen between spinboxes
>> >> or not. I think it would "look" better if both did have the hyphen
>> >> and both toolbars replaced "and" in the choice name with "-".
>> >> But do I assume this sounds less clear for VI users? Could they
>> >> still hear "and" instead of "-" somehow?
>> >
>> > I'd think VI users would be fine with the hyphen.  It is still clear what
>> > the fields are, and slightly shorter/faster than 'and'.
>> >
>> > My own dis-satisfaction with the choice control is that it is not themed
>> and
>> > not themable.
>> > That also goes for the choice controls in the Device toolbar.
>> >
>> > I think we could be looking at writing/simulating our own choice control
>> > which:
>> > - Is themable
>> > - Can center text on the hyphen.
>> > - Can say different things to VI users than the text on it.
>> >
>> > That could perhaps be built up using
>> > http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
>> > Or could be built up starting from the previous code that used wxText
>> and a
>> > menu pop-up.
>> >
>> > I'm unsure whether it should be the full width of both fields, or just
>> > (slightly more than) the max width to hold its contents.  Which do you
>> think
>> > Gale?
>> >
>> > --James.
>> >
>> >
>> >
>> >> Gale
>> >

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Gale
Administrator
On 1 June 2017 at 11:24, Steve the Fiddle <[hidden email]> wrote:

> My "first impression" of the new multi-choice dropdown above the time controls:
>
> Coming from Audacity 2.1.3, it looks comfortingly familiar. On first
> look, it looks no different other than that it is a dropdown choice
> rather than radio buttons. If anything it seems slightly clearer to me
> than the 3.1.4 version. On clicking the menu button, the new choices
> are obvious and it becomes clear why the change from radio buttons to
> menu.
>
> It also resolves a problem that I was about to report, that in the
> previous version, the height difference made it impossible to place
> the Spectral Selection toolbar on the same row after the normal
> Selection toolbar.

That fitting problem did not exist on Windows, so the only issue
was that it looked weird for those who turned Spectral Selection
Toolbar on.

I note that James has equalized the height now, anyway, so
hopefully it could support either dropdown menu or buttons
as we choose.


Gale

> I've not tested for accessibility, and that is of course very
> important for this feature.
>
> I note that it is still possible to type into the "Audio position"
> time control, which is a bit weird as it then it resets itself when I
> do anything else. I can live with this if the intention is that typing
> into the Audio position control will eventually do something (could be
> very handy when looping a long selection).
>
> Steve
>
>
> On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
>> Gale, do you think the previous version, IF it was on three buttons (left
>> chevron, title, right chevron) would be better for sighted users than what
>> we have right now?
>>
>> On 6/1/2017 5:34 AM, Gale Andrews wrote:
>>>
>>> James,
>>>
>>> My first reaction is that I'm not sure this works as well in Selection
>>> Toolbar as Spectral Selection Toolbar, because of the varying length
>>> of Selection Toolbar according to the chosen format.
>>
>> Having the button full width does though show that the start-end (or
>> whatever) fields belong together.
>>
>> I think if the text were centered above the hyphen that would be an
>> improvement.  Do you?
>> (unfortunately that is relatively hard to do without hacks based on spaces
>> that make assumptions about font).
>>
>>> The educational value of both toolbars looking the same is probably
>>> watered down by the fact that most users won't have Spectral
>>> Selection Toolbar on.
>>
>> Yes.  Spectral selection is a pro feature.
>>
>>> Both toolbars should either have the hyphen between spinboxes
>>> or not. I think it would "look" better if both did have the hyphen
>>> and both toolbars replaced "and" in the choice name with "-".
>>> But do I assume this sounds less clear for VI users? Could they
>>> still hear "and" instead of "-" somehow?
>>
>> I'd think VI users would be fine with the hyphen.  It is still clear what
>> the fields are, and slightly shorter/faster than 'and'.
>>
>> My own dis-satisfaction with the choice control is that it is not themed and
>> not themable.
>> That also goes for the choice controls in the Device toolbar.
>>
>> I think we could be looking at writing/simulating our own choice control
>> which:
>> - Is themable
>> - Can center text on the hyphen.
>> - Can say different things to VI users than the text on it.
>>
>> That could perhaps be built up using
>> http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
>> Or could be built up starting from the previous code that used wxText and a
>> menu pop-up.
>>
>> I'm unsure whether it should be the full width of both fields, or just
>> (slightly more than) the max width to hold its contents.  Which do you think
>> Gale?
>>
>> --James.
>>
>>
>>
>>> Gale

Gale


On 1 June 2017 at 18:24, Gale Andrews <[hidden email]> wrote:

> Just FYI, I started a thread about the latest Selection Toolbar
> iterations but misposted to the -manual list.
>
> If anyone wants to view it whole they can do so here, but you
> apparently need to be logged into SF to do so:
>
> https://sourceforge.net/p/audacity/mailman/audacity-manual/thread/CANSFOvD5NYN3A1nx6etEaW9_cmz7wAAUj-y9rN%2BvMYOzonrELA%40mail.gmail.com/#msg35870503
>
> Or the gist is below.
>
>
> Gale
>
>
> On 1 June 2017 at 11:49, Peter Sampson <[hidden email]> wrote:
>> On Thu, Jun 1, 2017 at 11:24 AM, Steve the Fiddle <[hidden email]>
>> wrote:
>>
>>> My "first impression" of the new multi-choice dropdown above the time
>>> controls:
>>>
>>> Coming from Audacity 2.1.3, it looks comfortingly familiar. On first
>>> look, it looks no different other than that it is a dropdown choice
>>> rather than radio buttons. If anything it seems slightly clearer to me
>>> than the 3.1.4 version. On clicking the menu button, the new choices
>>> are obvious and it becomes clear why the change from radio buttons to
>>> menu.
>>>
>>
>> Like Steve I'm finfing myself liking the latest iteration of these controls.
>> I'm finding this easy to understand and use
>>
>> I agree that users who are used to clicking in the radio buttons should
>> mostly
>> readily figure that the can click on the down-chevron to open up the
>> dropdown
>> menu which is clear and "discoverable" in its purpose and effect.
>>
>> The span of the menu box over both time data/selection boxes also makes
>> it clear wht the entry in the menu box is talking about.
>>
>>
>> This thread, though, is another example of something that should be being
>> discussed on the quality list, not restricted to the low-readership manual
>> list
>> as this is not a documentation issue until the UI design is finalized.
>> I thought we agreed that we would not do this ...
>>
>> Peter
>>
>>
>>>
>>> It also resolves a problem that I was about to report, that in the
>>> previous version, the height difference made it impossible to place
>>> the Spectral Selection toolbar on the same row after the normal
>>> Selection toolbar.
>>>
>>> I've not tested for accessibility, and that is of course very
>>> important for this feature.
>>>
>>> I note that it is still possible to type into the "Audio position"
>>> time control, which is a bit weird as it then it resets itself when I
>>> do anything else. I can live with this if the intention is that typing
>>> into the Audio position control will eventually do something (could be
>>> very handy when looping a long selection).
>>>
>>> Steve
>>>
>>>
>>> On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
>>> > Gale, do you think the previous version, IF it was on three buttons (left
>>> > chevron, title, right chevron) would be better for sighted users than
>>> what
>>> > we have right now?
>>> >
>>> > On 6/1/2017 5:34 AM, Gale Andrews wrote:
>>> >>
>>> >> James,
>>> >>
>>> >> My first reaction is that I'm not sure this works as well in Selection
>>> >> Toolbar as Spectral Selection Toolbar, because of the varying length
>>> >> of Selection Toolbar according to the chosen format.
>>> >
>>> > Having the button full width does though show that the start-end (or
>>> > whatever) fields belong together.
>>> >
>>> > I think if the text were centered above the hyphen that would be an
>>> > improvement.  Do you?
>>> > (unfortunately that is relatively hard to do without hacks based on
>>> spaces
>>> > that make assumptions about font).
>>> >
>>> >> The educational value of both toolbars looking the same is probably
>>> >> watered down by the fact that most users won't have Spectral
>>> >> Selection Toolbar on.
>>> >
>>> > Yes.  Spectral selection is a pro feature.
>>> >
>>> >> Both toolbars should either have the hyphen between spinboxes
>>> >> or not. I think it would "look" better if both did have the hyphen
>>> >> and both toolbars replaced "and" in the choice name with "-".
>>> >> But do I assume this sounds less clear for VI users? Could they
>>> >> still hear "and" instead of "-" somehow?
>>> >
>>> > I'd think VI users would be fine with the hyphen.  It is still clear what
>>> > the fields are, and slightly shorter/faster than 'and'.
>>> >
>>> > My own dis-satisfaction with the choice control is that it is not themed
>>> and
>>> > not themable.
>>> > That also goes for the choice controls in the Device toolbar.
>>> >
>>> > I think we could be looking at writing/simulating our own choice control
>>> > which:
>>> > - Is themable
>>> > - Can center text on the hyphen.
>>> > - Can say different things to VI users than the text on it.
>>> >
>>> > That could perhaps be built up using
>>> > http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
>>> > Or could be built up starting from the previous code that used wxText
>>> and a
>>> > menu pop-up.
>>> >
>>> > I'm unsure whether it should be the full width of both fields, or just
>>> > (slightly more than) the max width to hold its contents.  Which do you
>>> think
>>> > Gale?
>>> >
>>> > --James.
>>> >
>>> >
>>> >
>>> >> Gale
>>> >

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Gale
Administrator
On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
> Gale, do you think the previous version, IF it was on three buttons (left
> chevron, title, right chevron) would be better for sighted users than what
> we have right now?

I would have thought a single navigation button was better. As
you say, the two fields belong together, so one button should do.

By title button, do you mean e.g. "Length - End" could itself be
the navigation button?


> On 6/1/2017 5:34 AM, Gale Andrews wrote:
>>
>> James,
>>
>> My first reaction is that I'm not sure this works as well in Selection
>> Toolbar as Spectral Selection Toolbar, because of the varying length
>> of Selection Toolbar according to the chosen format.
>
> Having the button full width does though show that the start-end (or
> whatever) fields belong together.
>
> I think if the text were centered above the hyphen that would be an
> improvement.  Do you?
> (unfortunately that is relatively hard to do without hacks based on spaces
> that make assumptions about font).

You've removed hyphens for now, but I think the text saying "-"
instead of "and" and having the hyphen between spinboxes
would help more than centering text above the hyphen.

Unless the hyphen itself was centred, it wouldn't help much,
and centred hyphen would make the text look unbalanced
with "of Selection" at the end,


>> The educational value of both toolbars looking the same is probably
>> watered down by the fact that most users won't have Spectral
>> Selection Toolbar on.
>
> Yes.  Spectral selection is a pro feature.
>
>> Both toolbars should either have the hyphen between spinboxes
>> or not. I think it would "look" better if both did have the hyphen
>> and both toolbars replaced "and" in the choice name with "-".
>> But do I assume this sounds less clear for VI users? Could they
>> still hear "and" instead of "-" somehow?
>
> I'd think VI users would be fine with the hyphen.  It is still clear what
> the fields are, and slightly shorter/faster than 'and'.
>
> My own dis-satisfaction with the choice control is that it is not themed and
> not themable.
> That also goes for the choice controls in the Device toolbar.
>
> I think we could be looking at writing/simulating our own choice control
> which:
> - Is themable
> - Can center text on the hyphen.
> - Can say different things to VI users than the text on it.
>
> That could perhaps be built up using
> http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
> Or could be built up starting from the previous code that used wxText and a
> menu pop-up.
>
> I'm unsure whether it should be the full width of both fields, or just
> (slightly more than) the max width to hold its contents.  Which do you think
> Gale?

You mean max width to hold the longest item in the list?

Peter/Steve like full width when used with the selection based
toolbars, and I think I would be inclined to agree if we want a
dropdown choice.

As the "other" mystery shopper said, the key question with a
dropdown menu compared to a button is that it is more effort
with a dropdown to change to an adjoining choice, every single
time.

With Spectral Selection Toolbar, the choice is always adjoining
because there are only two choices.


Gale


On 1 June 2017 at 18:37, Gale Andrews <[hidden email]> wrote:

> On 1 June 2017 at 11:24, Steve the Fiddle <[hidden email]> wrote:
>> My "first impression" of the new multi-choice dropdown above the time controls:
>>
>> Coming from Audacity 2.1.3, it looks comfortingly familiar. On first
>> look, it looks no different other than that it is a dropdown choice
>> rather than radio buttons. If anything it seems slightly clearer to me
>> than the 3.1.4 version. On clicking the menu button, the new choices
>> are obvious and it becomes clear why the change from radio buttons to
>> menu.
>>
>> It also resolves a problem that I was about to report, that in the
>> previous version, the height difference made it impossible to place
>> the Spectral Selection toolbar on the same row after the normal
>> Selection toolbar.
>
> That fitting problem did not exist on Windows, so the only issue
> was that it looked weird for those who turned Spectral Selection
> Toolbar on.
>
> I note that James has equalized the height now, anyway, so
> hopefully it could support either dropdown menu or buttons
> as we choose.
>
>
> Gale
>
>> I've not tested for accessibility, and that is of course very
>> important for this feature.
>>
>> I note that it is still possible to type into the "Audio position"
>> time control, which is a bit weird as it then it resets itself when I
>> do anything else. I can live with this if the intention is that typing
>> into the Audio position control will eventually do something (could be
>> very handy when looping a long selection).
>>
>> Steve
>>
>>
>> On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
>>> Gale, do you think the previous version, IF it was on three buttons (left
>>> chevron, title, right chevron) would be better for sighted users than what
>>> we have right now?
>>>
>>> On 6/1/2017 5:34 AM, Gale Andrews wrote:
>>>>
>>>> James,
>>>>
>>>> My first reaction is that I'm not sure this works as well in Selection
>>>> Toolbar as Spectral Selection Toolbar, because of the varying length
>>>> of Selection Toolbar according to the chosen format.
>>>
>>> Having the button full width does though show that the start-end (or
>>> whatever) fields belong together.
>>>
>>> I think if the text were centered above the hyphen that would be an
>>> improvement.  Do you?
>>> (unfortunately that is relatively hard to do without hacks based on spaces
>>> that make assumptions about font).
>>>
>>>> The educational value of both toolbars looking the same is probably
>>>> watered down by the fact that most users won't have Spectral
>>>> Selection Toolbar on.
>>>
>>> Yes.  Spectral selection is a pro feature.
>>>
>>>> Both toolbars should either have the hyphen between spinboxes
>>>> or not. I think it would "look" better if both did have the hyphen
>>>> and both toolbars replaced "and" in the choice name with "-".
>>>> But do I assume this sounds less clear for VI users? Could they
>>>> still hear "and" instead of "-" somehow?
>>>
>>> I'd think VI users would be fine with the hyphen.  It is still clear what
>>> the fields are, and slightly shorter/faster than 'and'.
>>>
>>> My own dis-satisfaction with the choice control is that it is not themed and
>>> not themable.
>>> That also goes for the choice controls in the Device toolbar.
>>>
>>> I think we could be looking at writing/simulating our own choice control
>>> which:
>>> - Is themable
>>> - Can center text on the hyphen.
>>> - Can say different things to VI users than the text on it.
>>>
>>> That could perhaps be built up using
>>> http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
>>> Or could be built up starting from the previous code that used wxText and a
>>> menu pop-up.
>>>
>>> I'm unsure whether it should be the full width of both fields, or just
>>> (slightly more than) the max width to hold its contents.  Which do you think
>>> Gale?
>>>
>>> --James.
>>>
>>>
>>>
>>>> Gale
>
> Gale
>
>
> On 1 June 2017 at 18:24, Gale Andrews <[hidden email]> wrote:
>> Just FYI, I started a thread about the latest Selection Toolbar
>> iterations but misposted to the -manual list.
>>
>> If anyone wants to view it whole they can do so here, but you
>> apparently need to be logged into SF to do so:
>>
>> https://sourceforge.net/p/audacity/mailman/audacity-manual/thread/CANSFOvD5NYN3A1nx6etEaW9_cmz7wAAUj-y9rN%2BvMYOzonrELA%40mail.gmail.com/#msg35870503
>>
>> Or the gist is below.
>>
>>
>> Gale
>>
>>
>> On 1 June 2017 at 11:49, Peter Sampson <[hidden email]> wrote:
>>> On Thu, Jun 1, 2017 at 11:24 AM, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>>> My "first impression" of the new multi-choice dropdown above the time
>>>> controls:
>>>>
>>>> Coming from Audacity 2.1.3, it looks comfortingly familiar. On first
>>>> look, it looks no different other than that it is a dropdown choice
>>>> rather than radio buttons. If anything it seems slightly clearer to me
>>>> than the 3.1.4 version. On clicking the menu button, the new choices
>>>> are obvious and it becomes clear why the change from radio buttons to
>>>> menu.
>>>>
>>>
>>> Like Steve I'm finfing myself liking the latest iteration of these controls.
>>> I'm finding this easy to understand and use
>>>
>>> I agree that users who are used to clicking in the radio buttons should
>>> mostly
>>> readily figure that the can click on the down-chevron to open up the
>>> dropdown
>>> menu which is clear and "discoverable" in its purpose and effect.
>>>
>>> The span of the menu box over both time data/selection boxes also makes
>>> it clear wht the entry in the menu box is talking about.
>>>
>>>
>>> This thread, though, is another example of something that should be being
>>> discussed on the quality list, not restricted to the low-readership manual
>>> list
>>> as this is not a documentation issue until the UI design is finalized.
>>> I thought we agreed that we would not do this ...
>>>
>>> Peter
>>>
>>>
>>>>
>>>> It also resolves a problem that I was about to report, that in the
>>>> previous version, the height difference made it impossible to place
>>>> the Spectral Selection toolbar on the same row after the normal
>>>> Selection toolbar.
>>>>
>>>> I've not tested for accessibility, and that is of course very
>>>> important for this feature.
>>>>
>>>> I note that it is still possible to type into the "Audio position"
>>>> time control, which is a bit weird as it then it resets itself when I
>>>> do anything else. I can live with this if the intention is that typing
>>>> into the Audio position control will eventually do something (could be
>>>> very handy when looping a long selection).
>>>>
>>>> Steve
>>>>
>>>>
>>>> On 1 June 2017 at 08:55, James Crook <[hidden email]> wrote:
>>>> > Gale, do you think the previous version, IF it was on three buttons (left
>>>> > chevron, title, right chevron) would be better for sighted users than
>>>> what
>>>> > we have right now?
>>>> >
>>>> > On 6/1/2017 5:34 AM, Gale Andrews wrote:
>>>> >>
>>>> >> James,
>>>> >>
>>>> >> My first reaction is that I'm not sure this works as well in Selection
>>>> >> Toolbar as Spectral Selection Toolbar, because of the varying length
>>>> >> of Selection Toolbar according to the chosen format.
>>>> >
>>>> > Having the button full width does though show that the start-end (or
>>>> > whatever) fields belong together.
>>>> >
>>>> > I think if the text were centered above the hyphen that would be an
>>>> > improvement.  Do you?
>>>> > (unfortunately that is relatively hard to do without hacks based on
>>>> spaces
>>>> > that make assumptions about font).
>>>> >
>>>> >> The educational value of both toolbars looking the same is probably
>>>> >> watered down by the fact that most users won't have Spectral
>>>> >> Selection Toolbar on.
>>>> >
>>>> > Yes.  Spectral selection is a pro feature.
>>>> >
>>>> >> Both toolbars should either have the hyphen between spinboxes
>>>> >> or not. I think it would "look" better if both did have the hyphen
>>>> >> and both toolbars replaced "and" in the choice name with "-".
>>>> >> But do I assume this sounds less clear for VI users? Could they
>>>> >> still hear "and" instead of "-" somehow?
>>>> >
>>>> > I'd think VI users would be fine with the hyphen.  It is still clear what
>>>> > the fields are, and slightly shorter/faster than 'and'.
>>>> >
>>>> > My own dis-satisfaction with the choice control is that it is not themed
>>>> and
>>>> > not themable.
>>>> > That also goes for the choice controls in the Device toolbar.
>>>> >
>>>> > I think we could be looking at writing/simulating our own choice control
>>>> > which:
>>>> > - Is themable
>>>> > - Can center text on the hyphen.
>>>> > - Can say different things to VI users than the text on it.
>>>> >
>>>> > That could perhaps be built up using
>>>> > http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html
>>>> > Or could be built up starting from the previous code that used wxText
>>>> and a
>>>> > menu pop-up.
>>>> >
>>>> > I'm unsure whether it should be the full width of both fields, or just
>>>> > (slightly more than) the max width to hold its contents.  Which do you
>>>> think
>>>> > Gale?
>>>> >
>>>> > --James.
>>>> >
>>>> >
>>>> >
>>>> >> Gale
>>>> >

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Gale
Administrator
On 1 June 2017 at 22:55, Peter Sampson <[hidden email]> wrote:

> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]> wrote:
>
>> OK I have started employing an occasional "mystery shopper"
>> too.  He has not seen the previous iterations.
>>
>> His reaction. "Confusing at first until you look at the waves
>> with the boxes. 2.1.3 is much clearer which box is which.
>>
>
> Yes it was clear in 2.1.3 but then it was a binary choice, now it is more
> complex with multiple choices - hence the reason for James choosing to
> implement a dropdown

Actually, the first I heard about it was in the commits list.


>> More fuss to change from end to length than before (used
>> to be a single click).
>>
>
> Yes, but now we have multiple choices, four of them.  And I for one do
> not want to see four radio buttons.  James tried something similar in an
> earlier iteration but we abandoned that as being too messy and cluttered.

Um, I did not see a reason posted why the two chevrons were
abandoned. I understood James was going to work further on
that to see if it was a solution. Of course the solution has to be
good for VI users too.


>> But if you want to switch to/from the beta center feature
>> the dropbox seems a good way to go.
>
>
> We do not a pair of buttons AND a dropbox

I am not sure the mystery shopper was actually suggesting that,
but I think his point that the common navigation will be
between Start - End and Start - Length (the options we had
before) is well made.

I suspect the hyphens would help sighted users even if we
stayed with the dropdown.


>  the dropbox covers all four choices and more in the future
> if we wanted more (James had 8 choices originally IIRC).
>
> But I do note that your mystery shopper concedes that the
> "dropbox seems a good way to go" at least on some level.
>
>
>
>>
>> Is there a reason to move the unimportant Audio Position
>> box to left? If it was actually functional, there might be some
>> point, but now it seems merely in the way to me. Perhaps
>> it should be a separate toolbar so users could hide it?
>>
>
> I use the audio position box a lot
> a) as a data reference
> b) as a method of moving the audio position to a specific place
>
> My reason for moving it to the left was so that the boxes with dropdowns
> in the Selection Toolbar and the Spectral Selection Toolbar would be
> adjacent.  Purely cosmetic rather than utility.

I could get used to it, but it is quite a change in where to look
for Selection Start considering that most users won't have
Spectral Selection Toolbar on.

I agree it we retain the dropdown for Selection Toolbar that Audio
Position looks kind of odd - the only element in the lower tooldock
with no choice control.

I think we should give some thought to what we want Audio Position
to do. Perhaps it can do bars or beats positions in some future
Audacity, and have its own dropdown or whatever navigation method?



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Peter Sampson-2


On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]> wrote:
On 1 June 2017 at 22:55, Peter Sampson <[hidden email]> wrote:
> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]> wrote:
>
>> OK I have started employing an occasional "mystery shopper"
>> too.  He has not seen the previous iterations.
>>
>> His reaction. "Confusing at first until you look at the waves
>> with the boxes. 2.1.3 is much clearer which box is which.
>>
>
> Yes it was clear in 2.1.3 but then it was a binary choice, now it is more
> complex with multiple choices - hence the reason for James choosing to
> implement a dropdown

Actually, the first I heard about it was in the commits list.

Er yes, that's the way Audacity works.  James is the doer and he decides.

We are then free to test and comment - but QA is not part of the pre-design 
process (unless invited to do so by the developer).

We can of course block with a P1 if the developer creates a regression - but James
has not created a regression here he has taken no functionality away, rather he has
added to the functionality.  And having to use the dropdown with two clocks rather
than a one-click radio button is no a regression.


 


>> More fuss to change from end to length than before (used
>> to be a single click).
>>
>
> Yes, but now we have multiple choices, four of them.  And I for one do
> not want to see four radio buttons.  James tried something similar in an
> earlier iteration but we abandoned that as being too messy and cluttered.

Um, I did not see a reason posted why the two chevrons were
abandoned. I understood James was going to work further on
that to see if it was a solution.

Once again at that is a case of doer-decides.  And I must say that having tried
both I think it is better without the chevrons the dropdown is better by itself.
The chevrons actually tended to involve more clicks I found.

And I note that we do not have chevrons for all the other items in the Selection
Toolbar that have dropdown menus, like say the Project Rate.

 
Of course the solution has to be
good for VI users too.

Of course, but we (and they) seem to have been working with all the other
dropdowns (Project Rate, Snap To, time display format) all this time - so one
additional dropdown seems to be consistent with our design approach for this
toolbar

 


>> But if you want to switch to/from the beta center feature
>> the dropbox seems a good way to go.
>
>
> We do not a pair of buttons AND a dropbox

I am not sure the mystery shopper was actually suggesting that,
but I think his point that the common navigation will be
between Start - End and Start - Length (the options we had
before) is well made.

I suspect the hyphens would help sighted users even if we
stayed with the dropdown.


>  the dropbox covers all four choices and more in the future
> if we wanted more (James had 8 choices originally IIRC).
>
> But I do note that your mystery shopper concedes that the
> "dropbox seems a good way to go" at least on some level.
>
>
>
>>
>> Is there a reason to move the unimportant Audio Position
>> box to left? If it was actually functional, there might be some
>> point, but now it seems merely in the way to me. Perhaps
>> it should be a separate toolbar so users could hide it?
>>
>
> I use the audio position box a lot
> a) as a data reference
> b) as a method of moving the audio position to a specific place
>
> My reason for moving it to the left was so that the boxes with dropdowns
> in the Selection Toolbar and the Spectral Selection Toolbar would be
> adjacent.  Purely cosmetic rather than utility.

I could get used to it, but it is quite a change in where to look
for Selection Start considering that most users won't have
Spectral Selection Toolbar on.

Yes indeed, but given that with this 2.2.0 release we are making many visual
changes to the GUI, now would seem to be a good time to do this if we were
to do it.

 

I agree it we retain the dropdown for Selection Toolbar that Audio
Position looks kind of odd - the only element in the lower tooldock
with no choice control.

I think we should give some thought to what we want Audio Position
to do. Perhaps it can do bars or beats positions in some future
Audacity, and have its own dropdown or whatever navigation method?

It doesn't necessarily have to "do" anything additional, un less and until a new
feature demands something of it (a bit like the increased options for the selection 
display encouraging James to go for his new dropdown menu).

Peter.

 



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

James Crook

Thanks both for the feedback, for pros and cons of the design. This is
devolving into a who has rights to do what, and I want to undevolve
that.  I'd like to bring the discussion back to discussing the design
and its future.


IMO the drop down for selection now 'matches' the drop down for
spectral-selection.   If the selection drop-down is not good, then I
contend both are not good and both should change.  In particular if one
has a hyphen, both should, if one is bad for VI users, both are, if one
MUST be themed, both must.  Does that seem logical? (In terms of
programming effort it is usually not that hard to use 'the same code' in
different places, once that code has been worked out).

I could write an 'improved drop down' that would be themed, that would
have the text (hyphen) centered, that if we want it to has chevrons.  
The 'improved drop-down' is probably more than I want to do for 2.2.0.  
I think it's more work than is justified by the improvement at this
stage.  I see room for improvement in what we have right now, but I
think what we have right now is good, and is actually already a
worthwhile improvement on 2.1.3 (it supports the center-length option
better than any of the other solution tried, gives consistency with
spectral-selection, is better for VI use than 2.1.3 was).

The change from radio button to choice is going to momentarily puzzle
some people.  But the control is in the same place, and is of a
'familiar' kind, so I think that is fine.  I think the mystery shopper
testing tends to confirm that.

Of the various suggestions, I think splitting the audio position off as
a new toolbar gives the most return for work done, but even that is
probably not for 2.2.0.  If VI use is not as good as I think it now is,
then yes, I should fix that aspect for 2.2.0.

If here I'm not giving due weight to the pros and cons that you Peter
and you Gale have expressed, than let's dig into the issues more, so
that I understand why you give greater weight.  There are also other
things like wording and tooltips that can be tweaked without going to an
'improved drop down'.

--James.


On 6/2/2017 8:01 AM, Peter Sampson wrote:

> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]> wrote:
>
>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>> wrote:
>>> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>> wrote:
>>>> OK I have started employing an occasional "mystery shopper"
>>>> too.  He has not seen the previous iterations.
>>>>
>>>> His reaction. "Confusing at first until you look at the waves
>>>> with the boxes. 2.1.3 is much clearer which box is which.
>>>>
>>> Yes it was clear in 2.1.3 but then it was a binary choice, now it is more
>>> complex with multiple choices - hence the reason for James choosing to
>>> implement a dropdown
>> Actually, the first I heard about it was in the commits list.
>>
> Er yes, that's the way Audacity works.  James is the doer and he decides.
>
> We are then free to test and comment - but QA is not part of the pre-design
> process (unless invited to do so by the developer).
>
> We can of course block with a P1 if the developer creates a regression -
> but James
> has not created a regression here he has taken no functionality away,
> rather he has
> added to the functionality.  And having to use the dropdown with two clocks
> rather
> than a one-click radio button is no a regression.
>
>
>
>
>>
>>>> More fuss to change from end to length than before (used
>>>> to be a single click).
>>>>
>>> Yes, but now we have multiple choices, four of them.  And I for one do
>>> not want to see four radio buttons.  James tried something similar in an
>>> earlier iteration but we abandoned that as being too messy and cluttered.
>> Um, I did not see a reason posted why the two chevrons were
>> abandoned. I understood James was going to work further on
>> that to see if it was a solution.
>
> Once again at that is a case of doer-decides.  And I must say that having
> tried
> both I think it is better without the chevrons the dropdown is better by
> itself.
> The chevrons actually tended to involve more clicks I found.
>
> And I note that we do not have chevrons for all the other items in the
> Selection
> Toolbar that have dropdown menus, like say the Project Rate.
>
>
>
>> Of course the solution has to be
>> good for VI users too.
>>
> Of course, but we (and they) seem to have been working with all the other
> dropdowns (Project Rate, Snap To, time display format) all this time - so
> one
> additional dropdown seems to be consistent with our design approach for this
> toolbar
>
>
>
>>
>>>> But if you want to switch to/from the beta center feature
>>>> the dropbox seems a good way to go.
>>>
>>> We do not a pair of buttons AND a dropbox
>> I am not sure the mystery shopper was actually suggesting that,
>> but I think his point that the common navigation will be
>> between Start - End and Start - Length (the options we had
>> before) is well made.
>>
>> I suspect the hyphens would help sighted users even if we
>> stayed with the dropdown.
>>
>>
>>>   the dropbox covers all four choices and more in the future
>>> if we wanted more (James had 8 choices originally IIRC).
>>>
>>> But I do note that your mystery shopper concedes that the
>>> "dropbox seems a good way to go" at least on some level.
>>>
>>>
>>>
>>>> Is there a reason to move the unimportant Audio Position
>>>> box to left? If it was actually functional, there might be some
>>>> point, but now it seems merely in the way to me. Perhaps
>>>> it should be a separate toolbar so users could hide it?
>>>>
>>> I use the audio position box a lot
>>> a) as a data reference
>>> b) as a method of moving the audio position to a specific place
>>>
>>> My reason for moving it to the left was so that the boxes with dropdowns
>>> in the Selection Toolbar and the Spectral Selection Toolbar would be
>>> adjacent.  Purely cosmetic rather than utility.
>> I could get used to it, but it is quite a change in where to look
>> for Selection Start considering that most users won't have
>> Spectral Selection Toolbar on.
>>
> Yes indeed, but given that with this 2.2.0 release we are making many visual
> changes to the GUI, now would seem to be a good time to do this if we were
> to do it.
>
>
>
>> I agree it we retain the dropdown for Selection Toolbar that Audio
>> Position looks kind of odd - the only element in the lower tooldock
>> with no choice control.
>>
>> I think we should give some thought to what we want Audio Position
>> to do. Perhaps it can do bars or beats positions in some future
>> Audacity, and have its own dropdown or whatever navigation method?
>>
> It doesn't necessarily have to "do" anything additional, un less and until
> a new
> feature demands something of it (a bit like the increased options for the
> selection
> display encouraging James to go for his new dropdown menu).
>
> Peter.
>
>
>
>>
>>
>> Gale


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Peter Sampson-2


On Fri, Jun 2, 2017 at 10:04 AM, James Crook <[hidden email]> wrote:

Thanks both for the feedback, for pros and cons of the design. This is devolving into a who has rights to do what, and I want to undevolve that.  I'd like to bring the discussion back to discussing the design and its future.


IMO the drop down for selection now 'matches' the drop down for spectral-selection.   If the selection drop-down is not good, then I contend both are not good and both should change.  In particular if one has a hyphen, both should, if one is bad for VI users, both are, if one MUST be themed, both must.  Does that seem logical? (In terms of programming effort it is usually not that hard to use 'the same code' in different places, once that code has been worked out).

+1 

that seems eminently logical
 

I could write an 'improved drop down' that would be themed, that would have the text (hyphen) centered, that if we want it to has chevrons.  The 'improved drop-down' is probably more than I want to do for 2.2.0.  I think it's more work than is justified by the improvement at this stage.  I see room for improvement in what we have right now, but I think what we have right now is good, and is actually already a worthwhile improvement on 2.1.3 (it supports the center-length option better than any of the other solution tried, gives consistency with spectral-selection, is better for VI use than 2.1.3 was).

What you have now seems to work very well and is very clear I believe.  We might argue about hyphens versus "and" - I don't really mind either way.
A mockup may help us decide (or two different builds).

For me, more important is that we have the dropdown and that it be consistent
with the other dropdowns in the Selection Toolbar.

 

The change from radio button to choice is going to momentarily puzzle some people.  But the control is in the same place, and is of a 'familiar' kind, so I think that is fine.  I think the mystery shopper testing tends to confirm that.

Yes it will puzzle some people, but only for a little while.  And remember with release
2.2.0 we are making many changes to the GUI - so now is the time to collate all
the "puzzlement" in one go.

 

Of the various suggestions, I think splitting the audio position off as a new toolbar gives the most return for work done, but even that is probably not for 2.2.0.  If VI use is not as good as I think it now is, then yes, I should fix that aspect for 2.2.0.

I'm not sure that this would yield a good ROI - but that is up to you as a developer.

I suppose that logically the audio position indicator/setter is not really part of a
"selection" tool - except insofar as it enables you to select a new playback cursor
position - so for that reason I, personally, be minded to leave it where it is.

 

If here I'm not giving due weight to the pros and cons that you Peter and you Gale have expressed, than let's dig into the issues more, so that I understand why you give greater weight. 

No, I do think you've given due weight and I appreciate that.

 
There are also other things like wording and tooltips that can be tweaked without going to an 'improved drop down'. 


+1

Peter.
 


--James.



On 6/2/2017 8:01 AM, Peter Sampson wrote:
On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]> wrote:

On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
wrote:
On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
wrote:
OK I have started employing an occasional "mystery shopper"
too.  He has not seen the previous iterations.

His reaction. "Confusing at first until you look at the waves
with the boxes. 2.1.3 is much clearer which box is which.

Yes it was clear in 2.1.3 but then it was a binary choice, now it is more
complex with multiple choices - hence the reason for James choosing to
implement a dropdown
Actually, the first I heard about it was in the commits list.

Er yes, that's the way Audacity works.  James is the doer and he decides.

We are then free to test and comment - but QA is not part of the pre-design
process (unless invited to do so by the developer).

We can of course block with a P1 if the developer creates a regression -
but James
has not created a regression here he has taken no functionality away,
rather he has
added to the functionality.  And having to use the dropdown with two clocks
rather
than a one-click radio button is no a regression.





More fuss to change from end to length than before (used
to be a single click).

Yes, but now we have multiple choices, four of them.  And I for one do
not want to see four radio buttons.  James tried something similar in an
earlier iteration but we abandoned that as being too messy and cluttered.
Um, I did not see a reason posted why the two chevrons were
abandoned. I understood James was going to work further on
that to see if it was a solution.

Once again at that is a case of doer-decides.  And I must say that having
tried
both I think it is better without the chevrons the dropdown is better by
itself.
The chevrons actually tended to involve more clicks I found.

And I note that we do not have chevrons for all the other items in the
Selection
Toolbar that have dropdown menus, like say the Project Rate.



Of course the solution has to be
good for VI users too.

Of course, but we (and they) seem to have been working with all the other
dropdowns (Project Rate, Snap To, time display format) all this time - so
one
additional dropdown seems to be consistent with our design approach for this
toolbar




But if you want to switch to/from the beta center feature
the dropbox seems a good way to go.

We do not a pair of buttons AND a dropbox
I am not sure the mystery shopper was actually suggesting that,
but I think his point that the common navigation will be
between Start - End and Start - Length (the options we had
before) is well made.

I suspect the hyphens would help sighted users even if we
stayed with the dropdown.


  the dropbox covers all four choices and more in the future
if we wanted more (James had 8 choices originally IIRC).

But I do note that your mystery shopper concedes that the
"dropbox seems a good way to go" at least on some level.



Is there a reason to move the unimportant Audio Position
box to left? If it was actually functional, there might be some
point, but now it seems merely in the way to me. Perhaps
it should be a separate toolbar so users could hide it?

I use the audio position box a lot
a) as a data reference
b) as a method of moving the audio position to a specific place

My reason for moving it to the left was so that the boxes with dropdowns
in the Selection Toolbar and the Spectral Selection Toolbar would be
adjacent.  Purely cosmetic rather than utility.
I could get used to it, but it is quite a change in where to look
for Selection Start considering that most users won't have
Spectral Selection Toolbar on.

Yes indeed, but given that with this 2.2.0 release we are making many visual
changes to the GUI, now would seem to be a good time to do this if we were
to do it.



I agree it we retain the dropdown for Selection Toolbar that Audio
Position looks kind of odd - the only element in the lower tooldock
with no choice control.

I think we should give some thought to what we want Audio Position
to do. Perhaps it can do bars or beats positions in some future
Audacity, and have its own dropdown or whatever navigation method?

It doesn't necessarily have to "do" anything additional, un less and until
a new
feature demands something of it (a bit like the increased options for the
selection
display encouraging James to go for his new dropdown menu).

Peter.





Gale


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Robert Hänggi
It looks fine to me.
I don't mind having Audio Position in front, now that it also shows
the selection start at stop time.
I don't think that a hyphen would  be necessary (for vi users).
Symbols are always problematic. At a low punctuation level, it won't
be spoken at all or it could be read as "Start dash End", "Start minus
End", "Start hyphen End" or in German "Start Bindestrich Ende". With
fully written out labels, you're on the safe side, so thumbs up.

Combo boxes in the tool bars are potentially confusing in comparison
to those in e.g. dialogs.
For instance, Shift+i opens the input source dialog that you can
navigate with the arrow keys but also with  Home/End, first letter
navigation and Page Up/Down.
Don't try home in a combo box of a tool bar, it will remove the
selection and place the cursor at the project start.

Apart from this (general) issue, I like it a lot and it is exactly
what I had in mind when proposing a combo box.

I can't tell what box could be added to the Audio Position to improve
functionality and balance the appearance.
Bars and measures should be globally applicable to all controls.
One thing that comes to my mind is the roll-in feature that I've
mentioned elsewhere, it could be
"No Roll-in", "On Record", "On Playback" or "Both" or it could be a
combo like project rate with a default value of 0.0 seconds (and it
would only apply to record). However, I don't know if there would be
enough space for the label (.... Main Unit Roll-in).

I'm happy that James has made such a lot of successful progress. I
hope that the theming will be eventually be possible as well.

Robert

On 02/06/2017, Peter Sampson <[hidden email]> wrote:

> On Fri, Jun 2, 2017 at 10:04 AM, James Crook <[hidden email]> wrote:
>
>>
>> Thanks both for the feedback, for pros and cons of the design. This is
>> devolving into a who has rights to do what, and I want to undevolve that.
>> I'd like to bring the discussion back to discussing the design and its
>> future.
>>
>>
>> IMO the drop down for selection now 'matches' the drop down for
>> spectral-selection.   If the selection drop-down is not good, then I
>> contend both are not good and both should change.  In particular if one
>> has
>> a hyphen, both should, if one is bad for VI users, both are, if one MUST
>> be
>> themed, both must.  Does that seem logical? (In terms of programming
>> effort
>> it is usually not that hard to use 'the same code' in different places,
>> once that code has been worked out).
>>
>
> +1
>
> that seems eminently logical
>
>
>>
>> I could write an 'improved drop down' that would be themed, that would
>> have the text (hyphen) centered, that if we want it to has chevrons.  The
>> 'improved drop-down' is probably more than I want to do for 2.2.0.  I
>> think
>> it's more work than is justified by the improvement at this stage.  I see
>> room for improvement in what we have right now, but I think what we have
>> right now is good, and is actually already a worthwhile improvement on
>> 2.1.3 (it supports the center-length option better than any of the other
>> solution tried, gives consistency with spectral-selection, is better for
>> VI
>> use than 2.1.3 was).
>
>
> What you have now seems to work very well and is very clear I believe.  We
> might argue about hyphens versus "and" - I don't really mind either way.
> A mockup may help us decide (or two different builds).
>
> For me, more important is that we have the dropdown and that it be
> consistent
> with the other dropdowns in the Selection Toolbar.
>
>
>
>>
>> The change from radio button to choice is going to momentarily puzzle
>> some
>> people.  But the control is in the same place, and is of a 'familiar'
>> kind,
>> so I think that is fine.  I think the mystery shopper testing tends to
>> confirm that.
>>
>
> Yes it will puzzle some people, but only for a little while.  And remember
> with release
> 2.2.0 we are making many changes to the GUI - so now is the time to collate
> all
> the "puzzlement" in one go.
>
>
>
>>
>> Of the various suggestions, I think splitting the audio position off as a
>> new toolbar gives the most return for work done, but even that is
>> probably
>> not for 2.2.0.  If VI use is not as good as I think it now is, then yes,
>> I
>> should fix that aspect for 2.2.0.
>>
>
> I'm not sure that this would yield a good ROI - but that is up to you as a
> developer.
>
> I suppose that logically the audio position indicator/setter is not really
> part of a
> "selection" tool - except insofar as it enables you to select a new
> playback cursor
> position - so for that reason I, personally, be minded to leave it where it
> is.
>
>
>
>>
>> If here I'm not giving due weight to the pros and cons that you Peter and
>> you Gale have expressed, than let's dig into the issues more, so that I
>> understand why you give greater weight.
>
>
> No, I do think you've given due weight and I appreciate that.
>
>
>
>> There are also other things like wording and tooltips that can be tweaked
>> without going to an 'improved drop down'.
>
>
>
> +1
>
> Peter.
>
>
>>
>>
>> --James.
>>
>>
>>
>> On 6/2/2017 8:01 AM, Peter Sampson wrote:
>>
>>> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]>
>>> wrote:
>>>
>>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>>>>>
>>>> wrote:
>>>>
>>>>> OK I have started employing an occasional "mystery shopper"
>>>>>> too.  He has not seen the previous iterations.
>>>>>>
>>>>>> His reaction. "Confusing at first until you look at the waves
>>>>>> with the boxes. 2.1.3 is much clearer which box is which.
>>>>>>
>>>>>> Yes it was clear in 2.1.3 but then it was a binary choice, now it is
>>>>> more
>>>>> complex with multiple choices - hence the reason for James choosing to
>>>>> implement a dropdown
>>>>>
>>>> Actually, the first I heard about it was in the commits list.
>>>>
>>>> Er yes, that's the way Audacity works.  James is the doer and he
>>>> decides.
>>>
>>> We are then free to test and comment - but QA is not part of the
>>> pre-design
>>> process (unless invited to do so by the developer).
>>>
>>> We can of course block with a P1 if the developer creates a regression -
>>> but James
>>> has not created a regression here he has taken no functionality away,
>>> rather he has
>>> added to the functionality.  And having to use the dropdown with two
>>> clocks
>>> rather
>>> than a one-click radio button is no a regression.
>>>
>>>
>>>
>>>
>>>
>>>> More fuss to change from end to length than before (used
>>>>>> to be a single click).
>>>>>>
>>>>>> Yes, but now we have multiple choices, four of them.  And I for one
>>>>>> do
>>>>> not want to see four radio buttons.  James tried something similar in
>>>>> an
>>>>> earlier iteration but we abandoned that as being too messy and
>>>>> cluttered.
>>>>>
>>>> Um, I did not see a reason posted why the two chevrons were
>>>> abandoned. I understood James was going to work further on
>>>> that to see if it was a solution.
>>>>
>>>
>>> Once again at that is a case of doer-decides.  And I must say that
>>> having
>>> tried
>>> both I think it is better without the chevrons the dropdown is better by
>>> itself.
>>> The chevrons actually tended to involve more clicks I found.
>>>
>>> And I note that we do not have chevrons for all the other items in the
>>> Selection
>>> Toolbar that have dropdown menus, like say the Project Rate.
>>>
>>>
>>>
>>> Of course the solution has to be
>>>> good for VI users too.
>>>>
>>>> Of course, but we (and they) seem to have been working with all the
>>>> other
>>> dropdowns (Project Rate, Snap To, time display format) all this time -
>>> so
>>> one
>>> additional dropdown seems to be consistent with our design approach for
>>> this
>>> toolbar
>>>
>>>
>>>
>>>
>>>> But if you want to switch to/from the beta center feature
>>>>>> the dropbox seems a good way to go.
>>>>>>
>>>>>
>>>>> We do not a pair of buttons AND a dropbox
>>>>>
>>>> I am not sure the mystery shopper was actually suggesting that,
>>>> but I think his point that the common navigation will be
>>>> between Start - End and Start - Length (the options we had
>>>> before) is well made.
>>>>
>>>> I suspect the hyphens would help sighted users even if we
>>>> stayed with the dropdown.
>>>>
>>>>
>>>>   the dropbox covers all four choices and more in the future
>>>>> if we wanted more (James had 8 choices originally IIRC).
>>>>>
>>>>> But I do note that your mystery shopper concedes that the
>>>>> "dropbox seems a good way to go" at least on some level.
>>>>>
>>>>>
>>>>>
>>>>> Is there a reason to move the unimportant Audio Position
>>>>>> box to left? If it was actually functional, there might be some
>>>>>> point, but now it seems merely in the way to me. Perhaps
>>>>>> it should be a separate toolbar so users could hide it?
>>>>>>
>>>>>> I use the audio position box a lot
>>>>> a) as a data reference
>>>>> b) as a method of moving the audio position to a specific place
>>>>>
>>>>> My reason for moving it to the left was so that the boxes with
>>>>> dropdowns
>>>>> in the Selection Toolbar and the Spectral Selection Toolbar would be
>>>>> adjacent.  Purely cosmetic rather than utility.
>>>>>
>>>> I could get used to it, but it is quite a change in where to look
>>>> for Selection Start considering that most users won't have
>>>> Spectral Selection Toolbar on.
>>>>
>>>> Yes indeed, but given that with this 2.2.0 release we are making many
>>> visual
>>> changes to the GUI, now would seem to be a good time to do this if we
>>> were
>>> to do it.
>>>
>>>
>>>
>>> I agree it we retain the dropdown for Selection Toolbar that Audio
>>>> Position looks kind of odd - the only element in the lower tooldock
>>>> with no choice control.
>>>>
>>>> I think we should give some thought to what we want Audio Position
>>>> to do. Perhaps it can do bars or beats positions in some future
>>>> Audacity, and have its own dropdown or whatever navigation method?
>>>>
>>>> It doesn't necessarily have to "do" anything additional, un less and
>>> until
>>> a new
>>> feature demands something of it (a bit like the increased options for
>>> the
>>> selection
>>> display encouraging James to go for his new dropdown menu).
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>>
>>>> Gale
>>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Stevethefiddle
In reply to this post by James Crook
On 2 June 2017 at 09:04, James Crook <[hidden email]> wrote:

>
> Thanks both for the feedback, for pros and cons of the design. This is
> devolving into a who has rights to do what, and I want to undevolve that.
> I'd like to bring the discussion back to discussing the design and its
> future.
>
>
> IMO the drop down for selection now 'matches' the drop down for
> spectral-selection.   If the selection drop-down is not good, then I contend
> both are not good and both should change.  In particular if one has a
> hyphen, both should, if one is bad for VI users, both are, if one MUST be
> themed, both must.  Does that seem logical? (In terms of programming effort
> it is usually not that hard to use 'the same code' in different places, once
> that code has been worked out).

+1
I strongly agree with these points.

>
> I could write an 'improved drop down' that would be themed, that would have
> the text (hyphen) centered, that if we want it to has chevrons.  The
> 'improved drop-down' is probably more than I want to do for 2.2.0.  I think
> it's more work than is justified by the improvement at this stage.  I see
> room for improvement in what we have right now, but I think what we have
> right now is good, and is actually already a worthwhile improvement on 2.1.3
> (it supports the center-length option better than any of the other solution
> tried, gives consistency with spectral-selection, is better for VI use than
> 2.1.3 was).

+1
Better than 2.1.3.

>
> The change from radio button to choice is going to momentarily puzzle some
> people.  But the control is in the same place, and is of a 'familiar' kind,
> so I think that is fine.  I think the mystery shopper testing tends to
> confirm that.

"Familiar kind" sells it to me. Don't make me think
(https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think)

>
> Of the various suggestions, I think splitting the audio position off as a
> new toolbar gives the most return for work done, but even that is probably
> not for 2.2.0.  If VI use is not as good as I think it now is, then yes, I
> should fix that aspect for 2.2.0.

Many DAW applications have a feature that's sometimes called "Big Time".
What it is, is a BIG display of the current time position.
For some types of work it is invaluable.

If the audio position indicator could be split off, I would envisage
an option to display it as "Big Time".
https://i.ytimg.com/vi/GNMH_YX_tq4/maxresdefault.jpg

Steve

>
> If here I'm not giving due weight to the pros and cons that you Peter and
> you Gale have expressed, than let's dig into the issues more, so that I
> understand why you give greater weight.  There are also other things like
> wording and tooltips that can be tweaked without going to an 'improved drop
> down'.
>
> --James.
>
>
>
> On 6/2/2017 8:01 AM, Peter Sampson wrote:
>>
>> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]>
>> wrote:
>>
>>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>>> wrote:
>>>>
>>>> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>>>
>>> wrote:
>>>>>
>>>>> OK I have started employing an occasional "mystery shopper"
>>>>> too.  He has not seen the previous iterations.
>>>>>
>>>>> His reaction. "Confusing at first until you look at the waves
>>>>> with the boxes. 2.1.3 is much clearer which box is which.
>>>>>
>>>> Yes it was clear in 2.1.3 but then it was a binary choice, now it is
>>>> more
>>>> complex with multiple choices - hence the reason for James choosing to
>>>> implement a dropdown
>>>
>>> Actually, the first I heard about it was in the commits list.
>>>
>> Er yes, that's the way Audacity works.  James is the doer and he decides.
>>
>> We are then free to test and comment - but QA is not part of the
>> pre-design
>> process (unless invited to do so by the developer).
>>
>> We can of course block with a P1 if the developer creates a regression -
>> but James
>> has not created a regression here he has taken no functionality away,
>> rather he has
>> added to the functionality.  And having to use the dropdown with two
>> clocks
>> rather
>> than a one-click radio button is no a regression.
>>
>>
>>
>>
>>>
>>>>> More fuss to change from end to length than before (used
>>>>> to be a single click).
>>>>>
>>>> Yes, but now we have multiple choices, four of them.  And I for one do
>>>> not want to see four radio buttons.  James tried something similar in an
>>>> earlier iteration but we abandoned that as being too messy and
>>>> cluttered.
>>>
>>> Um, I did not see a reason posted why the two chevrons were
>>> abandoned. I understood James was going to work further on
>>> that to see if it was a solution.
>>
>>
>> Once again at that is a case of doer-decides.  And I must say that having
>> tried
>> both I think it is better without the chevrons the dropdown is better by
>> itself.
>> The chevrons actually tended to involve more clicks I found.
>>
>> And I note that we do not have chevrons for all the other items in the
>> Selection
>> Toolbar that have dropdown menus, like say the Project Rate.
>>
>>
>>
>>> Of course the solution has to be
>>> good for VI users too.
>>>
>> Of course, but we (and they) seem to have been working with all the other
>> dropdowns (Project Rate, Snap To, time display format) all this time - so
>> one
>> additional dropdown seems to be consistent with our design approach for
>> this
>> toolbar
>>
>>
>>
>>>
>>>>> But if you want to switch to/from the beta center feature
>>>>> the dropbox seems a good way to go.
>>>>
>>>>
>>>> We do not a pair of buttons AND a dropbox
>>>
>>> I am not sure the mystery shopper was actually suggesting that,
>>> but I think his point that the common navigation will be
>>> between Start - End and Start - Length (the options we had
>>> before) is well made.
>>>
>>> I suspect the hyphens would help sighted users even if we
>>> stayed with the dropdown.
>>>
>>>
>>>>   the dropbox covers all four choices and more in the future
>>>> if we wanted more (James had 8 choices originally IIRC).
>>>>
>>>> But I do note that your mystery shopper concedes that the
>>>> "dropbox seems a good way to go" at least on some level.
>>>>
>>>>
>>>>
>>>>> Is there a reason to move the unimportant Audio Position
>>>>> box to left? If it was actually functional, there might be some
>>>>> point, but now it seems merely in the way to me. Perhaps
>>>>> it should be a separate toolbar so users could hide it?
>>>>>
>>>> I use the audio position box a lot
>>>> a) as a data reference
>>>> b) as a method of moving the audio position to a specific place
>>>>
>>>> My reason for moving it to the left was so that the boxes with dropdowns
>>>> in the Selection Toolbar and the Spectral Selection Toolbar would be
>>>> adjacent.  Purely cosmetic rather than utility.
>>>
>>> I could get used to it, but it is quite a change in where to look
>>> for Selection Start considering that most users won't have
>>> Spectral Selection Toolbar on.
>>>
>> Yes indeed, but given that with this 2.2.0 release we are making many
>> visual
>> changes to the GUI, now would seem to be a good time to do this if we were
>> to do it.
>>
>>
>>
>>> I agree it we retain the dropdown for Selection Toolbar that Audio
>>> Position looks kind of odd - the only element in the lower tooldock
>>> with no choice control.
>>>
>>> I think we should give some thought to what we want Audio Position
>>> to do. Perhaps it can do bars or beats positions in some future
>>> Audacity, and have its own dropdown or whatever navigation method?
>>>
>> It doesn't necessarily have to "do" anything additional, un less and until
>> a new
>> feature demands something of it (a bit like the increased options for the
>> selection
>> display encouraging James to go for his new dropdown menu).
>>
>> Peter.
>>
>>
>>
>>>
>>>
>>> Gale
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

James Crook
On 6/2/2017 6:38 PM, Steve the Fiddle wrote:

> On 2 June 2017 at 09:04, James Crook <[hidden email]> wrote:
>> Thanks both for the feedback, for pros and cons of the design. This is
>> devolving into a who has rights to do what, and I want to undevolve that.
>> I'd like to bring the discussion back to discussing the design and its
>> future.
>>
>>
>> IMO the drop down for selection now 'matches' the drop down for
>> spectral-selection.   If the selection drop-down is not good, then I contend
>> both are not good and both should change.  In particular if one has a
>> hyphen, both should, if one is bad for VI users, both are, if one MUST be
>> themed, both must.  Does that seem logical? (In terms of programming effort
>> it is usually not that hard to use 'the same code' in different places, once
>> that code has been worked out).
> +1
> I strongly agree with these points.
>
>> I could write an 'improved drop down' that would be themed, that would have
>> the text (hyphen) centered, that if we want it to has chevrons.  The
>> 'improved drop-down' is probably more than I want to do for 2.2.0.  I think
>> it's more work than is justified by the improvement at this stage.  I see
>> room for improvement in what we have right now, but I think what we have
>> right now is good, and is actually already a worthwhile improvement on 2.1.3
>> (it supports the center-length option better than any of the other solution
>> tried, gives consistency with spectral-selection, is better for VI use than
>> 2.1.3 was).
> +1
> Better than 2.1.3.
>
>> The change from radio button to choice is going to momentarily puzzle some
>> people.  But the control is in the same place, and is of a 'familiar' kind,
>> so I think that is fine.  I think the mystery shopper testing tends to
>> confirm that.
> "Familiar kind" sells it to me. Don't make me think
> (https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think)
>
>> Of the various suggestions, I think splitting the audio position off as a
>> new toolbar gives the most return for work done, but even that is probably
>> not for 2.2.0.  If VI use is not as good as I think it now is, then yes, I
>> should fix that aspect for 2.2.0.
> Many DAW applications have a feature that's sometimes called "Big Time".
> What it is, is a BIG display of the current time position.
> For some types of work it is invaluable.
>
> If the audio position indicator could be split off, I would envisage
> an option to display it as "Big Time".
> https://i.ytimg.com/vi/GNMH_YX_tq4/maxresdefault.jpg

I am working on that for 2.2.1.  I'm planning not to make it an option.  
It will just be how that toolbar displays.  It won't be as big either -
it will just be double height - but it will still remain editable and
all formats.  Could be resizable I guess, if not docked.  Quite a bit to
work out.  Hence not 2.2.0.


>
> Steve
>
>> If here I'm not giving due weight to the pros and cons that you Peter and
>> you Gale have expressed, than let's dig into the issues more, so that I
>> understand why you give greater weight.  There are also other things like
>> wording and tooltips that can be tweaked without going to an 'improved drop
>> down'.
>>
>> --James.
>>
>>
>>
>> On 6/2/2017 8:01 AM, Peter Sampson wrote:
>>> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]>
>>> wrote:
>>>
>>>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>>>> wrote:
>>>>> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>>>> wrote:
>>>>>> OK I have started employing an occasional "mystery shopper"
>>>>>> too.  He has not seen the previous iterations.
>>>>>>
>>>>>> His reaction. "Confusing at first until you look at the waves
>>>>>> with the boxes. 2.1.3 is much clearer which box is which.
>>>>>>
>>>>> Yes it was clear in 2.1.3 but then it was a binary choice, now it is
>>>>> more
>>>>> complex with multiple choices - hence the reason for James choosing to
>>>>> implement a dropdown
>>>> Actually, the first I heard about it was in the commits list.
>>>>
>>> Er yes, that's the way Audacity works.  James is the doer and he decides.
>>>
>>> We are then free to test and comment - but QA is not part of the
>>> pre-design
>>> process (unless invited to do so by the developer).
>>>
>>> We can of course block with a P1 if the developer creates a regression -
>>> but James
>>> has not created a regression here he has taken no functionality away,
>>> rather he has
>>> added to the functionality.  And having to use the dropdown with two
>>> clocks
>>> rather
>>> than a one-click radio button is no a regression.
>>>
>>>
>>>
>>>
>>>>>> More fuss to change from end to length than before (used
>>>>>> to be a single click).
>>>>>>
>>>>> Yes, but now we have multiple choices, four of them.  And I for one do
>>>>> not want to see four radio buttons.  James tried something similar in an
>>>>> earlier iteration but we abandoned that as being too messy and
>>>>> cluttered.
>>>> Um, I did not see a reason posted why the two chevrons were
>>>> abandoned. I understood James was going to work further on
>>>> that to see if it was a solution.
>>>
>>> Once again at that is a case of doer-decides.  And I must say that having
>>> tried
>>> both I think it is better without the chevrons the dropdown is better by
>>> itself.
>>> The chevrons actually tended to involve more clicks I found.
>>>
>>> And I note that we do not have chevrons for all the other items in the
>>> Selection
>>> Toolbar that have dropdown menus, like say the Project Rate.
>>>
>>>
>>>
>>>> Of course the solution has to be
>>>> good for VI users too.
>>>>
>>> Of course, but we (and they) seem to have been working with all the other
>>> dropdowns (Project Rate, Snap To, time display format) all this time - so
>>> one
>>> additional dropdown seems to be consistent with our design approach for
>>> this
>>> toolbar
>>>
>>>
>>>
>>>>>> But if you want to switch to/from the beta center feature
>>>>>> the dropbox seems a good way to go.
>>>>>
>>>>> We do not a pair of buttons AND a dropbox
>>>> I am not sure the mystery shopper was actually suggesting that,
>>>> but I think his point that the common navigation will be
>>>> between Start - End and Start - Length (the options we had
>>>> before) is well made.
>>>>
>>>> I suspect the hyphens would help sighted users even if we
>>>> stayed with the dropdown.
>>>>
>>>>
>>>>>    the dropbox covers all four choices and more in the future
>>>>> if we wanted more (James had 8 choices originally IIRC).
>>>>>
>>>>> But I do note that your mystery shopper concedes that the
>>>>> "dropbox seems a good way to go" at least on some level.
>>>>>
>>>>>
>>>>>
>>>>>> Is there a reason to move the unimportant Audio Position
>>>>>> box to left? If it was actually functional, there might be some
>>>>>> point, but now it seems merely in the way to me. Perhaps
>>>>>> it should be a separate toolbar so users could hide it?
>>>>>>
>>>>> I use the audio position box a lot
>>>>> a) as a data reference
>>>>> b) as a method of moving the audio position to a specific place
>>>>>
>>>>> My reason for moving it to the left was so that the boxes with dropdowns
>>>>> in the Selection Toolbar and the Spectral Selection Toolbar would be
>>>>> adjacent.  Purely cosmetic rather than utility.
>>>> I could get used to it, but it is quite a change in where to look
>>>> for Selection Start considering that most users won't have
>>>> Spectral Selection Toolbar on.
>>>>
>>> Yes indeed, but given that with this 2.2.0 release we are making many
>>> visual
>>> changes to the GUI, now would seem to be a good time to do this if we were
>>> to do it.
>>>
>>>
>>>
>>>> I agree it we retain the dropdown for Selection Toolbar that Audio
>>>> Position looks kind of odd - the only element in the lower tooldock
>>>> with no choice control.
>>>>
>>>> I think we should give some thought to what we want Audio Position
>>>> to do. Perhaps it can do bars or beats positions in some future
>>>> Audacity, and have its own dropdown or whatever navigation method?
>>>>
>>> It doesn't necessarily have to "do" anything additional, un less and until
>>> a new
>>> feature demands something of it (a bit like the increased options for the
>>> selection
>>> display encouraging James to go for his new dropdown menu).
>>>
>>> Peter.
>>>
>>>
>>>
>>>>
>>>> Gale
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Gale
Administrator
In reply to this post by Peter Sampson-2
On 2 June 2017 at 08:01, Peter Sampson <[hidden email]> wrote:

>
>
> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>> wrote:
>> > On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>> > wrote:
>> >
>> >> OK I have started employing an occasional "mystery shopper"
>> >> too.  He has not seen the previous iterations.
>> >>
>> >> His reaction. "Confusing at first until you look at the waves
>> >> with the boxes. 2.1.3 is much clearer which box is which.
>> >>
>> >
>> > Yes it was clear in 2.1.3 but then it was a binary choice, now it is
>> > more
>> > complex with multiple choices - hence the reason for James choosing to
>> > implement a dropdown
>>
>> Actually, the first I heard about it was in the commits list.
>
>
> Er yes, that's the way Audacity works.  James is the doer and he decides.

There should not be a disjoint in the previous discussion, IMO.


> We are then free to test and comment - but QA is not part of the pre-design
> process (unless invited to do so by the developer).
>
> We can of course block with a P1 if the developer creates a regression - but
> James
> has not created a regression here he has taken no functionality away, rather
> he has
> added to the functionality.  And having to use the dropdown with two clocks
> rather
> than a one-click radio button is no a regression.

Some users may not see it that way if they normally only use the options
from 2.1.3.

We added two more options so we then find on balance the best way
to present them and to change them.


>> >> More fuss to change from end to length than before (used
>> >> to be a single click).
>> >>
>> >
>> > Yes, but now we have multiple choices, four of them.  And I for one do
>> > not want to see four radio buttons.  James tried something similar in an
>> > earlier iteration but we abandoned that as being too messy and
>> > cluttered.
>>
>> Um, I did not see a reason posted why the two chevrons were
>> abandoned. I understood James was going to work further on
>> that to see if it was a solution.
>
>
> Once again at that is a case of doer-decides.

I disagree if it breaks an existing discussion and leaves it hanging.

Only needs a sentence or two surely?


> And I must say that having tried both I think it is better without the
>  chevrons the dropdown is better by itself.
> The chevrons actually tended to involve more clicks I found.

We never got to see the final version of the chevrons AFAIK.
Perhaps it proved a dead end.


> And I note that we do not have chevrons for all the other items in the
> Selection
> Toolbar that have dropdown menus, like say the Project Rate.

True. But then there is a problem that these controls don't support
theming, as I understand from James.



Gale



>> Of course the solution has to be
>> good for VI users too.
>
>
> Of course, but we (and they) seem to have been working with all the other
> dropdowns (Project Rate, Snap To, time display format) all this time - so
> one
> additional dropdown seems to be consistent with our design approach for this
> toolbar
>
>
>>
>>
>>
>> >> But if you want to switch to/from the beta center feature
>> >> the dropbox seems a good way to go.
>> >
>> >
>> > We do not a pair of buttons AND a dropbox
>>
>> I am not sure the mystery shopper was actually suggesting that,
>> but I think his point that the common navigation will be
>> between Start - End and Start - Length (the options we had
>> before) is well made.
>>
>> I suspect the hyphens would help sighted users even if we
>> stayed with the dropdown.
>>
>>
>> >  the dropbox covers all four choices and more in the future
>> > if we wanted more (James had 8 choices originally IIRC).
>> >
>> > But I do note that your mystery shopper concedes that the
>> > "dropbox seems a good way to go" at least on some level.
>> >
>> >
>> >
>> >>
>> >> Is there a reason to move the unimportant Audio Position
>> >> box to left? If it was actually functional, there might be some
>> >> point, but now it seems merely in the way to me. Perhaps
>> >> it should be a separate toolbar so users could hide it?
>> >>
>> >
>> > I use the audio position box a lot
>> > a) as a data reference
>> > b) as a method of moving the audio position to a specific place
>> >
>> > My reason for moving it to the left was so that the boxes with dropdowns
>> > in the Selection Toolbar and the Spectral Selection Toolbar would be
>> > adjacent.  Purely cosmetic rather than utility.
>>
>> I could get used to it, but it is quite a change in where to look
>> for Selection Start considering that most users won't have
>> Spectral Selection Toolbar on.
>
>
> Yes indeed, but given that with this 2.2.0 release we are making many visual
> changes to the GUI, now would seem to be a good time to do this if we were
> to do it.
>
>
>>
>>
>> I agree it we retain the dropdown for Selection Toolbar that Audio
>> Position looks kind of odd - the only element in the lower tooldock
>> with no choice control.
>>
>> I think we should give some thought to what we want Audio Position
>> to do. Perhaps it can do bars or beats positions in some future
>> Audacity, and have its own dropdown or whatever navigation method?
>
>
> It doesn't necessarily have to "do" anything additional, un less and until a
> new
> feature demands something of it (a bit like the increased options for the
> selection
> display encouraging James to go for his new dropdown menu).
>
> Peter.
>
>
>>
>>
>>
>>
>> Gale
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Latest Selection Toolbar iterations

Gale
Administrator
In reply to this post by James Crook
On 2 June 2017 at 09:04, James Crook <[hidden email]> wrote:

>
> Thanks both for the feedback, for pros and cons of the design. This is
> devolving into a who has rights to do what, and I want to undevolve that.
> I'd like to bring the discussion back to discussing the design and its
> future.
>
>
> IMO the drop down for selection now 'matches' the drop down for
> spectral-selection.   If the selection drop-down is not good, then I contend
> both are not good and both should change.  In particular if one has a
> hyphen, both should, if one is bad for VI users, both are, if one MUST be
> themed, both must.  Does that seem logical?

Of course. Even I said both selection toolbars should have the same
design.


> (In terms of programming effort it is usually not that hard to use 'the same code' in different places, once
> that code has been worked out).
>
> I could write an 'improved drop down' that would be themed, that would have
> the text (hyphen) centered, that if we want it to has chevrons.  The
> 'improved drop-down' is probably more than I want to do for 2.2.0.  I think
> it's more work than is justified by the improvement at this stage.  I see
> room for improvement in what we have right now, but I think what we have
> right now is good, and is actually already a worthwhile improvement on 2.1.3
> (it supports the center-length option better than any of the other solution
> tried, gives consistency with spectral-selection, is better for VI use than
> 2.1.3 was).

James will appreciate if he asks me questions about chevrons then does
something else a few hours later, it gets kind of confusing.


> The change from radio button to choice is going to momentarily puzzle some
> people.  But the control is in the same place, and is of a 'familiar' kind,
> so I think that is fine.  I think the mystery shopper testing tends to
> confirm that.
>
> Of the various suggestions, I think splitting the audio position off as a
> new toolbar gives the most return for work done, but even that is probably
> not for 2.2.0.  If VI use is not as good as I think it now is, then yes, I
> should fix that aspect for 2.2.0.
>
> If here I'm not giving due weight to the pros and cons that you Peter and
> you Gale have expressed, than let's dig into the issues more, so that I
> understand why you give greater weight.  There are also other things like
> wording and tooltips that can be tweaked without going to an 'improved drop
> down'.

I think using hyphens would have got over most of the initial
shock for sighted users, but sadly Robert has confirmed this is
a problem for VI users. But we can use a hyphen in a tooltip,
can we not? "Selection Start - Selection Length" ? Or without
hyphens, "Boxes for Selection Start and Selection Length"
or some such. I think this would suffice for this issue.

Chevrons can be seen on Windows in any Audacity scrollbar,
so they are hardly unheard of. However if they were to be
added now or later, I would think the best (theoretical) place
could be where the hyphen between the spinboxes used to
be. I assume they would have to be Up and Down chevrons
and they would step through the dropdown. They would have
to look like self contained buttons so as not to confuse with
the spinbox content menus. I don't know about the
practicalities of this idea.

For Spectral Selection Toolbar which only has two choices,
it seems unarguable to me that a chevron would be quicker
than the dropdown for a sighted user. That toolbar does not
matter too much, but I do see potential for a problem given
the frequency you might want to change between end and
length in Selection Toolbar.


Gale





 On 6/2/2017 8:01 AM, Peter Sampson wrote:

>>
>> On Fri, Jun 2, 2017 at 3:30 AM, Gale Andrews <[hidden email]>
>> wrote:
>>
>>> On 1 June 2017 at 22:55, Peter Sampson <[hidden email]>
>>> wrote:
>>>>
>>>> On Thu, Jun 1, 2017 at 7:10 PM, Gale Andrews <[hidden email]>
>>>
>>> wrote:
>>>>>
>>>>> OK I have started employing an occasional "mystery shopper"
>>>>> too.  He has not seen the previous iterations.
>>>>>
>>>>> His reaction. "Confusing at first until you look at the waves
>>>>> with the boxes. 2.1.3 is much clearer which box is which.
>>>>>
>>>> Yes it was clear in 2.1.3 but then it was a binary choice, now it is
>>>> more
>>>> complex with multiple choices - hence the reason for James choosing to
>>>> implement a dropdown
>>>
>>> Actually, the first I heard about it was in the commits list.
>>>
>> Er yes, that's the way Audacity works.  James is the doer and he decides.
>>
>> We are then free to test and comment - but QA is not part of the
>> pre-design
>> process (unless invited to do so by the developer).
>>
>> We can of course block with a P1 if the developer creates a regression -
>> but James
>> has not created a regression here he has taken no functionality away,
>> rather he has
>> added to the functionality.  And having to use the dropdown with two
>> clocks
>> rather
>> than a one-click radio button is no a regression.
>>
>>
>>
>>
>>>
>>>>> More fuss to change from end to length than before (used
>>>>> to be a single click).
>>>>>
>>>> Yes, but now we have multiple choices, four of them.  And I for one do
>>>> not want to see four radio buttons.  James tried something similar in an
>>>> earlier iteration but we abandoned that as being too messy and
>>>> cluttered.
>>>
>>> Um, I did not see a reason posted why the two chevrons were
>>> abandoned. I understood James was going to work further on
>>> that to see if it was a solution.
>>
>>
>> Once again at that is a case of doer-decides.  And I must say that having
>> tried
>> both I think it is better without the chevrons the dropdown is better by
>> itself.
>> The chevrons actually tended to involve more clicks I found.
>>
>> And I note that we do not have chevrons for all the other items in the
>> Selection
>> Toolbar that have dropdown menus, like say the Project Rate.
>>
>>
>>
>>> Of course the solution has to be
>>> good for VI users too.
>>>
>> Of course, but we (and they) seem to have been working with all the other
>> dropdowns (Project Rate, Snap To, time display format) all this time - so
>> one
>> additional dropdown seems to be consistent with our design approach for
>> this
>> toolbar
>>
>>
>>
>>>
>>>>> But if you want to switch to/from the beta center feature
>>>>> the dropbox seems a good way to go.
>>>>
>>>>
>>>> We do not a pair of buttons AND a dropbox
>>>
>>> I am not sure the mystery shopper was actually suggesting that,
>>> but I think his point that the common navigation will be
>>> between Start - End and Start - Length (the options we had
>>> before) is well made.
>>>
>>> I suspect the hyphens would help sighted users even if we
>>> stayed with the dropdown.
>>>
>>>
>>>>   the dropbox covers all four choices and more in the future
>>>> if we wanted more (James had 8 choices originally IIRC).
>>>>
>>>> But I do note that your mystery shopper concedes that the
>>>> "dropbox seems a good way to go" at least on some level.
>>>>
>>>>
>>>>
>>>>> Is there a reason to move the unimportant Audio Position
>>>>> box to left? If it was actually functional, there might be some
>>>>> point, but now it seems merely in the way to me. Perhaps
>>>>> it should be a separate toolbar so users could hide it?
>>>>>
>>>> I use the audio position box a lot
>>>> a) as a data reference
>>>> b) as a method of moving the audio position to a specific place
>>>>
>>>> My reason for moving it to the left was so that the boxes with dropdowns
>>>> in the Selection Toolbar and the Spectral Selection Toolbar would be
>>>> adjacent.  Purely cosmetic rather than utility.
>>>
>>> I could get used to it, but it is quite a change in where to look
>>> for Selection Start considering that most users won't have
>>> Spectral Selection Toolbar on.
>>>
>> Yes indeed, but given that with this 2.2.0 release we are making many
>> visual
>> changes to the GUI, now would seem to be a good time to do this if we were
>> to do it.
>>
>>
>>
>>> I agree it we retain the dropdown for Selection Toolbar that Audio
>>> Position looks kind of odd - the only element in the lower tooldock
>>> with no choice control.
>>>
>>> I think we should give some thought to what we want Audio Position
>>> to do. Perhaps it can do bars or beats positions in some future
>>> Audacity, and have its own dropdown or whatever navigation method?
>>>
>> It doesn't necessarily have to "do" anything additional, un less and until
>> a new
>> feature demands something of it (a bit like the increased options for the
>> selection
>> display encouraging James to go for his new dropdown menu).
>>
>> Peter.
>>
>>
>>
>>>
>>>
>>> Gale
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Puzzled

Cliff Scott
Just was playing with a new build and noticed a couple of things that puzzled me.

1. In Ext-Command>Focus menu item "Toggle Focused Track" appears twice, once with ENTER as the shortcut and once without any shortcut.

2. In Preferences>Quality to the right of the default sample rate setting is a field with a grayed out "44100" with no labeling and it doesn't seem to change with anything I do. What is this supposed to indicate?

Cliff
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Puzzled

Robert Hänggi
The first point (1):
There are two entries because Enter and NumPad enter do the same, for
a laptop, you'' only have one Enter (or Return) key and that's
probably why this field is empty.
The other possibility is that NumPad Enter has not yet been added to
the James' exception list for special keys (those that have to be
labelled by their function instead of the character, itself such as
the arrow keys).

Robert

On 03/06/2017, Cliff Scott <[hidden email]> wrote:

> Just was playing with a new build and noticed a couple of things that
> puzzled me.
>
> 1. In Ext-Command>Focus menu item "Toggle Focused Track" appears twice, once
> with ENTER as the shortcut and once without any shortcut.
>
> 2. In Preferences>Quality to the right of the default sample rate setting is
> a field with a grayed out "44100" with no labeling and it doesn't seem to
> change with anything I do. What is this supposed to indicate?
>
> Cliff
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Puzzled

Cliff Scott
Interesting. I haven't used a full sized keyboard for quite a while so that wasn't in my thinking. Still looks strange, but makes some sense now anyway. In my comment when I said ENTER I really meant the symbol for ENTER/RETURN, not the word itself. The other entry has nothing at all in the shortcut column.

Cliff

> On Jun 3, 2017, at 5:13 AM, Robert Hänggi <[hidden email]> wrote:
>
> The first point (1):
> There are two entries because Enter and NumPad enter do the same, for
> a laptop, you'' only have one Enter (or Return) key and that's
> probably why this field is empty.
> The other possibility is that NumPad Enter has not yet been added to
> the James' exception list for special keys (those that have to be
> labelled by their function instead of the character, itself such as
> the arrow keys).
>
> Robert
>
> On 03/06/2017, Cliff Scott <[hidden email]> wrote:
>> Just was playing with a new build and noticed a couple of things that
>> puzzled me.
>>
>> 1. In Ext-Command>Focus menu item "Toggle Focused Track" appears twice, once
>> with ENTER as the shortcut and once without any shortcut.
>>
>> 2. In Preferences>Quality to the right of the default sample rate setting is
>> a field with a grayed out "44100" with no labeling and it doesn't seem to
>> change with anything I do. What is this supposed to indicate?
>>
>> Cliff
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Puzzled

Gale
Administrator
In reply to this post by Cliff Scott
On 3 June 2017 at 06:04, Cliff Scott <[hidden email]> wrote:
> Just was playing with a new build and noticed a couple of things that puzzled me.
>
> 1. In Ext-Command>Focus menu item "Toggle Focused Track" appears twice, once with ENTER as the shortcut and once without any shortcut.
>
> 2. In Preferences>Quality to the right of the default sample rate setting is a field with a grayed out "44100" with no labeling and it doesn't seem to change with anything I do. What is this supposed to indicate?

That box becomes enabled if you choose "Other..." from the list of
preset rates:
http://manual.audacityteam.org/man/quality_preferences.html#sampling .

When you choose one of the 13 preset rates, the box becomes grayed
out and just shows the currently selected rate. I would like to see it
become more useful and save the last entered "Other" rate in audacity.cfg.


Gale


> Cliff
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Puzzled

Cliff Scott

> On Jun 3, 2017, at 11:09 AM, Gale Andrews <[hidden email]> wrote:
>
> On 3 June 2017 at 06:04, Cliff Scott <[hidden email]> wrote:
>> Just was playing with a new build and noticed a couple of things that puzzled me.
>>
>> 1. In Ext-Command>Focus menu item "Toggle Focused Track" appears twice, once with ENTER as the shortcut and once without any shortcut.
>>
>> 2. In Preferences>Quality to the right of the default sample rate setting is a field with a grayed out "44100" with no labeling and it doesn't seem to change with anything I do. What is this supposed to indicate?
>
> That box becomes enabled if you choose "Other..." from the list of
> preset rates:
> http://manual.audacityteam.org/man/quality_preferences.html#sampling .

Opps. That was even there in 2.1.0 which is as far back as I have installed here and I just never paid attention to it before. Sorry for the unnecessary question.

Cliff

>
> When you choose one of the 13 preset rates, the box becomes grayed
> out and just shows the currently selected rate. I would like to see it
> become more useful and save the last entered "Other" rate in audacity.cfg.
>
>
> Gale
>
>
>> Cliff
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...