ditto. yay Brian.
toggle quoted messageShow quoted text
On 1/8/2016 11:48 PM, Robin Frost wrote:
Your explanation is very well put and confirms that which I thought
about you truly having the gift of the heart of a teacher which is
different than merely knowing something.
*From:* Brian Vogel <mailto:firstname.lastname@example.org>
*Sent:* Friday, January 8, 2016 11:44 PM
*To:* email@example.com <mailto:firstname.lastname@example.org>
*Subject:* Re: Views on Keyboard Shortcuts to teach or, perhaps,
emphasize when teaching
Thanks to all for this fascinating exchange of ideas.
Laura, your question is not in any way dumb and it is very difficult to
answer easily. It's relatively easy for me to know the difference
because I can literally see the Windows keyboard shortcuts "reveal
themselves" as the sequences are hit, at least a large number of them.
I certainly, for instance, didn't know the keyboard sequence that was
used in Windows Live Mail to do a message search in its entirety,
particularly the ALT+i for the find now key, but as I work through the
process the first time with the client at each step Windows (or the
Windows program) shows the next character or characters that are part of
the sequence, allowing me to build the entire sequence for inclusion in
the step-by-step directions.
I am glad, though, to hear others saying that it is important to make
this distinction. The main reason it's important to me is that there is
a huge set of Windows keyboard shortcuts, the three best known being
Ctrl+C (copy), Ctrl+X (cut), and Ctrl+V (paste), that are used in
precisely the same manner in more programs than I can count. There are
many more that fall into the "extended common" set of Windows keyboard
shortcuts and I want my clients to understand that, if they're in a
pinch, and they know how to do "process X" in "program Y" that they
should at least try seeing if "process X" will get the same result in
different Windows "program Z."
The same concept applies to the JAWS layer as well, since you use the
same JAWS keyboard shortcuts to accomplish the same tasks in a wide
array of Windows programs.
If you know the difference between the two, though, and you have that
knowledge "in your bones" you can actually sometimes function if speech
goes south at a given point in time and still complete at least the
current thing you're trying to do like save a file.
Another reason it's important to know the difference is because
sometimes assistive technology like JAWS, ZoomText, or the like
"captures" what would be a Windows keyboard shortcut for it's own use.
My client gave an example of this last night, that he'd figured out on
his own. He generally uses either ZoomText or JAWS (much more JAWS
these days) separately along with whatever Windows program he needs
beneath it. The other day he had ZoomText, plus JAWS, plus some Windows
program open. One of the commands that we always used to perform a
function in that Windows program when JAWS was running alone suddenly
wasn't working in the Windows program, and ZoomText was doing something
he'd never seen before. He figured out for himself that ZoomText had
commandeered that particular command for its own use and, thus, was not
passed along to the Windows program running beneath it for processing.
I use the analogy of the various programs being like separate sifting
screens stacked one atop the other. The screen readers and other
assistive technology are always the topmost screen. They get every
blessed keystroke you hit passed through them first, and these programs
get to interpret those first, so if a keystroke sequence is considered a
command by JAWS, for instance, JAWS does it's thing with that sequence
and nothing from it sifts through to the program that is "the next
sifting screen down." Then, all of the keystroke sequences that JAWS
didn't snag as its own get passed down to the next sifting screen, and
for the purposes of this narrative lets say that's ZoomText. Now
ZoomText gets "first crack" at interpreting the sequences that have
passed into its hands, and acts on any of those it recognizes as "my
command." Then whatever is left sifts through and falls into the screen
that is the Windows program running below it for interpretation as
commands it processes. I think it's important for people to understand
that there exists a hierarchy and that AT sits at the top of that heap
and gets first crack at every keyboard input sequence to decide if it
"belongs to me" before passing what remains on to the next guy. Very
often this may be irrelevant to doing what you want to do, but it can be
key to understanding why "things that used to work" may work no longer
if some other AT program gets added to the mix that ends up siphoning
off commands that used to be passed through to other programs, so those
other programs never see them.
Heavens, but the above seems awfully wordy, but I really can't think of
a short way to describe the conceptual framework of program layers and
that knowing about it can make sudden changes in behavior on your system
a bit more understandable when new stuff enters the mix of programs
running at the same time.