Re: [Audacity-devel] "Scrubbing gets trapped in a mode"
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
Menu
▾
▴
Re: [Audacity-devel] "Scrubbing gets trapped in a mode"
|
From: James C. <cr...@in...> - 2015-10-02 21:07:26
|
Paul, I've put some comments/responses on the wiki (talk) page. --James. On 02/10/2015 19:46, Paul Licameli wrote: > > > On Thu, Oct 1, 2015 at 2:01 PM, Peter Sampson > <pet...@ya... <mailto:pet...@ya...>> wrote: > > I've been thinking a lot today about scrubbing and how we might > achieve consensus. I've decided that I like most of what James > proposed > and would like to throw my weight behind that. > > What I am proposing is a two phase approach. Phase-1 is really a > bit of > a tidy-up with some of James' suggestions - but not changing the > UI, so > in this phase all Paul's current UI gestures will be preserved > this should thus > make Phase-1 relatively un-contentious - even for Paul ;-) > > The second phase will address the UI and how the user accesses > scrubbing, > that will be harder. > > > *Phase-1* > Change the green triangle on the cursor, so indicating that it is > not recording, nor playing, but some other mode. > James +1, Peter +1 > > > Is it not enough to make the triangle and the green line appear as > soon as you ctrl-click? We would like some other color to distinguish > scrub play from ordinary play? Or another shape? > > > Change the green triangle on the play button to indicate > scrubbing-play (in both cases possibly a double headed triangle > would work, indicating bi-directional). Combined these give a > clue that clicking on transport buttons could help. > James +1, Peter +1 > > > Could get elaborate to distinguish scrub from seek? > > Be cute (or silly) and make it look like a brush or binoculars? > > Make ESC take us out of scrubbing. > James +1, Peter +1 > > > Make ESC stop ordinary play and recording too? > > > Make clicking outside the track take us out of scrubbing. > James +1, Peter +1 > > > Do you mean outside the track or outside the track panel? Pointer can > be in the panel but over no track. > > Do we want to involve the horizontal ruler in scrubbing? See next. > > > *P3 Bugs (as part of Phase-1 clean-up)* > http://bugzilla.audacityteam.org/show_bug.cgi?id=1053 > Status Bar messages incorrect after scrub commences. > > http://bugzilla.audacityteam.org/show_bug.cgi?id=991 > Pause button and Pause command are not grayed out as inoperable > when in scrub mode > > http://bugzilla.audacityteam.org/show_bug.cgi?id=1079 > Scrubbing is stopped when a tool that is not Select is chosen > > > Remember why scrubbing is allowed only in select tool: Because we > repurposed click and drag to switch scrubbing to seeking, but we can't > (or didn't want to) do that in other cursor modes. > > But this unsatisfactorily makes it impossible to click and drag during > scrubbing to change selection. > > So I suggested we change seeking to be a click and drag on the green > triangle instead. Then click and drag in the track in the select tool > can have its usual effect. > > But does that mean scrubbing could work in any tool? Well still no, > because ctrl-click conflicts with things in the other tools. > > So I want to hear a suggestion for an alternative to ctrl-click for > starting scrub. Again, perhaps it should be started only by some > action in the time ruler. > > So 1079 is bound up with the answers to these questions, and I say it > should be moved to phase 2. > > PRL > > > > *Phase-2* > UI/GUI discussion - to be undertaken once Phase-1 is complete > This will involve a lot more discussion I'm thinking. > > > Phase-1 will not help the user who accidentally strays into > scrubbing, but > it will give them (and us) a bit of a clue as to what is going on. > > Hoping that Steve and Paul can both agree to this modest Phase-1 > proposal > and that James can stick with the ideas he proposed and thereby we > can get > a consensus among interested parties - and Paul can proceed with > Phase-1 > as soon as 2.1.2 is released. > > Peter. > > > > Peter Sampson Tel: +44 (0)1625 524 780 > <tel:%2B44%20%280%291625%20524%20780> > > ------------------------------------------------------------------------ > *From:* James Crook <cr...@in... <mailto:cr...@in...>> > *To:* aud...@li... > <mailto:aud...@li...> > *Sent:* Tuesday, September 29, 2015 11:08 AM > *Subject:* Re: [Audacity-devel] "Scrubbing gets trapped in a mode" > > Paul, > > Play and record are indeed modes too, just ones users are much > more familiar with. As we improve Audacity I/we would like to be > able to do more things we currently can't do in those modes, but > that is nice to have, not an urgent problem. The problem with > scrubbing being a mode is more serious. > > With play and record the cursor is moving and either sound is > coming out or new waveform is being drawn. With scrubbing, if the > cursor has caught up with the mouse, it isn't as clear that the > user is in a mode. Sure, the play button is down, but that does > look a bit as if play is active but for some reason stuck. > Attempting to select a region won't work, whereas it does work in > play. To a user not familiar with scrubbing it looks as if > Audacity is broken. > > Some random clicking around won't get the user out of the mode > that they don't really know they are in. > > > Above the line is 'the problem' > ----- > A solution that would work for my use of scrubbing is that we go > out of scrubbing as soon as we release the left mouse, (or release > middle wheel - and middle click as well as ctrl-left-click > activates scrubbing). That might defeat some of how you use > scrubbing. It would though completely satisfy me that scrubbing > was no longer 'a mode a user could be trapped in'. > > Other alternative design features that could make this mode more OK: > - Change the green triangle on the cursor, so indicating that it > is not recording, nor playing, but some other mode. > - Change the green triangle on the play button to indicate > scrubbing-play (in both cases possibly a double headed triangle > would work, indicating bi-directional). Combined these give a > clue that clicking on transport buttons could help. > - Make selecting a region of more than 10 pixels take us out of > scrubbing (selecting is probably one of the first things a stuck > user would do) > - Make ESC take us out of scrubbing. > - Make clicking outside the track take us out of scrubbing. > > These are not prescriptive, they are just possible approaches to > the problem. Hopefully there is something in the suggestions that > from your perspective does not damage scrubbing in any way, and > that I and Steve would be happy with as solving the problems for > the stuck-in-scrubbing users. > > --James. > > > > > > > > > > > On 29/09/2015 02:19, Paul Licameli wrote: >> >> >> On Monday, September 28, 2015, Steve the Fiddle >> <ste...@gm... <mailto:ste...@gm...>> wrote: >> > On 29 September 2015 at 01:33, Paul Licameli >> <pau...@gm... <mailto:pau...@gm...>> wrote: >> >> I recognize that it would be better to depress the play button >> and show the >> >> play head as soon as you ctrl-click. >> >> >> >> However, I think that's a separate question from being "stuck >> in a mode." >> >> As soon as you do move the mouse, you do get the playhead and >> the changed >> >> button appearance. That indicates the "mode" and we would >> simply indicate >> >> that "mode" sooner. >> > >> > Imagine that you are standing in front of a machine, and you are >> > trying to work out what it does and how to use it. >> > * You pull a lever - nothing happens >> > * You press a button - the lights come on >> > The obvious conclusion is that pressing the button turns on the >> lights. >> > >> > By analogy, that is not would be the wrong conclusion in the >> case of scrubbing. >> > * The user clicks on the track (with the Ctrl button held down, but >> > they may be depressing the Ctrl button inadvertently) - nothing >> > happens. >> > * The user moves the mouse - playback starts. >> > The obvious conclusion is that "somehow" moving the mouse initiated >> > playback. The user has been lead to the wrong conclusion. >> > >> > Does that help? >> > >> > Steve >> >> If the changed appearance of the button and playhead were >> immediate after the click -- which I could arrange easily enough >> -- then it would no longer be true that "nothing happens" but it >> would still be true that you are then "in a mode." >> >> Is the proper complaint here only the "nothing happens" part? Is >> the "mode" not really the problem, or is it indeed an added problem? >> >> >> PRL >> > >> >> >> >> If it is not then obvious that you can stop scrub play just as >> you stop >> >> other play, I don't know what would make it more obvious. >> >> >> >> Or is "stuck in a mode" a mischaracterization of the problem? >> Is this >> >> non-immediacy of the feedback the only major inconvenience >> that really needs >> >> a fix? (Yes there are other problems like inappropriate >> status bar >> >> messages.) >> >> >> >> Or do we need some other interface for initiating scrub that >> you are less >> >> likely to do by accident? I do not know what that would be. >> >> >> >> PRL >> >> >> >> On Mon, Sep 28, 2015 at 7:11 PM, Steve the Fiddle >> <ste...@gm... <mailto:ste...@gm...>> >> >> wrote: >> >>> >> >>> On 28 September 2015 at 21:21, Paul Licameli >> <pau...@gm... <mailto:pau...@gm...>> >> >>> wrote: >> >>> > I agree to attempt some improvements in scrubbing user >> interface as a >> >>> > priority for 2.1.3 / 2.2.0. I think figuring out the best >> way to >> >>> > untangle >> >>> > my scrubber hacks from track panel was a needed research >> preliminary >> >>> > that I >> >>> > have completed now. >> >>> > >> >>> > I am still undecided what the best interface should look >> like. I think >> >>> > we >> >>> > all are. >> >>> > >> >>> > But the complaint I have heard and do not understand is >> that "scrubbing >> >>> > gets >> >>> > trapped in a mode." >> >>> > >> >>> > How is scrubbing any more a confusing "mode" than are >> playing and >> >>> > recording? >> >>> >> >>> The short answer is, because it is unfamiliar. >> >>> >> >>> A longer answer involves how users, particularly novice users, >> >>> perceive the behaviour: >> >>> >> >>> When playing or recording, there is a "Stop" button on the >> Transport >> >>> toolbar. The Transport toolbar is laid out in the style of a tape >> >>> player, which is a format familiar to everyone. During >> playback and >> >>> record, the mouse may be moved freely - it is clearly not >> captured. >> >>> There is no problem with stopping normal Play or Record >> because the >> >>> behaviour is familiar and expected, even for a total novice. >> >>> >> >>> If a user is inadvertently holding down the Ctrl (or Command) >> key and >> >>> clicks on the waveform, it is not immediately obvious that >> they have >> >>> done anything. Unless they are moving the mouse, there is no >> obvious >> >>> indication that they have started scrubbing. On Linux, the >> Play button >> >>> is not even down (I've not tested on other platforms). >> >>> >> >>> It is quite easy for a user to inadvertently enter scrubbing >> mode. On >> >>> Windows or Linux, the use may be intended to extend a >> selection with >> >>> Shift + click and hit the wrong button. >> >>> >> >>> As soon as the user moves the mouse it is obvious that "something >> >>> unexpected" is happening (as the user sees it if they are not >> >>> expecting scrubbing). Each time they move the mouse, playback >> starts >> >>> either forward or backward. Of course this is exactly what is >> supposed >> >>> to happen, but if a user is not aware of the scrubbing >> feature, either >> >>> that Audacity now has one or how to activate/deactivate it, >> then the >> >>> behaviour is surprising and unexpected. >> >>> >> >>> If they move the mouse toward the Stop button, Audacity starts >> >>> playing backward. "How do I stop that horrible noise" they cry. >> >>> (dramatic interpretation :-) >> >>> >> >>> Of course there are several ways to stop scrub playback >> (including >> >>> some unintended ways). The point is that the user may have no >> idea >> >>> what is happening or why. If they try to do anything with the >> mouse >> >>> "it makes the problem happen" (as they see it). >> >>> >> >>> I think that it would certainly help if mouse activated >> scrubbing was >> >>> active only when the pointer is over a track. Scrubbing would >> then >> >>> stop when they move the mouse toward the stop button, but >> they would >> >>> see that the Play button is down. Clicking the Stop button is >> then a >> >>> more obvious solution to escape from "the problem". >> >>> >> >>> Also there should be feedback to the user that they have gone >> into >> >>> scrubbing mode as soon as they Ctrl + click. Providing visual >> feedback >> >>> is both informative and reassuring for users. This article from >> >>> Microsoft is mostly about touch screen apps, but there are >> some useful >> >>> guidelines and tips that apply to all applications: >> >>> >> https://msdn.microsoft.com/en-us/library/windows/apps/hh465342.aspx >> >>> >> >>> Not all users use keyboard shortcuts. In fact, most novice >> users don't >> >>> use keyboard shortcuts at all, not even the most common and >> standard >> >>> shortcuts. We cannot safely assume that users will think to >> use the >> >>> spacebar or Esc key. >> >>> >> >>> We need to inform the user "in some way" that they have gone into >> >>> scrub mode as soon as they activate scrub mode (not wait >> until scrub >> >>> playback starts). How to escape from scrub playback also >> needs to be >> >>> obvious, though I think that is not really a problem if the play >> >>> button is down and mouse activated scrubbing only happens >> while the >> >>> mouse is over tracks. >> >>> >> >>> Steve >> >>> >> >>> >> >>> > Those two are easily escaped by hitting the spacebar, and >> scrubbing is >> >>> > no >> >>> > different. >> >>> > >> >>> > I think the ESC key convention for escaping from modes (not >> only from >> >>> > modal >> >>> > dialogs) should become universal. I have made ESC work to >> escape some >> >>> > click-drag-release actions, such as zooming the vertical >> ruler, and I >> >>> > expect >> >>> > to make it escape from all of the remaining drag actions >> too in the next >> >>> > version. >> >>> > >> >>> > Perhaps ESC should also do what spacebar does. Then users who >> >>> > understand >> >>> > the convention can guess how to get out of scrubbing. >> >>> > >> >>> > ESC will be one of the few special keys (TAB is another) >> that cannot be >> >>> > reassigned to other purposes in keyboard preferences. >> >>> > >> >>> > PRL > > |