Re: [Audacity-devel] Tool tips for track panel make things discoverable.

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Peter Sampson-2
I added Qulaity to the distribution for this email as this really is a QA discussion
and not a pure development discussion.

On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]> wrote:


On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]> wrote:
When you hover over one of our toolbar buttons or sliders, a tooltip appears with the same text as is in the status bar.

A bit of experiment shows that it is very simple to get the same behavior in TrackPanel, for any of the several status bar messages.

Should I do it?

Should I add " (TAB for more choices)" as appropriate, if this new development is agreeable to us all, making the TAB key cycling very discoverable?

Asking forgiveness instead of permission... I just did it at fcc7bfea.  See if you like it.  Easily reverted if we don't.

Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in the message.

For consistency with our use of other keys in the app and in the Manual (e.g Ctrl and Cmd)
then the correct usage here would be "Tab"
 

I think this leaves no question about discoverability of the TAB key.  Is this enough, then, that we want to revert the changed appearance of split lines as unnecessary now?

I also added a distinction of tooltip/status bar messages when you TAB cycle between snapping and non-snapping selection.
 

Should I define new status bar and tooltip texts for the TCP buttons and sliders?  There are not yet any.

I looked at this, and there are a number of questions, to be raised in another email thread.

Yes I do think that mouseover tooltips for the TCP buttons would be useful (and consistent)
I asked you to consider doing this yesterday in a separate email.

By and large mouseover tooltips are better than Status Bar messages.  We know that many folk
(ourselves included) never, or seldom look at the Status Bar.  In contrast the moseover tooltip
appears where the user's visual attention is already focussed.

But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no harm.

 
 

Nominations for exact wording?  There are three sliders and five buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides which, there are also the MIDI channel buttons.

There is also the inverse of Minimize, the Expand.

We can work with you on wording.  Do you want us (QA) to propose the initial
wording or would you want to effect that?

I would suggest that we do that on the Wiki>Wording>Talk page
http://wiki.audacityteam.org/wiki/Talk:Wording
before committing anything to the app.

Peter.

 

For the sliders, it may be unnecessary, because they do show a tooltip when you click or drag them.  But that does leave an inconsistency with the other sliders in toolbars.  Those in the bars show a tooltip simply for hovering.  Those in TCP don't.  Making all sliders consistent may not be hard, but not quite so simple as for the other tips.  Making hover tooltips for sliders the easy way, would make duplicate tooltips in different colors when you click -- and that is undesirable.
 
PRL


PRL



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



------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Peter Sampson-2


On Fri, Jul 14, 2017 at 8:58 AM, Peter Sampson <[hidden email]> wrote:
I added Qulaity to the distribution for this email as this really is a QA discussion
and not a pure development discussion.

On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]> wrote:


On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]> wrote:
When you hover over one of our toolbar buttons or sliders, a tooltip appears with the same text as is in the status bar.

A bit of experiment shows that it is very simple to get the same behavior in TrackPanel, for any of the several status bar messages.

Should I do it?

Should I add " (TAB for more choices)" as appropriate, if this new development is agreeable to us all, making the TAB key cycling very discoverable?

Asking forgiveness instead of permission... I just did it at fcc7bfea.  See if you like it.  Easily reverted if we don't.

Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in the message.

For consistency with our use of other keys in the app and in the Manual (e.g Ctrl and Cmd)
then the correct usage here would be "Tab"
 

I think this leaves no question about discoverability of the TAB key.  Is this enough, then, that we want to revert the changed appearance of split lines as unnecessary now?

I also added a distinction of tooltip/status bar messages when you TAB cycle between snapping and non-snapping selection.
 

Should I define new status bar and tooltip texts for the TCP buttons and sliders?  There are not yet any.

I looked at this, and there are a number of questions, to be raised in another email thread.

Yes I do think that mouseover tooltips for the TCP buttons would be useful (and consistent)
I asked you to consider doing this yesterday in a separate email.

By and large mouseover tooltips are better than Status Bar messages.  We know that many folk
(ourselves included) never, or seldom look at the Status Bar.  In contrast the moseover tooltip
appears where the user's visual attention is already focussed.

But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no harm.


On thinking about this some more, we would do well to remember in terms of GUI design that
button-ids and button-descriptors are not really statuses at all - and as such they have no real
place on a Status bar. 

Statuses are things like: playing, rording, paused, reamining recording time available, remaining
disk space etc.

The buttons really should just have tooltips.

Peter


 

 
 

Nominations for exact wording?  There are three sliders and five buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides which, there are also the MIDI channel buttons.

There is also the inverse of Minimize, the Expand.

We can work with you on wording.  Do you want us (QA) to propose the initial
wording or would you want to effect that?

I would suggest that we do that on the Wiki>Wording>Talk page
http://wiki.audacityteam.org/wiki/Talk:Wording
before committing anything to the app.

Peter.

 

For the sliders, it may be unnecessary, because they do show a tooltip when you click or drag them.  But that does leave an inconsistency with the other sliders in toolbars.  Those in the bars show a tooltip simply for hovering.  Those in TCP don't.  Making all sliders consistent may not be hard, but not quite so simple as for the other tips.  Making hover tooltips for sliders the easy way, would make duplicate tooltips in different colors when you click -- and that is undesirable.
 
PRL


PRL



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




------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Stevethefiddle
On 14 July 2017 at 10:15, Peter Sampson <[hidden email]> wrote:

>
>
> On Fri, Jul 14, 2017 at 8:58 AM, Peter Sampson
> <[hidden email]> wrote:
>>
>> I added Qulaity to the distribution for this email as this really is a QA
>> discussion
>> and not a pure development discussion.
>>
>> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>>> appears with the same text as is in the status bar.
>>>>
>>>> A bit of experiment shows that it is very simple to get the same
>>>> behavior in TrackPanel, for any of the several status bar messages.
>>>>
>>>> Should I do it?
>>>>
>>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>>> development is agreeable to us all, making the TAB key cycling very
>>>> discoverable?
>>>
>>>
>>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> See if you like it.  Easily reverted if we don't.
>>>
>>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> the message.
>>
>>
>> For consistency with our use of other keys in the app and in the Manual
>> (e.g Ctrl and Cmd)
>> then the correct usage here would be "Tab"
>>
>>>
>>>
>>> I think this leaves no question about discoverability of the TAB key.  Is
>>> this enough, then, that we want to revert the changed appearance of split
>>> lines as unnecessary now?
>>>
>>> I also added a distinction of tooltip/status bar messages when you TAB
>>> cycle between snapping and non-snapping selection.
>>>
>>>
>>>>
>>>>
>>>> Should I define new status bar and tooltip texts for the TCP buttons and
>>>> sliders?  There are not yet any.
>>>
>>>
>>> I looked at this, and there are a number of questions, to be raised in
>>> another email thread.
>>
>>
>> Yes I do think that mouseover tooltips for the TCP buttons would be useful
>> (and consistent)
>> I asked you to consider doing this yesterday in a separate email.
>>
>> By and large mouseover tooltips are better than Status Bar messages.  We
>> know that many folk
>> (ourselves included) never, or seldom look at the Status Bar.  In contrast
>> the moseover tooltip
>> appears where the user's visual attention is already focussed.
>>
>> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>> harm.
>
>
>
> On thinking about this some more, we would do well to remember in terms of
> GUI design that
> button-ids and button-descriptors are not really statuses at all - and as
> such they have no real
> place on a Status bar.
>
> Statuses are things like: playing, rording, paused, reamining recording time
> available, remaining
> disk space etc.
>
> The buttons really should just have tooltips.

