This reference model is intended as a tool for use in determining classes of behavior of the AIAP, for addressing scope and requirement problems, and as a means of common communication among standard development groups in V2.Ê Whether it ever becomes a Reference Model for AIAP is not relevant at this time.Ê This model is a convenient means of separating, and hopefully simplifying, many of the very complex issues that arise in the description of AIAP, and should be thought of as a mental aid for that process.Ê It is not holy writ!

We will divide the areas of interest for the AIAP into four areas:

ÊÊÊÊÊÊÊÊÊÊÊ 1 An area related to the current user interface;

2 An area related to the various user conditions that aid in or determine the selection or transformation of an alternative interface;

ÊÊÊÊÊÊÊÊÊÊÊ 3 An area related to provision of the alternative interface.

ÊÊÊÊÊÊÊÊÊÊÊ 4 An area related to the object, device, system or service the user is trying to

access (i.e., ãoffered serviceä);

To avoid semantic confusions, for now we will simply refer to these as Areas 1,2,3, and 4 of the System.Ê Note that "system" here refers to this collection of areas and the AIAP and not the "user's" system or the "target" system--these will appear as elements of the Areas.

[I believe that these four areas are the minimum required for definition of the problem.Ê Certainly more areas could be used, but this tends to complicate the description rather than to simplify it.]

The AIAP is conceived of as having components among the four Areas.Ê In some instantiations of the System, there may be "null" AIAP components, e.g., where there is no function because the particular choice of elements in the Areas does not require AIAP interaction.Ê Although some areas may be very simple or the elements implicit, it is difficult to conceive of a situation where one of the Areas would be totally empty.Ê However, there may be implicit components, that occur just because of the nature of the element systems under consideration, and components that get executed before any other transaction takes place, perhaps even when the system is installed.Ê These should be accounted for in any case, so that complete System information is available, because other implementations and possibly updated version of a system (or even the standard) may need to make use of this information.

The System can be instantiated on a single device, such as a PC, or one or more Areas can be physically distributed to other devices or systems, connected by various connection technologies, ranging from software (e.g., procedure call), system-bus, hardwire or simple wireless links (e.g., RF, IR) to networks, including wireless, LAN, Internet and other technologies having sets of complex protocols that effect the communications between the components.

Area 1

This area consists of the User, User Description Input System, the User Local System and the User Experience elements.Ê The conceptual intersection of the User Local System andÊ the User Experience is the User Interface.

The User element consists of the human user and the current conditions that qualify the usage for the user.Ê By way of the User Experience the user receives presentation material from the User Local System and enters control and input actions User Local System.Ê Conditions that may qualify usage include:

ÊÊÊÊÊÊÊÊÊÊÊ

á Situation - what the user may be involved in doing: walking, sitting, riding or driving, carrying things, hands in messy material, task;

á Environment - weather conditions, lighting, noise, time of day, interfering activities; computing environment (standalone, hand-held, networked, operating system, application, etc.)

á Behavior - fatigue, alertness, stress, physical strain, discomfort;

á Context - where the user is: home, in a car, office, on a street, in church;

á limitations of equipment;

ÊÊÊÊÊÊÊÊÊÊÊ

Note: the User Description Input is included here for conceptual completeness.Ê It is not intended to be in the scope of the AIAP.

The User Description Input System consists of tools, sensors and other input mechanisms for gathering data that describe the user and the usage qualifying conditions characterizedÊ above.Ê Such information may be gathered while the user is directly interacting with the System or it may be gathered in some prior activity.Ê As an example of the latter, a service organization, set up explicitly for the purpose, could gather the information in support of the user's purchase of an instance of the User Local System, e.g., a personal accessor.Ê The tools might also include software or hardware devices that can assess the nature of a person's disability; for example, a computer-based tool that runs simple tests to determine visual acuity, colorblindness, field of view, and the like, for each user not already determined to be completely blind.Ê The particular natures of the tools, sensors and other input mechanisms in the User Description Input component are not specified, with the expectation that other parties will supply them for particular implementations.Ê

The User Experience consists of media and devices for presentation to the user, for control ofÊ the User Local System and applications being executed under the supervision of the User Local System, and input by the user to the User Local System as data for an application or other use.Ê Such devices and media include visual, aural, tactile, haptic, gestural and other modes, and specifically includes assistive and accessor devices that accommodate a disability of a user.Ê Typically, for a personal computer, the User Experience would include keyboard, mouse, monitor and speakers as devices, and a graphical user interface (GUI) for the operating system and applications.Ê For a blind user, the User Experience would probably eliminate the mouse and possibly the monitor, and substitute a screen reader.

