[Accessforall] Are common terms a flawed concept?

Christophe Strobbe strobbe at hdm-stuttgart.de
Thu Dec 19 06:17:46 EST 2013


Hi Colin,


Am Mi, 4.12.2013, 00:35 schrieb Colin Clark:
> Hi Christophe,
>
> Thanks for your post. I appreciate the time you took to write down your
> thoughts so we can understand and discuss them. I agree with Gregg that
> there are some misunderstandings here that should be addressed. Hopefully
> I can help clarify a few architectural points below.

I started writing a response some time ago, but I couldn't finish before
today as other things got in between.


>
> On Dec 3, 2013, at 12:59 PM, Christophe Strobbe <strobbe at hdm-stuttgart.de>
> wrote:
>
>> [Definitions of common terms etc snipped.]
>>
> (...)
>
>> Common terms imply stability, for example, because each change in the
>> value range (or data type, description, ...) would necessitate changes
>> to
>> transformers and other code that would affect all the implementations
>> that
>> rely on it. Using a common term for an application's setting implies
>> that
>> the values for that setting need to be just as stable as the value range
>> defined for that common term. As an application developer (our SP3
>> solutions), I think you would want the freedom to change your settings,
>> and therefore the freedom to change the (application-specific) terms
>> when
>> improving your application. For example, if you develop an AT for colour
>> inversion on a desktop OS, you would not want to be prevented from
>> adding
>> a new colour inversion scheme by relying on a common term for colour
>> inversion scheme that lists only x values (but not the ones you want to
>> add to the new version of your AT). If you develop an operating system
>> and
>> you want to add more contrast themes, you don't want to be limited by a
>> fixed list of contrast themes defined for the corresponding common
>> terms.
>> If you develop a screen reader that can announce capitals in certain
>> ways
>> and you want to add a new way of announcing capitals, you don't want to
>> be
>> limited by the options listed for the corresponding common term. There
>> are
>> probably many settings where developers would want to avoid such
>> limitations and opt for application-specific terms instead of common
>> terms.
>
> This seems to be where one of our misunderstandings stems from. You seem
> to be assuming that developers have to implement common terms directly in
> their products, which isn’t the case.

The assumption about the implementation of common terms does not stem from
my understanding of the system. I have several times heard the statement
that implementers would be encouraged to use common terms (e.g. during the
AccessForAll calls). During our face-to-face meeting in Madrid, it was
even claimed that the SP3 solutions in Cloud4all use only common terms and
no application-specific terms. (Quoting from the meeting minutes: "Only
common terms are part of this integration phase"
<https://docs.google.com/document/d/1FFpZxUK7WvYkqr5c1QeXWe9JngMyqSrBDxYktHLhah8/edit#heading=h.1urwc3kvsifz>)
Lastly, some of the SP3 implementers provided only a list of existing
common terms when we asked them which terms they would like to see
supported in the second pilot phase. This included an organisation that
integrates an AT with GPII without having access to that AT's source code.
(This situation was rectified last week.) How likely is it that that AT's
settings match the common terms and that no application-specific terms are
necessary?
It is when I noticed this misunderstanding about implementing common terms
in SP3 that I started thinking about the potential consequences and wrote
my original mail.


> The main motivation for common terms is to serve as a “meeting point” for
> a diverse community of developers and application vendors. Common terms
> represent common ground where we can translate to and from
> application-specific representations.

This is how I have always understood common terms. There is no
misunderstanding on my part.

> There is no requirement for developers to implement common terms in their
> application’s internals. This decision is entirely up to the developer,
> and we are committed to creating a system that can work with whatever
> format, structure, and persistence mechanisms are used in the real world.

This matches my misunderstanding but it leaves out past statements that
implementers would be encouraged (not required!) to use common terms, as I
mentioned above.


> Your argument about common terms constraining innovation is one that is
> often made about standards in general, and it’s a red herring. I know that
> you’re experienced enough with a variety of accessibility standards to
> recognize that in reality, good standards often serve as platforms for
> innovation, not barriers to it.

The deduction from most standards to this standard is a red herring, isn't
it? The statement that good standards can serve as platforms for
innovation is something that needs to be ensured for each individual
standard, it is achieved by branding an arbitrary specification as a
standard.
My concern is only about common terms in the revision of ISO 24751, not
about standards in general.


> In this case, a good standard should
> provide a reasonable baseline of useful common terms that can be easily
> used to 1) promote interoperability across systems and 2) provide an easy
> starting point for building new applications and solutions.
>
> Equally, it’s important to have mechanisms with which we can extend the
> common vocabulary in a community-driven way. That is our goal here. If a
> common term doesn’t fit, there’s nothing forcing a developer to use it.
> Over time, we can continue to extend and refine the vocabulary in context
> of the registry.