+1 to Peter's comments.

In terms of priority and user benefit, I think time would be better
spent fixing http://bugzilla.audacityteam.org/show_bug.cgi?id=1534

Steve

>
> Peter
>
>
>
>>
>>
>>
>>>
>>>
>>>>
>>>>
>>>> Nominations for exact wording?  There are three sliders and five
>>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides
>>>> which, there are also the MIDI channel buttons.
>>
>>
>> There is also the inverse of Minimize, the Expand.
>>
>> We can work with you on wording.  Do you want us (QA) to propose the
>> initial
>> wording or would you want to effect that?
>>
>> I would suggest that we do that on the Wiki>Wording>Talk page
>> http://wiki.audacityteam.org/wiki/Talk:Wording
>> before committing anything to the app.
>>
>> Peter.
>>
>>
>>>
>>>
>>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> when you click or drag them.  But that does leave an inconsistency with the
>>> other sliders in toolbars.  Those in the bars show a tooltip simply for
>>> hovering.  Those in TCP don't.  Making all sliders consistent may not be
>>> hard, but not quite so simple as for the other tips.  Making hover tooltips
>>> for sliders the easy way, would make duplicate tooltips in different colors
>>> when you click -- and that is undesirable.
>>>
>>> PRL
>>>
>>>>
>>>> PRL
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Paul Licameli
In reply to this post by Peter Sampson-2


On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson <[hidden email]> wrote:
I added Qulaity to the distribution for this email as this really is a QA discussion
and not a pure development discussion.

On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]> wrote:


On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]> wrote:
When you hover over one of our toolbar buttons or sliders, a tooltip appears with the same text as is in the status bar.

A bit of experiment shows that it is very simple to get the same behavior in TrackPanel, for any of the several status bar messages.

Should I do it?

Should I add " (TAB for more choices)" as appropriate, if this new development is agreeable to us all, making the TAB key cycling very discoverable?

Asking forgiveness instead of permission... I just did it at fcc7bfea.  See if you like it.  Easily reverted if we don't.

Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in the message.

For consistency with our use of other keys in the app and in the Manual (e.g Ctrl and Cmd)
then the correct usage here would be "Tab"
 

I think this leaves no question about discoverability of the TAB key.  Is this enough, then, that we want to revert the changed appearance of split lines as unnecessary now?

I also added a distinction of tooltip/status bar messages when you TAB cycle between snapping and non-snapping selection.
 

Should I define new status bar and tooltip texts for the TCP buttons and sliders?  There are not yet any.

I looked at this, and there are a number of questions, to be raised in another email thread.

Yes I do think that mouseover tooltips for the TCP buttons would be useful (and consistent)
I asked you to consider doing this yesterday in a separate email.

As mentioned in another email thread in -quality, questions arose in my mind about making complete, correct, and brief messages for each of those buttons.  Minimize, mute, and solo buttons are two-states, needing variation in the message.  The Mute and Solo further vary their behavior with the Shift modifier key, in ways difficult to summarize.  Solo's behavior also varies with interface preferences.
 

By and large mouseover tooltips are better than Status Bar messages.  We know that many folk
(ourselves included) never, or seldom look at the Status Bar.  In contrast the moseover tooltip
appears where the user's visual attention is already focussed.

But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no harm.

 
 

Nominations for exact wording?  There are three sliders and five buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides which, there are also the MIDI channel buttons.

There is also the inverse of Minimize, the Expand.

We can work with you on wording.  Do you want us (QA) to propose the initial
wording or would you want to effect that?

I would suggest that we do that on the Wiki>Wording>Talk page
http://wiki.audacityteam.org/wiki/Talk:Wording
before committing anything to the app.

Peter.

All right then.

Ignoring the question of the buttons, are there opinions about the tooltips you do get?

PRL

 

 

For the sliders, it may be unnecessary, because they do show a tooltip when you click or drag them.  But that does leave an inconsistency with the other sliders in toolbars.  Those in the bars show a tooltip simply for hovering.  Those in TCP don't.  Making all sliders consistent may not be hard, but not quite so simple as for the other tips.  Making hover tooltips for sliders the easy way, would make duplicate tooltips in different colors when you click -- and that is undesirable.
 
PRL


PRL



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



------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Peter Sampson-2
In reply to this post by Peter Sampson-2
Ok I had a spare few moments today Paul - so to save you thinkimg too much
I made an initial draft of suggestions on Wiki>Wording>Talk:
http://wiki.audacityteam.org/wiki/Talk:Wording#TCP_buttons_.26_sliders

Peter

On Fri, Jul 14, 2017 at 8:58 AM, Peter Sampson <[hidden email]> wrote:
I added Qulaity to the distribution for this email as this really is a QA discussion
and not a pure development discussion.

On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]> wrote:


On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]> wrote:
When you hover over one of our toolbar buttons or sliders, a tooltip appears with the same text as is in the status bar.

A bit of experiment shows that it is very simple to get the same behavior in TrackPanel, for any of the several status bar messages.

Should I do it?

Should I add " (TAB for more choices)" as appropriate, if this new development is agreeable to us all, making the TAB key cycling very discoverable?

Asking forgiveness instead of permission... I just did it at fcc7bfea.  See if you like it.  Easily reverted if we don't.

Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in the message.

For consistency with our use of other keys in the app and in the Manual (e.g Ctrl and Cmd)
then the correct usage here would be "Tab"
 

I think this leaves no question about discoverability of the TAB key.  Is this enough, then, that we want to revert the changed appearance of split lines as unnecessary now?

I also added a distinction of tooltip/status bar messages when you TAB cycle between snapping and non-snapping selection.
 

Should I define new status bar and tooltip texts for the TCP buttons and sliders?  There are not yet any.

I looked at this, and there are a number of questions, to be raised in another email thread.

Yes I do think that mouseover tooltips for the TCP buttons would be useful (and consistent)
I asked you to consider doing this yesterday in a separate email.

By and large mouseover tooltips are better than Status Bar messages.  We know that many folk
(ourselves included) never, or seldom look at the Status Bar.  In contrast the moseover tooltip
appears where the user's visual attention is already focussed.

But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no harm.

 
 

Nominations for exact wording?  There are three sliders and five buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides which, there are also the MIDI channel buttons.

There is also the inverse of Minimize, the Expand.

We can work with you on wording.  Do you want us (QA) to propose the initial
wording or would you want to effect that?

I would suggest that we do that on the Wiki>Wording>Talk page
http://wiki.audacityteam.org/wiki/Talk:Wording
before committing anything to the app.

Peter.

 

For the sliders, it may be unnecessary, because they do show a tooltip when you click or drag them.  But that does leave an inconsistency with the other sliders in toolbars.  Those in the bars show a tooltip simply for hovering.  Those in TCP don't.  Making all sliders consistent may not be hard, but not quite so simple as for the other tips.  Making hover tooltips for sliders the easy way, would make duplicate tooltips in different colors when you click -- and that is undesirable.
 
PRL


PRL



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




------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Gale
Administrator
In reply to this post by Paul Licameli
On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:

>
>
> On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
> <[hidden email]> wrote:
>>
>> I added Qulaity to the distribution for this email as this really is a QA
>> discussion
>> and not a pure development discussion.
>>
>> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>>> appears with the same text as is in the status bar.
>>>>
>>>> A bit of experiment shows that it is very simple to get the same
>>>> behavior in TrackPanel, for any of the several status bar messages.
>>>>
>>>> Should I do it?
>>>>
>>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>>> development is agreeable to us all, making the TAB key cycling very
>>>> discoverable?
>>>
>>>
>>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> See if you like it.  Easily reverted if we don't.
>>>
>>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> the message.
>>
>>
>> For consistency with our use of other keys in the app and in the Manual
>> (e.g Ctrl and Cmd)
>> then the correct usage here would be "Tab"
>>
>>>
>>>
>>> I think this leaves no question about discoverability of the TAB key.  Is
>>> this enough, then, that we want to revert the changed appearance of split
>>> lines as unnecessary now?
>>>
>>> I also added a distinction of tooltip/status bar messages when you TAB
>>> cycle between snapping and non-snapping selection.
>>>
>>>
>>>>
>>>>
>>>> Should I define new status bar and tooltip texts for the TCP buttons and
>>>> sliders?  There are not yet any.
>>>
>>>
>>> I looked at this, and there are a number of questions, to be raised in
>>> another email thread.
>>
>>
>> Yes I do think that mouseover tooltips for the TCP buttons would be useful
>> (and consistent)
>> I asked you to consider doing this yesterday in a separate email.
>
>
> As mentioned in another email thread in -quality, questions arose in my mind
> about making complete, correct, and brief messages for each of those
> buttons.  Minimize, mute, and solo buttons are two-states, needing variation
> in the message.  The Mute and Solo further vary their behavior with the
> Shift modifier key, in ways difficult to summarize.  Solo's behavior also
> varies with interface preferences.

I personally agree it is legitimate to have Status Bar messages give
terse help with what will happen with modified clicks and to flag up any
differences on what will happen when the mouse is at a slightly
different position e.g. when the split line is in the centre of the
waveform (if that feature is really the least bad way of handling
Bug 800).

To take the view that Status Bar messages should be "statuses
only" seems to mean e.g. removing the Edit Toolbar and Tools
Toolbar messages. I doubt we want to do that. I don't think
completing Status Bar messages and button tooltipping/
highlighting is necessarily something that necessarily needs to
be done for 2.2.0 but this is Paul's decision.

I agree the Tooltips have greater importance but it is possible
user has selected audio according to the Status Bar, could
click the scissors icon and still be looking at the Status Bar to
see if he got the correct tool.


Gale





>> By and large mouseover tooltips are better than Status Bar messages.  We
>> know that many folk
>> (ourselves included) never, or seldom look at the Status Bar.  In contrast
>> the moseover tooltip
>> appears where the user's visual attention is already focussed.
>>
>> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>> harm.
>>
>>
>>>
>>>
>>>>
>>>>
>>>> Nominations for exact wording?  There are three sliders and five
>>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides
>>>> which, there are also the MIDI channel buttons.
>>
>>
>> There is also the inverse of Minimize, the Expand.
>>
>> We can work with you on wording.  Do you want us (QA) to propose the
>> initial
>> wording or would you want to effect that?
>>
>> I would suggest that we do that on the Wiki>Wording>Talk page
>> http://wiki.audacityteam.org/wiki/Talk:Wording
>> before committing anything to the app.
>>
>> Peter.
>
>
> All right then.
>
> Ignoring the question of the buttons, are there opinions about the tooltips
> you do get?
>
> PRL
>
>
>>
>>
>>
>>>
>>>
>>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> when you click or drag them.  But that does leave an inconsistency with the
>>> other sliders in toolbars.  Those in the bars show a tooltip simply for
>>> hovering.  Those in TCP don't.  Making all sliders consistent may not be
>>> hard, but not quite so simple as for the other tips.  Making hover tooltips
>>> for sliders the easy way, would make duplicate tooltips in different colors
>>> when you click -- and that is undesirable.
>>>
>>> PRL
>>>
>>>>
>>>> PRL
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Paul Licameli


On Fri, Jul 14, 2017 at 1:24 PM, Gale Andrews <[hidden email]> wrote:
On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:
>
>
> On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
> <[hidden email]> wrote:
>>
>> I added Qulaity to the distribution for this email as this really is a QA
>> discussion
>> and not a pure development discussion.
>>
>> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>>> appears with the same text as is in the status bar.
>>>>
>>>> A bit of experiment shows that it is very simple to get the same
>>>> behavior in TrackPanel, for any of the several status bar messages.
>>>>
>>>> Should I do it?
>>>>
>>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>>> development is agreeable to us all, making the TAB key cycling very
>>>> discoverable?
>>>
>>>
>>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> See if you like it.  Easily reverted if we don't.
>>>
>>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> the message.
>>
>>
>> For consistency with our use of other keys in the app and in the Manual
>> (e.g Ctrl and Cmd)
>> then the correct usage here would be "Tab"
>>
>>>
>>>
>>> I think this leaves no question about discoverability of the TAB key.  Is
>>> this enough, then, that we want to revert the changed appearance of split
>>> lines as unnecessary now?
>>>
>>> I also added a distinction of tooltip/status bar messages when you TAB
>>> cycle between snapping and non-snapping selection.
>>>
>>>
>>>>
>>>>
>>>> Should I define new status bar and tooltip texts for the TCP buttons and
>>>> sliders?  There are not yet any.
>>>
>>>
>>> I looked at this, and there are a number of questions, to be raised in
>>> another email thread.
>>
>>
>> Yes I do think that mouseover tooltips for the TCP buttons would be useful
>> (and consistent)
>> I asked you to consider doing this yesterday in a separate email.
>
>
> As mentioned in another email thread in -quality, questions arose in my mind
> about making complete, correct, and brief messages for each of those
> buttons.  Minimize, mute, and solo buttons are two-states, needing variation
> in the message.  The Mute and Solo further vary their behavior with the
> Shift modifier key, in ways difficult to summarize.  Solo's behavior also
> varies with interface preferences.

