[BRLTTY] Explicit toggle change

[Dave Mielke]

[quoted lines by Stéphane Doyon on 2013/10/24 at 23:29 -0400]

>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 disaghree. Sometimes you actually do want to verify whether or not something 
was heard.

>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.

The alert tunes are a kind of language, so let's consider this from a speech 
perspective. If pressing FREEZE+on the second time wewe to respeak "the screen 
has now been frozen", any user would conclude that the software is flaky. 
That's how it feels to me when I rehear the tune when, in fact, no action 
needed to be taken.

>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? 

Can you think of a nicer tune that sounds more like a warning or notice than an 
error?

>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. 

I've done that more than once. I've even, on occasion, gone as far as rebooting 
the system because I thought my keyboard had gone dead simply because I'd 
forgotten that the braille screen was frozen. :-) Perhaps that sort of thing 
happens way more to me due to the huge potential for distraction here.

To me, though, this is another topic which I'd also like to discuss. I myself 
wouldn't mind a single, short tone played every half miute or so while the 
screen is frozen.

>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. 

How common does something need to be before it should be provided? It's not all 
that common for a shopping mall to catch fire yet they still offer fire alarm 
triggers and fire hydrants. To me, a feature should be provided if its use can 
be anticipated, even if its use will be predictably infrequent. I believe in 
being proactive rather than reactive. Those who always insist on a business 
case first are NEVER ready when their users first perceive a need.

>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.

Yes, I agree. Back to the speech example. What it should say is "already muted" 
rather than "what kind of stupid action did you just request". I just put 
something there, but, as always, am wide open to improvements. Perhaps you can 
come up with a better tune.

>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.

Sure. Even simpler might be to just play the appropriate tune twice, as in "ON 
pause ON". .

>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.

Yes.

>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.

I was focusing more on FREEZE, and had forgotten that CSRTRK+on has a side 
effect. FREEZE+on/off also does have a side effect because of the way the code 
is written. That could be undone, of course, but at the expense of messing up 
the code. The issue is that freezing/unfreezing the screen requires action 
within the code to be taken in addition to merely flipping a toggle.

>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...

Yes, I understand. As mentioned above, I'd actually completely forgotten about 
CSRTRK+on having a very useful (and in use) side effect. This has just now been 
fixed.
 
-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/