Re: The top three big problems, Summing up # 1
- From: "Andreas Stefik" <stefika@xxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Sat, 13 Oct 2007 20:09:04 -0700
le said: Thanks Andy for posing the question.
No problem, this is all extremely fascinating. So, ok, I'm going to
take a shot at summing up the important features, if I'm correctly
processing everyone's thoughts, in order of importance. Here goes
(Critiques welcome!)
1. A way to navigate in such a way that you can quickly jump between
pertinent program constructs. (End of method, end of block, beginning
of block, beginning of method). (Marlon, Will)
The debugger I've created allows you to "navigate" the execution of a
program, backward and forward. It sounds like it would be much more
useful if you could also, with the keyboard, navigate back and forth
between major events too, like "jump back to the beginning of the
method" or " jump to the end of this block. Code that isn't running in
the debugger could probably allow you to navigate in the same way,
making the interface aurally consistent, and navigationally
consistent, for both running and non-running programs, just the
program "speaks" different information. At runtime, it gives you
information about the values of variables, control flow, etc, but
while not at runtime it gives you static information.
2. Construct Preview.
Not sure what to call this idea. What if, while you are debugging or
while your cursor is at some position in the code, you can get a
preview of "what is left" in the rest of the block or the method.
Marlon, and others, suggested things like collapsing methods would be
cool. I'm thinking, perhaps if you can preview what's ahead of the
cursor, and what is behind, that this might simulate "hiding" of code?
For example, would statements like, "There are 10 statements left in
this method?" or something equivalent, be useful at all? (Maybe not)
Any other ideas for how to "hide" code using audio?
3. Optional ways to read the code, depending upon the context.
(Veli-Pekka Tätilä )
It sounds like, sometimes you want the spoken text to include words
that give you the semantics of what is happening in the program, while
other times you want the no frills syntax so you literally know what
to type. What about a suggestion like this:
You have two sets of key combinations. One shortcut will read the
syntax to the left or right of the cursor raw. Another shortcut could
read the semantics of the left or right syntax. For example, maybe
something like:
a * b, the cursor, if it were right before the b, could read either
"multiplication" or "asterisk," while the phrase
*p * b. If the cursor is right before the second asterisk, in the
language C, it could read, "pointer p" or "asterisk p," depending on
what key combination you pressed. This is a cool idea, I think because
it could adapt to whatever programming language you are using, to tell
you not only the syntax, but what the syntax means. What do you think?
4. Easier navigation of errors. (Marlon)
Right now I've got a multiline textbox representing compiler errors,
etc. If you could choose any system for how you access errors from
this box, how would you do it?
Like, should I just include a key combination that navigates you to
the box, then have another combination that reads the next error or
the previous error?
Great conversation, thanks for the feedback everyone. For sighted
person like myself, this type of information is solid gold.
Andy
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