The User Experience also covers access such as that for ATMs and kiosks, smartphones, set-top boxes, smart appliances, and other uses that are likely to be encountered in pervasive computing.Ê This includes devices like smartcards, Javaú rings, and RF tags which can initiate a session with a User Local System.

The User Local System is the computing or electronic device that the human user is currently using, including the operating system, the application(s) or local component(s) of what the user is interacting with, coupling to peripheral devices including assistive and accessor devices (to the extent that these are distinct from the User Local System, and communications software and protocols that couple the User Local System to external resources of information, applications, services and collaboration.Ê The User Local System can have a wide variety of realizations, including, but not limited to, handheld devices, personal or laptop computers, applications (e.g., a browser provides access to a website), networked federation of computers.

Note that in many cases the User Experience and the User Local System may be indistinguishable.Ê Whether or not they are or can be distinguished depends upon how the equipment is being used.Ê For example, a user might be using a wireless accessor device to couple to a PC, but the userâs coupling to the accessor device itself might be a lower level assistive device such as a sip-and-puff switch.Ê In this case, the sip-and-puff switch is part of the User Experience, while the accessor device is the User Local System.Ê Another user might user the same accessor device to couple to a PC but would use a microphone built into the accessor device to voice-control the accessor.Ê Here the User Experience is a part of the User Local System.Ê We use the distinction between the User Local System and the User Experience when it is important to be able to substitute elements of the user interface.

Area 2

This area contains access to or processing of the information that will be used to select, modify, amplify, qualify, condition, or constrain the alternative interface, on behalf of the user.Ê The information itself may be explicit, or implicit, in the sense that the effect on the alternative interface has to be inferred from other information or that some action by the user serves to constrain the alternative interface.Ê As an example of the latter, suppose the user has a wireless handheld device as a local system that uses an LCD screen for presentation to the user, but when the device is placed into a cradle on the console of the userâs car, the presentation will be by audio output.Ê There is an area of the device that detects when the device is in the cradle and appropriately switches to audio output.Ê That area corresponds to Area 2.Ê The information is implicit, in that it is derived fromÊ a signal (e.g., from a contact switch) and does not persist beyond the residence in the cradle.Ê Other implicit information might have to do with a disability.Ê For example, the user may have stated somewhere, in some way, that she has multiple sclerosis.Ê This disease affects different people in different ways, ranging from optical defects to motor nerve limitations.Ê In order to make use of this information in selecting or modifying and interface, it may be necessary to use further information about the disease and the effects of it on this particular user to obtain specific directions for interface selection or modification.Ê

Thus, in Area 2, the processing of the information may involve only a simple program switch internally, or it could be as complex as accessing and inferencing on information stored in repositories remote from the user.Ê In many cases, this information will consist of the capabilities of the User Local System.Ê This might be built in to the device (perhaps in a ROM), or it might be accessed remotely and indirectly from a manufacturerâs repository.

Area 2 could contain rules for handling and shaping the information.Ê The rules could be simple declarations or they could reside in a complex rule engine.

This area also includes explicit preferences, such as ãI want red backgrounds on all visual presentationsä. [Note that even blind users could choose this if they so desired.Ê The choice is empty if there is no visual display, but the preference can still be stated.]

Area 3

This area represents the act of providing the alternative interface to the user.Ê In activity, it can range from reacting to direct selection by the user from a list or menu of interface options (e.g., table look-up) to an elaborate engine which takes the declarations on behalf of the user (from Area 2) and the declarations on behalf of the ãoffered serviceä (in Area 4) and uses them in to construct custom versions ofÊ dynamically variable interfaces.

Area 3 may return the interface chosen (or constructed or modified) directly to the User Local System, or it can return it to an agent or proxy for the User Local System (e.g., when the User Local System is a cellphone and the interface has to be converted to WML), or it can be returned to the Area 4 offered service (e.g., what is returned is a set of instructions for modifying the web page and the offered service is a web site which uses these instructions to construct the explicit HTML to be returned to the User Local System.Ê Note that this is a special case of the proxy mentioned above).

Area 4

ÊThis area represents what the user is attempting to access, supported by the User Local System, meaning any object, device, service, resource, application, collaboration, or interaction, whether external or internal to the User Local System.Ê This includes, but is not limited to, such things as databases, information bases, registries, repositories and other storage facilities, applications, agents, web sites, Internet Service Providers, Application Service Providers, chat rooms, collaborations and conferencing, devices and device drivers, adaptation and conversion services.Ê For example, in terms of devices, it can include personal or laptop, computers, ATMs, kiosks, handheld devices and computers, smart appliances, network devices, networked federations of computers, game systems, and electronic instrumentation.

In general, Area 4 provides information for the other side of the interface selection or modification constrain equation, the first side being provided on behalf of the user in Area 2.Ê This information could range from a fixed list of alternative interfaces (or elements that can be substituted) to full abstract interface definitions and characteristics of the interface components and design.

AIAP

The AIAP has components among the four Areas.Ê The principal, or core, components are between (direction important):

á Area 2 and Area 3,Ê [user information to selection/transformation]

á Area 4 and Area 3, [offered service information to selection/ transformation]

á Area 3 and Area 1 [return of alternative interface to user]

In some instantiations, there may also be secondary components between (direction important):

á Area 4 and Area 2,

á Area 4 and Area 1,

á Area 1 and Area 4,

á Area 3 and Area 4,

á Area 1 and Area 2.

[The implementation of the protocol components, whether by simple text conveyance or by complex sets of complex objects is of no concern in the discussion of the components.Ê Possible implementations are to be decided by the nature of the equipment and services that appear in the Areas, and thus in the Scope and Requirements declarations.]

Let us agree for this discussion to refer to AIAP components in the following manner:

ÊÊÊÊÊÊÊÊÊÊÊ If an AIAP component provides the protocol between Area x and Area y, with

direction important, we will refer to that component by the symbol Axy.Ê Thus, an

AIAP component between Area 2 and Area 3 would be symbolized by A23.

Core Components

Area 2 to Area 3÷A23

The A23 component of the AIAP is responsible for conveying user side information to the selection or transformation process.Ê The information may be uncomplicated, consisting of only a user identification and equipment identification, or it may be very complex, consisting of detailed interface characteristics to be considered, detailed user equipment characteristics, and detailed authorization/authentication parameters.Ê The information must also indicate whether or not the User Local System is capable of receiving the returned alternative interface directly or whether it requires an intermediary, such as a separate agent or proxy.Ê In the simplest case, this might be implicit in the design of the system, but it still should be accounted for in requirements declarations.

[The design of this protocol component itself must be flexible enough to capture this wide variety of descriptions, without burdening the simpler case or unnecessarily limiting the complicated case.Ê Consequently, it will be important to capture the requirements of the information to be conveyed for the extremes before attempting to formalize the protocol in any way.]

Area 4 to Area 3÷A43

The offered service must likewise provide information about the alternative interface to the selection or transformation process.Ê This information may be as simple as providing a list of interfaces or substitutions that can be handled, to as complex as providing information about the structure and modifiability of the interface, collaboration structure, and media types present.

Area 3 to Area 1÷A31

Once an alternative interface has been selected or transformed, it must be returned to the user.Ê For this particular component, we assume that the interface is returned directly to the User Local System with no intervening proxy or agent.Ê The case for return via a proxy or agent is a combination of components, and will be discussed separately below.Ê The returned interface may be complete as it stands, with nor further action to be taken except to execute it.Ê On the other hand, it may require considerable configuration and setup, even to the point of having to execute special software to realize the interface and having to implement special communications paths.

[Note: Even though in very simple cases the user, via the User Local System, may be interacting directly with the offered service to select an interface, for consistency we want to consider this to be information conveyed by AIAP as a ãpreferenceä, from Area 2 to Area 3.Ê This may prevent a designer from having to later re-architect a device when extending its capabilities for an updated version.]

Secondary Components

Area 4 and Area 2÷A42

It may be necessary in some cases for the offered service to convey to Area 2 information about the interface properties, so that appropriate information from the user side can be collected, and irrelevant or inappropriate information can be identified and omitted, for conveyance by the A23 component.Ê For example, the interface information might indicate that only certain kinds of visual components or properties appear on the interface.Ê Processing in Area 2 might determine that a personâs disability only affects access to certain kinds of interface properties, e.g., color.Ê Thus, there would be no need to convey information on button or font sizes, since these would not be affected in the interface transformation.ÊÊ The A42 component might be used to make the System more efficient.

Area 4 and Area 1÷A41

Sometimes, before the interface transaction has actually begun it may be necessary for the offered service to convey back to the user information necessary for the user to setup the information for the A23 component.Ê For example, the offered service might provide a selection menu, either in response to a query by the user or automatically upon making connection.Ê It might also be a prompt to the user to provide more identifying information regarding the equipment the user has, or to provide a set of preferences of some sort.Ê The user response in either of these cases is an A23 component, and not an A14 component.

An A41 component could also be used to convey an alternative interface to the user when the offered service acts as a proxy.Ê For example, Area 3 could send the alternative interface to the offered service, which then transcodes or adapts the interface to WML for the User Local System which is a smartphone.

Area 1 and Area 4÷A14

This component will be primarily for queries from the user to the offered service, about interfaces.Ê In general, it is assumed that these are fixed queries that the offered service can interpret, such as executing a function getInterfaceOptions(), meaning ãWhat interface options do you have?ä.

Area 3 and Area 4÷A34

In some cases it will be useful to convey information about the alternative interface selected or transformed, for audit, use management, and other logging.Ê It may also be the case that the offered service wants to control the return of the interface to the user for security reasons, financial reasons or other unspecified reasons.Ê This will have to be indicated in the A43 component so that Area 3 makes appropriate disposition of the interface.

Area 1 and Area 2÷A12

Area 2 in the cases where the interface is to be constructed or modified by means of preference declarations on the part of the user might involve considerable processing of user condition and equipment information before anything can be passed on to Area 3 by the A23 component.Ê The information for processing this comes from the User Description Input System in Area 1.Ê Consequently, the means for conveying it to Area 2 is the A12 component.

===============================================================

In the case of an independent proxy, we will use versions of the A34 and A41 components, even though the proxy itself may not be a part of the offered service.Ê A proxy can be in several places, and the particular proxy to be used would be determined by designation from the user or by implication from the capability declarations of the userâs equipment.Ê For example, a UIML Renderer could be a proxy on the userâs PC, and the userâs equipment capability declaration via A23 would indicate the presence of this proxy.Ê On the other hand, if the userâs equipment were a cellphone, its identification as such in the transaction would be indicated in the A23 component.Ê In either case a ãlistenerä to intercept the incoming interface would be identified.

The Scoping Problem

The scoping problem is that of determining the range of characteristics of the elements in the Areas.Ê Once (an attempt at) scoping is done, requirements for the AIAP components can be undertaken.Ê The following principle, although obvious, will be noted: The narrower the scope in the areas, the simpler will be the AIAP, both overall and component-wise.ÊÊ It can be expected that several attempts will be made before an appropriate scope can be obtained, with ãsimple enoughä [A. Einstein] AIAP requirements.

The Requirements Problem

The requirements problem is that of determining what information must be conveyed by the AIAP components between the Area elements defined in the scoping problem, and what AIAP components are needed.Ê Additionally, the complete AIAP requirements will also included the nature of interactions the AIAP must undertake to accomplish the information transfer.Ê That is, the elements in the Areas must cooperate to effect the information transfer, and the interactions between the elements must be identified [and be specified later].Ê For example, if everything were being done on a single piece of hardware, say a PC, then such an interaction might be the invoking of a procedure andÊ the protocol becomes a parameter pass.Ê In a more distributed case, we might still have a procedure invoked, but remotely (e.g., using RMI or Corba), and the protocol is again a set of parameters for the remote procedure.Ê For both of theses cases, we would say that the information transfer requires a remote procedure call.Ê In anotherÊ case, suppose that the selection of Area elements requires that simple text commands or information be transferred and that the communications medium is RS-232.Ê Here the interaction would be just invoking the RS-232 interface to signal a transfer.

Using This Reference Model in Addressing the Scoping and Requirements Problems

The first step in addressing the scoping problem is to decide the nature of the elements of Areas 1 and 4, e.g., the userâs system and the target system.Ê We then determine the nature of the communications that will exist between these.Ê In some instances, this communication will be implicit, but this needs to be identified and stated as such.Ê Thus, if an A41 protocol is required, we will know how to describe the interactions needed to execute it.Ê [In any case, it may be useful to know how the User Local System contacts the offered service.]

Next, we identify the interface information that will be provided from Area 4, and what will likely be done with it in Area 3.Ê This gives us some sense of what has to be conveyed to the selection or transformation process by an A43 component..

We then perform a similar identification of the information to be provided on the user side, from Area 2 to Area 3, giving us a sense of the A23 component.

Finally, we consider the return of the interface to Area 1.Ê We will know at this point whether or not a separate agent or proxy is required, from the nature of the devices chosen in Area 1, the information transferred from Area 2 and that of the interface selected or transformed.Ê This gives us a sense of the information required to transfer the interface back to the user, and any intermediary actions that need to be taken.

Perhaps a good way of attacking any scoping/requirements problem is to create a few scenarios to indicate the limits of what is to be considered in the scope, a ãprescopingä, if you will.Ê Our initial separation into Task Groups A and B was analogous to this, by limiting the systems to be considered in each case.Ê Another example of a prescoping example lies in a decision to limit discussion to devices that exchange (i.e., input and present) information by text only, vice complex objects.Ê However, this decision is prescoping, because it may not be sufficient to provide well-defined limits to the problem.Ê Why?Ê Because the nature of the interface has not yet been considered, nor the means of choosing it.Ê I can have a pair of devices that exchange only text, and still have a very complex interface, and the inputs can serve to extensively modify that interface (consider Dynamic HTML and the use of JavaScript to carry out the modifications)..

Letâs take an example to see how the model works.

Suppose the user has an accessor that is to mediate the interaction with an ATM.Ê Thus, we have chosen Area 1 and Area 4 elements.Ê The accessor communicates with the ATM via an RF (e.g., Bluetooth) link.Ê In general, we donât consider the actual handshake between the accessor and the ATM to be part of the AIAP, even though some link protocol implementations may carry AIAP information in a data part of the transport ãconnect requestä packet.Ê Also, security (e.g., PIN) and device-type recognition (e.g., compatible device) information might also be carried by the link protocol, but we also will not include this as part of the AIAP, which may have separate security and device information to convey (even if it is carried using the handshake as a transport mechanism).Ê The reason for this is that, often, initial device-type and security information is provided for the behalf of the offered service (in this case the ATM) and not the user.Ê Moreover, the AIAP is for obtaining a usable interface, not physical access in general, and we donât want to constrain manufacturers in those cases where no alternative interface is desired.ÊÊ Consequently, security and device information provided on behalf of the user would be an A23 component, even if it is implemented in the initial handshake.

Suppose now that the user needs to know what alternative interfaces the ATM can provide via the accessor.Ê A query is posted to the ATM in this regard.Ê This becomes an A14 component.Ê The response to the query becomes an A41 component.Ê Additionally, this will require an underlying protocol to manage the state of the query transaction, in support of the A14 and A41 components. [It may not be necessary for us to specify the protocol that manages the transaction state, just to identify the need for one, and its general properties.Ê Many connection technologies include this capability.Ê As an informative appendix we may offer the general requirements that such a capability must meet.]

Letâs stop a minute and consider scoping.Ê We want to ask the questions (without trying to answer them in this discussion):

á what other choices in Area 1 and Area 4 can be made that are like the ones we chose?

á what are the differences, if any, that need to be considered?

á how far can we extend the characteristics of the choices without losing the essential features of the AIAP components?

á what the commonalities among the characteristics ofÊ the different choices?

The answers to these questions help to provide the general scope for the particular standard we are writing.Ê For example, suppose the first two questions above indicated it would desirable to include another type of equipment than what we originally envisioned, and that the additional type requires a proxy, where the original did not.Ê Does it make the System more complicated to include processing of the added AIAP components?ÊÊ Does it make the User Local System more complicated to include the proxy? ÊIs there a way that the proxy could be made optional? [This speaks to the mandatory and optional features for the standard].Ê Does the additional type actually belong to another class of behavior, and is its relationship to the original type shallow or deep (i.e., more superficial than substantial)?

Next we consider the means by which the alternative interface will be selected or transformed.Ê In any case, this will be a process of some sort [not necessarily an executing computer process], and we must determine the kind of information necessary to obtain the alternative interface.Ê Since we have chosen an ATM for the target, we have to think about what the ATM manufacturers would do about interfaces.Ê So far, they all seem to like their own versions, with little standardization, although that could change.Ê Moreover, we have to believe that banking institutions will collaborate with manufacturers to obtain competitive edges with customers [Wells Fargo is doing that in California now with voice operated ATMs].Ê So we can either make an assumption about a simple approach÷choose among a small number of standard interfaces÷or a more complex one with interface features conditioned by user preferences.Ê

Suppose we opt for the simpler case.Ê Will the ATM present the options on its own, or will it wait for prompting by the user?ÊÊ Where will it have the capability of showing the user what the options are÷on its own physical plant or on a userâs accessor, or both?Ê Will it then present the chosen option on its own plant or will it transmit to the userâs accessor?ÊÊ In the former case, the accessor has only acted as an agent for determining the interface, and after that determination it no longer is a part of the transaction.Ê The AIAP has not played a complete role in the transaction, in that the A31 component is not explicit.Ê That is, the interface is not transmitted back to the user original User Local System, but to a ãproxyä, the ATM.Ê The interface does go back to Area 1, however, because the ATM display now becomes a part of the User Experience.Ê

The latter case, where the alternative interface is sent back to the accessor, is clearly different.Ê Here the userâs equipment and preferences have a larger role in determining what the ãlook and feelä of the alternative interface.Ê For example, if a visual display on the accessorÊ is used, how does the ATM display map to a smaller screen?Ê [Note that this is not conceptually different than conversion of a web page to a PDA.]

[Whether or not the ATM can override the presentation on its own plant to avoid disclosing private information to other people who might be nearby is not a concern of AIAP, but a concern of the designer of the ATM.Ê AIAP is responsible for conveying information about security and privacy, but not for ensuring that security and privacy.]

[At this point, we could consider the scoping problem again, going back and determining whether or not our scopes for Areas 1 and 4 are narrow enough or not broad enough.Ê However, we will not do that now in the interest of moving ahead with the discussion.]

We can limit the scope of information needed for selection or transformation of an interface by making some assumptions:

á when the accessor makes contact with the ATM, it thereby ãknowsä that the operational environment will be with an ATM device of particular manufacture.Ê The ATM could indicate this in the handshake.

á the accessor can thereby expect an interface of certain characteristics and features in its interface(s), but perhaps not all of the options, since this might be a factor of what the financial institution has actually bought in its ATMs and the particular version installed at the branch where the user is making contact. [This would mean that part of the A43 component of the protocol is implicit and has taken place outside this transaction.Ê The rest of the A43 protocol will be explicit to this transaction and will indicate the remainder information, perhaps new options or more details on known options.]

á the accessor may already have preferences for this kind of ATM stored in memory [even Java rings and smartcards have some memory], and these will correspond to known features for this kind of ATM.

á the ATM will also know about the general characteristics of the accessor, perhaps being identified indirectly through handshake information.Ê Since ATMs are generally networked devices (at least at a simple level), they could also have access to more detailed information about the accessor from a manufacturerâs repository, or could have it stored locally.Ê This part of the A23 component would be implicit and could be a part of the current transaction (obtaining it from a repository) or could take place prior to the transaction (i.e., storing it locally, called up by specific reference).

These assumptions are not unreasonable, in that they are likely to be the result of agreements between accessor manufacturers and ATM manufacturers.Ê V2 would offer the AIAP methodology to an accessor/ATM consortium and they would supply the details of the interactions.

Note that we do not care about the specific method of alternative interface choice or construction.Ê This will be determined by the ATM manufacturer.Ê We just need to know what kind of information is to be supplied to the method.

Conclusion

We have presented a reference model and method for determining scope and requirements for the AIAP.Ê It may well be simplified more and it may prove inadequate for more than coarse work on scope and requirements.Ê However, it is a start and suggestions for improvements are welcome.

One such improvement might be a questionnaire to help guide the decisions in each Area.Ê For example, we might ask:

á To what extent does the System require networking?

á How does the User Local System communicate with the offered service?Ê What is the nature of the communication (i.e., text, complex objects, etc.)

á What is the processing power of the User Local System?

á What are the characteristics of the User Local System and the User Experience? (i.e., what is the current user interface like?)

á What method isÊ used to select or construct an alternative interface?

á What information does the offered service already have about the User Local System?Ê What information does the User Local System have about the offered service? (i.e., what can designers assume about what to build into their systems?)

á What user information must be taken into account? (e.g., what knowledge about a disability is useful in determining what to do about selecting or transforming an interface?

and so on.Ê Such a questionnaire might be tailored in lower levels of detail to the particular Task Group missions.

Wayne McCoy