I personally agree it is legitimate to have Status Bar messages give
terse help with what will happen with modified clicks

Not sure I understand.  You do like status mentioning Shift-, etc.?  Or you would agree to statuses that do not mention the modifiers, but change as different modifiers are pressed?
 
and to flag up any
differences on what will happen when the mouse is at a slightly
different position e.g. when the split line is in the centre of the
waveform (if that feature is really the least bad way of handling
Bug 800).

"Flag up" means what?  Surely you do not mean a status should describe what might happen if the pointer is somewhere else than where it is now?

I think the message should be appropriate just to where the pointer is now.
 

To take the view that Status Bar messages should be "statuses
only" seems to mean e.g. removing the Edit Toolbar and Tools
Toolbar messages.  I doubt we want to do that.
 

Who suggests this?  I did not.  Status messages now duplicate the tooltips for toolbar buttons.  That is good enough.  I say ALSO duplicate MORE of the existing status messages in tooltips.  But if so, it would be good to make some of them more concise.

PRL



I don't think
completing Status Bar messages and button tooltipping/
highlighting is necessarily something that necessarily needs to
be done for 2.2.0 but this is Paul's decision.


 

I agree the Tooltips have greater importance but it is possible
user has selected audio according to the Status Bar, could
click the scissors icon and still be looking at the Status Bar to
see if he got the correct tool.


Gale





>> By and large mouseover tooltips are better than Status Bar messages.  We
>> know that many folk
>> (ourselves included) never, or seldom look at the Status Bar.  In contrast
>> the moseover tooltip
>> appears where the user's visual attention is already focussed.
>>
>> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>> harm.
>>
>>
>>>
>>>
>>>>
>>>>
>>>> Nominations for exact wording?  There are three sliders and five
>>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.  Besides
>>>> which, there are also the MIDI channel buttons.
>>
>>
>> There is also the inverse of Minimize, the Expand.
>>
>> We can work with you on wording.  Do you want us (QA) to propose the
>> initial
>> wording or would you want to effect that?
>>
>> I would suggest that we do that on the Wiki>Wording>Talk page
>> http://wiki.audacityteam.org/wiki/Talk:Wording
>> before committing anything to the app.
>>
>> Peter.
>
>
> All right then.
>
> Ignoring the question of the buttons, are there opinions about the tooltips
> you do get?
>
> PRL
>
>
>>
>>
>>
>>>
>>>
>>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> when you click or drag them.  But that does leave an inconsistency with the
>>> other sliders in toolbars.  Those in the bars show a tooltip simply for
>>> hovering.  Those in TCP don't.  Making all sliders consistent may not be
>>> hard, but not quite so simple as for the other tips.  Making hover tooltips
>>> for sliders the easy way, would make duplicate tooltips in different colors
>>> when you click -- and that is undesirable.
>>>
>>> PRL
>>>
>>>>
>>>> PRL
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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


------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Gale
Administrator
On 14 July 2017 at 18:51, Paul Licameli <[hidden email]> wrote:

>
>
> On Fri, Jul 14, 2017 at 1:24 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
>> > <[hidden email]> wrote:
>> >>
>> >> I added Qulaity to the distribution for this email as this really is a
>> >> QA
>> >> discussion
>> >> and not a pure development discussion.
>> >>
>> >> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>> >>>> appears with the same text as is in the status bar.
>> >>>>
>> >>>> A bit of experiment shows that it is very simple to get the same
>> >>>> behavior in TrackPanel, for any of the several status bar messages.
>> >>>>
>> >>>> Should I do it?
>> >>>>
>> >>>> Should I add " (TAB for more choices)" as appropriate, if this new
>> >>>> development is agreeable to us all, making the TAB key cycling very
>> >>>> discoverable?
>> >>>
>> >>>
>> >>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>> >>> See if you like it.  Easily reverted if we don't.
>> >>>
>> >>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>> >>> the message.
>> >>
>> >>
>> >> For consistency with our use of other keys in the app and in the Manual
>> >> (e.g Ctrl and Cmd)
>> >> then the correct usage here would be "Tab"
>> >>
>> >>>
>> >>>
>> >>> I think this leaves no question about discoverability of the TAB key.
>> >>> Is
>> >>> this enough, then, that we want to revert the changed appearance of
>> >>> split
>> >>> lines as unnecessary now?
>> >>>
>> >>> I also added a distinction of tooltip/status bar messages when you TAB
>> >>> cycle between snapping and non-snapping selection.
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> Should I define new status bar and tooltip texts for the TCP buttons
>> >>>> and
>> >>>> sliders?  There are not yet any.
>> >>>
>> >>>
>> >>> I looked at this, and there are a number of questions, to be raised in
>> >>> another email thread.
>> >>
>> >>
>> >> Yes I do think that mouseover tooltips for the TCP buttons would be
>> >> useful
>> >> (and consistent)
>> >> I asked you to consider doing this yesterday in a separate email.
>> >
>> >
>> > As mentioned in another email thread in -quality, questions arose in my
>> > mind
>> > about making complete, correct, and brief messages for each of those
>> > buttons.  Minimize, mute, and solo buttons are two-states, needing
>> > variation
>> > in the message.  The Mute and Solo further vary their behavior with the
>> > Shift modifier key, in ways difficult to summarize.  Solo's behavior
>> > also
>> > varies with interface preferences.
>>
>> I personally agree it is legitimate to have Status Bar messages give
>> terse help with what will happen with modified clicks
>
>
> Not sure I understand.  You do like status mentioning Shift-, etc.?

See "Ctrl-Click to select or deselect track." when hovering a dead part
of the Track Control Panel.


> Or you would agree to statuses that do not mention the modifiers,
> but change as different modifiers are pressed?

Better to mention if possible.

>> and to flag up any
>> differences on what will happen when the mouse is at a slightly
>> different position e.g. when the split line is in the centre of the
>> waveform (if that feature is really the least bad way of handling
>> Bug 800).
>
>
> "Flag up" means what?  Surely you do not mean a status should describe what
> might happen if the pointer is somewhere else than where it is now?

Fortunately no need for that hack now.


> I think the message should be appropriate just to where the pointer is now.
>
>>
>>
>> To take the view that Status Bar messages should be "statuses
>> only" seems to mean e.g. removing the Edit Toolbar and Tools
>> Toolbar messages.  I doubt we want to do that.
>
>
>
> Who suggests this?

Peter and Steve suggested messages are statuses only as I read it.

I do not agree.


> I did not.  Status messages now duplicate the tooltips
> for toolbar buttons.  That is good enough.  I say ALSO duplicate MORE of the
> existing status messages in tooltips.  But if so, it would be good to make
> some of them more concise.
>
> PRL
>
>
>>
>> I don't think
>> completing Status Bar messages and button tooltipping/
>> highlighting is necessarily something that necessarily needs to
>> be done for 2.2.0 but this is Paul's decision.
>
>
>
>
>>
>>
>> I agree the Tooltips have greater importance but it is possible
>> user has selected audio according to the Status Bar, could
>> click the scissors icon and still be looking at the Status Bar to
>> see if he got the correct tool.
>>
>>
>> Gale
>>
>>
>>
>>
>>
>> >> By and large mouseover tooltips are better than Status Bar messages.
>> >> We
>> >> know that many folk
>> >> (ourselves included) never, or seldom look at the Status Bar.  In
>> >> contrast
>> >> the moseover tooltip
>> >> appears where the user's visual attention is already focussed.
>> >>
>> >> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>> >> harm.
>> >>
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> Nominations for exact wording?  There are three sliders and five
>> >>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.
>> >>>> Besides
>> >>>> which, there are also the MIDI channel buttons.
>> >>
>> >>
>> >> There is also the inverse of Minimize, the Expand.
>> >>
>> >> We can work with you on wording.  Do you want us (QA) to propose the
>> >> initial
>> >> wording or would you want to effect that?
>> >>
>> >> I would suggest that we do that on the Wiki>Wording>Talk page
>> >> http://wiki.audacityteam.org/wiki/Talk:Wording
>> >> before committing anything to the app.
>> >>
>> >> Peter.
>> >
>> >
>> > All right then.
>> >
>> > Ignoring the question of the buttons, are there opinions about the
>> > tooltips
>> > you do get?
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> For the sliders, it may be unnecessary, because they do show a tooltip
>> >>> when you click or drag them.  But that does leave an inconsistency
>> >>> with the
>> >>> other sliders in toolbars.  Those in the bars show a tooltip simply
>> >>> for
>> >>> hovering.  Those in TCP don't.  Making all sliders consistent may not
>> >>> be
>> >>> hard, but not quite so simple as for the other tips.  Making hover
>> >>> tooltips
>> >>> for sliders the easy way, would make duplicate tooltips in different
>> >>> colors
>> >>> when you click -- and that is undesirable.
>> >>>
>> >>> PRL
>> >>>
>> >>>>
>> >>>> PRL
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> audacity-devel mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Stevethefiddle
On 15 July 2017 at 16:19, Gale Andrews <[hidden email]> wrote:

> On 14 July 2017 at 18:51, Paul Licameli <[hidden email]> wrote:
>>
>>
>> On Fri, Jul 14, 2017 at 1:24 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:
>>> >
>>> >
>>> > On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
>>> > <[hidden email]> wrote:
>>> >>
>>> >> I added Qulaity to the distribution for this email as this really is a
>>> >> QA
>>> >> discussion
>>> >> and not a pure development discussion.
>>> >>
>>> >> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>> >>>> appears with the same text as is in the status bar.
>>> >>>>
>>> >>>> A bit of experiment shows that it is very simple to get the same
>>> >>>> behavior in TrackPanel, for any of the several status bar messages.
>>> >>>>
>>> >>>> Should I do it?
>>> >>>>
>>> >>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>> >>>> development is agreeable to us all, making the TAB key cycling very
>>> >>>> discoverable?
>>> >>>
>>> >>>
>>> >>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> >>> See if you like it.  Easily reverted if we don't.
>>> >>>
>>> >>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> >>> the message.
>>> >>
>>> >>
>>> >> For consistency with our use of other keys in the app and in the Manual
>>> >> (e.g Ctrl and Cmd)
>>> >> then the correct usage here would be "Tab"
>>> >>
>>> >>>
>>> >>>
>>> >>> I think this leaves no question about discoverability of the TAB key.
>>> >>> Is
>>> >>> this enough, then, that we want to revert the changed appearance of
>>> >>> split
>>> >>> lines as unnecessary now?
>>> >>>
>>> >>> I also added a distinction of tooltip/status bar messages when you TAB
>>> >>> cycle between snapping and non-snapping selection.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Should I define new status bar and tooltip texts for the TCP buttons
>>> >>>> and
>>> >>>> sliders?  There are not yet any.
>>> >>>
>>> >>>
>>> >>> I looked at this, and there are a number of questions, to be raised in
>>> >>> another email thread.
>>> >>
>>> >>
>>> >> Yes I do think that mouseover tooltips for the TCP buttons would be
>>> >> useful
>>> >> (and consistent)
>>> >> I asked you to consider doing this yesterday in a separate email.
>>> >
>>> >
>>> > As mentioned in another email thread in -quality, questions arose in my
>>> > mind
>>> > about making complete, correct, and brief messages for each of those
>>> > buttons.  Minimize, mute, and solo buttons are two-states, needing
>>> > variation
>>> > in the message.  The Mute and Solo further vary their behavior with the
>>> > Shift modifier key, in ways difficult to summarize.  Solo's behavior
>>> > also
>>> > varies with interface preferences.
>>>
>>> I personally agree it is legitimate to have Status Bar messages give
>>> terse help with what will happen with modified clicks
>>
>>
>> Not sure I understand.  You do like status mentioning Shift-, etc.?
>
> See "Ctrl-Click to select or deselect track." when hovering a dead part
> of the Track Control Panel.
>
>
>> Or you would agree to statuses that do not mention the modifiers,
>> but change as different modifiers are pressed?
>
> Better to mention if possible.
>
>>> and to flag up any
>>> differences on what will happen when the mouse is at a slightly
>>> different position e.g. when the split line is in the centre of the
>>> waveform (if that feature is really the least bad way of handling
>>> Bug 800).
>>
>>
>> "Flag up" means what?  Surely you do not mean a status should describe what
>> might happen if the pointer is somewhere else than where it is now?
>
> Fortunately no need for that hack now.
>
>
>> I think the message should be appropriate just to where the pointer is now.
>>
>>>
>>>
>>> To take the view that Status Bar messages should be "statuses
>>> only" seems to mean e.g. removing the Edit Toolbar and Tools
>>> Toolbar messages.  I doubt we want to do that.
>>
>>
>>
>> Who suggests this?
>
> Peter and Steve suggested messages are statuses only as I read it.

I don't recall commenting on this, though I think it is normal
practice for status bar messages to indicate statuses and for tool
tips to give tips about tools.

