[BRLTTY] Explicit toggle change

[Stéphane Doyon]

On Wed, 23 Oct 2013, Dave Mielke wrote:

> [quoted lines by Stéphane Doyon on 2013/10/14 at 17:34 -0400]
>
>> in r7287 you have "Indicate via a tune if an explicit toggle change
>> is redundant."
>>
>> Can you explain the rationale?
>
> It was bothering me more and more that a tune indicating an action was being
> played when, in fact, no action was being taken. The worst offender was the
> FREEZE toggle.

Really? I don't think I would have seen that as an issue. Did you often 
refreeze an already frozen screen?

> It seemed quite harmless to me to introduce a way to indicate
> that the toggle was already in the intended state. In all similar instances I
> can think of, like a mute switch when on a teleconference, this kind of
> indication is, in fact, extremelye valuable.

I'm heartily with you about the teleconference mute. I also hate that 
recorders typically pause if you press the record button again while 
already recording.

> I can't imagine why anyone would
> ever want the position of a switch to be invisible or unverifiable.

Fair point. But for our toggles, we're not so much probing for the state, 
as asking again for a state change (because we have a doubt or we forgot). 
With the mute button, if I have a doubt whether I'm muted and can't check 
some status light or label, I'd want to give it the command to "do mute me 
now". What I mostly care is to be confident that I am really muted after 
that action. It is true it might be nice to know whether I 
had been already muted or not before the action, although to me that's 
secondary to confirming that I've reached the desired state.

I'm not sure why you feel replaying the freeze toggle sound is especially 
inappropriate. What I like about that particular sound is that it's 
distinctive, while for most (all?) other toggles we have generic on/off 
sounds. I love that the sound for freeze tells me not just whether it's on 
or off, but I can also recognize the command, I can confirm yeah it's 
really freeze screen that I did, I didn't press the wrong keys (fumbled 
fingers or unsure of the bindings). So to me that sound seems valuable, 
even if no state change occurs, as it confirms to me I have obtained the 
state I wanted. I do see your point that it doesn't tell me whether it had 
already been frozen. I'll admit that cursor tracking is the only explicit 
toggle I use, one of only two bound for my displays, so maybe my 
perspective would be different if I used explicit toggle changes more.

The sound you have added to indicate the state is already as requested, 
just conveys to me "error, you did something wrong". I guess I see your 
point that asking to freeze when already frozen does not really make 
sense. But then clearly the user is mistaken, do we need to rub their nose 
in it? The only scenario I can think of where the knowledge would matter 
to the user might be if they were waiting for some screen change and might 
have missed it if somehow they'd been frozen without realizing. Back to 
the teleconference example: I suppose there is value in being able to 
check if I was muted, to know if the other participants heard something I 
did not want them to; but this scenario still feels just a little bit 
uncommon. Now suppose I press mute, and in response I get an error buzz. 
Does that mean I was already muted, or does it mean the mute isn't 
working? That's why I'm a little uncomfortable with your new sound.

Well, what if we had both? Play the on tune and then an already in state 
tune, that way you get both pieces of info that the state is confirmed 
plus that you were already in that state before.

> The same is true, for example, for me when I switch between six-dot and
> eight-dot mode. Perhaps I'm just odd, but I don't mind finding out that I was
> already in the intended mode.

Fair enough, but I don't want to be made to feel that I'm required to keep 
track of that state. Giving me additional info yes, telling me I did wrong 
for not memorizing my state correctly, not so much. It's not necessary for 
me to remember whether it was already in 6 or 8 dots mode. That's one 
recognized problem with modes in user interfaces. So if the sound could 
first confirm the state, and additionally carry the info that we were 
already in that state, I think we'd be in a good place.

> That's understandable. Is it, however, an argument for removing the tune for
> being already in the intended state or for treating CSRTRK+on as a special case
> since it has an additional side effect?

That's interesting, because so far all we've discussed is the feedback 
sound. Your motivation for playing an error beep was to indicate that no 
action is being taken, and you explained you wanted to make it possible to 
discover the state of the toggle. But actually you've inadvertently 
changed the behavior to prevent it from taking any action when already in 
the target state. I could see this being valuable if something destructive 
would happen by reenabling the already enabled state. But as far as I can 
tell, the only toggle that has a visible side-effect is cursor tracking 
for which the side-effect was desirable.

Today I had to work for a few minutes on a laptop that wouldn't play the 
beeps (some sound misconfiguration I guess). Having to remember the cursor 
tracking state was an annoyance, it got confusing. Plus going to the 
cursor requiring either two button presses or the less finger-friendly 
HOME binding on my display...

> I myself believe it to be the latter,
> and must then ask if it's better to deal with the special case or to merely
> tweak it into working right by removing what may well be, in all other cases, a
> useful feature.

Maybe having the side-effect makes it a special case. It's hard to 
generalize from a single case, we'd need a couple more toggles with 
side-effect. However for freeze or 8/6 dots, I feel I'd still prefer to 
hear confirmation of the obtained state in priority to hearing about there 
having been no state change. Maybe that's just me being used to hearing 
the on/off tunes, but it seems to me richer feedback to have both pieces 
of info. You could invent tunes for on-and-was-already-on and similar for 
off, but then we'd lose the nice distinctive sound for freeze, so I still 
think playing two sounds back to back might be better: the obtained state 
as before, and then an indication that there was in fact no change.

Oh OK here's a tune suggestion: for already on, use: {
   TUNE_REST( 60),
   TUNE_NOTE( 30,  86),
   TUNE_REST( 30),
   TUNE_NOTE( 30,  86),
   TUNE_STOP()
}
What this does is repeat the last note of the toggle_on tune twice, with 
appropriate delays. It's like reasserting it, hammering it. If you play 
toggle_on followed by this, it says to me: it's on, yeah it's on already, 
really on.
You'd do similarly for already off, repeating the last note of toggle_off.

> Exactly. I believe that CSRTRK+on really is a special case. We should fix it so
> that the side effect is restored.  What, however, should we do with its tune?
> We could have it still play the ON tune. We could make it silent if cursor
> tracking is already on.

Hmm silent if already on could actually be a good idea in this case: since 
the display moves, there is an immediate visible effect so sound feedback 
is not entirely necessary for this situation.