Interrupting effect dialog says what?

[ferdnyc]

Some of the ways in which effects provide feedback to the user seem excessively disruptive, particularly when they rely on dialog boxes for feedback. Here’s an example:

Say I’m working on cleaning up a noisy audio file using the Click Removal effect, manually scrolling through the waveform, selecting sections of audio to clean up, and hitting Ctrl+r to apply the effect on each selection.

Whenever the audio I’ve selected doesn’t exceed the parameters I’ve selected for the effect, performing Click Removal will have no effect (no pun) on the audio. And each time that happens, I’m presented with this dialog:

…That is not an important enough message to interrupt my entire workflow with! Heck, when it comes to a “cleanup” effect like Click Removal, it’s not even a problem — if the effect has none, when applied to a section of audio, it just means that audio was already in good shape. There’s no problem there.

I’m not saying Audacity shouldn’t tell the user, when an effect doesn’t change the audio it’s applied to. But a dialog box doesn’t just tell the user — it forces them to stop all of their other activities and respond to the message (by clicking “OK” in the dialog), before they can get back to work. Interruptions like that are like speedbumps, every one threatens to ruin your concentration and derail your train of thought.

There has to be a less disruptive means of providing feedback to the user, in cases like that where the message doesn’t even necessarily represent any sort of problem, and certainly not a problem that warrants interrupting their work and forcing them to respond to it immediately. Possibilities include:

• A message in the status bar
• Some area of the interface turning red briefly, or flashing red a few times. (The selected waveform, perhaps, or the background of the current track.)
• A floating (but non-clickable) message that pops up over the selected waveform, and disappears when the selection is moved or the effect parameters are changed.

The commonality between all of those suggestions (which are far from exhaustive) is that they require no response from the user, and they don’t create any barriers to the user proceeding uninterrupted with whatever work they’re hoping to accomplish.

I’m singling out Click Removal here, but I’m sure it’s not the only example of an effect being too disruptive with its feedback. Dialog boxes are an ugly pattern in UX design, and overreliance on them is the enemy of productivity. They should be used very sparingly, and only after carefully considering whether the message being presented is important enough that it justifies forcing the user to stop whatever they’re doing, and switch gears in order to immediately read and respond to a message.

[ferdnyc]

What’s frustrating is that, with that dialog box, Click Removal is treating an unaffected waveform — which, again, is not a bad thing when running a cleanup plugin — as an error on the exact same level as, say, an invalid selection:

I might argue that even that information isn’t really worth interrupting the user’s work, if it can instead be presented in a non-disruptive manner. But at least it’s an actual problem that requires correction. Unaffected audio, 99% of the time, is NOT.

(Further proof that Click Removal is treating an unchanged waveform as an error, when it’s not: Anytime it fails to modify the audio, its settings don’t get stored as the current “Repeat effect” menu selection.

So, if I run Click Removal and my settings don’t change the current selection, I can’t quickly repeat those settings on a different selection using Ctrl+r. It only gets enabled as the repeatable filter once it does change some audio. …That simply doesn’t make any sense. Just because some settings don’t affect one particular piece of audio doesn’t mean I don’t want to apply them to some other section. The two things are unrelated.)

[steve]

@ferdnyc

Heck, when it comes to a “cleanup” effect like Click Removal, it’s not even a problem — if the effect has none, when applied to a section of audio, it just means that audio was already in good shape. There’s no problem there.

Unfortunately that’s not actually true.
Audacity’s Click Removal effect is very old and very basic. It is very effective on certain types of clicks, but due to the very simple algorithm there are many kinds of clicks that it is unable to detect.

When it says “Algorithm not effective on this audio. Nothing changed.”, it means exactly what it says: The algorithm was unable to detect any clicks, so any clicks that were present are still not fixed. It does not mean that there aren’t any clicks, just that there aren’t any clicks that the algorithm was able to detect.

The actual solution is for the algorithm to be replaced by a better click detection algorithm. (Developing good click detection algorithms is a surprisingly difficult task).

[ferdnyc]

@steve

The algorithm was unable to detect any clicks, so any clicks that were present are still not fixed. It does not mean that there aren’t any clicks, just that there aren’t any clicks that the algorithm was able to detect.

But that still assumes (a) that there are clicks in the selected audio that it can’t detect (which presumes far too much about the user’s selections), and (b) that the user can do anything about it, even when there are.

As you say, the algorithm is imperfect — but it’s also the algorithm that’s available. It’s not as if there’s a better algorithm waiting in the wings to be employed; if there were, we’d already be using that one.

So even if the lack of modifications to the audio is a failing of the algorithm, it’s still not an actionable event for the user. Not definitively, anyway. Yes, maybe it means they need to tweak their settings to have more effect. Or, maybe it means they’re SOL unless a better algorithm comes along. Or, like I said, maybe it means they’ve selected audio with no clicks in the first place.

At LEAST two of those three situations are non-speedbump events that shouldn’t impede the user’s flow of activity. (I’d argue, all three, as long as the indication of ineffectualness is prominent enough to catch the user’s attention without having to commandeer it.)

[steve]

Personally I like to know when an effect fails. I hate silent failures.

Yes there are much better click removal tools available. (I use “Gtk Wave Cleaner”, which is good, but I think it’s only available for Linux.)

[ferdnyc]

@steve

Personally I like to know when an effect fails. I hate silent failures.

As do I.

(Edit: But, note, there’s still this conflation of “doesn’t change the audio” with “failure”. A cleanup plugin not altering the audio is not always a failure! Sometimes, there’s just nothing to clean.)

But even when it is, I presented several options for communicating the failure to the user without monopolizing their attention and stopping all of their activity. It’s the idea that the only way, or even an appropriate way to communicate that failure is by popping up a dialog box, that I’m calling out here.

And the thing is… really, I was taking it easy, with my description of the effect dialogs here, in the interest of staying focused and not drift into wider questions of UI design.

But if I do go down that road, really I believe that a UX is broken whenever ANY dialog box is displayed that contains only a single button.

A dialog box requires that the user stop all activity, shift their attention to it, consume the information it’s present, and then respond to it. It’s appropriate only when the user must make a decision, and they must make it immediately before any other activity can be allowed to continue.

But a dialog box with one button isn’t presenting the user with options. It’s not a decision they have to make right now, in fact it’s not a decision at all.

When a program shows a dialog box with a single “OK” button, it’s demanding an immediate acknowlegement from the user. Which is a complete role inversion. Is the software there to respond to the user’s commands, or is the user there to respond to the computer’s demands for attention?

My software should never require me to click a button, so I can prove that I’m listening to it and giving it the attention it apparently craves.

[steve]

The algorithm cannot know if it failed or if there was nothing to clean, but if there was nothing to clean, then why would you apply the effect?

So let’s assume that you applied “Click Removal” because there are some clicks in the audio. How do you suggest that Audacity informs you that no clicks have been fixed (so as to avoid failure without notification)?