Re: The top three big problems, Summing up # 1

  • From: Veli-Pekka Tätilä <vtatila@xxxxxxxxxxxxxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Sun, 14 Oct 2007 13:23:42 +0300

Some comments on points 2 and 4. Yup, you are right, when I write code I
want to hear exactly what is being typed. However, If I read code that
has compiled correctly, then reading the semantics of the code, as
understood by the parser, would make understanding code easier for me.
The whole point of the interpreted mode is that it should be language
specific. It should predictably shorten common language idioms and
constructs as to make them shorter reading than they would otherwise be.
preinc is shorter than plus plus, however pointer to pointer to is
significantly longer than "two stars" so here some alternative
expression would be needed. But you can go too short, too, in which case
the added brevity actually doesn't make the code any easier to read.
Using the word ptr in stead of pointer, might be some such thing.
However, struct is C jargon, structure would be needlessly longer. By
the way, perhaps you could also use the pitch indicates nesting level
idea outside of lisp, too, for parens in complex expressions.

And going even further, maybe you could have the system be customizable
to understand common conventions. Windows and SymbianOS coders use
Hungarian notation to denote important things about the types of
variables. Sometimes these are read quite bad HINSTANCE becomes
"hinstance" in stead of "h instance" or "instance handle". Typenames
like CALLWNDPROC, TDesC or variables like wparam are no fun reading with
speech, either, all of these are read as words by Meridian Orpheus.
Generally case changes or underlines are taken to be word separators in

Actually the problem I have with hotkeys is that if there are many and
they are not awfully mnemonic then I don't use them. I still don't
recall what my read line hotkey was in the reader, actually it appears
to be numpad 7, I use cursor up, cursor down, which results in the
current line being read, is screne reader agnostic, and is something you
can reason about on your own.

In stead of separate hotkeys I would actually prefer a single hotkey for
switching between two modes raw and interpreted. You could then use
regular Windows text editing keys to move around, and have a screen
reader like readout of the code either interpreted or raw. What I mean
by regular is the hotkeys that work in notepad and the conventions that
Narrator uses to read bits of text when you use keys like up/down,
ctrl+left/right, home/end etc... You could try this out in Windows to
get an idea of how screen readder users expect this to work. The word on
the left of the cursor is what is read when you move words in all
Windows readers. Apple chose the word on the right, and this made me
make a huge amount of off by one errors on trying to select text on a
Mac. So convention is important, even though the choices may be
arbitrary in the end.

As for the error log. When it is visible, would be quite nice if you
could discover it without having to recall the hotkey that gives it the
focus. MAybe you could use ctrl+tab or shift+tab to move to other
fields, even when tab inserts tab characters in a text field. Another
intuitive choice would be focusing the error log when there are errors
after a compile. And of course a menu choice like: view, error log
activatable with alt+v, e. Again I wish you could cursor around and read
the error log similarly to any other text field.

One problem I have with the Visual Studio error log is that if there are
multiple errors in the same file, and the path is long, the path is
redundantly repeated before every error. A view which would group errors
by file and mention each file only once would be much speech friendlier

I don't use line numbers so refering to line numbers, if you can go to
the line with enter, might not be necessary. I would be far more willing
to have an overview of the faulty line as a whole, or a couple of lines
around it, in-line in the error log. This would be useful on glancing at
upcoming errors without yet hitting enter on any of them. Such a view
should be optional. Maybe one list of errors, and another field to show
more info about the current error including the code preview and context
such as in function main on trying to call DoExampleL.

With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:

Andreas Stefik wrote:
> 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.
View the list's information and change your settings at 

Other related posts: