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

Sat Jan 7 22:24:22 UTC 2012

Hi Ben,

Thanks for the input.

I will check around the college to see if I can find a proficient AutoCad
user. I expect that I can find one, because one of the other departments
teaches courses in that general area. I would really like to see how that
user interface works.

Dick Baldwin

On Sat, Jan 7, 2012 at 4:09 PM, Ben Humphreys <brh at opticinspiration.org>wrote:

> 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/ <http://www.austincc.edu/baldwin/>
>> ______________________________**_________________
>> Blindmath mailing list
>> Blindmath at nfbnet.org
>> http://nfbnet.org/mailman/**listinfo/blindmath_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<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/brh%40opticinspiration.org>
>>
>
>
> ______________________________**_________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://nfbnet.org/mailman/**listinfo/blindmath_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/**
> baldwin%40dickbaldwin.com<http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com>
>

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