Steve

>
> I do not agree.
>
>
>> I did not.  Status messages now duplicate the tooltips
>> for toolbar buttons.  That is good enough.  I say ALSO duplicate MORE of the
>> existing status messages in tooltips.  But if so, it would be good to make
>> some of them more concise.
>>
>> PRL
>>
>>
>>>
>>> I don't think
>>> completing Status Bar messages and button tooltipping/
>>> highlighting is necessarily something that necessarily needs to
>>> be done for 2.2.0 but this is Paul's decision.
>>
>>
>>
>>
>>>
>>>
>>> I agree the Tooltips have greater importance but it is possible
>>> user has selected audio according to the Status Bar, could
>>> click the scissors icon and still be looking at the Status Bar to
>>> see if he got the correct tool.
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>>
>>>
>>> >> By and large mouseover tooltips are better than Status Bar messages.
>>> >> We
>>> >> know that many folk
>>> >> (ourselves included) never, or seldom look at the Status Bar.  In
>>> >> contrast
>>> >> the moseover tooltip
>>> >> appears where the user's visual attention is already focussed.
>>> >>
>>> >> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>>> >> harm.
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Nominations for exact wording?  There are three sliders and five
>>> >>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.
>>> >>>> Besides
>>> >>>> which, there are also the MIDI channel buttons.
>>> >>
>>> >>
>>> >> There is also the inverse of Minimize, the Expand.
>>> >>
>>> >> We can work with you on wording.  Do you want us (QA) to propose the
>>> >> initial
>>> >> wording or would you want to effect that?
>>> >>
>>> >> I would suggest that we do that on the Wiki>Wording>Talk page
>>> >> http://wiki.audacityteam.org/wiki/Talk:Wording
>>> >> before committing anything to the app.
>>> >>
>>> >> Peter.
>>> >
>>> >
>>> > All right then.
>>> >
>>> > Ignoring the question of the buttons, are there opinions about the
>>> > tooltips
>>> > you do get?
>>> >
>>> > PRL
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> >>> when you click or drag them.  But that does leave an inconsistency
>>> >>> with the
>>> >>> other sliders in toolbars.  Those in the bars show a tooltip simply
>>> >>> for
>>> >>> hovering.  Those in TCP don't.  Making all sliders consistent may not
>>> >>> be
>>> >>> hard, but not quite so simple as for the other tips.  Making hover
>>> >>> tooltips
>>> >>> for sliders the easy way, would make duplicate tooltips in different
>>> >>> colors
>>> >>> when you click -- and that is undesirable.
>>> >>>
>>> >>> PRL
>>> >>>
>>> >>>>
>>> >>>> PRL
>>> >>>>

------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Paul Licameli


On Sat, Jul 15, 2017 at 11:31 AM, Steve the Fiddle <[hidden email]> wrote:
On 15 July 2017 at 16:19, Gale Andrews <[hidden email]> wrote:
> On 14 July 2017 at 18:51, Paul Licameli <[hidden email]> wrote:
>>
>>
>> On Fri, Jul 14, 2017 at 1:24 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:
>>> >
>>> >
>>> > On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
>>> > <[hidden email]> wrote:
>>> >>
>>> >> I added Qulaity to the distribution for this email as this really is a
>>> >> QA
>>> >> discussion
>>> >> and not a pure development discussion.
>>> >>
>>> >> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>> >>>> appears with the same text as is in the status bar.
>>> >>>>
>>> >>>> A bit of experiment shows that it is very simple to get the same
>>> >>>> behavior in TrackPanel, for any of the several status bar messages.
>>> >>>>
>>> >>>> Should I do it?
>>> >>>>
>>> >>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>> >>>> development is agreeable to us all, making the TAB key cycling very
>>> >>>> discoverable?
>>> >>>
>>> >>>
>>> >>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> >>> See if you like it.  Easily reverted if we don't.
>>> >>>
>>> >>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> >>> the message.
>>> >>
>>> >>
>>> >> For consistency with our use of other keys in the app and in the Manual
>>> >> (e.g Ctrl and Cmd)
>>> >> then the correct usage here would be "Tab"
>>> >>
>>> >>>
>>> >>>
>>> >>> I think this leaves no question about discoverability of the TAB key.
>>> >>> Is
>>> >>> this enough, then, that we want to revert the changed appearance of
>>> >>> split
>>> >>> lines as unnecessary now?
>>> >>>
>>> >>> I also added a distinction of tooltip/status bar messages when you TAB
>>> >>> cycle between snapping and non-snapping selection.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Should I define new status bar and tooltip texts for the TCP buttons
>>> >>>> and
>>> >>>> sliders?  There are not yet any.
>>> >>>
>>> >>>
>>> >>> I looked at this, and there are a number of questions, to be raised in
>>> >>> another email thread.
>>> >>
>>> >>
>>> >> Yes I do think that mouseover tooltips for the TCP buttons would be
>>> >> useful
>>> >> (and consistent)
>>> >> I asked you to consider doing this yesterday in a separate email.
>>> >
>>> >
>>> > As mentioned in another email thread in -quality, questions arose in my
>>> > mind
>>> > about making complete, correct, and brief messages for each of those
>>> > buttons.  Minimize, mute, and solo buttons are two-states, needing
>>> > variation
>>> > in the message.  The Mute and Solo further vary their behavior with the
>>> > Shift modifier key, in ways difficult to summarize.  Solo's behavior
>>> > also
>>> > varies with interface preferences.
>>>
>>> I personally agree it is legitimate to have Status Bar messages give
>>> terse help with what will happen with modified clicks
>>
>>
>> Not sure I understand.  You do like status mentioning Shift-, etc.?
>
> See "Ctrl-Click to select or deselect track." when hovering a dead part
> of the Track Control Panel.
>
>
>> Or you would agree to statuses that do not mention the modifiers,
>> but change as different modifiers are pressed?
>
> Better to mention if possible.
>
>>> and to flag up any
>>> differences on what will happen when the mouse is at a slightly
>>> different position e.g. when the split line is in the centre of the
>>> waveform (if that feature is really the least bad way of handling
>>> Bug 800).
>>
>>
>> "Flag up" means what?  Surely you do not mean a status should describe what
>> might happen if the pointer is somewhere else than where it is now?
>
> Fortunately no need for that hack now.
>
>
>> I think the message should be appropriate just to where the pointer is now.
>>
>>>
>>>
>>> To take the view that Status Bar messages should be "statuses
>>> only" seems to mean e.g. removing the Edit Toolbar and Tools
>>> Toolbar messages.  I doubt we want to do that.
>>
>>
>>
>> Who suggests this?
>
> Peter and Steve suggested messages are statuses only as I read it.

