[chuck] Re: Re: Audicle presentation award / video (oliver oli)

[rjc]

Never having seen Audicle, I can't answer any specific questions. However, 
there are some conventions which have been developed to keyboard-enable a 
GUI.  In a normal windows app, tab tends to move focus from component to 
component, arrows move focus from element to element in a listbox or change 
values in a slider or spin control, arrows move through the text in a single 
or multi-line textbox, space or enter activates a pushbutton, etc.  You can 
also attach shortcut keys to buttons and controls to eleviate the user from 
having to tab around so much.

Look at Java Swing for a good example of how GUI interfaces can be made 
accessible. If audicle happens to be written in Java, then a lot of the work 
has already been done for you. All one needs to do is be sure that any 
custom components used make use of the IAccessible interface and set text 
labels for interface elements which need them, etc.

Hope this helps a bit...

-- Rich

----- Original Message ----- 
From: "oliver oli" <smoerk at gmail.com>
To: "Mailing list for programming language 'ChucK'" 
<chuck at lists.cs.princeton.edu>
Sent: Monday, February 07, 2005 1:21 PM
Subject: Re: [chuck] Re: Re: Audicle presentation award / video (oliver oli)


the question remains: if you're blind and using a screen reader, is
there anything in audicle which should be made more screen reader aware
or should you just use the command line interface?

could the command line chuck be improved for screen readers?

what would be a good interface for blind people?

how usable is audicle for visually impaired people?

Jeffrey Treviño wrote:
>     From: *oliver oli <smoerk at gmail.com>
>
>     I don't know much about Audicle, I only watched the video. It's
>     mainly a visualization of what is going on inside of ChucK. How many
>     shreds are running and when they get activated, etc... There is also
>     an editor which some nifty user interface, which I guess is based on
>     OpenGL, too.
>
>
>  From the performance standpoint, I can say that the Audicle is much more 
> than a fancy editor / visualization. We have to keep in mind that this 
> language aims to facilitate on-the-fly programming. The Audicle interface 
> substantially changes how a performer might interact with Chuck in 
> realtime, because it fundamentally changes the characteristics of the 
> performance interface.
>
>
>     But this stuff is completely optional, you can also do everything
>     with plain chuck and an editor of your choice.
>
>
> Except that you can do it more quickly and in different ways using 
> Audicle. Plus our plain editors are way less interesting to audience 
> members than are fancy visualizations.
>
>     I don't think it makes any sense to try to make Audicle more screen
>     reader friendly, because it's mainly 2D and 3D visualization. I
>     guess it's possible to magnify everything in Audicle as it's based
>     on OpenGL.
>
>     But maybe it's possible to make the command line interface of chuck
>     more accessible? Have you tried to run chuck? Is there anything
>     which could be improved for a screen reader...?
>
>
> As a composer/performer, I personally prefer virtual instrument GUIs of 
> some kind (even if they're dynamically defined) over command line 
> interfaces for performance. We need to get away from the suspicion that 
> your new music laptop performer is in fact checking his e-mailing during 
> the performance you're watching, and projecting visualizations--especially 
> visualizations like this that are integrated with the code editor and are 
> apparently effecting the way in which the performer makes musical 
> decisions--has a lot of potential as a cure.
>
> --Jeff Treviño, Stanford University Computer Center for Research in Music 
> and Acoustics (CCRMA)
_______________________________________________
chuck mailing list
chuck at lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck