[ossrp-control] Re: Features So Far

Hi Rick,

Yes, that was one of the things I was thinking of.  The Patterns and
Practices group at Microsoft have a freely available code block, that when
included within in an application will allow it to be updated over the web.

So, that is one of the things that would be useful to include.  It will mean
the user will get to take advantage of any fixes or upgrades as early as
possible.

Will
----- Original Message ----- 
From: "Richard Thomas" <rthomas@xxxxxxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Thursday, April 28, 2005 2:12 PM
Subject: [ossrp-control] Re: Features So Far


> Hi gang;
> To ensure quality of product would it be a good idea to use and distribute
> patches with updates to the original source?  This way embedded code could
> be submitted as patch modules to the original project managers, reviewed
and
> implemented with the original product without creating a new version of
the
> programs each time a small change is invoked.  Then once every so often
the
> original version updated with the tested and burned in patches could
replace
> the archived prior version for distribution.
> As for using  a script language, I'd prefer just staying within the Net
> framework as  David mentioned for the same reasons.
> Rick of Farmington Mich. USA
>
>
> ----- Original Message ----- 
> From: "David Lant" <david.lant1@xxxxxxxxxxxxxx>
> To: <ossrp-control@xxxxxxxxxxxxx>
> Sent: Thursday, April 28, 2005 7:31 AM
> Subject: [ossrp-control] Re: Features So Far
>
>
> Hi,
>
> Well, it would seem to me that the best way to achieve both requirements,
is
> to not have scripting as a primary configuration function of the screen
> reader.  But instead, to create an SDK for the screen reader so that
anyone
> who wants to add functionality, or customise how it works, can build
> relevant components to do that.  This has 3 main benefits:
>
> 1. It fits in with the modular approach being recommended for the screen
> reader project.
>
> 2. It obviates the need to invent a new scripting language, or try and
> incorporate one into the delivered product.
>
> 3. As the project may be .NET based, anyone wishing to alter how the
screen
> reader behaves will be able to use any of 32 different supported languages
> to do so.  The main objective of the SDK would then be to simply provide a
> means of exposing the object model, and then packaging the result in a way
> that is easily distributed to the users.
>
> Thus, end users would not need to even be aware of, or worse still
> confronted with, the idea of programming in order to perform more subtle
or
> complex changes.  Since 99.99% of screen reader users never touch
scripting,
> it shouldn't be a top priority in my humble opinion.  Since most scripting
> is done by comparative experts, and then distributed to a general user
base,
> the above SDK idea wouldn't seem to conflict with that historical use at
> all.
>
> Having some way of programmatically altering how the screen reader behaves
> is definitely a good idea.  It just isn't necessary to expose that to the
> main users, but rather to have it available as a fall-back option for more
> experienced people.
>
> Just my twopence.
>
> All the best,
>
> David
>
>
> -----Original Message-----
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Sina Bahram
> Sent: 28 April 2005 06:46
> To: ossrp-control@xxxxxxxxxxxxx
> Subject: [ossrp-control] Re: Features So Far
>
>
> Hi David,
>
> Those wizzards, dialogues, and macro recorders can simply implement the
> scripting language by providing a frontend to it.
>
> Take care,
> Sina
>
> ________________________________
>
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
> Sent: Wednesday, April 27, 2005 3:41 PM
> To: ossrp-control@xxxxxxxxxxxxx
> 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
>
>
>
> To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
> unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
> quotes
>
> To post to the list, send a message to:
> ossrp-control@xxxxxxxxxxxxx
> To unsubscribe, send a message to:
> ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
> quotes
>
>
>
> To post to the list, send a message to:
> ossrp-control@xxxxxxxxxxxxx
> To unsubscribe, send a message to:
> ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
quotes
>
>


To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: