[ossrp-control] Re: Features So Far

MessageI agree with this approache, because the screen reader is open source, 
we can contain configurability options with in the source.  Also, there may be 
the moment where more functionality and such is needed, in which we can develop 
a moduler  configuration system, in which you can insert modules that are 
written for the screen reader to allow for this extra functionality.  This 
would allow for the ability not to recompile the screen reader everytime.

Thanks


  ----- Original Message ----- 
  From: Will Pearson 
  To: ossrp-control@xxxxxxxxxxxxx 
  Sent: Wednesday, April 27, 2005 1:54 PM
  Subject: [ossrp-control] Re: Features So Far


  Hi,

  Is a scripting language really necessary?  As far as I know, VBS isn't being 
developed further, although it will still continue to be supported for a while 
yet.  The main reason that I can see for implementing a scripting language is 
the ability to modify the behaviour of a specific portion of the screen 
reader's execution path.  With an open source project, there exists a much 
better way, and that's to modify the source code itself, and as it's an open 
source project, anyone can download their own sand box copy and modify the code.

  Scripting languages generally tend to give you access to more coarse 
functionality, which is both a good and bad thing.  Sometimes you want to play 
at that level of coarseness, something which access to the source code allows 
you to do, but at other times you only want to make very minor changes, 
something that access to the source code permits, but scripting capabilities do 
not.

  So, implementing a scripting language looks a lot of work for relatively 
minor gains.  If it was a closed source project, then it would be a good and 
valid suggestion, but as it's not the returns you get from it are fairly minor.

  Will
    ----- Original Message ----- 
    From: Jamal Mazrui 
    To: ossrp-control@xxxxxxxxxxxxx 
    Sent: Wednesday, April 27, 2005 8:26 PM
    Subject: [ossrp-control] Re: Features So Far


    One exercise I think is useful sometimes is to ask what is not desired.  
Phrased another way, what features of present Windows screen readers do we 
think are not worth emulating?  I do not have ready answers to this question 
myself, but thought it was worth posing, as it can help draw boundaries around 
the scope of the project.

    Also, a topic which I do not recall being addressed specifically is whether 
the screen reader should support a scripting language for application 
configurations.  Is there a new scripting language for Longhorn, a successor to 
VBA?  If there is a built-in scripting language, then it may be the easiest 
language for the screen reader to host for configuration scripts.  

    Naturally, as much configuration as possible should be implemented without 
the need for scripting.  Some people may even prefer to avoid the scripting 
route entirely.  Thoughts anyone?

    Jamal


    -----Original Message-----
    From: ossrp-control-bounce@xxxxxxxxxxxxx 
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
    Sent: Wednesday, April 27, 2005 3:02 PM
    To: ossrp-control@xxxxxxxxxxxxx
    Subject: [ossrp-control] Features So Far


    Hi,

    Here's my understanding of the important features that should be 
investigated for version 1.  It doesn't feature everything, but then there'll 
be versions after 1 in which more things can be brought in.

    Functional requirements:
    * ability to read *windows* login screen
    * ability to work with widely used types of applications, e.g. word 
processors, spreadsheets
    * support for TTS engines that use the SAPI interface, as some of these 
provide clearer speech than current formant synthesisers
    * ability to use mouse or equivalent functionality
    * must work with User Interface Automation
    * ability to update components over the web
    * support for Braille devices

    Architectural requirements:
    * based on .Net Framework/WinFX
    * component based architecture

    * Research requirements
    * investigate mechanisms to provide more efficient interaction mechanics
    * investigate techniques to convey all the semantic information contained 
within a GUI through auditory and tactual/haptech transmission media.
    * investigate means for clearer speech
    * investigate perceptual psychology techniques for semantic conversion of 
web based graphical turing tests to text

    Project management requirements:
    * risk analysis
    * avoid scope creep
    * requirements management
    * beta 1 to be made publically available April 2006

    These are fairly high level requirements, and if anyone feels anything is 
being missed or would like to include anything, then say now.

    Will

Other related posts: