[ossrp-control] Re: Features So Far

I have to agree with Mary, because the things she mentioned here happened to me 
not to long ago... Scripts can really mess you up, especially when versions are 
changed. However, I'm not against the possibility of scripting, just think we 
have to keep the actual need for it to a bare minimum. Also, I agree that 
magnification is also very important, and I know many people who'd use it. 
  ----- Original Message ----- 
  From: Mary Otten 
  To: ossrp-control@xxxxxxxxxxxxx 
  Sent: Wednesday, April 27, 2005 9:59 PM
  Subject: [ossrp-control] Re: Features So Far


  David,
  I would add my voice to yours with regard to avoiding the use of a scripting 
language for user-level configuration if at all possible. If it can be shown 
that addition of such a language will add serious power to the screen reader 
which can't be done in any other more user friendly way, then I could have my 
mind changed on this topic. However, generally speaking, I think the scripting 
language is one of the least attractive points about the most widely used 
screen reader today. Its out of reach for the great majority of end users. And 
when versions change, scripts often break, causing end users to be stuck until 
they can get somebody to come and figure out what has changed to cause the 
script to break. And that in turn can be a time waster and very costly, not to 
mention that the after market scripting is itself an added cost. I am 
definitely for keeping the user interface and interactions as simple as 
possible, while keeping in mind that configurability may be necessary in s ome 
instances to assist in making ill behaved applications usable, or desirable in 
others, to allow users to customize output or streamline input. But I would 
urge caution against making the thing overly complex or dependent on 
specialized knowledge on the part of the end user.
  Mary Otten
  senior tester
  Tecaccess


  --Original Message Text---
  From: David Lant
  Date: Wed, 27 Apr 2005 20:40:59 +0100

  Message 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: