Bugzilla – Bug 1420
Tooltip for Scrub Bar is inaccurate/misleading
Last modified: 2018-08-20 11:45:22 UTC
Whe the user moves the cursor into the Scrub Bar the tooltip that appears says: "Click to scrub, drag to seek". 1)This is not strictly accurate as all that dragging the widget does at that stage is move the double-headed green triangle widget up and down the Scrub Bar - it does not actually initiate seeking. 2)Similarly just clicking there does not actually initiate scrubbing - it just moves you into a pre-scrubbing/pre-seeking state prior to the user's next gesture. I can live with 2 (I can see no easy way to reword that - and anyway the subsequent tooltip "Move to scrub, drag to seek" is more helpful and accurate). But as 1 is actally wrong I think you need to reword the initial tooltip to say: "Click to scrub, click and drag to seek" Even better, I think, it would be an improvement if the initial tooltip announced itself as the Scrub Bar thus: "Scrub Bar: click to scrub, click and drag to seek" This would be useful as the Scrub Bar is a new Audacity entity, totally unfamilair to most users
I would prefer the tooltip on initial hover to be: "Click-move to scrub or click-drag to seek". Hyphen can be replaced by "and" if we feel that would not make it too long.
(In reply to Gale Andrews from comment #1) >I would prefer the tooltip on initial hover to be: "Click-move to scrub >or click-drag to seek". Or the hyphen could be replace with a + sign or an ampersand: "Click+move to scrub or click+drag to seek". "Click & move to scrub or click & drag to seek". Personally I prefer the plus sign variant.
(In reply to Peter Sampson from comment #2) The "+" variant looks odd to me, the "&" version is OK with me. Comma might be OK. "Click, move to scrub or click, drag to seek". Actually I like the comma version. Drag implies a click, but it could look odd to say "Click & move to scrub or drag to seek".
Wording change. https://github.com/audacity/audacity/commit/308ccb9eab75a443f5dc220065f82c2fe8071cb2
Testing on W10 audacity-win-r6828529-2.1.3-alpha-15-jul-16 That looks much better - accurate and informative - good to go (but still to be tested on Mac & Linux)
As I've said somewhere on the mailing lists, after you see (as now) "Click & move to scrub. Click & drag to seek" then left-click and don't release the mouse, you see "Move to scrub, drag to seek", but that tooltip is strictly wrong. Either move or drag will seek. If we want a tooltip before mouse up (or can't prevent it), then I believe it should be "Release and move to scrub. Drag to seek." On mouse up, the current "Move to scrub, drag to seek" is correct. It this fixable or have we got to live with the inaccuracy before mouse up? Also I see that on http://wiki.audacityteam.org/wiki/Guidelines_on_capitalization_in_Audacity_dialogs_and_messages it says that tooltips are sentence case but for buttons, use the title caps of the menu item that button refers to. If does not say about capitalising those menu items in other tooltips/infotips, so what looks better? I think capitalising looks better if you compare the Scrub Bar tooltip with the Scrub, Seek and Scrub Bar buttons. And the guidelines do imply that if we have two sentences, both must end in a period (but no period if only one sentence). So I suggest James's tooltip in the commit should be "Click & move to Scrub. Click & drag to Seek". Anyone disagree?
I disagree. I think better than: "Click & move to Scrub. Click & drag to Seek" is "Click & move to Scrub. Click & drag to Seek." i.e. with the full stop included. If the tooltip mentioned in the first paragraph of comment #6 just needs new words, then please get the agreed words for it on the Wording page of the wiki - or if you have a good solution just apply it directly. If the better solution is not to show a tooltip whilst mouse is down at all, please confirm, and something can then be done about that. I'd like to distinguish wording changes from code changes where possible.
(In reply to James Crook from comment #7) > I disagree. I think better than: > > "Click & move to Scrub. Click & drag to Seek" > is > "Click & move to Scrub. Click & drag to Seek." > > i.e. with the full stop included. </quote> Sorry, I meant to write in comment 6 "Click & move to Scrub. Click & drag to Seek." with the period inside the quotes. So we do agree that change would be better, including the caps change, and I went ahead and clarified these points on http://wiki.audacityteam.org/wiki/Guidelines_on_capitalization_in_Audacity_dialogs_and_messages . I think the optimal solution is to have a separate tooltip on mouse down and until mouse up "Release and move to Scrub. Drag to Seek." because on mouse down a change (or removal of) tooltip catches your attention. So the natural inclination is to hold the mouse down a while until you are used to scrubbing and thus it's better to do the "positive" action of showing a tooltip. Then on mouse up, show a caps- and period-modified "Move to Scrub. Drag to Seek." (the same meaning as now). If we don't show a tooltip at all while mouse is down, we don't get a tooltip while user begins drag to seek. But if removing the tooltip while mouse is down is the only alternative, I'm still +1 because I think that's better than showing an incorrect message on mouse down (which although "coding" is close enough covered by this bug title).
(In reply to Gale Andrews from comment #6) >As I've said somewhere on the mailing lists, after you see (as now) >"Click & move to scrub. Click & drag to seek" then left-click and don't >release the mouse, you see "Move to scrub, drag to seek", but that >tooltip is strictly wrong. Either move or drag will seek. This is still the case on W10 audacity-win-rcf2625a-2.1.3-alpha-18-jul-16 and on Mac El Capitan with rcf2625a 20Jul16- and thus still wrong.
(In reply to Gale Andrews from comment #8) I made the consistency change agreed at https://github.com/audacity/audacity/commit/5d15eba . Because this bug blocked the wording bug 1427 I've actually got to RESOLVE it because the residual that the tooltip on mouse down is wrong is a coding issue. That is now at bug 1456.
