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

Sat Jan 7 23:06:57 UTC 2012

The only thing I would add to this is that tools like autocad, cisco routers 
and computer algebra systems are all tools aimed at people who probably have 
training in them or would be expected to spend time learning the tool. There 
is nothing in itself wrong with this, however you should consider whether it 
is what you want/expect of users of your tools. As an example, while cisco 
routers may use command line tools, many of the consumer routers for home 
use have web interfaces, there is an expectation that for home users it 
isn't exceptable for users to learn about how to manage a network before 
they can get a wifi system working, the manufacturers want it that anyone 
can pick it up and get going quickly. Also probably the home user would not 
want such an advanced system as a cisco router used by some businesses, 
therefore it can be acceptable to miss out features which aren't needed and 
so meaning the user has fewer options which they may set wrongly. In 
comparison those who do need the extra power probably will not find the time 
to learn the system is a waste as they may very well need all features 
offered and so will make use of all knowledge gained.

Michael Whapples
-----Original Message----- 
From: Richard Baldwin
Sent: Saturday, January 07, 2012 10:24 PM
To: Blind Math list for those interested in mathematics
Subject: Re: [Blindmath] How useful is a GUI to blind users?

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/
_______________________________________________
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/mwhapples%40aim.com 