# Presentation: 532886

## Alternative Interface Access Protocols (AIAP)

- Controlling Next Generation Technologies by Alternative User Interfaces

**Notes:**
In this presentation I would like to introduce a standardization effort of the National Committee for Information Technology Standards (NCITS).  This effort is aimed to provide extension hooks for alternative interfaces of standard products and services in order to make them accessible to a wide range of users.

## Functional Limitations as a Function of Age

**Notes:**
This chart shows a statistic from the Bureau of the Census, from 1995.  Each pie represents the statistical amount of people with any or severe functional limitations, as a proportion to the overall population in a distinct age range.

Do you want to become 65 years old? Or even 80?

It is obvious: Statistically spoken it is just a matter of time until you will be concerned of being functionally limited in one or the other form.

## What to Do?

- Make STANDARD services and devices directly usable by people with a wide range of abilities
- Best way to create access to most technologies
- Create standard extension hooks for services and devices
- Alternative interface
- Enhanced capability
- Use new technologies for adaptive solutions where existing solutions don’t cope

**Notes:**
What can we do to prevent that the products and services we design will become inaccessible for people as they age or are functionally limited for other reasons? This is what Universal Design means:

Where possible, we try to make standard services (and devices) directly usable by a wide range of different users. Usually we achieve this by designing multi-modal user interfaces so that there are different ways of doing the same task, but by the use of different user capabilities.  This is the best way of enabling access. This is particularly true for aging people who become gradually functionally limited and don’t want to switch over to new products and services as they age.
If this approach doesn’t work, we can still make products and services accessible by providing extension hooks to accommodate alternative interfaces and enhanced capabilities. In a second presentation I will say something about the alternative interface approach.  An example for an enhanced capability would be a hook in a word processor in order to harness any spell-checking service that could be provided locally or remotely. By this we enhance the capability of the word processing program.  This hook could be used by a variety of service programs, including dictionaries and thesauri. Another example would be a hook in the IP telephony infrastructure so that if I click a button on my computer screen and a window pops up text-captioning everything what the other person says to me over the IP-phone.  More to that later.
The third approach is kind of an intelligent way to combine the first two approaches.  This means that the service or device itself adapt to the user’s needs.  For instance, the text captioning window could pop up automatically the next time I make a phone call via IP.  Or a speech recognition service could adapt to the strange language of a non-native speaker (like me) or to a user with a speech deficiency.  However, some initial training would be necessary.

## The  Problem

- People are faced with a product or service
- they cannot operate
- in a place where they cannot adapt or modify the product to meet their needs
- e.g. Kiosk, ATM, shared workstation, immersive environment
- People with disabilities cannot get the needed efficiency through the interface that is built into the product
- e.g. Workstation

**Notes:**
This approach is necessary when it is not possible to make standard products and services accessible by means of their built-in user interface.

Products and services located in public areas are particularly of interest  because they cannot be adapted or extended as well as private products can be.  The standard addresses the problem of persons being unable to operate a product or service - or being unable to operate them efficiently.

## Person cannot use interface on product (Scenario #1)

- Interface Hardware

- Interface Software

- Function Software

**Notes:**
With the following slides I would like to give you an idea what this standardization effort is about.  I hereby refer to 4 scenarios that together present the “solution space” for the up-coming standard.

All 4 scenarios address the same problem: a person cannot use a built-in user interface of a product or service.  For simplicity in these scenarios the product is a regular ATM.  Its main components are the user interface hardware (mainly keyboard and screen), user interface software (the software that drives the input and output devices and invokes the functions of the application), and the function software (the application itself).

## Person cannot use interface on product (Scenario #1)

- Interface Hardware

- Interface Software

- Function Software

- ... but has alternative keyboard they can use

**Notes:**
Assumed this person cannot use their hands for typing, but can use a special (switch-controlled) keyboard which they carry with them.

## Person cannot use interface on product (Scenario #1)

- ... but has alternative keyboard they can use
- V2- Effort #1 is aimed at giving them a way to use it instead of the keyboard on the product

- Interface Hardware

- Interface Software

- Function Software

**Notes:**
Then this alternative keyboard could be used to connect to the user interface software on the target device and thus be used instead of the built-in keyboard.  By this part of the user interface hardware could be replaced by alternative devices that basically do the same.

## Person cannot use interface on product (Scenario #2)

- Interface Hardware

- Interface Software

- Function Software

**Notes:**
In the next scenario a person cannot use the default user interface at all.

## Person cannot use interface on product (Scenario #2)

- Interface Hardware

- Interface Software

- Function Software

- ... but has a remote console device

**Notes:**
But can use a special portable device as a remote console.  The remote console would consist of an appropriate user interface hardware and software that would be usable by the person.

## Person cannot use interface on product (Scenario #2)

- Interface Hardware

- Interface Software

- Function Software

- ... but has a remote console device
- V2- Effort #2 is aimed at giving them a way to use it instead of the entire interface on the product

**Notes:**
Thus this person could use their remote console device to control the product or service. This means that the entire interface of the product or service is replaced by the remote console.  

## BrailleNoteOne Possible Remote Console Device

**Notes:**
How would a remote console device look like?  It would basically be any device with input and output capabilities, for example a Palm pilot or a cell phone.

This is a portable computer using braille for input and output.  This would enable blind or deaf-blind persons to use an ATM with their BrailleNote as a remote console device connecting to the ATM.

## Person cannot use interface on product (Scenario #3)

- Interface Hardware

- Interface Software

- Function Software

**Notes:**
The third scenario assumes that the person can use the user interface of a product or service.  However, changes to the default user interface are necessary, e.g. larger fonts.

## Person cannot use interface on product (Scenario #3)

- Interface Hardware

- Interface Software

- Function Software

- ... but has a card or device that describes their abilitiesOR their preferences

**Notes:**
Instead of the cumbersome work of configuring the user interface the necessary changes are just triggered by an ID card (e.g. a smart card) the person carries with them.

## Person cannot use interface on product (Scenario #3)

- Interface Hardware

- Interface Software

- Function Software

- ... but has a card or device that describes their abilitiesOR their preferences
- V2- Effort #3 is aimed at giving them a way to send their information to the product – so that the product can adapt its interface to meet their needs

**Notes:**
And as the person walks up to the product or service the user interface preferences on the card are transferred to the interface software which in turn adapts the user interface to the person’s needs.

## Person cannot use interface on product (Scenario #4)

- Interface Hardware

- Interface Software

- Function Software

**Notes:**
The 4th scenario is similar to the 3rd, except that the behavior of the product’s user interface is entirely changed.

## Person cannot use interface on product (Scenario #4)

- Interface Hardware

- Interface Software

- Function Software

- ... but they could if new interface software could be located or created for them and loaded into the product

**Notes:**
This means that there is somewhere an alternative interface software that can use the default user interface hardware as well.

## Person cannot use interface on product (Scenario #4)

- Interface Hardware

- Interface Software

- Function Software

- ... but they could if new interface software could be located or created for them and loaded into the product
- V2 – Effort #4 is aimed at providing ways for alternative software to be called up and downloaded into a product

**Notes:**
The alternative interface software thus replaces the whole or part of the built-in user interface software, so that the person can use the default user interface hardware, but with a different behavior.

(Example: A user with only one hand, using the provided keyboard as a one-hand-keyboard.)

## Considerations for the Access Grid

- Important to think about when constructing the Grid – so that it will support such standards.
- Provides an interesting prototype for both scalable and interchangeable user interfaces.
- Could provide key strategies for common portal work.

**Notes:**
Now you may ask how this relates to the work you are doing on the Access Grid.

1. It may be good to have this in mind in order to provide extension hooks in the overall architecture.

2. The Grid also addresses a wide variety of input and output devices.  So this could be a prototype how to connect these devices and their user interfaces to the Grid services and resources.

3. Altogether this could provide key strategies for developing an architecture for common portals to the Grid.

## ConsiderationsPerson cannot be present at the “default” access point

- Interface Hardware& Software

- Access infrastructure (gateway)

- Grid services

- ... but has a remote device (e.g. cell phone, pager, handheld)
- Scenario A: Remote Job Control
- Scenario B: Linking people with remote devices to an AG session
- More?

**Notes:**
Please let me illustrate this by using one of the previous scenarios and putting them into the Grid context.  So instead of the ATM we are now talking about the Grid services at the back-end, the access infrastructure (or gateway) in the middle, and the interface hardware & software on the left (that means a computer with a web browser, for instance).

Now the person with an uncommon device (like a cell phone or a Palm pilot) wants to access the Grid services.

In one possible scenario the person would connect with their “remote console device” to the Grid services which would allow him to control massive distributed compute services.

In another scenario a scientist could be linked to an Access Grid session “on demand”, by using only a cell phone.

I am sure we could find more and perhaps better scenarios.  The target should be to design our services and products in an extensible manner that allows flexible patterns of usage.

## Thank you!

**Notes:**
Thank you for your attention!