[ossrp-control] Re: Features So Far

MessageHi,

Here's some more thoughts on scripting.

It will either cost money to licence a third party scripting language, such as 
VBA, or suck up resources to create our own language, compiler and run-time 
system to use everything, and this will be a significant porportion of the 
resources.

At the moment scripting seems to be used in circumstances where the main screen 
reader code fails to work as expected.  To me, this is something that should 
really be taken care of in the main code.  If you fix something in one area, 
then it's likely to have advantages and benefits in other areas, enabling a 
wider pool of users to benefit from that.

Ultimately, a screen reader, as with any other man-machine interface, is just a 
means of communication between user and machine, and vice versa.  At least 
initially, I really feel the focus should be in delivering the user the best 
means of communication possible, both in terms of accuracy and efficiency.  I 
think we can do a much more cutting-edge product if we stick to this initial 
goal.

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


  Hi Jamal,

  I think I've nailed my colours to that particular mast on another list. 
<grin>  Personally, I would prefer avoiding scripting for the first line user 
configuration.  I would wholeheartedly endorse an SDK for developers to create 
add-ins for the screen reader down the line.  But I strongly feel that the 
configuration aspect of the screen reader should be as accessible, in the 
conceptual sense, to as many users as possible.  E.g. wizards, dialogs and 
macro recording style features would be easiest to learn.

  All the best, 

  David 

    -----Original Message-----
    From: ossrp-control-bounce@xxxxxxxxxxxxx 
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Jamal Mazrui
    Sent: 27 April 2005 08:27
    To: ossrp-control@xxxxxxxxxxxxx
    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: