[Accessforall] Are common terms a flawed concept?

Colin Clark colinbdclark at gmail.com
Tue Dec 3 18:35:21 EST 2013

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.

On Dec 3, 2013, at 12:59 PM, Christophe Strobbe <strobbe at hdm-stuttgart.de> wrote:

> (1) common term: name for a setting or preference that would apply across
> many applications or devices and for which the name (unique ID), data
> type, value space and definition are defined in the Registry. This type of
> term should be stable and not change much (if at all). In the current
> Cloud4all implementation, these terms belong in the namespace
> http://registry.gpii.org/common/.
> (2) application-specific term: name for a setting or preference that
> applies to a specific device or application, that has a name, data type
> and value space that are determined by the device or application for which
> the term was defined. This type of term represents settings that can only
> be applied to other devices or applications after translation or
> transformation because those other devices or applications use a different
> name, a different data type, a different value space (or even a
> combination of multiple settings) to represent the same thing. In the
> current Cloud4all implementation, these terms belong in the namespace
> http://registry.gpii.org/applications/.
> (3) application-unique term: name for a setting or preference that applies
> to a specific device or application, that has a name, data type and value
> space that are determined by the device or application for which the term
> was defined. This type of term only makes sense in the context of the
> device or application for which it was defined; it cannot be translated to
> anything else.

This is a very nice summary of the differences between the three types of terms. Thanks for writing it up.

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

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.

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

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

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.

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

To deliver a reliable, robust, and sustainable architecture for real production usage, we need to make sure we can foster many different matchmaking strategies, each tailored for particular users and use cases. The Statistical Matchmaker is one of these strategies, and there are currently several others in development. The goal of our architecture effort is to ensure that the appropriate tools, idioms, and APIs are in place to support diverse approaches.

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.

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,


More information about the Accessforall mailing list