Interoperability is the keyword here. We both agree that implementers
don't need to implement common terms natively in order to ensure
interoperability; they can use their application-specific terms and
provide mappings and transformations to common terms.
My concern is specifically about common terms where the value range
consists of enumerated values.
(a) They would be unattractive to implement natively because that implies
that you commit to their value range. (Fortunately, you don't need to
support them natively.)
(b) They can lead to a loss of precision in setting values when you need
to convert from an application-specific terms that uses a specific set of
enumerated values to a common term that uses a different set of enumerated
values and there is simply no good mapping. (This would be a bit like
translating colour terms between languages without recourse to RGB or
something similar.)
(c) In theory, they can also lead to a loss of precision when an
application-specific term uses a value range based on continuous data (or
even simply integers) whereas the common term uses enumerated values. This
is something we are currently avoiding by our choice of data types and
value ranges for the common terms.

There are a number of common terms where we have not avoided enumerated
values so far, i.e. trackingTTS, readingUnit, highContrastTheme,
magnifierPosition. To define the value range of these common terms, we
just used the superset of the values of the corresponding
application-specific terms. New values will need to be added when we
discover "new" values in the application-specific terms of new solutions
we want to integrate with GPII.

highContrastTheme is a particularly tricky term because we treat it as
something atomic, which it is obviously not. Themes define things such as
UI foreground colour, UI background colour, cursor colour transparency,
system sounds, etc. and many of these things can be customised
individually. We will probably need to revisit this term after the second
pilot phase. (Decomposing such a term has the side effect that each change
to one of its aspects will need to trigger checks on all the other aspects
of the original composed term, since the certain values may have
dependencies on the values of other aspects of the decomposed term.)


>> So I see two main reasons why application developers would prefer
>> application-specific terms over common terms:
>> (1) the flexibility to modify the definition of their settings as the
>> need
>> arises, without being hampered by the stability of common terms;
>> (2) the settings they had implemented before GPII came into existence
>> differ from the definitions of the common terms and they don't want to
>> move to the common terms (for whatever reasons).
>
> Again, you’ve structured the argument as an either/or, but in reality it’s
> both. Common terms serve as a useful meeting point for translating and
> transferring a user’s preferences across different contexts, devices, and
> situations. A developer may find it useful to use them internally in their
> application, but it it’s not required.

Sure, a developer could choose to implement common terms for settings A, B
and C and application-specific terms for settings D, E and F. That could
be a way to avoid being constrained by the enumerated values defined for a
common term.
The choice between a common term and an application-specific term should
be made wisely, because certain settings have dependencies on other
settings, e.g. for magnifiers, the options for magnification position (top
half, bottom half, right half, left half, ...) may depend on the magnifier
view or mode (split screen, magnifying glass, ...). Using a mixture of
common terms and application-unique terms for this combination of settings
would needlessly complicate the application of settings to the magnifier.