I don't recall commenting on this, though I think it is normal
practice for status bar messages to indicate statuses and for tool
tips to give tips about tools.

This clarifies nothing to me.

The precedent that exists in Audacity is that when you hover on a tooltip button, the status message and the tooltip are identical, briefly describing the command and the shortcut key.  Likewise sliders.  Hovering on the meters gives a short status though no tooltip.

Should something like it be done in TrackPanel?  Minimally, the five buttons in the controls might follow the same convention.

PRL
 

Steve

>
> I do not agree.
>
>
>> I did not.  Status messages now duplicate the tooltips
>> for toolbar buttons.  That is good enough.  I say ALSO duplicate MORE of the
>> existing status messages in tooltips.  But if so, it would be good to make
>> some of them more concise.
>>
>> PRL
>>
>>
>>>
>>> I don't think
>>> completing Status Bar messages and button tooltipping/
>>> highlighting is necessarily something that necessarily needs to
>>> be done for 2.2.0 but this is Paul's decision.
>>
>>
>>
>>
>>>
>>>
>>> I agree the Tooltips have greater importance but it is possible
>>> user has selected audio according to the Status Bar, could
>>> click the scissors icon and still be looking at the Status Bar to
>>> see if he got the correct tool.
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>>
>>>
>>> >> By and large mouseover tooltips are better than Status Bar messages.
>>> >> We
>>> >> know that many folk
>>> >> (ourselves included) never, or seldom look at the Status Bar.  In
>>> >> contrast
>>> >> the moseover tooltip
>>> >> appears where the user's visual attention is already focussed.
>>> >>
>>> >> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>>> >> harm.
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Nominations for exact wording?  There are three sliders and five
>>> >>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.
>>> >>>> Besides
>>> >>>> which, there are also the MIDI channel buttons.
>>> >>
>>> >>
>>> >> There is also the inverse of Minimize, the Expand.
>>> >>
>>> >> We can work with you on wording.  Do you want us (QA) to propose the
>>> >> initial
>>> >> wording or would you want to effect that?
>>> >>
>>> >> I would suggest that we do that on the Wiki>Wording>Talk page
>>> >> http://wiki.audacityteam.org/wiki/Talk:Wording
>>> >> before committing anything to the app.
>>> >>
>>> >> Peter.
>>> >
>>> >
>>> > All right then.
>>> >
>>> > Ignoring the question of the buttons, are there opinions about the
>>> > tooltips
>>> > you do get?
>>> >
>>> > PRL
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> >>> when you click or drag them.  But that does leave an inconsistency
>>> >>> with the
>>> >>> other sliders in toolbars.  Those in the bars show a tooltip simply
>>> >>> for
>>> >>> hovering.  Those in TCP don't.  Making all sliders consistent may not
>>> >>> be
>>> >>> hard, but not quite so simple as for the other tips.  Making hover
>>> >>> tooltips
>>> >>> for sliders the easy way, would make duplicate tooltips in different
>>> >>> colors
>>> >>> when you click -- and that is undesirable.
>>> >>>
>>> >>> PRL
>>> >>>
>>> >>>>
>>> >>>> PRL
>>> >>>>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________


------------------------------------------------------------------------------
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
|

Re: [Audacity-devel] Tool tips for track panel make things discoverable.

Peter Sampson-2
I'm more than somewhat of a purist in this respect and agree with Steve
(and disagree with Gale).

Tooltips are (should be) for tools an Status Bar messages should be
for statuses.

When the user is attempting to use a tool they really don't want to be shifting
their visual attention away from their focus on the Status Bar stuck away sown
at the bottom.

In contrast while recording is active it is useful tp be able to observe the recoring
time remaining displayed there - and useful to see there if Playback is Stopped
or Paused.  Or indeed useful to ascertain if you are in Scrubbing mode.

The other problem with duplicating tooltips in the Status bar is that it makes for
more development and maintenanve (which could be avoided - a good thing).

Just my 2c worth ...

Peter.

On Sat, Jul 15, 2017 at 4:49 PM, Paul Licameli <[hidden email]> wrote:


On Sat, Jul 15, 2017 at 11:31 AM, Steve the Fiddle <[hidden email]> wrote:
On 15 July 2017 at 16:19, Gale Andrews <[hidden email]> wrote:
> On 14 July 2017 at 18:51, Paul Licameli <[hidden email]> wrote:
>>
>>
>> On Fri, Jul 14, 2017 at 1:24 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 14 July 2017 at 13:15, Paul Licameli <[hidden email]> wrote:
>>> >
>>> >
>>> > On Fri, Jul 14, 2017 at 3:58 AM, Peter Sampson
>>> > <[hidden email]> wrote:
>>> >>
>>> >> I added Qulaity to the distribution for this email as this really is a
>>> >> QA
>>> >> discussion
>>> >> and not a pure development discussion.
>>> >>
>>> >> On Fri, Jul 14, 2017 at 3:51 AM, Paul Licameli
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Jul 13, 2017 at 8:06 PM, Paul Licameli
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> When you hover over one of our toolbar buttons or sliders, a tooltip
>>> >>>> appears with the same text as is in the status bar.
>>> >>>>
>>> >>>> A bit of experiment shows that it is very simple to get the same
>>> >>>> behavior in TrackPanel, for any of the several status bar messages.
>>> >>>>
>>> >>>> Should I do it?
>>> >>>>
>>> >>>> Should I add " (TAB for more choices)" as appropriate, if this new
>>> >>>> development is agreeable to us all, making the TAB key cycling very
>>> >>>> discoverable?
>>> >>>
>>> >>>
>>> >>> Asking forgiveness instead of permission... I just did it at fcc7bfea.
>>> >>> See if you like it.  Easily reverted if we don't.
>>> >>>
>>> >>> Gale, tell me if "TAB" is correct or "Tab" or "tab" to name the key in
>>> >>> the message.
>>> >>
>>> >>
>>> >> For consistency with our use of other keys in the app and in the Manual
>>> >> (e.g Ctrl and Cmd)
>>> >> then the correct usage here would be "Tab"
>>> >>
>>> >>>
>>> >>>
>>> >>> I think this leaves no question about discoverability of the TAB key.
>>> >>> Is
>>> >>> this enough, then, that we want to revert the changed appearance of
>>> >>> split
>>> >>> lines as unnecessary now?
>>> >>>
>>> >>> I also added a distinction of tooltip/status bar messages when you TAB
>>> >>> cycle between snapping and non-snapping selection.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Should I define new status bar and tooltip texts for the TCP buttons
>>> >>>> and
>>> >>>> sliders?  There are not yet any.
>>> >>>
>>> >>>
>>> >>> I looked at this, and there are a number of questions, to be raised in
>>> >>> another email thread.
>>> >>
>>> >>
>>> >> Yes I do think that mouseover tooltips for the TCP buttons would be
>>> >> useful
>>> >> (and consistent)
>>> >> I asked you to consider doing this yesterday in a separate email.
>>> >
>>> >
>>> > As mentioned in another email thread in -quality, questions arose in my
>>> > mind
>>> > about making complete, correct, and brief messages for each of those
>>> > buttons.  Minimize, mute, and solo buttons are two-states, needing
>>> > variation
>>> > in the message.  The Mute and Solo further vary their behavior with the
>>> > Shift modifier key, in ways difficult to summarize.  Solo's behavior
>>> > also
>>> > varies with interface preferences.
>>>
>>> I personally agree it is legitimate to have Status Bar messages give
>>> terse help with what will happen with modified clicks
>>
>>
>> Not sure I understand.  You do like status mentioning Shift-, etc.?
>
> See "Ctrl-Click to select or deselect track." when hovering a dead part
> of the Track Control Panel.
>
>
>> Or you would agree to statuses that do not mention the modifiers,
>> but change as different modifiers are pressed?
>
> Better to mention if possible.
>
>>> and to flag up any
>>> differences on what will happen when the mouse is at a slightly
>>> different position e.g. when the split line is in the centre of the
>>> waveform (if that feature is really the least bad way of handling
>>> Bug 800).
>>
>>
>> "Flag up" means what?  Surely you do not mean a status should describe what
>> might happen if the pointer is somewhere else than where it is now?
>
> Fortunately no need for that hack now.
>
>
>> I think the message should be appropriate just to where the pointer is now.
>>
>>>
>>>
>>> To take the view that Status Bar messages should be "statuses
>>> only" seems to mean e.g. removing the Edit Toolbar and Tools
>>> Toolbar messages.  I doubt we want to do that.
>>
>>
>>
>> Who suggests this?
>
> Peter and Steve suggested messages are statuses only as I read it.

