[ossrp-control] Re: Features So Far

I'm not sure if I'm understanding you correctly, but if I am, I'm not
sure this is a good idea.  In software engineering one of the things we
learned was that while developing a product, if one person works on a
moduole that moduole should be frozen so that you don't have two
versions of the same moduole floating around and lose track of who did
what, etc.  It sounds like what you are suggesting would do that.  By
the way, just by way of introduction I'm a junior here at Juniata
College majoring in Information Technology with a leaning toward web
design.  I've had some training with Java and c++ as well.  I'm not sure
if I'll be able to help with the programming or not, but at least I can
maybe help with testing.

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Richard Thomas
Sent: Thursday, April 28, 2005 9:13 AM
To: ossrp-control@xxxxxxxxxxxxx
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: