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._______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
