RE: Sonified Debugger vs. Screenreader Question
- From: "Sina Bahram" <sbahram@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Thu, 22 Nov 2007 18:00:31 -0500
I'm very much heartened that you're not in research and that we have such
quality folks as Will and Andreas, and to a minor part: myself, doing this
type of work instead.
Take care,
Sina
-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of John Greer
Sent: Thursday, November 22, 2007 3:17 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Sonified Debugger vs. Screenreader Question
I think I can answer this one and save thousands of dollars worth of study.
Sighted people use a mouse but take the mouse away from them and they are
completely lost. Blind people use the keyboard shortcuts that are built
into Windows and the programs themselves to get around the computer. The f1
hotkey has been in Windows since the beginning of Windows but show them they
have to read in order to learn it and both sighted and blind get bored.
Present the information in a way that both blind and sighted can use and
they both can perform the same job. But the difference is because the
sighted person is the one doing the hiring, the blind person has to prove
they can do the job because, to coin a common phrase that all we blind
people hear, "They just can't imagine what they would do if they were blind"
----- Original Message -----
From: "Andreas Stefik" <stefika@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Wednesday, November 21, 2007 11:32 PM
Subject: Re: Sonified Debugger vs. Screenreader Question
> Sina asks:
>
> Are you going to be doing a goms analysis
>
> Andreas says:
>
> Not exactly. I've built a custom compiler, debugger, etc, that
> integrates speech based audio into the very heart of the compiler
> itself. The key advantage, as you might imagine, is that the speech
> audio can give hordes of information that visual studio can never come
> close to duplicating, as even the add-in architecture can't connect
> super deeply into the compiler (for technical reasons with the way
> visual studio's compiler/debugger architecture works).
>
> So, while GOMS analysis is largely, if I recall, keystroke level
> empirically derived analysis about the time it would take to complete
> tasks, our analysis is more about how effective the audio is for
> helping you program. I think GOMS estimates are built on sighted folks
> as well, so I have no idea how they apply to the blind community.
> (With braille keyboards typically, correct?) Have you seen a paper on
> this Sina?
>
> In other words, we are not doing a GOMS analysis of non-sighted
> programmer activities, but someone publishing this would be a super
> valuable research project. It could be a great contribution to the
> literature as well, as sighted folks like me have near zero data on
> the keystrokes non-sighted programmers actually use in practice, let
> alone how they compare to the traditional GOMS techniques for
> analyzing keystrokes.
>
> Sina said:
>
> At first, when you mentioned video taping it, I immediately thought of
> a cognitive JogThrough as introduced by Rowlands, D.E. and Rhodes, D.G.
>
> Andreas said:
>
> Oh, yes, that's definitely one way to do it. The video tapes in our
> case are mostly so we can go back and figure out what, inevitably,
> went wrong, AKA they are more qualitative analysis than anything super
> formal. My phd advisor though has done some of that insanely time
> consuming analysis before. Several of my friends/colleagues have
> participated on those kind studies and man, you aren't kidding, it's
> like several months of work for a single study, pretty nuts. For
> whatever reason though, I've always gotten lucky and not had to do it.
> They always have me writing some piece of a compiler instead.
>
> We have worked on designing measures of how well people can comprehend
> audio for programming, but those measures are also insanely time
> consuming as well. No free lunch I guess. Our next study should be
> pretty straightforward, though, no super fancy analysis. I think we're
> just going to measure things like "time to complete task" and stuff
> like that. Easy.
>
> Hope that answers your questions!
>
> Andreas
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
