Mind you, I never asked you any sleepless nights. That's your dicission!
Well, I could go on with a few more questions here, but will drop it for
now, and
rather be back, when your product comes out. But, as my questions might
already have
given you a clue of, you see that a FULL screen reader needs do more than
just 'read'
the screen. If, for instance, your software only lets me SCROLL through 150
links
on a webpage, well, sorry, but that won't keep water... :) ALL mainstream
products,
will have commands, to quickly find next link, next heading, next table, and
navigating
inside a table. If you don't know, what I am talking about, or you don't see
the
need for this... - Hmm, then I am sorry, but you'd better sit down and
close your
eyes for three more hours on the web. Hope you don't find me impolite here,
but really,
that is the real life. At least, if you want to claim your software to be
more efficient
than the screen readers known to the public.
You mention the learning curve of shortcuts? BELIEVE me, I do know what I am
talking.
If you noticed my last paragraph in my prior message, I have been teaching
computers
for a handful years. Teaching sighted people, and blind ones. Mostly blind
ones,
actually. And, agree, there is a learning curve, but that mainly applies to
learning
computing in general. Most users will grasp the shortcuts in a very short
time. Learning
to operate a mouse, that you don't have the visual feedback on, is a FAR,
FAR, and
let me repeat that fifty times more, F A R bigger learning curve. But, we
will see,
when your product is out. Several products, I have seen, have tried to
accomplish
the task of letting the blind user handle the mouse. Noone, and I repeat
this again,
noone, have managed to take over the screen reader industry yet. Why, do you
think
that is? Well, I am not saying this to discourage your job, and I think it
only can
be fairly told, if you let blind people thoroughly test your product, for a
good
portion of time. Noone should be judged, without a fair trial; neither
should you
and your product. Yet, your concept of useing the mouse, letting some kind
of speech
give the user feedback, is NOT anything new. There is, on the other hand, a
good
reason, and a really good one as well, why the mainstream products that we
know,
and have known from the earliest computer days, do NOT leave the blind
person relying
on the mouse for his orientation on the screen. You might find this rather
strange,
since you are used to your mouse. As already pointed out, closing your eyes,
trying
out your mouse, is no real test. You do know your screen, you do know your
software,
and you do know your applications. The real challenge is for a blind person
to know
any of these.
Another thing to take into account, is the fact that most blind computer
users will
already got used to their screen reader. Switching from one screen reader to
another
- well, I have been doing that a numerous ammount of times, and actually
been working
with more than one screen reader paralel many times up through the years,
specially
in my time as a teacher - having to adapt to the actual screen reader of my
student.
Even if the one screen reader handles things slightly different, even if it
has another
shortcut for jumping to next link, well it doesn't make much for a switch.
But to
learn navigate the screen with a - for most of the community - brand new
device such
as the mouse? Again, it has been tested in several products, and so far,
never really
worked well. My earlier message gave you a few ideas of how little chance
the blind
person has, for knowing where his pointer is, compared to where his physical
plastic
equipment in his hand, actually is located in the real world. Yes, I am
blind, and
hence speak out of mere REAL WORLD experience, not just out of
closing-my-eyes-for-ten-minute
experience. Agreed, if that is the test you are able to do, you never can
talk out
of any more experience. And, that is, why I encourage you to let out your
product,
have blind people test it, and open your ears wide for any feedback they
might give
you. Yet, I do think you might want to be prepared, that here we are talking
REAL
challenges.
Since you attacked the mainstream products, I just want to point out to you,
that
so far, we haven't even touched the matter of set files, and scripting. Of
course,
I don't know your product, but if it is to keep water, some kind of user
adjustments
for each application, will be a MUST. This simply due to the fact that users
are
different, and so is applications. Also, do keep in mind, that not all of
the info
on the screen is of the same importance. For the user to have the chance of
deciding
the info he wants to hear, and when to hear it, is of outmost importance.
For you,
as a sighted person, it is a matter of a glance, and you will see the change
on the
screen, and things that are capatilized, in bold, underlined, or in any
other way
marked as outstanding. For the blind, this is not possible. He will neeed to
either
rely on the software (that is, the scrteen reader, in most cases) to give
him the
most important info, or he will have to know his application, and define and
save
his settings for what to be read, when to have it read, and in what order.
In Window-Eyes,
for instance, this can be done in three ways:
1. By use of USER Windows.
2. By use of set files, of which there is several handfuls right out of the
box,
and the user can either create his own or modify the premade ones.
3. By scripts.
Unless your software has at least one of these features implemented, I am
afraid
it pretty soon will fall short. If the user cannot have the chance of
tayloring the
way of having info from the screen presented, it would mean, for him to have
to rover
the whole screen every so often, so as to keep updated on what's going on.
Particularly
so, since most software develoers now aday, seem to enjoy spreading the info
all
over the window, and not even always make the same kind of information pop
up on
the same spot of the screen at all times.
Your testing, I am fully convinced, is how well you have the ability to do.
And thanks
for all your hard work. Noone ever will ask you test things, that you don't
have
the ability, or resources, to do. If you don't own an Office suite, I do
understand
you haven't had a chance to test the product in things like Word, Excel and
Powerpoint.
Yet, many - if not most - of the blind users do have Office, and actively
uses it
every day. And believe me, in things like Excel, it does make a whole lot of
a difference,
how things are presented. So, it will be quite interesting to test your
product in
things like that. Also, places like the Volume screen in Windows itself,
where you
have trackbars that show which level your volume of the different parts of
your sound
card has been set to, will be an interesting thing, since you here will have
to let
your software actually do some kind of translation, from the graphical
trackbar,
and into some kind of spoken word. That is but a few things, that will be
really
interesting to see.
Moving from clip to clip? Is that a wish? Sorry, but NO! That is a
requirement. Without
that, the user might have an even harder time to navigate his screen. Well,
at least,
that is my experience, and I am sure several people will back me on that
one. So,
make sure that is implemented.
Well, I will drop you a few more questions, just to make sure your product
will have
the very basics, before shipping. And, mind you, we are talking basic
requirements,
not necessary basic programming (said from a programmer himself):
1. When a dialog pops up on the screen, letting the user know what is going
on, or
required, what does your software do about that dialog?
2. If I want to have the status line of my application read aloud, will I
have to
move the mouse down there, read what I want, and then make my way back up to
my actual
work? Or, how do you solve that one, without a SHORTCUT KEYBOARD COMMAND?
3. How does your software handle different kinds of graphics, or icons? -
Simply
just skip them, or do you have some kind of dictionary, that translates them
into
spoken information? And, in case, are these user editable, and user
buildable.
4. What kind of choice does the user have, when comes to the speech output,
and its
settings. Things like, choosing different voices, speed, volume etc.
5. Does your software offer the user any exception dictionary? Well, maybe
you don't
know what that is, so let me just explain quickly: An abbriviation like ETC
will
normally be spoken like one word etc, by the speech synthesizer. An
exception dictionary,
will tell the synthesizer to recognize, and transform, the abbriviation, and
make
the outspoken information etiher sound like "E T C", or "Eet Cetra". Such a
dictionary
should be user-definable, and there wil be the need for a general one, as
well as
an application specific one, for each application, where you might have
special words
and abbriviations. Furthermore, there will be a line of words, that the
synthesizer
will not know how to pronounce correctly, and hence the dictionary will take
care
of all that.
6. If your software is to keep up with the mainstream products, there need
to be
a chance for the user to quickly skip to things like next paragraph in a
text.
7. To just illustrate this point, open the built-in calculator of Windows.
Then enter
a piece of math, let's say 3+5+9-12, and press Enter. What does your
software do?
Does it read the result? Or, do I have to somehow, who knows how, search my
way around
the screen, so as to hit the spot, where the calculator happened to place
the result?
This point, does apply in a long line of applications, and should leave you
a bit
of an idea, of what I said earlier about reading IMPORTANT information
automatically
for the user. Bet you, there is no really easy way to know, where, and what
info
is important, hence you see the need for the user to be able to predefine
some kind
of adjustment for the given software.
Well, I'd leave you with these questions for now. As I said in my intro,
there will
be several more. We haven't even touched the questions that has to do with
Braille
output to do, and won't do so, till we see your first Beta. Just mind you,
there
is drivers and other goodies to mess around with, somewhere down the road.
Your product
will be interesting, but make sure it meets the basics, in a way that is
workable.
Hmm, what did that last statement mean? Well, if the user will have to
listen to
a load of 'smalltalk' all the time from the screen reader, he will first get
tired,
and later on, his ears will fall off. (smile!) It is of outmost importance,
that
he will get the info he needs, in every given situation - no more, no less!
I have
to admit, that I do have a hard time, realizing how you would ever build a
fully
functional, workable, screen reader, without having to make excessive use of
keyboard
shortcuts; of which you seem to have a good deal of paranoids. So, I am
quite eager
to see what solutions you come up with. If you manage to get the blind
community
to switch over, starting using the mouse, then congratulations! You
definately will
have performed a brag. Meanwhile, please, don't pull down anyone, or
anyone's product.
When your software is out, and we can test it, we will see what amazing
things you
have accomplished. Till then, let me not be criticizing, only sound minded
critical,
asking the questions needed to have the very least amount of functionality
built-in.
And, the day your software can perform the same as, or rather far better
than, the
competitors, well then you can start criticizing; in a constructive way.
That will
benefit all, if you can add on to knowledge, or ask questions well thought
over,
and make your points clear.
Just quickly at the end:
You say that you spend hours on trying to handle Window-Eyes, right out of
the box?
Ok, don't know, what your definitions are here. Till now, I have seen just
about
NO SOFTWARE from ANY VENDOR, on which a new user hasn't spend hours, in
learnign.
Actually, I did switch to Window-Eyes, myself, only a couple of years ago.
And, yes,
it took, a few days to get used to it. Still, after this long time in use,
there
is things I don't know about Window-Eyes, and its powerful features. That is
what
the mailing list, and the manual are fore. But, so was the case, when I did
start
out with any of the numerous screen readers I been through down through
history.
There is ALWAYS going to be a learning curve. Some might have a short one,
others
a longer. And, you will have to put out a PRETTY GOOD software, being in the
nature
of a screen reader, if you'd expect your users not to have a good portion of
a learning
curve. After all, I don't see the length of the learning curve to be the
biggest
deal. The main points are, if the software will let you up and run - even in
a 'beginner'
mode - right away, leaving you the chance of learning as you move on. The
other thing
is, how easy is it to learn things along the way, i.e how well is the manual
written,
how logical are the commands, how much help does the screen reader
implement, and
how friendly is the support.
For you, being a sighted person, to claim that the software has a too high
learning
curve, I don't really find all that fair. First of all, to know whether a
product
has a high learning curve, you will have to take all aspects into account.
Everyone
knows the keyboard - or at lieast, wil have to get to know it, before ever
handling
a computer. The keyboard is a static input device, that doesn't move around,
and
it's pretty well tied to the cursor on the screen. The mouse is none of
these, hence
will by far, implement a higher learning curve. The way the mainstream
products present
the screen info, right out of the box, has well been tested, and thought
through;
so as to namely help the beginner get running. If I, as a blind person, got
a software,
which opened on my desktop, leaving me no other info but what was just
happening
to sit under a mouse pointer I don't even see... Well, and then left me on
my own,
having to roam about with that mouse pointer I don't see, hoping for me to
get an
idea?? :) Well, we will see when you decide to let out that cat of the sack,
and
let us have our hands on the product.
Once again, I never meant to discourage any newcomer, and their ideas. Only
I do
not think it is a good idea to introduce any product by knocking anyone else
off
the scene. Specially so, when you are not finished with your product. And,
as already
stated, it is proper for the community to be a bit skeptic, asking critical
questions,
demanding actual features. Specially so, since things like this have been
tested
out several times before, with little positive results. Further taken into
account,
that the users are the ones that will know best. I am dropping this message
on the
mailing list as well, hoping for the community stopping to be criticizing,
and rather
fill me in, when comes to requirements for your screen reader to be water
proof.
Unless it can hold water, I am afraid you will sink, even before you learn
to swim;
and so hope the community could let you see, that the reason why Window-Eyes
and
Jaws and the rest of the gang, do charge money, is because there is a ton of
work
behind the product. Be as it will, the price might be discussed, and in the
future,
might be adjusted. If you can come out with things that will contribute to a
lower
price in the general market, then OK. But make it waterproof, and make it
solid enough
to work on the same scale of platforms and applications, with teh same
amount of
choices for speech synthesizers, and Braille displays. Then, claim you have
done
it. Otherwise, go ahead, release your screen reader, and let it be a more
affordable
- lightweight - product, for the people who cannot afford the big mainstream
products,
or who don't demand the same high productivity. There is space for such
products
as well, so don't give up. But just keep in mind, that if you Really want to
benefit
the blind, the best thing is to listen, built your product, and leave the
competitors
alone. Or, of course, even better, share your expertise. That is something
there
is way too little of, in this market: Sharing of expertise. Way too often we
see
users, and vendors, pegging on each other, instead of being constructive.
----- Original Message -----
From:
shane findley
To:
David
Sent: Thursday, September 02, 2010 9:39 PM
Subject:
Re: GW Micro Responds to the Future of Screen Readers Discussion Panel
Questions
Hello David, I appreciate you polite questions, and the time you took to
engage.
I have not slept all night working on Windows 7, to get those list items
back.
I got them back, after over filtering them during the last update.
I've spent alot of hours, all summer long to strive for best possible
product.
My full code library is in this project.
----- Original Message -----
From: "Ray Campbell" <[email protected]>
To: <[email protected]>
Sent: Thursday, September 02, 2010 9:49 PM
Subject: RE: GW Micro Responds to the Future of Screen Readers Discussion
Panel Questions
Hi All:
What Shane is describing about the mouse sounds very much like a product
that was out for a while about 10 years or so ago called Screen Rover. The
concept was you moved the mouse, and the screen rover would cause the mouse
to guide your hand to something on the screen. There was a speech output
component to this as well. While I thought it was an interesting product, I
felt that using products like Window-Eyes was much more efficient.
With all of the keystrokes we have in Windows, there really isn't a need
from my perspective for a person who is blind to know how to work the mouse.
This is not to disparage Shane's or anyone else's work. What can't you do
with the keyboard, including mouse equivalents like you have in Window-Eyes,
that you can do with the mouse?
Thanks,
Ray Campbell, Adaptive Technology Help Desk Technician
The Chicago Lighthouse for People Who Are Blind or Visually Impaired
1850 W. Roosevelt Road
Chicago, IL 60608
312.997.3651 (Voice/Relay) or 888.825.0080 (Voice/Relay)
[email protected]
www.chicagolighthouse.org
If you reply to this message it will be delivered to the original sender
only. If your reply would benefit others on the list and your message is
related to GW Micro, then please consider sending your message to
[email protected] so the entire list will receive it.
GW-Info messages are archived at http://www.gwmicro.com/gwinfo. You can
manage your list subscription at http://www.gwmicro.com/listserv.
If you reply to this message it will be delivered to the original sender only.
If your reply would benefit others on the list and your message is related to
GW Micro, then please consider sending your message to [email protected] so
the entire list will receive it.
GW-Info messages are archived at http://www.gwmicro.com/gwinfo. You can manage
your list subscription at http://www.gwmicro.com/listserv.
