[Architecture] [Profiles] TextHelp
tobias at inclusive.com
Wed Feb 8 13:56:36 UTC 2012
Denis, the point you raise about different features within a single product
category is crucial. AT vendors will certainly fight on this front - their
goals are to retain their customers and reach new ones by projecting their
competitive advantages. There will always be pressure to expand the
preferences file. Some of it will even be terminology - vendors using
different terms to refer to identical features, or settings within features.
I have no idea how to solve this, but we have to be very careful about
thinking that just because we try to project an air of fine-grained
objectivity that others will regard us that way automatically.
From: architecture-bounces at lists.gpii.net
[mailto:architecture-bounces at lists.gpii.net] On Behalf Of Denis Anson
Sent: Wednesday, February 08, 2012 8:25 AM
To: Gregg Vanderheiden
Cc: profiles at lists.gpii.net; architecture at lists.gpii.net
Subject: Re: [Architecture] [Profiles] TextHelp
It's probably because I come from the days when cycles were expensive and
data was delivered through a straw, but I've been thinking about settings
files in a compressed format.
Any given AT feature (like the word prediction in TextHelp, not the entire
program) has a relatively limited set of parameters. Rather than having a
settings file that contains all possible AT products, it should be possible
to have a single type of AT record that would have a product type
identifier, and a "preferred" or "licensed" identifier. (This is the
product that the user is most familiar with). After these fields, there
would be a set of general purpose fields, whose definition is determined by
the type identifier. So, if the AT identifier were "word prediction," and
the product were TextHelp, the first field would determine whether the
prediction list were alphabetical or frequency; the second field would be
the number of predictions to show; the third might be the number of letters
to be typed before predicting; the fourth might be the preferred x
coordinate of the prediction window on the screen; and so on. There would
also be a field that would be the URL of the individual's prediction history
and custom vocabulary.
If the product were an on-screen keyboard, the same fields would have
relevant settings for product. Since a given individual would only require
a few interventions, this would allow the preferences file to be very
compact. It would also simplify the case where the desired product was not
available, and an alternative would need to be used. I conceive it as
something like the CSS "Font" parameter, where you specify preferred fonts,
then the family to draw from of the preferred are not available. If the
selected product doesn't have all of the features of the preferred product,
those would be ignored.
In some places, the size of the preference file is irrelevant, because
delivery pipes are large. But in some settings, we still don't have
broadband, and we want to minimize the delay of GPII.
It just occurred to me that this might be a way to get additional buy-in
from vendors, too. If my product has features that are not set in the
preferences for the individual, it could, on invocation, ask the user for
preferred settings for those features his product doesn't contain. If the
user finds those extra features valuable, she might migrate to the new
product to gain them in other settings. This would provide vendors with a
way to call out differentiating features. Vendors don't want their AT to
become commodities, which could happen if the user never knew which product
was being used, because they all act the same way (according to the
Denis Anson, MS, OTR
Director of Research and Development
Assistive Technology Research Institute
301 Lake St.
Dallas, PA 18636
danson at misericordia.edu
On Jan 31, 2012, at 1:02 PM, Gregg Vanderheiden wrote:
TextHelp as offered to provide us with their Settings File for Read and
This will provide an interesting set of settings used by a very flexible,
configurable accessibility tool..
It is NOT comprehensive. But it will give us another diverse setting
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison
Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org <http://Raisingthefloor.org/> ---
Profiles mailing list
Profiles at lists.gpii.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Architecture