Re: [Audacity-quality] Why enh bug 1331 is there and what to do about it

[Steve t. F. <ste...@gm...>]

On 21 January 2017 at 00:11, Gale Andrews <ga...@au...> wrote:
> Steve asked about bug 1331:
> ( http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c16 )
>
>> is this bug / enhancement about restoring the Wx2.8 behaviour, or is it limited to
>> the specific feature as demanded by (a few) users? In other words, is this logged here
>> on bugzilla because the current behaviour is considered "wrong", (which would imply
>> that any other behavioural changes in Audacity due to this change in WxWidgets are
>> also wrong), or are we only concerned with the specific issue of "Play on spacebar
>> while mouse button down"?
>
> I'd like to give my thoughts about how it might be "fixed" so rather
> than do that in the comment trail I'll do so here.

Thanks for moving this to the email list.
I'm interested in not only this specific "enh bug", but also the more
general issue of how to use bugzilla and the wiki feature requests
most effectively.

>
> SPACE with mouse button down not working is what has generated the
> most complaints (if we are calculating, I think it sums to about ~11
> users so far, not just the "three more" in
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c11 .

Whether 3 or 11, it is still a minuscule proportion of users, and
although that is no reason to not do something, we do need to keep a
sense of proportion so as not to over-react to squeaky wheels.

>
> I've also seen two complaints about DEL with mouse button down not
> working any longer, as well as about Silence Audio and Zoom.  As those
> complaints have been fewer and much less insistent, and I am guessing
> globally re-enabling shortcuts with mouse down is unsafe or infeasible
> (see near the end of this message), I was not intending to track those
> other complaints formally for now.
>
> They could be so tracked though - perhaps as a summary of less
> requested restorations of shortcuts with mouse down.
>
> This specific enh (bug 1331) is listed because the users see
> disallowing SPACE with mouse down as "wrong" (it's a "bug" to them).

At least one user has claimed that rendering track envelopes in
"compressed copy of project" is a bug, though clearly it's not.
Many users regularly report the leading padding on MP3 exports is a
bug, which clearly it is not (even if we could handle  it better).
Some users have reported lack of Opus support as a "bug", which
clearly it's not.

There are countless examples of users reporting "bugs", which they see
as "bugs", that are not bugs at all, but surely that is why we have
QA? It's up to us to differentiate between "bug", "feature request",
"user error", and whatever "enh bug" is.

As Peter noted, there are many enhancements listed on the wiki feature
request page that have many more votes than this issue, but, correct
me if I'm wrong, an "enhancement" listed on bugzilla is actively
tracked along with "real bugs", and thereby has greater priority than
enhancements listed on the wiki. What determines whether an
enhancement should get this preferential treatment?

> This enh is specific to that problem, but the complaint does not
> necessarily predict the fix. This enh means for us that:
>
> * there is a considerable risk of affected users not updating Audacity

Risk to whom?
With all software there are early adopters, late adopters, and users
that try out the latest and greatest then go back to a previous
version for a while. In the end it is up to the user to decide what
software best meets their needs. If a later version of an application
has many improvements over old versions and one feature that a user
dislikes, it is up to the user to decide if the many improvements
outweigh the one feature that they don't like.
It's not a "risk" to either the user or to us, it's a decision that
the user is free to make.

Our task is to make Audacity "as good as possible", but we are never
going to satisfy everyone.

In this specific case, 11 users are complaining that they can't start
play until they have completed making a selection. This is only an
issue at all because WxWidgets 2.8 allowed that to happen, but as far
as I'm aware it was not a documented, or even an intended by design
feature of Audacity, but rather just something that happened because
that's what WxWidgets 2.8 did.

With WxWidgets 3.0, we can add the ability to start playback while
making a selection is in progress, by calling OnPlayStop when the
spacebar is pressed, but then it becomes a "design feature" which has
never existed in Audacity previously.

What happens if we add the proposed feature and 12 new users that have
only ever used Audacity 2.1.2 complain that they don't want play to
start unless they have completed making the selection (don't allow
play until mouse button is up)?

In my opinion, our design decisions should primarily be concerned with
making Audacity as good as we possibly can, and while we should
certainly take account of user feedback, we need to remember that the
user is not always right. Something that is "right" for one user can
easily be "wrong" for thousands of other users.

I am not convinced that the proposed "new feature" (and I call it a
"new feature" because it will need to be a new deliberately designed
feature rather than just "what happens") is better than now. So
although I'm not strongly against the feature (though I do slightly
prefer the current behaviour), I see no reason that it should be
elevated above feature requests that have many more "votes".

Also, as "P3" it would appear to be elevated above hundreds of actual
"bugs", which I don't see to be in the best interest of "making
Audacity as good as we possibly can".

Steve

> * if the original behaviour is not reinstated, we should consider how
> we could make things easier for these people when enhancing playback
> features.
>
> One fix would be to disallow SPACE with mouse down, but if mouse is
> down, play on mouse up.
>
> Examples of apps with arguably more friendly waveform playback
> behaviour than we have now were given here:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c5
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1331#c7 .
>
> I notice we still allow shortcuts to be used after a fashion with
> mouse down in Envelope Tool. It is more restrictive (some might say
> weird) and presumably safer than in 2.1.1. In HEAD with the mouse
> down, use the desired shortcut (or any other). This releases the mouse
> (even if you are still holding it down). Then use the desired
> shortcut.
>
> So, can we do something like that when in Selection Tool? For example,
> when mouse is down, make SPACE release the mouse and then play the
> track. While playing, moving the mouse would only move the pointer,
> not drag the selection, even if mouse button was still down. When you
> press SPACE again to Stop, this re-engages the mouse (but this assumes
> we don't have to deliver a left-click which would destroy the
> selection). If the mouse had moved while playing, let the selection be
> redrawn according to the new pointer position.
>
> Yes, the more obvious fix would be to treat this as a request to
> restore use of SPACE with mouse down.  Obviously the users would like
> that, but I think we should only oblige if it is safe to do so.
>
>
>> I wouldn't want to waste time reintroducing the specific feature request and then
>> be told that it does not fix other cases.
>
> Is there some kind of global "switch" to re-enable shortcuts with
> mouse down? Even if there was, given what Paul found, might such a
> "global" change be potentially dangerous?  Should we not take it case
> by case to see if other relaxations such as DEL with mouse down are
> safe?
>
>
>> We normally treat "bugs" as the whole issue and "feature requests" as a specific
>> feature - which is this?
>
> As it was decided this was enh, not bug, it's the specific feature (or
> a means of implementing something comparable in the waveform that
> could still satisfy the complainants).
>
>
> Gale
>
> ------------------------------------------------------------------------------
> 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
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality