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