[Blindmath] How useful is a GUI to blind users?

[Ben Humphreys]

Richard,

May I propose you  sit down with a proficient AutoCAD user and ask 
them to draw things for you and watch the process unfold?

The AutoCAD interface today still uses a command-driven window with a 
text-response format nearly identical to that from 20+ years ago.

For those not familiar with the AutoCAD command-response format, 
think of logging into an FTP server.  Better yet, if you can, bring 
to mind the command-response interface of a Cisco router or 
switch.  You have hundreds of commands available to you.
There are different "modes" of operation each identified with a 
unique prompt.

In the case of Cisco, only the first few unique characters of a 
command are necessary before specifying other parameters or pressing 
Enter.  I believe Tab may be used to rotate through the commands with 
partial matches.

Commands may specify parameters or the user may pres Enter and be 
prompted for the most common ones.

In the case of AutoCAD, the "arc" command comes to mind.  The user 
types "arc" and presses Enter and a number of first-character menu 
choices are presented, each which then asks for further input.

Other examples of instances where a text-based interface was vastly 
superior for me was when using a Computer Algebra System this 
semester.  I used both Maxima and Maple.  In both cases, the 
Java-based interfaces were a disaster but when I found the "dos 
style" command-driven program, my productivity skyrocketed.

One great benefit of a command-driven interface is the ability to 
save the commands used to produce a result in a text file and later 
run it as a script.


This all starts to sound increasingly similar to an interactive Logo 
programming interface.

And if you look at the original design goals of Logo, you can 
appreciate the applicability of those goals with blind users of a 
drawing program:

 From Wikipedia:
"Its intellectual roots are in artificial intelligence, mathematical 
logic and developmental psychology.

The goal was to create a math land where kids could play with words 
and sentences. Modeled on LISP, the design goals of Logo 
included  accessible power and informative error messages.

The use of virtual Turtles allowed for immediate visual feedback and 
debugging."

More generically, I find a screen-reader running on top of either a 
GUI or menu-driven interface both problematic.  I think emacspeak has 
the right concept -- design an interface from the beginning which 
gives and receives the information the visually impaired user is 
likely to need in a format which makes sense to them without regard 
to visual presentation.

I believe a text-based command-driven interface like that of AutoCAD, 
Cisco products, an FTP server, or the command-window versions of 
Computer Algebra Systems are all great examples of this concept in action.

And as for visually impaired users, I can speak only from personal 
experience.  But as my vision deteriorated all the way down from 
20/100 to nearly nothing, I always preferred the clear chrisp 
characters, excellent color on black contrast, and predictable text 
placement of the standard 80x25 console interface over the 
increasingly high-resolution of the GUIs.

Finally, if moving from a GUI which stymies your productivity to a 
command-driven interface increases your productivity significantly, 
then I think it's a great trade-off.

Personally, I'd rather see you spending time on real features, like 
the ability to name objects and associate them with one another 
instead of having to become a Java accessability activist.

Ben

At 10:45 AM 1/7/2012, you wrote:
>It occurred to me the other day that prior to the advent of the Graphical
>User Interface (GUI), the user interfaces for all programs were accessible
>for blind users so long as they had a screen reader that would speak the
>information displayed on the command-prompt screen.
>
>For those who are too young to remember, programs in that day prompted the
>user for input and the user responded in a back-and-forth dialog fashion.
>Once all of the input data was provided, the program ran and did whatever
>it was supposed to do.
>
>Another way that information was provided to the program was in the form of
>typed information (commonly called switches) provided by the user when she
>started the program running. Batch files were often created with a simple
>text editor to make this procedure less prone to typing errors.
>
>The one area where I see the GUI being particularly useful for a blind user
>is the file selection dialog. The use of the GUI dialog eliminates the
>requirement to type long path and file names. However, if the disk is
>organized in such a way as to keep the paths short, even this doesn't
>appear to be a significant advantage.
>
>For those who don't know, and without getting into the technical details as
>to why, there are major problems associated with creating accessible user
>interfaces when programming in Java. Using the SWT to create accessible
>user interfaces significantly reduces the power of the Java programming
>environment because it precludes the use of many excellent programming
>libraries.
>
>This causes me to wonder if, for those programs that are primarily intended
>for use by blind and VI users, it might make sense to go backwards in time,
>forego the GUI, and write those programs using the "old-fashioned" prompt
>and reply style of user interface. I would be interested in seeing some
>discussion on this topic.
>
>Dick Baldwin
>
>--
>Richard G. Baldwin (Dick Baldwin)
>Home of Baldwin's on-line Java Tutorials
>http://www.DickBaldwin.com
>
>Professor of Computer Information Technology
>Austin Community College
>(512) 223-4758
>mailto:Baldwin at DickBaldwin.com
>http://www.austincc.edu/baldwin/
>_______________________________________________
>Blindmath mailing list
>Blindmath at nfbnet.org
>http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
>To unsubscribe, change your list options or get your account info 
>for Blindmath:
>http://nfbnet.org/mailman/options/blindmath_nfbnet.org/brh%40opticinspiration.org