[Architecture] [Profiles] TextHelp

Denis Anson danson at misericordia.edu
Wed Feb 8 13:24:45 UTC 2012

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 preference file).

Denis Anson, MS, OTR
Director of Research and Development
Assistive Technology Research Institute
Misericordia University
301 Lake St.
Dallas, PA 18636

voice: 570-674-6413
fax: 570-674-8054

danson at misericordia.edu<mailto: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 Write Gold.

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 corpus.

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/>   ---   http://GPII.net<http://GPII.net/>

Profiles mailing list
Profiles at lists.gpii.net<mailto:Profiles at lists.gpii.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20120208/a5c3b8f6/attachment.html>

More information about the Architecture mailing list