Bugzilla – Bug 1053
[Scrub Phase I] Status Bar message does not mention scrub if pointer over waveform
Last modified: 2018-08-20 11:51:38 UTC
Probably "Playing" should change to "Scrubbing". During standard scrub, message in the main part of Status Bar should change to something like "Drag to continue scrubbing, click to move scrub position". During scroll-scrub, perhaps "Drag to continue scroll-scrub, click or hold to scroll-seek". Paul would have to decide if there could be a sensible message for scroll-scrub.
(In reply to Gale Andrews from comment #0) Not "probably" - definitely the left Status Bar box should change to say "Scrubbing" rather than "Playing". The users really deserve this clarity, we have precious few visual cues that we are in scrubbing mode - this could be a valuable one (and should be easy to implement). I would suggest that we probably do not need the subtlety of changing this to "Seeking" when in seek mode or "Scroll-scrubbing" when scroll-scrubbing. I think "Scrubbing" will easily suffice for all three forms of scrubbing behavior.
Fixed at: https://github.com/audacity/audacity/commit/51f061928fe99446c49ae5fceed0be539974b545 The leftmost part of the status bar will now say "Scrubbing." The message right of that will be either "Move to adjust speed, click to skip, ESC to stop." for scroll scrub, or, "Move to scrub, click to seek, ESC to stop." for standard scrub. If these are not the best messages, it is easy to find the text in the source code and edit.
(In reply to Paul L from comment #2) Testing on 10 and macbook Pro El Capitan 19Apr16 nightlies/ Behaves correctly as Paul writes on both platforms But the messagges in tthe status bar would raed better as: "Move mouse to scroll ..." and "Move mouse to adjust speed" Otherwise the user may be confused as to hust what it is they are supposed to be moving. On a side note The ESC key to Stop scrolling, as npw mentioned in the Status Bar message now works on both platforms effecting a STOP to scrolling.
On thinking about this we should probaly not add "mouse" to the meassage as the user could be using a track-pad or a track-call. But should it say "move left or right to ... " ?
(In reply to Peter Sampson from comment #4) > On thinking about this we should probaly not add "mouse" to the meassage as > the user could be using a track-pad or a track-call. > > But should it say "move left or right to ... " ? or "move mouse pointer left or right to ..."
On second thought, this work may be very soon invalidated. If I do my own interpretation of phase 2, then scrubbing will be controlled by clicks and drags in the time ruler and not use modifier keys. I would then revert this change for status messages in the track panel. There are no status bar messages yet for the mouse in the time ruler, describing quick play and adjustment of play region and the other things it can do. We should think about right wording for them.
Steve and I both think that yoy should leave the Timeline ruler well alone. If you were to do that you would create a major regression for Timeline Quick-Play which a *lot* of peple use - many using that in preference to scrubbing.
(In reply to Paul L from comment #6) > If I do my own interpretation of phase 2, then scrubbing will be controlled > by clicks and drags in the time ruler As I have already said several times, I am strongly opposed to you interfering with the Timeline Quick Play interface. I spent a lot of time and effort in designing that interface to be effective and user friendly.
I'm reopening it because as of HEAD right now, the Status Bar messages assume you are scrubbing by using the pointer in Scrub Bar. The menu and shortcut methods which don't require Scrub Bar only have the former Selection Tool messages which are correct but insufficient. Title is now "[Scrub Phase I] Status Bar messages incomplete for scrub started with menu or shortcut." I suppose we should say "move mouse pointer" for the messages. Just "pointer" may not be clear to all users. I'll change the Bug 33 message to reflect the scrubbing shortcuts that are now available.
Testing on audacity-win-rdab59cb-2.1.3-alpha-02-jul-16 What is still wrong is then when you are Seeking the Status Bar message (and the associated Scrub Bar Tooltip) say "Move to Scrub, drag to seek". This incoreect because when you are in Seek mode yoe move to seek (and there is no click gesture to temporarily shift you into scrub mode). Also the Status Bar message (and its associated button tooltip) when you hover over the Scrub Bar always says "Hide Scrub Bar" - this doesn't really make sense when the Scrub Bar is already hidden (which is the default state after all) = so either the message needs to change to "Show Scrub Bar" when it is hidden and "Hide Scrub Bar" when iys is shown - or use a single meesaage and tooltip that says "Show/Hide Scrub Bar". I would put the "Show" first as the default state is not shown. Otherwise the Status Bar messages and tooltips for scrubbing and seeking look ok to me.
DEVEL - FIX MADE https://github.com/audacity/audacity/commit/5939fe66e8890b324bd99876cf530f927f21d531 Note the wording is currently either: "Move mouse pointer to Seek" OR "Move mouse pointer to Scrub" Given audio is active, the seeking/scrubbing is more important in my opinion than the ability to select, so I feel in this case less is more. IF the wording is not quite right, but only a wording change to those two phrases is needed, then please close and use wording on wiki. The message with multi-tool active keeps changing in a not very predictable way, but I feel that the message for multi tool mode was already over complex. We're never going to be able to put everything relevant from the whole help manual into a tooltip :-)
(In reply to James Crook from comment #11) Testing on Mac El Capitan a90f32e 11Aug16 tests ok on Mac when using the Transport Menu and when using the buttons in the Scrub Toolbar. And I'm happy with the wording as it is now.
Testing on W10 audacity-win-ra90f32e-2.1.3-alpha-11-aug-16 Tests ok on W10 too
Messages ok on both platforms when invoking Scrr/Seek from the Scrub Bar
REOPENED and made clear in "Not Fixed" Step 1 what the residual problem is. We do see "Move mouse pointer to Seek" or "Move mouse pointer to Scrub" if we move the pointer into the waveform, but not if the pointer is aleady in the waveform and pointer is not moved after starting Scrubbing or Seeking by shortcut. The message shown "click and drag" if acted on will start Seeking (not Scrubbing) and Scrub mode is then exited on mouse release. So the message is not helpful. I'm OK with those messages (and only those) after audio is active, we just need to get them showing in the case mentioned.
Works for me (on Windows). 1 Move pointer into the waves if not already there. Start scrubbing by shortcut and moving the mouse, but leave the pointer in the waves. 2 Status Bar shows message "Move mouse pointer to Scrub". If in step 1 I click in the wave and don't move the mouse before or after pressing the shortcut, then yes, I get 'Click and Drag to move right selection boundary' and that is true too. What's the problem? I'd argue against: 'Click and Drag to move right selection boundary or Move mouse pointer to Scrub' or the more accurate 'Click and Drag right to move right selection boundary or Click and Drag left to move left selection boundary or Move mouse pointer to Scrub or Shift Click Drag left to move left selection boundary and seek at the same time or Shift Click and Drag right to move right selection boundary and seek at the same time.' We shouldn't try and tell them everything! Even if you don't agree with me, please demote to P5 or add a release note for the residual.
Previously had a release note of "// see 33" (which is accessibility). Corrected by adding an actual release note for the residual issue.
Following Gale's not fixed steps 1 and 2 on Mac El Cap and W10 a) withouth moving the cursor in the waveform the Status Bar message reads "Click and drag to select audio" b) as soon as you move the mouse in the waveform the Status bar message immediately changes to "move mouse pointer to scrub" Now given that this behavior only affects users who have taken the trouble to set up a shortcut for scrubbing (given that we have made no default settings) then it is fair to assume that such folk are "scrub knowledgeable" and are quite aware that scrubbing is a mode of play that involves moving the cursor to "scrub". Given this assumption I think the current messages are fine. This situaltion may change on the future if we are able to male a VI accessible scrubbing.
Shortcuts and Status Bar messages are accessibility issues. It wasn't a mistake to list in Bug 33. The Bug 33 entry has been slightly tweaked to say: "Different [http://manual.audacityteam.org/man/scrubbing_and_seeking.html Scrubbing] modes may also be started using shortcuts or the Transport Menu, but there is no keyboard interface yet to control scrubbing. Scrubbing may be started by shortcut even if the pointer is in the waveform, although the Status Bar messages don't refer to moving the pointer to Scrub." I removed the duplicate Release Note in this bug. I agree we should not write an essay in the Status Bar but there is a good chance that there will be some default shortcut for Scrub and/or Seek in future (I still regard it as a significant omission that there is not already). If there is such, then IMO a user who sees this shortcut for the first time should be entitled to the five extra words in Status Bar now suggested in "Steps to Reproduce".
Also, clarified title to "[Scrub Phase I] Status Bar message does not mention scrub if pointer over waveform".
Since there are no default shortcuts for Scrub or Seek - one can reasonably assume that the user who sets these will be reasonably "advanced" and "aware" and who can realistically be assumed to be "scrub knowledgeable" Acoordingly I am going to close this bug as WONTFIX