I don't recall commenting on this, though I think it is normal
practice for status bar messages to indicate statuses and for tool
tips to give tips about tools.

This clarifies nothing to me.

The precedent that exists in Audacity is that when you hover on a tooltip button, the status message and the tooltip are identical, briefly describing the command and the shortcut key.  Likewise sliders.  Hovering on the meters gives a short status though no tooltip.

Should something like it be done in TrackPanel?  Minimally, the five buttons in the controls might follow the same convention.

PRL
 

Steve

>
> I do not agree.
>
>
>> I did not.  Status messages now duplicate the tooltips
>> for toolbar buttons.  That is good enough.  I say ALSO duplicate MORE of the
>> existing status messages in tooltips.  But if so, it would be good to make
>> some of them more concise.
>>
>> PRL
>>
>>
>>>
>>> I don't think
>>> completing Status Bar messages and button tooltipping/
>>> highlighting is necessarily something that necessarily needs to
>>> be done for 2.2.0 but this is Paul's decision.
>>
>>
>>
>>
>>>
>>>
>>> I agree the Tooltips have greater importance but it is possible
>>> user has selected audio according to the Status Bar, could
>>> click the scissors icon and still be looking at the Status Bar to
>>> see if he got the correct tool.
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>>
>>>
>>> >> By and large mouseover tooltips are better than Status Bar messages.
>>> >> We
>>> >> know that many folk
>>> >> (ourselves included) never, or seldom look at the Status Bar.  In
>>> >> contrast
>>> >> the moseover tooltip
>>> >> appears where the user's visual attention is already focussed.
>>> >>
>>> >> But "belt & braces" - i.e. havitng tooltip and Status Bar msg - does no
>>> >> harm.
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Nominations for exact wording?  There are three sliders and five
>>> >>>> buttons:  Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo.
>>> >>>> Besides
>>> >>>> which, there are also the MIDI channel buttons.
>>> >>
>>> >>
>>> >> There is also the inverse of Minimize, the Expand.
>>> >>
>>> >> We can work with you on wording.  Do you want us (QA) to propose the
>>> >> initial
>>> >> wording or would you want to effect that?
>>> >>
>>> >> I would suggest that we do that on the Wiki>Wording>Talk page
>>> >> http://wiki.audacityteam.org/wiki/Talk:Wording
>>> >> before committing anything to the app.
>>> >>
>>> >> Peter.
>>> >
>>> >
>>> > All right then.
>>> >
>>> > Ignoring the question of the buttons, are there opinions about the
>>> > tooltips
>>> > you do get?
>>> >
>>> > PRL
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> For the sliders, it may be unnecessary, because they do show a tooltip
>>> >>> when you click or drag them.  But that does leave an inconsistency
>>> >>> with the
>>> >>> other sliders in toolbars.  Those in the bars show a tooltip simply
>>> >>> for
>>> >>> hovering.  Those in TCP don't.  Making all sliders consistent may not
>>> >>> be
>>> >>> hard, but not quite so simple as for the other tips.  Making hover
>>> >>> tooltips
>>> >>> for sliders the easy way, would make duplicate tooltips in different
>>> >>> colors
>>> >>> when you click -- and that is undesirable.
>>> >>>
>>> >>> PRL
>>> >>>
>>> >>>>
>>> >>>> PRL
>>> >>>>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________


------------------------------------------------------------------------------
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
|

Change in mouse cursor at edge of selection

Cliff Scott
In reply to this post by Paul Licameli
Just did a build using the latest commits and found that when wanting to expand an existing selection on the waveform the cursor doesn't change to the "hand" at the edge of the selection. I hope this is not intentional. To me it means I have to guess that I'm exactly at the edge or else the selection goes away. Not a good way to do it in my opinion.

Steps to reproduce:

1. Make a short recording, let's say 15 seconds long.
2. Make a selection a few seconds in length somewhere in the middle of the waveform.
3. Try to expand the edge of the selection by dragging. The mouse cursor does not pickup the edge of the selection so in trying to drag if one miss judges the edge (the pickup zone is rather narrow) when dragging, the selection is canceled.

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
|

Re: Change in mouse cursor at edge of selection

Paul Licameli
Probably my fault, I'll examine it...

PRL


On Sun, Jul 16, 2017 at 10:50 PM, Cliff Scott <[hidden email]> wrote:
Just did a build using the latest commits and found that when wanting to expand an existing selection on the waveform the cursor doesn't change to the "hand" at the edge of the selection. I hope this is not intentional. To me it means I have to guess that I'm exactly at the edge or else the selection goes away. Not a good way to do it in my opinion.

Steps to reproduce:

1. Make a short recording, let's say 15 seconds long.
2. Make a selection a few seconds in length somewhere in the middle of the waveform.
3. Try to expand the edge of the selection by dragging. The mouse cursor does not pickup the edge of the selection so in trying to drag if one miss judges the edge (the pickup zone is rather narrow) when dragging, the selection is canceled.

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