> In reality, a user’s preference set will likely contain a blend of both
> common and application-specific terms, depending on how they first "got
> their foot in the door,” whether through a simple and user-friendly
> discovery or exploration tool or via the Settings Snapshotter component or
> a combination of both.
>
>> However, how many settings really exist that are generic enough that
>> application developers can commit to them without limiting the changes
>> they can make to their applications later? The above list even ignores
>> that you often wouldn't want to present users with the values used for
>> the
>> common terms, e.g. screen readers use a range for 1-100 for speech rate
>> that does not represent words per minute, but the common term "speech
>> rate" is currently (provisionally) expressed as words per minute. In
>> such
>> cases, you would only use the common terms if the conversion from the
>> range in the UI to the range of the common term is done in the
>> application
>> (so it can use the common term's range internally).
>
> I think our experience with the AccessForAll specifications and similar
> standardization efforts suggests that there are indeed a lot of needs and
> preferences that can be generalized across applications as common terms.
> More importantly, there is an immense interoperability benefit to doing
> so.
>
> Equally, common terms are invaluable when creating really good user
> interfaces for preference editors and discovery tools that have been
> tailored for users. Let’s face it: computer-generated user interfaces
> invariably suck. Really good UIs are carefully crafted by experienced
> interaction designers who know their audience very well. And more
> importantly, users often don’t speak the language of complicated settings
> and features. They often want simple ways to express an overarching set of
> needs, irrespective of how they are ultimately stored down in the guts of
> an application.
>
> Since application-specific settings are essentially infinite, we’ll have
> to resort to automatically generating adjusters and UIs for them. Whereas,
> with common terms, we can craft better user interfaces that allow the user
> to express preferences in the way they are most comfortable, and then
> transform these at the system level to application-specific terms at
> runtime. A user of a discovery or exploration tool shouldn’t have to deal
> with the complexity of a typical system settings dialog box.
>
> With common terms, we can also more easily share these user interfaces
> amongst a variety of tools and editors, promoting consistency and ease of
> use across the GPII.

Sure, but this is essentially an aspirational statement, not a solution to
technical issues that will arise.


>
>> When we said in previous discussions (last year, during the AccessForAll
>> teleconferences) that there would probably by hundreds of common terms,
>> we
>> were probably too optimistic. Based on the implementation experience so
>> far, I can't imagine more than a few dozen common terms (as a very
>> optimistic estimation), and I expect all other terms to be
>> application-specific. I don't know what the future of application-unique
>> terms will be, but I guess that application-specific terms without
>> mappings or transformations to common terms will be just as opaque to
>> the
>> real-time framework as application-unique terms.
>
> Again, as best as I can tell, this impression stems from confusion about
> common terms. The metric for success of a common term isn’t whether or not
> developers adopt it internally. Instead, a successful common term is one
> that can viably serve as common ground for translating amongst different
> formats and value ranges. So far, we’ve already collected quite a large
> number of terms that are meaningful across applications, and we need to
> continue that effort.
>
>> Moreover, the common terms are not needed by the statistical matchmaker
>> because its goal is to infer relationships between application-specific
>> settings. In other words, the common terms are a requirement for a
>> specific class of matchmakers that got promoted to a requirement at the
>> level of the real-time framework itself.
>
> I’m very excited about the potential of the Statistical Matchmaker. It is
> a cool and ambitious project.
>
> (...)
>
> While common terms and transformations may not be required for your
> matchmaker, they are an invaluable tool for supporting a variety of
> matchmaking strategies, and for promoting interoperability and
> transparency throughout the system. The combination of common terms and
> our declarative transformation rules currently drives the out-of-the-box
> Matchmaker implementations quite effectively, and is also proving valuable
> to the Rule-Based Matchmaker. Indeed, if I remember correctly, even the
> Statistical Matchmaker used the Transformer in the first round of
> Cloud4all pilots (which tested only application-specific terms), so this
> approach has clearly proven its usefulness so far.

If your memory is correct, you should also know that the use of
transformers by the statistical matchmaker in the first phase was only a
temporary measure.


Best regards,

Christophe


>
> But let’s be clear: there is nothing in the GPII realtime framework that
> requires the use of common terms. If a Matchmaker doesn’t need the
> transformation phase of the workflow, it can opt out of transformation by
> declaring a few lines of JSON configuration or replacing a bit of
> JavaScript. Matchmakers can pick and choose which core services they need.
>
> I hope this helps clarify,
>
> Colin


-- 
Christophe Strobbe
Akademischer Mitarbeiter
Adaptive User Interfaces Research Group
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749



More information about the Accessforall mailing list