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

Post by Paul Licameli
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.

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.

Post by Paul Licameli
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.

Post by Paul Licameli
Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo. Besides which,
there are also the MIDI channel buttons.

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

Peter Sampson

2017-07-14 07:58:09 UTC

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

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"

Post by Paul Licameli
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.

Post by Paul Licameli
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.

Post by Paul Licameli
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.

Post by Paul Licameli
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

------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2017-07-14 09:15:06 UTC

On Fri, Jul 14, 2017 at 8:58 AM, Peter Sampson <

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

Post by Paul Licameli
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?

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"

Post by Paul Licameli
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

Post by Peter Sampson

Post by Paul Licameli
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.

Steve the Fiddle

2017-07-14 10:40:11 UTC

Post by Peter Sampson
On Fri, Jul 14, 2017 at 8:58 AM, Peter Sampson

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

Post by Paul Licameli
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?

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"

Post by Paul Licameli
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

Post by Peter Sampson
Peter

Post by Peter Sampson

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.

------------------------------------------------------------------------------
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-quality

Peter Sampson

2017-07-14 12:52:28 UTC

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 <

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

Post by Paul Licameli
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?

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"

Post by Paul Licameli
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.

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.

Gale Andrews

2017-07-14 17:39:49 UTC

I think Peter is correct that shortcuts are sentence case as per
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference.

So "Tab" is correct and we also want "Esc" not ESC.

http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference_-_Full_set
still shows fully capitalised shortcuts for now.

Tooltips, Infotips and Status Bar messages are sentence case. They
only take title
caps if they explicitly refer to menu items that take title caps.

Gale

Post by Paul Licameli
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.

Post by Paul Licameli
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.

Post by Paul Licameli
Gain, Pan, Velocity; Close, Menu, Minimize, Mute, Solo. Besides which,
there are also the MIDI channel buttons.

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