Dynamically determing appropriate computer user interfaces

Abstract

A method, system, and computer-readable medium are described for dynamically determining an appropriate user interface (“UI”) to be provided to a user. In some situations, the determining is to dynamically modify a UI being provided to a user of a wearable computing device so that the current UI is appropriate for a current context of the user. In order to dynamically determine an appropriate UI, various types of UI needs may be characterized (e.g., based on a current user's situation, a current task being performed, current I/O devices that are available, etc.) in order to determine characteristics of a UI that is currently optimal or appropriate, various existing UI designs or templates may be characterized in order to identify situations for which they are optimal or appropriate, and one of the existing UIs that is most appropriate may then be selected based on the current UI needs.

Description

TECHNICAL FIELD

[0002] The following disclosure relates generally to computer user interfaces, and more particularly to various techniques for dynamically determining an appropriate user interface, such as based on a current context of a user of a wearable computer.

BACKGROUND

[0003] Current user interfaces (UIs) often use a windows, icons, menus, and pointers (WIMP) interface. While WIMP interfaces have proved useful for some users of stationary desktop computers, a WIMP interface is not typically appropriate for other users (e.g., users that are non-stationary and/or users of other types of computing devices). One reason that WIMP interfaces are inappropriate in other situations is that they make several inappropriate assumptions about the user's situation, including: (a) that the user's computing device has a significant amount of screen real estate available for the UI; (b) that interaction, not digital information, is the user's primary task (e.g., that the user is willing to track a pointer's movement, hunt down a menu item or button, find an icon, and/or immediately receive and respond to information being presented); and (c) that the user can and should explicitly specify how and when to change the interface (e.g., to adapt to changes in the user's environment).

[0004] Moreover, what limited controls are available to the user in a WIMP interface (e.g., manually changing the entire computer display's brightness or audio volume) are typically complicated (e.g., system controls are not integrated in the control mechanisms of the computing system—instead, users must go through multiple layers of system software), inflexible (e.g., user preferences do not apply to different input and output (I/O) devices), non-automated (e.g., UIs do not typically respond to context changes without direct user intervention), not user-extensible (e.g., new devices cannot be integrated into existing preferences), not user-programmable (e.g., users cannot modify underlying logic used), and difficult to share (e.g., there is a lack of integration, which means preference for logic used cannot be conveniently stored and exported to other computers), as well as suffering from various other problems.

[0005] A computing system and/or an executing software application that were able to dynamically modify a UI during execution so as to appropriately reflect current conditions would provide a variety of benefits. However, to perform such dynamic modification of a UI, whether by choosing between existing options and/or by creating a custom UI, such a system and/or software may need to be able to determine and respond to a variety of complex current UI needs. For instance, in a situation in which the user requires that the input to the computing environment be private, the computer-assisted task is complex, and the user has access to a head-mounted display (HMD) and a keyboard, the UI needs are different than a situation in which the user does not require any privacy, has access to a desktop computer with a monitor, and the computer-assisted task is simple.

[0006] Unfortunately, current computing systems and software applications (including WIMP interfaces) do not explicitly model sufficient UI needs (e.g., privacy, safety, available I/O devices, learning style, etc.) to allow an optimal or near-optimal UI to be dynamically determined and used during execution. In fact, most computing systems and software applications do not explicitly model any UI needs, and make no attempt to dynamically modify their UI during execution to reflect current conditions.

[0007] Some current systems do attempt to provide modifiability of UI designs in various limited ways that do not involve modeling such UI needs, but each fail for one reason or another. Some such current techniques include:

[0008] changing UI design based on device type;

[0009] specifying explicit user preferences; and

[0010] changing UI output by selecting a platform at compile-time.

[0011] Unfortunately, none of these techniques address the entire problem, as discussed below.

[0012] Changing the UI based on the type of device (e.g., providing a personal digital assistant (PDA) with a different UI than a desktop computer or a computer in an automobile) typically involves designing completely separate UIs that are not inter-compatible and that do not react to the user's context. Thus, the user gets a different UI on each computing device that they use, and gets the same UI on a particular device regardless of their situation (e.g., whether they are driving a car, working on an airplane engine, or sitting at a desk).

[0013] Specifying of user preferences (e.g., as allowed by the Microsoft Windows operating system and some application programs) typically allows a UI to be modified, but in ways that are limited to appearance and superficial functionality (e.g., accessibility, pointers, color schemes, etc.), and requires an explicit user intervention (which is typically difficult and time-consuming to specify) every time that the UI is to change.

[0014] Changing the type of UI output that will be presented (e.g., pop-up menus versus scrolling lists) based on the underlying software platform (e.g., operating system) that will be used to support the presentation is typically a choice that must be made at compile time, and often involves requiring the UI to be limited to a subset of functionality that is available on every platform to be supported. For example, Geoworks' U.S. Pat. No. 5,327,529 describes a system that supports the creation of software applications that can change their appearance in limited manners based on different platforms.

[0015] Thus, while current systems provide limited modifiability of UI designs, such current systems do not dynamically modify a UI during execution so as to appropriately reflect current conditions. The ability to provide such dynamic modification of a UI would provide significant benefits in a wide variety of situations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1 is a data flow diagram illustrating one embodiment of dynamically determining an appropriate or optimal UI.

[0017] FIG. 2 is a block diagram illustrating an embodiment of a computing device with a system for dynamically determining an appropriate UI.

[0018] FIG. 3 illustrates an example relationship between various techniques related to dynamic optimization of computer user interfaces.

[0019] FIG. 4 illustrates an example of an overall mechanism for characterizing a user's context.

[0020] FIG. 5 illustrates an example of automatically generating a task characterization at run time.

[0021] FIG. 6 is a representation of an example of choosing one of multiple arbitrary predetermined UI designs at run time.

[0022] FIG. 7 is a representation of example logic that can be used to choose a UI design at run time.

[0023] FIG. 8 is an example of how to match a UI design characterization with UI requirements via a weighted matching index.

[0024] FIG. 9 is an example of how UI requirements can be weighted so that one characteristic overrides all other characteristics when using a weighted matching index.

[0025] FIG. 10 is an example of how to match a UI design characterization with UI requirements via a weighted matching index.

[0026] FIG. 11 is a block diagram illustrating an embodiment of a computing device capable of executing a system for dynamically determining an appropriate

[0027] FIG. 12 is a diagram illustrating an example of characterizing multiple UI designs.

[0028] FIG. 13 is a diagram illustrating another example of characterizing multiple UI designs.

[0029] FIG. 14 illustrates an example UI.

DETAILED DESCRIPTION

[0030] A software facility is described below that provides various techniques for dynamically determining an appropriate UI to be provided to a user. In some embodiments, the software facility executes on behalf of a wearable computing device in order to dynamically modify a UI being provided to a user of the wearable computing device (also referred to as a wearable personal computer or “WPC”) so that the current UI is appropriate for a current context of the user. In order to dynamically determine an appropriate UI, various embodiments characterize various types of UI needs (e.g., based on a current user's situation, a current task being performed, current I/O devices that are available, etc.) in order to determine characteristics of a UI that is currently optimal or appropriate, characterize various existing UI designs or templates in order to identify situations for which they are optimal or appropriate, and then selects and uses one of the existing UIs that is most appropriate based on the current UI needs. In other embodiments, various types of UI needs are characterized and a UI is dynamically generated to reflect those UI needs, such as by combining in an appropriate or optimal manner various UI building block elements that are appropriate or optimal for the UI needs. A UI may in some embodiments be dynamically generated only if an existing available UI is not sufficiently appropriate, and in some embodiments a UI to be used is dynamically generated by modifying an existing available UI.

[0031] For illustrative purposes, some embodiments of the software facility are described below in which current UI needs are determined in particular ways, in which existing UIs are characterized in various ways, and in which appropriate or optimal UIs are selected or generated in various ways. In addition, some embodiments of the software facility are described below in which described techniques are used to provide an appropriate UI to a user of a wearable computing device based on a current context of the user. However, those skilled in the art will appreciate that the disclosed techniques can be used in a wide variety of other situations and that UI needs and UI characterizations can be determined in a variety of ways.

[0032] FIG. 1 illustrates an example of one embodiment of an architecture for dynamically determining an appropriate UI. In particular, box 109 represents using an appropriate UI for a current context. When changes in the current context render a previous UI inappropriate or non-optimal, a new UI appropriate or optimal UI can be selected or generated, as is shown in boxes 146 and 155 respectively. In order to enable selection of a new UI that is appropriate or optimal, the characteristics of a UI that is currently appropriate or optimal are determined in box 145 and the characteristics of various existing UIs are determined in box 135 (e.g., in a manual and/or automatic manner). In order to enable the determination of the characteristics of a UI that is currently appropriate or optimal, in the illustrated embodiment the UI requirements of the current task are determined in box 149 (e.g., in a manual and/or automatic manner), the UI requirements corresponding to the user are determined in box 150 (e.g., based on the user's current needs), and the UI requirements corresponding to the currently available I/O devices are determined in box 147. The UI requirements corresponding to the user can be determined in various ways, such as in the illustrated embodiment by determining in box 106 the quantity and quality of attention that the user can currently provide to their computing system and/or executing application. If a new appropriate or optimal UI is to generated in box 155, the generation is enabled in the illustrated embodiment by determining the characteristics of a UI that is currently appropriate or optimal in box 145, determining techniques for constructing a UI design to reflect UI requirements in box 156 (e.g., by combining various specified UI building block elements), and determining how newly available hardware devices can be used as part of the UI. The order and frequency of the illustrated types of processing can be varied in various embodiments, and in other embodiments some of the illustrated types of processing may not be performed and/or additional non-illustrated types of processing may be used.

[0033] FIG. 2 illustrates an example computing device 200 suitable for executing an embodiment of the facility, as well as one or more additional computing device 250s with which the computing device 200 may interact. The computing device 200 includes a CPU 205, various I/O devices 210, storage 220, and memory 230. The I/O devices include a display 211, a network connection 212, a computer-readable media drive 213, and other I/O devices 214.

[0034] Various components 241-248 are executing in memory 230 to enable dynamic determination of appropriate or optimal UIs, as are a UI Applier component 249 to apply an appropriate or optimal UI that is dynamically determined. One or more other application programs 235 may also be executing in memory, and the UI Applier may supply, replace or modify the UIs of those application programs. The dynamic determination components include a Task Characterizer 241, a User Characterizer 242, a Computing System Characterizer 243, an Other Accessible Computing Systems Characterizer 244, an Available UI Designs Characterizer 245, an Optimal UI Determiner 246, an Existing UI Selector 247, and a New UI Generator 248. The various components may use and/or generate a variety of information when executing, such as UI building block elements 221, current context information 222, and current characterization information 223.

[0035] Those skilled in the art will appreciate that computing devices 200 and 250 are merely illustrative and are not intended to limit the scope of the present invention. Computing device 200 may be connected to other devices that are not illustrated, including through one or more networks such as the Internet or via the World Wide Web (WWW), and many in some embodiments be a wearable computer. In other embodiments, the computing devices may comprise other combinations of hardware and software, including computers, network devices, internet appliances, PDAs, wireless phones, pagers, electronic organizers, television-based systems and various other consumer products that include inter-communication capabilities. In addition, the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available.

[0036] Those skilled in the art will also appreciate that, while various items are illustrated as being stored in memory or on storage while being used, these items or portions of them can be transferred between memory and other storage devices for purposes of memory management and data integrity. Some or all of the components and their data structures may also be stored (e.g., as instructions or structured data) on a computer-readable medium, such as a hard disk, a memory, a network, or a portable article to be read by an appropriate drive. The components and data structures can also be transmitted as generated data signals (e.g., as part of a carrier wave) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums Accordingly, the present invention may be practiced with other computer system configurations.

[0037] What follows are various examples of techniques for dynamically determining an appropriate UI, such as by characterizing various types of UI needs and/or by characterizing various existing UI designs or templates in order to identify situations for which they are optimal or appropriate.

[0038] Modeling a Computer User's Cognitive Availability

[0039] User's Meaning

[0040] (the significance and/or implication of things, in the user's mind)

[0041] Task, Purpose, Activity, Destination, Motivation, Desired Privacy

[0042] When we assign a type, a friendly name, or description to a thing like place, we support the inference of intention.

[0043] A grocery store is where activity associated with shopping can be accomplished—it is a characterization, an association of activities, in the mind of the user about a specific place.

[0044] User's Cognition

[0045] Cognitive/Attention Availability

[0046] “Change in Cognitive Availability Change in Mode of interaction” (could differentiate between ‘user doesn't have the cycles’ and ‘user has them, but does not chose to give them to WPC’)

[0047] “State Info/Compartmentalization Complexity of UI”

[0048] Characterize tasks as PC Aware, or not.

[0049] Divided User Attention

[0050] This section will deal primarily with Divided Attention.

[0051] When performing more than one task at a time, the user can engage in three types of tasks:

[0052] Focus Tasks: requires the users primary attention

[0053] An example of a Focus Task is looking at a map.

[0054] Routine Tasks: requires attention from the user, but allows multi-tasking in parallel

[0055] An example of a Routine Task is talking on a cell phone, through the headset.

[0056] Awareness Tasks: does not require any significant attention from the user

[0057] For an example of an “Awareness Task”, imagine that the rate of data connectivity were represented as the background sound of flowing water. The user would be aware of the rate at some level, without significantly impacting the available User Attention.

[0058] To perform tasks simultaneously, there are three kinds of divided attention-Task Switched, Parallel, and Awareness, as follows:

[0059] Task Switching (Focus Task+Focus Task)

[0060] When the user is engaged in more than one Focus Task, the attention is Task Switched. The user performs a compartmentalized subset of one task, interrupts that task, and performs a compartmentalized subset of the other task, as follows:

[0061] Re-Grounding Phase: As the user returns to a Focus Task, they first reacquire any state information associated with the task, and/or acquire the UI elements themselves. Either the user or the WPC can carry the state information.

[0062] Work Phase: Here the user actually performs the sub-task. The longer this phase, the more complex the subtask can be.

[0063] Interruption/Off Task: When the interruption occurs, the user switches from one Focus Task to another task.

[0064] When the duration of Work on Task increases (say, when the user's motion temporarily goes from 30 MPH to 0), then task presentation can more complex. This includes increased context of the steps involved (e.g., view more steps in the Bouncing Ball Wizard) or greater detail of each step (addition of other people's schedule when making appointments).

[0065] The longer the Off Task cycle, the more likely the user is to lose Task State Information that is carried in their head. Also, the more complex or voluminous the Task State Information, the more desirable it becomes to allow the WPC to present the state information. The side effect of using the WPC to present Task State Information is that the Re-Grounding Phase may be lengthened, reducing the Work Phase.

[0066] Parallel

[0067] (Focus Task+Routine) OR (Routine+Routine)

[0068] Background Awareness

[0069] The concept of Background Awareness is that a non-focus output stimulus allows the user to monitor information without devoting significant attention or cognition. The stimulus retreats to the subconscious, but the user is consciously aware of an abrupt change in the stimulus.

[0070] Cocktail Party Effect

[0071] In audio, a phenomenon known as the “Cocktail Party Effect” allows a user to listen to multiple background audio channels, as long as the sounds representing each process are distinguishable.

[0072] Experiments have shown that increasing the channels beyond three (3) causes degradation in comprehension. [Stiefelman94]

[0073] Spatial layout (3D Audio) can be used as an aid to audio memory. Focus can be given to a particular audio channel by increasing the gain on that channel.

[0074] Listening and Monitoring have different cognitive burdens.

[0075] The MIT Nomadic Radio Paper “Simultaneous and Spatial Listening” provides additional information on this phenomenon.

[0076] Characterizing a Computer User's UI Requirements

[0077] When monitoring and evaluating some or all available characteristics that could cause a UI to change (regardless of the source of the characteristic), it is possible to choose one or more of the most important characteristics upon which to build a UI, and then pass those characteristics to the computing system.

[0078] Considered singularly, many of the characteristics described in this disclosure can be beneficially used to inform a computing system when to change. However, with an extensible system, additional characteristics can be considered (or ignored) at anytime, providing precision to the optimization.

[0079] Attributes Analyzed

[0080] This section describes various modeled real-world and virtual contexts The described model for optimal UI design characterization includes at least the following categories of attributes when determining the optimal UI design:

[0081] All available attributes. The model is dynamic so it can accommodate for any and all attributes that could affect the optimal UI design for a user's context.

[0082] For example, this model could accommodate for temperature, weather conditions, time of day, available I/O devices, preferred volume level, desired level of privacy, and so on.

[0083] Significant attributes. Some attributes have a more significant influence on the optimal UI design than others. Significant attributes include, but are not limited to, the following:

[0084] The user can see video.

[0085] The user can hear audio.

[0086] The computing system can hear the user.

[0087] The interaction between the user and the computing system must be private.

[0088] The user's hands are occupied.

[0089] Attributes that correspond to a theme. Specific or programmatic. Individual or group.

[0090] Using even one of these attribute categories can produce a large number of potential UIs. As discussed below, a limited model of user context can generate a large number of distinct situations, each potentially requiring a unique UI design. Despite this large number, this is not a challenge for software implementation. Modern computers can easily handle software implementations of much larger lookup tables.

[0091] Although this document lists many attributes of a user's tasks and mental and physical environment, these attributes are meant to be illustrative because it is not possible to know all of the attributes that will affect a UI design until run time. The described model is dynamic so it can account for unknown attributes.

[0092] It is important to note that any of the attributes mentioned in this document are just examples. There are other attributes that can cause a UI to change that are not listed in this document. However, the dynamic model can account for additional attributes.

[0093] User Characterizations

[0094] This section describes the characteristics that are related to the user.

[0095] User Preferences

[0096] User preferences are a set of attributes that reflect the user's likes and dislikes, such as I/O devices preferences, volume of audio output, amount of haptic pressure, and font size and color for visual display surfaces. User preferences can be classified in the following categories:

[0097] Self characterization. Self-characterized user preferences are indications from the user to the computing system about themselves. The self-characterizations can be explicit or implicit. An explicit, self-characterized user preference results in a tangible change in the interaction and presentation of the UI. An example of an explicit, self characterized user preference is “Always use the font size 18” or “The volume is always off.” An implicit, self-characterized user preference results in a change in the interaction and presentation of the UI, but it might be not be immediately tangible to the user. A learning style is an implicit self-characterization. The user's learning style could affect the UI design, but the change is not as tangible as an explicit, self-characterized user preference.

[0098] If a user characterizes themselves to a computing system as a “visually impaired, expert computer user,” the UI might respond by always using 24-point font and monochrome with any visual display surface. Additionally, tasks would be chunked differently, shortcuts would be available immediately, and other accommodations would be made to tailor the UI to the expert user.

[0099] Theme selection. In some situations, it is appropriate for the computing system to change the UI based on a specific theme. For example, a high school student in public school 1420 who is attending a chemistry class could have a UI appropriate for performing chemistry experiments. Likewise, an airplane mechanic could also have a UI appropriate for repairing airplane engines. While both of these UIs would benefit from hands free, eyes out computing, the UI would be specifically and distinctively characterized for that particular system.

[0100] System characterization. When a computing system somehow infers a user's preferences and uses those preferences to design an optimal UI, the user preferences are considered to be system characterizations. These types of user preferences can be analyzed by the computing system over a specified period on time in which the computing system specifically detects patterns of use, learning style, level of expertise, and so on. Or, the user can play a game with the computing system that is specifically designed to detect these same characteristics.

[0101] Pre-configured. Some characterizations can be common and the UI can have a variety of pre-configured settings that the user can easily indicate to the UI. Pre-configured settings can include system settings and other popular user changes to default settings.

[0102] Remotely controlled. From time to time, it may be appropriate for someone or something other than the user to control the UI that is displayed.

[0103] Example User Preference Characterization Values

[0104] This UI characterization scale is enumerated. Some example values include:

[0105] Self characterization

[0106] Theme selection

[0107] System characterization

[0108] Pre-configured

[0109] Remotely controlled

[0110] Theme

[0111] A theme is a related set of measures of specific context elements, such as ambient temperature, current user task, and latitude, which reflect the context of the user. In other words, theme is a name collection of attributes, attribute values, and logic that relates these things. Typically, themes are associated with user goals, activities, or preferences. The context of the user includes:

[0112] The user's mental state, emotional state, and physical or health condition.

[0113] The user's setting, situation or physical environment. This includes factors external to the user that can be observed and/or manipulated by the user, such as the state of the user's computing system.

[0114] The user's logical and data telecommunications environment (or “cyber-environment,” including information such as email addresses, nearby telecommunications access such as cell sites, wireless computer ports, etc.).

[0115] Some examples of different themes include: home, work, school, and so on. Like user preferences, themes can be self characterized, system characterized, inferred, pre-configured, or remotely controlled.

[0116] Example Theme Characterization Values

[0117] This characteristic is enumerated. The following list contains example enumerated values for theme.

[0118] No theme

[0119] The user's theme is inferred.

[0120] The user's theme is pre-configured.

[0121] The user's theme is remotely controlled.

[0122] The user's theme is self characterized.

[0123] The user's theme is system characterized.

[0124] User Characteristics

[0125] User characteristics include:

[0126] Emotional state

[0127] Physical state

[0128] Cognitive state

[0129] Social state

[0130] Example User Characteristics Characterization Values

[0131] This UI characterization scale is enumerated. The following lists contain some of the enumerated values for each of the user characteristic qualities listed above.

* Emotional state.
* Happiness
* Sadness
* Anger
* Frustration
* Confusion
* Physical state
* Body
* Biometrics
* Posture
* Motion
* Physical Availability
* Senses
* Eyes
* Ears
* Tactile
* Hands
* Nose
* Tongue
* Workload demands/effects
* Interaction with computer devices
* Interaction with people
* Physical Health
* Environment
* Time/Space
* Objects
* Persons
* Audience/Privacy Availability
* Scope of Disclosure
* Hardware affinity for privacy
* Privacy indicator for user
* Privacy indicator for public
* Watching indicator
* Being observed indicator
* Ambient Interference
* Visual
* Audio
* Tactile
* Location.
* Place_name
* Latitude
* Longitude
* Altitude
* Room
* Floor
* Building
* Address
* Street
* City
* County
* State
* Country
* Postal_Code
* Physiology.
* Pulse
* Body_temperature
* Blood_pressure
* Respiration
* Activity
* Driving
* Eating
* Running
* Sleeping
* Talking
* Typing
* Walking
*Cognitive state
* Meaning
* Cognition
* Divided User Attention
* Task Switching
* Background Awareness
* Solitude
* Privacy
* Desired Privacy
* Perceived Privacy
* Social Context
* Affect
* Social state
* Whether the user is alone or if others are present
* Whether the user is being observed (e.g., by a camera)
* The user's perceptions of the people around them and the user's
perceptions of the intentions of the people that surround them.
* The user's social role (e.g. they are a prisoner, they are a guard, they are
a nurse, they are a teacher, they are a student, etc.)

[0132] Cognitive Availability

[0133] There are three kinds of user tasks: focus, routine, and awareness and three main categories of user attention: background awareness, task switched attention, and parallel. Each type of task is associated with a different category of attention. Focus tasks require the highest amount of user attention and are typically associated with task-switched attention. Routine tasks require a minimal amount of user attention or a user's divided attention and are typically associated with parallel attention. Awareness tasks appeals to a user's precognitive state or attention and are typically associated with background awareness. When there is an abrupt change in the sound, such as changing from a trickle to a waterfall, the user is notified of the change in activity.

[0134] Background Awareness

[0135] Background awareness is a non-focus output stimulus that allows the user to monitor information without devoting significant attention or cognition.

[0136] Example Background Awareness Characterization Values

[0137] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user has no awareness of the computing system/the user has background awareness of the computing system.

[0138] Using these values as scale endpoints, the following list is an example background awareness scale.

[0139] No background awareness is available. A user's pre-cognitive state is unavailable.

[0140] A user has enough background awareness available to the computing system to receive one type of feedback or status.

[0141] A user has enough background awareness available to the computing system to receive more than one type of feedback, status and so on.

[0142] A user's background awareness is fully available to the computing system. A user has enough background awareness available for the computing system such that they can perceive more than two types of feedback or status from the computing system.

[0143] Exemplary UI Design Implementations for Background Awareness

[0144] The following list contains examples of UI design implementations for how a computing system might respond to a change in background awareness.

[0145] If a user does not have any attention for the computing system, that implies that no input or output are needed.

[0146] If a user has enough background awareness available to receive one type of feedback, the UI might:

[0147] Present a single light in the peripheral vision of a user. For example, this light can represent the amount of battery power available to the computing system. As the battery life weakens, the light gets dimmer. If the battery is recharging, the light gets stronger.

[0148] If a user has enough background awareness available to receive more than one type of feedback, the UI might:

[0149] Present a single light in the peripheral vision of the user that signifies available battery power and the sound of water to represent data connectivity.

[0150] If a user has full background awareness, then the UI might:

[0151] Present a single light in the peripheral vision of the user that signifies available battery power, the sound of water that represents data connectivity, and pressure on the skin to represent the amount of memory available to the computing system.

[0152] Task Switched Attention

[0153] When the user is engaged in more than one focus task, the user's attention can be considered to be task switched.

[0154] Example Task Switched Attention Characterization Values

[0155] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have any attention for a focus task/the user has full attention for a focus task.

[0156] Using these characteristics as the scale endpoints, the following list is an example of a task switched attention scale.

[0157] A user does not have any attention for a focus task.

[0158] A user does not have enough attention to complete a simple focus task. The time between focus tasks is long.

[0159] A user has enough attention to complete a simple focus task. The time between focus tasks is long.

[0160] A user does not have enough attention to complete a simple focus task. The time between focus tasks is moderately long.

[0161] A user has enough attention to complete a simple focus task. The time between tasks is moderately long.

[0162] A user does not have enough attention to complete a simple focus task. The time between focus tasks is short.

[0163] A user has enough attention to complete a simple focus task. The time between focus tasks is short.

[0164] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[0165] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[0166] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is moderately long.

[0167] A user has enough attention to complete a moderately complex focus task. The time between tasks is moderately long.

[0168] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[0169] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[0170] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[0171] A user has enough attention to complete a complex focus task. The time between focus tasks is long.

[0172] A user does not have enough attention to complete a complex focus task. The time between focus tasks is moderately long.

[0173] A user has enough attention to complete a complex focus task. The time between tasks is moderately long.

[0174] A user does not have enough attention to complete a complex focus task. The time between focus tasks is short.

[0175] A user has enough attention to complete a complex focus task. The time between focus tasks is short.

[0176] A user has enough attention to complete a very complex, multi-stage focus task before moving to a different focus task.

[0177] Parallel

[0178] Parallel attention can consist of focus tasks interspersed with routine tasks (focus task+routine task) or a series of routine tasks (routing task+routine task).

[0179] Example Parallel Attention Characterization Values

[0180] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have enough attention for a parallel task/the user has full attention for a parallel task.

[0181] Using these characteristics as scale endpoints, the following list is an example of a parallel attention scale.

[0182] A user has enough available attention for one routine task and that task is not with the computing system.

[0183] A user has enough available attention for one routine task and that task is with the computing system.

[0184] A user has enough attention to perform two routine tasks and at least of the routine tasks is with the computing system.

[0185] A user has enough attention to perform a focus task and a routine task. At least one of the tasks is with the computing system.

[0186] A user has enough attention to perform three or more parallel tasks and at least one of those tasks is in the computing system.

[0187] Physical Availability

[0188] Physical availability is the degree to which a person is able to perceive and manipulate a device. For example, an airplane mechanic who is repairing an engine does not have hands available to input indications to the computing systems by using a keyboard.

[0189] Learning Profile

[0190] A user's learning style is based on their preference for sensory intake of information. That is, most users have a preference for which sense they use to assimilate new information.

[0191] Example Learning Style Characterization Values

[0192] This characterization is enumerated. The following list is an example of learning style characterization values.

[0193] Auditory

[0194] Visual

[0195] Tactile

[0196] Exemplary UI Design Implementation for Learning Style

[0197] The following list contains examples of UI design implementations for how the computing system might respond to a learning style.

[0198] If a user is a auditory learner, the UI might:

[0199] Present content to the user by using audio more frequently.

[0200] Limit the amount of information presented to a user if these is a lot of ambient noise.

[0201] If a user is a visual learner, the UI might:

[0202] Present content to the user in a visual format whenever possible.

[0203] Use different colors to group different concepts or ideas together.

[0204] Use illustrations, graphs, charts, and diagrams to demonstrate content when appropriate.

[0205] If a user is a tactile learner, the UI might:

[0206] Present content to the user by using tactile output.

[0207] Increase the affordance of tactile methods of input (e.g. increase the affordance of keyboards).

[0208] Software Accessibility

[0209] If an application requires a media-specific plug-in, and the user does not have a network connection, then a user might not be able to accomplish a task.

[0210] Example Software Accessibility Characterization Values

[0211] This characterization is enumerated. The following list is an example of software accessibility values.

[0212] The computing system does not have access to software.

[0213] The computing system has access to some of the local software resources.

[0214] The computing system has access to all of the local software resources.

[0215] The computing system has access to all of the local software resources and some of the remote software resources by availing itself to opportunistic user of software resources.

[0216] The computing system has access to all of the local software resources and all remote software resources by availing itself to the opportunistic user of software resources.

[0217] The computing system has access to all software resources that are local and remote.

[0218] Perception of Solitude

[0219] Solitude is a user's desire for, and perception of, freedom from input. To meet a user's desire for solitude, the UI can do things like:

[0220] Cancel unwanted ambient noise

[0221] Block out human made symbols generated by other humans and machines

[0222] Example Solitude Characterization Values

[0223] This characterization is scalar, with the minimum range being binary. Example binary values, or scalar endpoints, are: no solitude/complete solitude.

[0224] Using these characteristics as scale endpoints, the following list is an example of a solitude scale.

[0225] No solitude

[0226] Some solitude

[0227] Complete solitude

[0228] Privacy

[0229] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be a head mounted display (HMD) and the preferred input device might be an eye-tracking device.

[0230] Hardware Affinity for Privacy

[0231] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[0232] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[0233] Example Privacy Characterization Values

[0234] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[0235] Using no privacy and fully private as the scale endpoints, the following list is an example privacy characterization scale.

[0236] No privacy is needed for input or output interaction

[0237] The input must be semi-private. The output does not need to be private.

[0238] The input must be fully private. The output does not need to be private.

[0239] The input must be fully private. The output must be semi-private.

[0240] The input does not need to be private. The output must be fully private.

[0241] The input does not need to be private. The output must be semi-private.

[0242] The input must be semi-private. The output must be semi-private.

[0243] The input and output interaction must be fully private.

[0244] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[0245] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[0246] Exemplary UI Design Implementation for Privacy

[0247] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[0248] If no privacy is needed for input or output interaction:

[0249] The UI is not restricted to any particular I/O device for presentation and interaction. For example, the UI could present content to the user through speakers on a large monitor in a busy office.

[0250] If the input must be semi-private and if the output does not need to be private, the UI might:

[0251] Encourage the user to use coded speech commands or use a keyboard if one is available. There are no restrictions on output presentation.

[0252] If the input must be fully private and if the output does not need to be private, the UI might:

[0253] Not allow speech commands. There are no restrictions on output presentation.

[0254] If the input must be fully private and if the output needs to be semi-private, the UI might:

[0255] Not allow speech commands (allow only keyboard commands). Not allow an LCD panel and use earphones to provide audio response to the user.

[0256] If the output must be semi-private and if the input does not need to be private, the UI might:

[0257] Restrict users to an HMD device and/or an earphone for output. There are no restrictions on input interaction,

[0258] If the output must be semi-private and if the input does not need to be private, the UI might:

[0259] Restrict users to HMD devices, earphones, and/or LCD panels. There are no restrictions on input interaction.

[0260] If the input and output must be semi-private, the UI might:

[0261] Encourage the user to use coded speech commands and keyboard methods for input. Output may be restricted to HMD devices, earphones or LCD panels.

[0262] If the input and output interaction must be completely private, the UI might:

[0263] Not allow speech commands and encourage the user of keyboard methods of input. Output is restricted to HMD devices and/or earphones.

[0264] User Expertise

[0265] As the user becomes more familiar with the computing system or the UI, they may be able to navigate through the UI more quickly. Various levels of user expertise can be accommodated. For example, instead of configuring all the settings to make an appointment, users can recite all the appropriate commands in the correct order to make an appointment. Or users might be able to use shortcuts to advance or move back to specific screens in the UI. Additionally, expert users may not need as many prompts as novice users. The UI should adapt to the expertise level of the user.

[0266] Example User Expertise Characterization Values

[0267] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: new user/not new user, not an expert user/expert user, new user/expert user, and novice/expert.

[0268] Using novice and expert as scale endpoints, the following list is an example user expertise scale.

[0269] The user is new to the computing system and to computing in general.

[0270] The user is new to the computing system and is an intermediate computer user.

[0271] The user is new to the computing system, but is an expert computer user.

[0272] The user is an intermediate user in the computing system.

[0273] The user is an expert user in the computing system.

[0274] Exemplary UI Design Implementation for User Expertise

[0275] The following are characteristics of an exemplary audio UI design for novice and expert computer users.

[0276] The computing system speaks a prompt to the user and waits for a response.

[0277] If the user responds in x seconds or less, then the user is an expert. The computing system gives the user prompts only.

[0278] If the user responds in >x seconds, then the user is a novice and the computing system begins enumerating the choices available.

[0279] This type of UI design works well when more than 1 user accesses the same computing system and the computing system and the users do not know if they are a novice or an expert.

[0280] Language

[0281] User context may include language, as in the language they are currently speaking (e.g. English, German, Japanese, Spanish, etc.).

[0282] Example Language Characterization Values

[0283] This characteristic is enumerated. Example values include:

[0284] American English

[0285] British English

[0286] German

[0287] Spanish

[0288] Japanese

[0289] Chinese

[0290] Vietnamese

[0291] Russian

[0292] French

[0293] Computing System

[0294] This section describes attributes associated with the computing system that may cause a UI to change.

[0295] Computing Hardware Capability

[0296] For purposes of user interfaces designs, there are four categories of hardware:

[0297] Input/output devices

[0298] Storage (e.g. RAM)

[0299] Processing capabilities

[0300] Power supply

[0301] The hardware discussed in this topic can be the hardware that is always available to the computing system. This type of hardware is usually local to the user. Or the hardware could sometimes be available to the computing system. When a computing system uses resources that are sometimes available to it, this can be called an opportunistic use of resources.

[0302] Storage

[0303] Storage capacity refers to how much random access memory (RAM) is available to the computing system at any given moment. This number is not considered to be constant because the computing system might avail itself to the opportunistic use of memory.

[0304] Usually the user does not need to be aware of how much storage is available unless they are engaged in a task that might require more memory than to which they reliably have access. This might happen when the computing system engages in opportunistic use of memory. For example, if an in-motion user is engaged in a task that requires the opportunistic use of memory and that user decides to change location (e.g. they are moving from their vehicle to a utility pole where they must complete other tasks), the UI might warn the user that if they leave the current location, the computing system may not be able to complete the task or the task might not get completed as quickly.

[0305] Example Storage Characterization Values

[0306] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no RAM is available/all RAM is available.

[0307] Using no RAM is available and all RAM is available, the following table lists an example storage characterization scale.

Scale attribute                  Implication
No RAM is available to the       If no RAM is available, there is
computing system                 no UI available.-Or-There is no
                                 change to the UI.
Of the RAM available to the      The UI is restricted to the
computing system, only the       opportunistic use of RAM.
opportunistic use of RAM is available.
Of the RAM that is available to  The UI is restricted to using
the computing system, only the local local RAM.
RAM is accessible
Of the RAM that is available to  The UI might warn the user
the computing system, the local RAM is that if they lose
available and the user is about to lose opportunistic use of memory,
opportunistic use of RAM.        the computing system might
                                 not be able to complete the
                                 task, or the task might not
                                 be completed as quickly
Of the total possible RAM        If there is enough memory
available to the computing system, all available to the computing
of it is available.              system to fully function
                                 at a high level, the UI
                                 may not need to inform the
                                 user. If the user indicates
                                 to the computing system that
                                 they want a task completed
                                 that requires more memory,
                                 the UI might suggest that
                                 the user change locations
                                 to take advantage of
                                 additional opportunistic
                                 use of memory.

[0308] Processing Capabilities

[0309] Processing capabilities fall into two general categories:

[0310] Speed. The processing speed of a computing system is measured in megahertz (MHz). Processing speed can be reflected as the rate of logic calculation and the rate of content delivery. The more processing power a computing system has, the faster it can calculate logic and deliver content to the user.

[0311] CPU usage. The degree of CPU usage does not affect the UI explicitly.

[0312] With current UI design, if the CPU becomes too busy, the UI Typically “freezes” and the user is unable to interact with the computing system. If the CPU usage is too high, the UI will change to accommodate the CPU capabilities. For example, if the processor cannot handle the demands, the UI can simplify to reduce demand on the processor.

[0313] Example Processing Capability Characterization Values

[0314] This UI characterization is scalar, with the minimum range being binary. Example binary or scale endpoints are: no processing capability is available/all processing capability is available.

[0315] Using no processing capability is available and all processing capability as scale endpoints, the following table lists an example processing capability scale.

Scale attribute               Implication
No processing power is        There is no change to the UI
available to the comput-
ing system
The computing system has      The UI might be audio or text
access to a slower speed CPU. only.
The computing system has      The UI might choose to use
access to a high speed CPU    video in the presentation
                              instead of a still picture.
The computing system has      There are no restrictions on the
access to and control of all  UI based on processing power.
processing power available
to the computing system.

[0316] Power Supply

[0317] There are two types of power supplies available to computing systems: alternating current (AC) and direct current (DC). Specific scale attributes for AC power supplies are represented by the extremes of the exemplary scale. However, if a user is connected to an AC power supply, it may be useful for the UI to warn an in-motion user when they're leaving an AC power supply. The user might need to switch to a DC power supply if they wish to continue interacting with the computing system while in motion. However, the switch from AC to DC power should be an automatic function of the computing system and not a function of the UI.

[0318] On the other hand, many computing devices, such as wearable personal computers (WPCs), laptops, and PDAs, operate using a battery to enable the user to be mobile. As the battery power wanes, the UI might suggest the elimination of video presentations to extend battery life. Or the UI could display a VU meter that visually demonstrates the available battery power so the user can implement their preferences accordingly.

[0319] Example Power Supply Characterization Values

[0320] This task characterization is binary if the power supply is AC and scalar if the power supply is DC. Example binary values are: no power/full power. Example scale endpoints are: no power/all power.

[0321] Using no power and full power as scale endpoints, the following list is an example power supply scale.

[0322] There is no power to the computing system.

[0323] There is an imminent exhaustion of power to the computing system.

[0324] There is an inadequate supply of power to the computing system.

[0325] There is a limited, but potentially inadequate supply of power to the computing system.

[0326] There is a limited but adequate power supply to the computing system.

[0327] There is an unlimited supply of power to the computing system.

[0328] Exemplary UI Design Implementations for Power Supply

[0329] The following list contains examples of UI design implementations for how the computing system might respond to a change in the power supply capacity.

[0330] If there is minimal power remaining in a battery that is supporting a computing system, the UI might:

[0331] Power down any visual presentation surfaces, such as an LCD.

[0332] Use audio output only.

[0333] If there is minimal power remaining in a battery and the UI is already audio-only, the UI might:

[0334] Decrease the audio output volume.

[0335] Decrease the number of speakers that receive the audio output or use earplugs only.

[0336] Use mono versus stereo output.

[0337] Decrease the number of confirmations to the user.

[0338] If there is, for example, six hours of maximum-use battery life available and the computing system determines that the user not have access to a different power source for 8 hours, the UI might:

[0339] Decrease the luminosity of any visual display by displaying line drawings instead of 3-dimensional illustrations.

[0340] Change the chrominance from color to black and white.

[0341] Refresh the visual display less often.

[0342] Decrease the number of confirmations to the user.

[0343] Use audio output only.

[0344] Decrease the audio output volume.

[0345] Computing Hardware Characteristics

[0346] The following is a list of some of the other hardware characteristics that may be influence what is an optimal UI design.

[0347] Cost

[0348] Waterproof

[0349] Ruggedness

[0350] Mobility

[0351] Again, there are other characteristics that could be added to this list. However, it is not possible to list all computing hardware attributes that might influence what is considered to be an optimal UI design until run time.

[0352] Bandwidth

[0353] There are different types of bandwidth, for instance:

[0354] Network bandwidth

[0355] Inter-device bandwidth

[0356] Network Bandwidth

[0357] Network bandwidth is the computing system's ability to connect to other computing resources such as servers, computers, printers, and so on. A network can be a local area network (LAN), wide area network (WAN), peer-to-peer, and so on. For example, if the user's preferences are stored at a remote location and the computing system determines that the remote resources will not always be available, the system might cache the user's preferences locally to keep the UI consistent. As the cache may consume some of the available RAM resources, the UI might be restricted to simpler presentations, such as text or audio only.

[0358] If user preferences cannot be cached, then the UI might offer the user choices about what UI design families are available and the user can indicate their design family preference to the computing system.

[0359] Example Network Bandwidth Characterization Values

[0360] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no network access/full network access.

[0361] Using no network access and full network access as scale endpoints, the following table lists an example network bandwidth scale.

Scale attribute               Implication
The computing system does not The UI is restricted to using local
have a connection to network  computing resources only. If user
resources.                    preferences are stored remotely, then
                              the UI might not account for user
                              preferences.
The computing system has an   The UI might warn the user that
unstable connection to        the connection to remote resources
network resources             might be interrupted. The UI might
                              ask the user if they want to cache
                              appropriate information to
                              accommodate for the unstable
                              connection to network resources.
The computing system has a    The UI might simplify, such as
slow connection to network    offer audio or text only, to
resources                     accommodate for the slow connection.
                              Or the computing system might cache
                              appropriate data for the UI so the UI
                              can always be optimized without
                              restriction of the slow connection.
The computing system has a    In the present moment, the UI
high speed, yet limited (by   does not have any restrictions based
time) access to network       on access to network resources. If the
resources                     computing system determines that
                              it will lose a network connection,
                              then the UI can warn the user and
                              offer choices, such as does the
                              user want to cache appropriate
                              information, about what to do.
The computing system has a    There are no restrictions to the
very high-speed connection    UI based on access to network
to network resources.         resources. The UI can offer text,
                              audio, video, haptic output, and so
                              on.

[0362] Inter-Device Bandwidth

[0363] Inter-device bandwidth is the ability of the devices that are local to the user to communicate with each other. Inter-device bandwidth can affect the UI in that if there is low inter-device bandwidth, then the computing system cannot compute logic and deliver content as quickly. Therefore, the UI design might be restricted to a simpler interaction and presentation, such as audio or text only. If bandwidth is optimal, then there are no restrictions on the UI based on bandwidth. For example, the UI might offer text, audio, and 3-D moving graphics if appropriate for the user's context.

[0364] Example Inter-Device Bandwidth Characterization Values

[0365] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no inter-device bandwidth/full inter-device bandwidth.

[0366] Using no inter-device bandwidth and full inter-device bandwidth as scale endpoints, the following table lists an example inter-device bandwidth scale.

Scale attribute                 Implication
The computing system does not   Input and output is restricted to
have inter-device connectivity. each of the disconnected devices. The
                                UI is restricted to the capability of each
                                device as a stand-alone device.
Some devices have connectivity  It depends
and others do not.
The computing system has        The task that the user wants to
slow inter-device bandwidth.    complete might require more bandwidth
                                that is available among devices. In this
                                case, the UI can offer the user a choice.
                                Does the user want to continue and
                                encounter slow performance? Or, does
                                the user want to acquire more
                                bandwidth by moving to a different
                                location and taking advantage of
                                opportunistic use of bandwidth?
The computing system has fast   There are few, if any, restrictions
inter-device bandwidth.         on the interaction and presentation
                                between the user and the computing
                                system. The UI sends a warning
                                message only if there is not enough
                                bandwidth between devices.
The computing system has very   There are no restrictions on the
high-speed inter-device         UI based on inter-device connectivity.
connectivity.

[0367] Context Availability

[0368] Context availability is related to whether the information about the model of the user context is accessible. If the information about the model of the context is intermittent, deemed inaccurate, and so on, then the computing system might not have access to the user's context.

[0369] Example Context Availability Characterization Values

[0370] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: context not available/context available.

[0371] Using context not available and context available as scale endpoints, the following list is an example context availability scale.

[0372] No context is available to the computing system

[0373] Some of the user's context is available to the computing system.

[0374] A moderate amount of the user's context is available to the computing system.

[0375] Most of the user's context is available to the computing system.

[0376] All of the user's context is available to the computing system

[0377] Exemplary UI Design for Context Availability

[0378] The following list contains examples of UI design implementations for how the computing system might respond to a change in context availability.

[0379] If the information about the model of context is intermittent, deemed inaccurate, or otherwise unavailable, the UI might:

[0380] Stay the same.

[0381] Ask the user if the UI needs to change.

[0382] Infer a UI from a previous pattern if the user's context history is available.

[0383] Change the UI based on all other attributes except for user context (e.g. I/O device availability, privacy, task characteristics, etc.)

[0384] Use a default UI.

[0385] Opportunistic Use of Resources

[0386] Some UI components, or other enabling UI content, may allow acquisition from outside sources. For example, if a person is using a wearable computer and they sit at a desk that has a monitor on it, the wearable computer might be able to use the desktop monitor as an output device.

[0387] Example Opportunistic Use of Resources Characterization Scale

[0388] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: no opportunistic use of resources/use of all opportunistic resources.

[0389] Using these characteristics, the following list is an example of an opportunistic use of resources scale.

[0390] The circumstances do not allow for the opportunistic use of resources in the computing system.

[0391] Of the resources available to the computing system, there is a possibility to make opportunistic use of resources.

[0392] Of the resources available to the computing system, the computing system can make opportunistic use of most of the resources.

[0393] Of the resources available to the computing system, all are accessible and available.

[0394] Content

[0395] Content is defined as information or data that is part of or provided by a task. Content, in contrast to UI elements, does not serve a specific role in the user/computer dialog. It provides informative or entertaining information to the user. It is not a control. For example a radio has controls (knobs, buttons) used to choose and format (tune a station, adjust the volume & tone) of broadcasted audio content.

[0396] Sometimes content has associated metadata, but it is not necessary.

[0397] Example content characterization values

[0398] Quality

[0399] Static/streamlined

[0400] Passive/interactive

[0401] Type

[0402] Output device required

[0403] Output device affinity

[0404] Output device preference

[0405] Rendering software

[0406] Implicit. The computing system can use characteristics that can be inferred from the information itself, such as message characteristics for received messages.

[0407] Source. A type or instance of carrier, media, channel or network path

[0408] Destination. Address used to reach the user (e.g., a user typically has multiple address, phone numbers, etc.)

[0409] Message content. (parseable or described in metadata)

[0410] Data format type.

[0411] Arrival time.

[0412] Size.

[0413] Previous messages. Inference based on examination of log of actions on similar messages.

[0414] Explicit. Many message formats explicitly include message-characterizing information, which can provide additional filtering criteria.

[0415] Title.

[0416] Originator identification. (e.g., email author)

[0417] Origination date & time

[0418] Routing. (e.g., email often shows path through network routers)

[0419] Priority

[0420] Sensitivity. Security levels and permissions

[0421] Encryption type

[0422] File format. Might be indicated by file name extension

[0423] Language. May include preferred or required font or font type

[0424] Other recipients (e.g., email cc field)

[0425] Required software

[0426] Certification. A trusted indication that the offer characteristics are dependable and accurate.

[0427] Recommendations. Outside agencies can offer opinions on what information may be appropriate to a particular type of user or situation.

[0428] Security

[0429] Controlling security is controlling a user's access to resources and data available in a computing system. For example when a user logs on a network, they must supply a valid user name and password to gain access to resource on the network such as, applications, data, and so on.

[0430] In this sense, security is associated with the capability of a user or outside agencies in relation to a user's data or access to data, and does not specify what mechanisms are employed to assure the security.

[0431] Security mechanisms can also be separately and specifically enumerated with characterizing attributes.

[0432] Permission is related to security. Permission is the security authorization presented to outside people or agencies. This characterization could inform UI creation/selection by giving a distinct indication when the user is presented information that they have given permission to others to access.

[0433] Example Security Characterization Values

[0434] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints are: no authorized user access/all user access, no authorized user access/public access, and no public access/public access.

[0435] Using no authorized user access and public access as scale endpoints, the following list is an example security scale.

[0436] No authorized access.

[0437] Single authorized user access.

[0438] Authorized access to more than one person

[0439] Authorized access for more than one group of people

[0440] Public access

[0441] Single authorized user only access. The only person who has authorized access to the computing system is a specific user with valid user credentials.

[0442] Public access. There are no restrictions on who has access to the computing system. Anyone and everyone can access the computing system.

[0443] Exposing Characterization of User's UI Needs

[0444] There are many ways to expose user UI need characterizations to the computing system. This section describes some of the ways in which this can be accomplished.

[0445] Numeric Key

[0446] A context characterization can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[0447] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent the need for a visual display device capable of displaying at least 24 characters of text in an unbroken series. Therefore a UI characterization of decimal 5 would require such a display to optimally display its content.

[0448] XML Tags

[0449] A UI's characterization can be exposed to the system with a string of characters conforming to the XML structure.

[0450] For instance, a context characterization might be represented by the following:

[0451] <Context Characterization>

[0452] <Theme>Work </Theme>

[0453] <Bandwidth>High Speed LAN Network Connection</Bandwidth>

[0454] <Field of View>28°</Field of View>

[0455] <Privacy>None </Privacy>

[0456] </Context Characterization>

[0457] One significant advantage of the mechanism is that it is easily extensible.

[0458] Programming Interface

[0459] A context characterization can be exposed to the computing system by associating the design with a specific program call.

[0460] For instance:

[0461] GetSecureContext can return a handle to the computing system that describes a UI a high security user context.

[0462] Name/Value Pairs

[0463] A user's UI needs can be modeled or represented with multiple attributes that each correspond to a specific element of the context (e.g., safety, privacy, or security), and the value of an attribute represents a specific measure of that element. For example, for an attribute that represents the a user's privacy needs, a value of “5” represents a specific measurement of privacy. Each attribute preferably has the following properties: a name, a value, an uncertainty level, and a timestamp. For example, the name of the privacy attribute may be “User Privacy” and its value at a particular time may be 5. Associated with the current value may be a timestamp of 08/01/2001 13:07 PST that indicates when the value was generated, and an uncertainty level of +/−1 degrees.

[0464] How to Expose Manual Characterization

[0465] The UI Designer or other person manually and explicitly determines the task characteristic values. For example, XML metadata could be attached to a UI design that explicitly characterizes it as “private” and “very secure.”

[0466] Manual and Automatic Characterization

[0467] A UI Designer or other person could manually and explicitly determine a task characteristic and the computing system could automatically derive additional values from the manual characterization. For example, if a UI Designer characterized cognitive load as “high,” then the computing system might infer that the values of task complexity and task length are “high” and “long,” respectively.

[0468] Automatic Characterization

[0469] The following list contains some ways in which the previously described methods of task characterization could be automatically exposed to the computing system.

[0470] The computing system examines the structure of the task and automatically evaluates calculates the task characterization method. For example, an application could evaluate how many steps there are in a wizard to task assistant to determine task complexity. The more steps, the higher the task complexity.

[0471] The computing system could apply patterns of use to establish implicit characterizations. For example, characteristics can be based on historic use. A task could have associated with is a list of selected UI designs. A task could therefore have an arbitrary characteristic, such as “activity” with associated values, such as “driving.” A pattern recognition engine determines a predictive correlation using a mechanism such as neural networks.

[0472] Characterizing a Task's UI Requirements

[0473] For a system to accurately determine an optimal UI design for a user's current computing context, it should be able to determine the task function including the dialog elements, content, task sequence, user requirements, choices in task and the choices about the task. This disclosure describes an explicit extensible method to characterize tasks executed with the assistance of a computing system. Computer UIs are designed to allow the interaction between users and computers for a wide range of system configurations and user situations. In general, any task characterizations can be considered if they are exposed in a way that the system can interpret. Therefore there are three aspects

[0474] What task characteristics are exposed?

[0475] What are the methods to characterize the tasks?

[0476] How are task characteristics exposed to the computing system?

[0477] Task Characterizations

[0478] A task is a user-perceived objective comprising steps. The topics in this section enumerate some of the important characteristics that can be used to describe tasks. In general, characterizations are needed only if they require a change in the UI design.

[0479] The topics in this section include examples of task characterizations, example characterization values, and in some cases, example UI designs or design characteristics.

[0480] Task Length

[0481] Whether a task is short or long depends upon how long it takes a target user to complete the task. That is, a short task takes a lesser amount of time to complete than a long task. For example, a short task might be creating an appointment. A long task might be playing a game of chess.

[0482] Example Task Length Characterization Values

[0483] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: short/not short, long/not long, or short/long.

[0484] Using short/long as scale endpoints, the list is an example task length scale.

[0485] The task is very short and can be completed in 30 seconds or less

[0486] The task is moderately short and can be completed in 31-60 seconds.

[0487] The task is short and can be completed in 61-90 seconds.

[0488] The task is slightly long and can be completed in 91-300 seconds.

[0489] The task is moderately long and can be completed in 301-1,200 seconds.

[0490] The task is long and can be completed in 1,201-3,600 seconds.

[0491] The task is very long and can be completed in 3,601 seconds or more.

[0492] Task Complexity

[0493] Task complexity is measured using the following criteria:

[0494] Number of elements in the task. The greater the number of elements, the more likely the task is complex.

[0495] Element interrelation. If the elements have a high degree of interrelation, then the more likely the task is complex.

[0496] User knowledge of structure. If the structure, or relationships, between the elements in the task is unclear, then the more likely the task is considered to be complex.

[0497] If a task has a large number of highly interrelated elements and the relationship between the elements is not known to the user, then the task is considered to be complex. On the other hand, if there are a few elements in the task and their relationship is easily understood by the user, then the task is considered to be well-structured. Sometimes a well-structured task can also be considered simple.

[0498] Example Task Complexity Characterization Values

[0499] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: simple/not simple, complex/not complex, simple/complex, well-structured/not well-structured, or well-structured/complex.

[0500] Using simple/complex as scale endpoints, the list is an example task complexity scale.

[0501] There is one, very simple task composed of 1-5 interrelated elements whose relationship is well understood.

[0502] There is one simple task composed of 6-10 interrelated elements whose relationship is understood.

[0503] There is more than one very simple task and each task is composed of 1-5 elements whose relationship is well understood.

[0504] There is one moderately simple task composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[0505] There is more than one simple task and each task is composed of 6-10 interrelated whose relationship is understood by the user.

[0506] There is one somewhat simple task composed of 16-20 interrelated elements whose relationship is understood by the user.

[0507] There is more than one moderately simple task and each task is composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[0508] There is one complex task complex task composed of 21-35 interrelated elements whose relationship is 60-79% understood by the user.

[0509] There is more than one somewhat complex task and each task is composed of 16-20 interrelated elements whose relationship is understood by the user.

[0510] There is one moderately complex task composed of 36-50 elements whose relationship is 80-90% understood by the user.

[0511] There is more than one complex task and each task is composed of 21-35 elements whose relationship is 60-79% understood by the user.

[0512] There is one very complex task composed of 51 or more elements whose relationship is 40-60% understood by the user.

[0513] There is more than one complex task and each task is composed of 36-50 elements whose relationship is 40-60% understood by the user.

[0514] There is more than one very complex task and each part is composed of 51 or more elements whose relationship is 20-40% understood by the user.

[0515] Exemplary UI Design Implementation for Task Complexity

[0516] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[0517] For a task that is long and simple (well-structured), the UI might:

[0518] Give prominence to information that could be used to complete the task.

[0519] Vary the text-to-speech output to keep the user's interest or attention.

[0520] For a task that is short and simple, the U might:

[0521] Optimize to receive input from the best device. That is, allow only input that is most convenient for the user to use at that particular moment.

[0522] If a visual presentation is used, such as an LCD panel or monitor, prominence may be implemented using visual presentation only.

[0523] For a task that is long and complex, the UI might:

[0524] Increase the orientation to information and devices

[0525] Increase affordance to pause in the middle of a task. That is, make it easy for a user to stop in the middle of the task and then return to the task.

[0526] For a task that is short and complex, the UI might:

[0527] Default to expert mode.

[0528] Suppress elements not involved in choices directly related to the current task.

[0529] Change modality

[0530] Task Familiarity

[0531] Task familiarity is related to how well acquainted a user is with a particular task. If a user has never completed a specific task, they might benefit from more instruction from the computing environment than a user who completes the same task daily. For example, the first time a car rental associate rents a car to a consumer, the task is very unfamiliar. However, after about a month, the car rental associate is very familiar with renting cars to consumers.

[0532] Example Task Familiarity Characterization Values

[0533] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: familiar/not familiar, not unfamiliar/unfamiliar, and unfamiliar/familiar.

[0534] Using unfamiliar and familiar as scale endpoints, the list is an example task familiarity scale.

[0535] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 1.

[0536] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 2.

[0537] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 3.

[0538] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 4.

[0539] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 5.

[0540] Exemplary UI Design Implementation for Task Familiarity

[0541] The following list contains examples of UI design implementations for how the computing system might respond to a change in task familiarity.

[0542] For a task that is unfamiliar, the UI might:

[0543] Increase task orientation to provide a high level schema for the task.

[0544] Offer detailed help.

[0545] Present the task in a greater number of steps.

[0546] Offer more detailed prompts.

[0547] Provide information in as many modalities as possible.

[0548] For a task that is familiar, the UI might:

[0549] Decrease the affordances for help

[0550] Offer summary help

[0551] Offer terse prompts

[0552] Decrease the amount of detail given to the user

[0553] Use auto-prompt and auto-complete (that is, make suggestions based on past choices made by the user).

[0554] The ability to barge ahead is available.

[0555] Use user-preferred modalities.

[0556] Task Sequence

[0557] A task can have steps that must be performed in a specific order. For example, if a user wants to place a phone call, the user must dial or send a phone number before they are connected to and can talk with another person. On the other hand, a task, such as searching the Internet for a specific topic, can have steps that do not have to be performed in a specific order.

[0558] Example Task Sequence Characterization Values

[0559] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: scripted/not scripted, nondeterministic/not nondeterministic, or scripted/nondeterministic.

[0560] Using scripted/nondeterministic as scale endpoints, the following list is an example task sequence scale.

[0561] The each step in the task is completely scripted.

[0562] The general order of the task is scripted. Some of the intermediary steps can be performed out of order.

[0563] The first and last steps of the task are scripted. The remaining steps can be performed in any order.

[0564] The steps in the task do not have to be performed in any order.

[0565] Exemplary UI Design Implementation for Task Sequence

[0566] The following list contains examples of UI design implementations for how the computing system might respond to a change in task sequence.

[0567] For a task that is scripted, the UI might:

[0568] Present only valid choices.

[0569] Present more information about a choice so a user can understand the choice thoroughly.

[0570] Decrease the prominence or affordance of navigational controls.

[0571] For a task that is nondeterministic, the UI might:

[0572] Present a wider range of choices to the user.

[0573] Present information about the choices only upon request by the user.

[0574] Increase the prominence or affordance of navigational controls

[0575] Task Independence

[0576] The UI can coach a user though a task or the user can complete the task without any assistance from the UI. For example, if a user is performing a safety check of an aircraft, the UI can coach the user about what questions to ask, what items to inspect, and so on. On the other hand, if the user is creating an appointment or driving home, they might not need input from the computing system about how to successfully achieve their objective.

[0577] Example Task Independence Characterization Values

[0578] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: coached/not coached, not independently executed/independently executed, or coached/independently executed.

[0579] Using coached/independently executed as scale endpoints, the following list is an example task guidance scale.

[0580] The each step in the task is completely scripted.

[0581] The general order of the task is scripted. Some of the intermediary steps can be performed out of order. For example, the first and last steps of the task are scripted and the remaining steps can be performed in any order.

[0582] The steps in the task do not have to be performed in any order.

[0583] Task Creativity

[0584] A formulaic task is a task in which the computing system can precisely instruct the user about how to perform the task. A creative task is a task in which the computing system can provide general instructions to the user, but the user uses their knowledge, experience, and/or creativity to complete the task. For example, the computing system can instruct the user about how to write a sonnet. However, the user must ultimately decide if the combination of words is meaningful or poetic.

[0585] Example Task Creativity Characterization Values

[0586] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints could be defined as formulaic/not formulaic, creative/not creative, or formulaic/creative.

[0587] Using formulaic and creative as scale endpoints, the following list is an example task creativity scale.

[0588] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 1.

[0589] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 2.

[0590] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 3.

[0591] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 4.

[0592] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 5.

[0593] Software Requirements

[0594] Tasks can be intimately related to software requirements. For example, a user cannot create a complicated database without software.

[0595] Example Software Requirements Characterization Values

[0596] This task characterization is enumerated. Example values include:

[0597] JPEG viewer

[0598] PDF reader

[0599] Microsoft Word

[0600] Microsoft Access

[0601] Microsoft Office

[0602] Lotus Notes

[0603] Windows NT 4.0

[0604] Mac OS 10

[0605] Task Privacy

[0606] Task privacy is related to the quality or state of being apart from company or observation. Some tasks have a higher level of desired privacy than others. For example, calling a physician to receive medical test results has a higher level of privacy than making an appointment for a meeting with a co-worker.

[0607] Example Task Privacy Characterization Values

[0608] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: private/not private, public/not public, or private/public.

[0609] Using private/public as scale endpoints, the following table is an example task privacy scale.

[0610] The task is not public. Anyone can have knowledge of the task.

[0611] The task is semi-private. The user and at least one other person have knowledge of the task.

[0612] The task is fully private. Only the user can have knowledge of the task.

[0613] Hardware Requirements

[0614] A task can have different hardware requirements. For example, talking on the phone requires audio input and output while entering information into a database has an affinity for a visual display surface and a keyboard.

[0615] Example Hardware Requirements Characterization Values

[0616] 10 MB available of storage

[0617] 1 hour of power supply

[0618] A free USB connection

[0619] Task Collaboration

[0620] A task can be associated with a single user or more than one user. Most current computer-assisted tasks are designed as single-user tasks. Examples of collaborative computer-assisted tasks include participating in a multi-player video game or making a phone call.

[0621] Example Task Collaboration Characterization Values

[0622] This task characterization is binary. Example binary values are single user/co laboration.

[0623] Task Relation

[0624] A task can be associated with other tasks, people, applications, and so on. Or a task can stand alone on it's own.

[0625] Example Task Relation Characterization Values

[0626] This task characterization is binary. Example binary values are unrelated task/related task.

[0627] Task Completion

[0628] There are some tasks that must be completed once they are started and others that do not have to be completed. For example, if a user is scuba diving and is using a computing system while completing the task of decompressing, it is essential that the task complete once it is started. To ensure the physical safety of the user, the software must maintain continuous monitoring of the user's elapsed time, water pressure, and air supply pressure/quantity. The computing system instructs the user about when and how to safely decompress. If this task is stopped for any reason, the physical safety of the user could be compromised.

[0629] Example Task Completion Characterization Values

[0630] Example values are:

[0631] Must be completed

[0632] Does not have to be completed

[0633] Can be paused

[0634] Not known

[0635] Task Priority

[0636] Task priority is concerned with order. The order may refer to the order in which the steps in the task must be completed or order may refer to the order in which a series of tasks must be performed. This task characteristic is scalar. Tasks can be characterized with a priority scheme, such as (beginning at low priority) entertainment, convenience, economic/personal commitment, personal safety, personal safety and the safety of others. Task priority can be defined as giving one task preferential treatment over another. Task priority is relative to the user. For example, “all calls from mom” may be a high priority for one user, but not another user.

[0637] Example Task Privacy Characterization Values

[0638] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are no priority/high priority.

[0639] Using no priority and high priority as scale endpoints, the following list is an example task priority scale.

[0640] The current task is not a priority. This task can be completed at any time.

[0641] The current task is a low priority. This task can wait to be completed until the highest priority, high priority, and moderately high priority tasks are completed.

[0642] The current task is moderately high priority. This task can wait to be completed until the highest priority and high priority tasks are addressed.

[0643] The current task is high priority. This task must be completed immediately after the highest priority task is addressed.

[0644] The current task is of the highest priority to the user. This task must be completed first.

[0645] Task Importance

[0646] Task importance is the relative worth of a task to the user, other tasks, applications, and so on. Task importance is intrinsically associated with consequences. For example, a task has higher importance if very good or very bad consequences arise if the task is not addressed. If few consequences are associated with the task, then the task is of lower importance.

[0647] Example Task Importance Characterization Values

[0648] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not important/very important.

[0649] Using not important and very important as scale endpoints, the following list is an example task importance scale.

[0650] The task in not important to the user. This task has an importance rating of “1.”

[0651] The task is of slight importance to the user. This task has an importance rating of “2.”

[0652] The task is of moderate importance to the user. This task has an importance rating of “3.”

[0653] The task is of high importance to the user. This task has an importance rating of “4.”

[0654] The task is of the highest importance to the user. This task has an importance rating of “5.”

[0655] Task Urgency

[0656] Task urgency is related to how immediately a task should be addressed or completed. In other words, the task is time dependent. The sooner the task should be completed, the more urgent it is.

[0657] Example Task Urgency Characterization Values

[0658] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not urgent/very urgency.

[0659] Using not urgent and very urgent as scale endpoints, the following list is an example task urgency scale.

[0660] A task is not urgent. The urgency rating for this task is “1.”

[0661] A task is slightly urgent. The urgency rating for this task is “2.”

[0662] A task is moderately urgent. The urgency rating for this task is “3.”

[0663] A task is urgent. The urgency rating for this task is “4.”

[0664] A task is of the highest urgency and requires the user's immediate attention. The urgency rating for this task is “5.”

[0665] Exemplary UI Design Implementation for Task Urgency

[0666] The following list contains examples of UI design implementations for how the computing system might respond to a change in task urgency.

[0667] If the task is not very urgent (e.g. a task urgency rating of 1, using the scale from the previous list), the UI might not indicate task urgency.

[0668] If the task is slightly urgent (e.g. a task urgency rating of 2, using the scale from the previous list), and if the user is using a head mounted display (HMD), the UI might blink a small light in the peripheral vision of the user.

[0669] If the task is moderately urgent (e.g. a task urgency rating of 3, using the scale from the previous list), and if the user is using an HMD, the UI might make the light that is blinking in the peripheral vision of the user blink at a faster rate.

[0670] If the task is urgent, (e.g. a task urgency rating of 4, using the scale from the previous list), and if the user is wearing an HMD, two small lights might blink at a very fast rate in the peripheral vision of the user.

[0671] If the task is very urgent, (e.g. a task urgency rating of 5, using the scale from the previous list), and if the user is wearing an HMD, three small lights might blink at a very fast rate in the peripheral vision of the user. In addition, a notification is sent to the user's direct line of sight that warns the user about the urgency of the task. An audio notification is also presented to the user.

[0672] Task Concurrency

[0673] Mutually exclusive tasks are tasks that cannot be completed at the same time while concurrent tasks can be completed at the same time. For example, a user cannot interactively create a spreadsheet and a word processing document at the same time. These two tasks are mutually exclusive. However, a user can talk on the phone and create a spreadsheet at the same time.

[0674] Example Task Concurrency Characterization Values

[0675] This task characterization is binary. Example binary values are mutually exclusive and concurrent.

[0676] Task Continuity

[0677] Some tasks can have their continuity or uniformity broken without comprising the integrity of the task, while other cannot be interrupted without compromising the outcome of the task. The degree to which a task is associated with saving or preserving human life is often associated with the degree to which it can be interrupted. For example, if a physician is performing heart surgery, their task of performing heart surgery is less interruptible than the task of making an appointment.

[0678] Example Task Continuity Characterization Values

[0679] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are interruptible/not interruptible or abort/pause.

[0680] Using interruptible/not interruptible as scale endpoints, the following list is an example task continuity scale.

[0681] The task cannot be interrupted.

[0682] The task can be interrupted for 5 seconds at a time or less.

[0683] The task can be interrupted for 6-15 seconds at a time.

[0684] The task can be interrupted for 16-30 seconds at a time.

[0685] The task can be interrupted for 31-60 seconds at a time.

[0686] The task can be interrupted for 61-90 seconds at a time.

[0687] The task can be interrupted for 91-300 seconds at a time.

[0688] The task can be interrupted for 301-1,200 seconds at a time.

[0689] The task can be interrupted 1,201-3,600 seconds at a time.

[0690] The task can be interrupted for 3,601 seconds or more at a time.

[0691] The task can be interrupted for any length of time and for any frequency.

[0692] Cognitive Load

[0693] Cognitive load is the degree to which working memory is engaged in processing information. The more working memory is used, the higher the cognitive load. Cognitive load encompasses the following two facets: cognitive demand and cognitive availability.

[0694] Cognitive demand is the number of elements that a user processes simultaneously. To measure the user's cognitive load, the system can combine the following three metrics: number of elements, element interaction, and structure. Cognitive demand is increased by the number of elements intrinsic to the task. The higher the number of elements, the more likely the task is cognitively demanding. Second, cognitive demand is measured by the level of interrelation between the elements in the task. The higher the interrelation between the elements, the more likely the task is cognitively demanding. Finally, cognitive load is measured by how well revealed the relationship between the elements is. If the structure of the elements is known to the user or if it's easily understood, then the cognitive demand of the task is reduced.

[0695] Cognitive availability is how much attention the user uses during the computer-assisted task. Cognitive availability is composed of the following:

[0696] Expertise. This includes schema and whether or not it is in long term memory

[0697] The ability to extend short term memory.

[0698] Distraction. A non-task cognitive demand.

[0699] How Cognitive Load Relates to Other Attributes

[0700] Cognitive load relates to at least the following attributes:

[0701] Learner expertise (novice/expert). Compared to novices, experts have an extensive schemata of a particular set of elements and have automaticity, the ability to automatically understand a class of elements while devoting little to no cognition to the classification. For example, a novice reader must examine every letter of the word that they're trying to read. On the other hand, an expert reader has built a schema so that elements can be “chunked” into groups and accessed as a group rather than a single element. That is, an expert reader can consume paragraphs of text at a time instead of examining each letter.

[0702] Task familiarity (unfamiliar/familiar). When a novice and an expert come across an unfamiliar task, each will handle it differently. An expert is likely to complete the task either more quickly or successfully because they access schemas that they already have and use those to solve the problem/understand the information. A novice may spend a lot of time developing a new schema to understand the information/solve the problem.

[0703] Task complexity (simple/complex or well-structured/complex). A complex task is a task whose structure is not well-known. There are many elements in the task and the elements are highly interrelated. The opposite of a complex task is well-structured. An expert is well-equipped to deal with complex problems because they have developed habits and structures that can help them decompose and solve the problem.

[0704] Task length (short/long). This relates to how much a user has to retain in working memory.

[0705] Task creativity. (formulaic/creative) How well known is the structure of the interrelation between the elements?

[0706] Example Cognitive Demand Characterization Values

[0707] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are cognitively undemanding/cognitively demanding.

[0708] Exemplary UI Design Implementation for Cognitive Load

[0709] A UI design for cognitive load is influenced by a tasks intrinsic and extrinsic cognitive load. Intrinsic cognitive load is the innate complexity of the task and extrinsic cognitive load is how the information is presented. If the information is presented well (e.g. the schema of the interrelation between the elements is revealed), it reduces the overall cognitive load.

[0710] The following list contains examples of UI design implementations for how the computing system might respond to a change cognitive load.

[0711] Present information to the user by using more than one channel. For example, present choices visually to the user, but use audio for prompts.

[0712] Use a visual presentation to reveal the relationships between the elements. For example if a family tree is revealed, use colors and shapes to represent male and female members of the tree or shapes and colors can be used to represent different family units.

[0713] Reduce the redundancy. For example, if the structure of the elements is revealed visually, do not use audio to explain the same structure to the user.

[0714] Keep complementary or associated information together. For example, if creating a dialog box so a user can print, create a button that has the word “Print” on it instead of a dialog box that has a question “Do you want to print?” with a button with the work “OK” on it.

[0715] Task Alterability

[0716] Some task can be altered after they are completed while others cannot be changed. For example, if a user moves a file to the Recycle Bin, they can later retrieve the file. Thus, the task of moving the file to the Recycle Bin is alterable. However, if the user deletes the file from the Recycle Bin, they cannot retrieve it at a later time. In this situation, the task is irrevocable.

[0717] Example Task Alterability Characterization Values

[0718] This task characterization is binary, with the minimum range being binary. Example binary values or scale endpoints are alterable/not alterable, irrevocable/revocable, or alterable/irrevocable.

[0719] Task Content Type

[0720] This task characteristic describes the type of content to be used with the task. For example, text, audio, video, still pictures, and so on.

[0721] Example Content Type Characteristics Values

[0722] This task characterization is an enumeration. Some example values are:

[0723] asp

[0724] .jpeg

[0725] .avi

[0726] .jpg

[0727] .bmp

[0728] .jsp

[0729] .gif

[0730] .php

[0731] .htm

[0732] .txt

[0733] .html

[0734] .wav

[0735] .doc

[0736] .xls

[0737] .mdb

[0738] .vbs

[0739] .mpg

[0740] Again, this list is meant to be illustrative, not exhaustive.

[0741] Task Type

[0742] A task can be performed in many types of situations. For example, a task that is performed in an augmented reality setting might be presented differently to the user than the same task that is executed in a supplemental setting.

[0743] Example Task Type Characteristics Values

[0744] This task characterization is an enumeration. Example values can include:

[0745] Supplemental

[0746] Augmentative

[0747] Mediated

[0748] Methods of Task Characterization

[0749] There are many ways to expose task characterizations to the system. This section describes some of the ways in which this can be accomplished.

[0750] Numeric Key

[0751] Task characterization can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[0752] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent task hardware requirements. Therefore a task characterization of decimal 5 would indicate that minimal processing power is required to complete the task.

[0753] XML Tags

[0754] Task characterization can be exposed to the system with a string of characters conforming to the XML structure.

[0755] For instance, a simple and important task could be represented as:

[0756] <Task Characterization><Task Complexity=“0” Task Length=“9”></Task Characterization>

[0757] One significant advantage of this mechanism is that it is easily extensible.

[0758] Programming Interface

[0759] A task characterization can be exposed to the system by associating a task characteristic with a specific program call.

[0760] For instance:

[0761] GetUrgentTask can return a handle to that communicates that task urgency to the UI.

[0762] Name/Value Pairs

[0763] A task is modeled or represented with multiple attributes that each correspond to a specific element of the task (e.g., complexity, cognitive load or task length), and the value of an attribute represents a specific measure of that element. For example, for an attribute that represents the task complexity, a value of “5” represents a specific measurement of complexity. Each attribute preferably has the following properties: a name, a value, an uncertainty level, and a timestamp. For example, the name of the complexity attribute may be “task complexity” and its value at a particular time may be 5. Associated with the current value may be a timestamp of 08/01/2001 13:07 PST that indicates when the value was generated, and an uncertainty level of +/−1 degrees.

[0764] How to Expose to the Computing System Manual Characterization

[0765] The UI Designer or other person manually and explicitly determines the task characteristic values. For example, XML metadata could be attached to a UI design that explicitly characterizes it as “private” and “very secure.”

[0766] Manual and Automatic Characterization

[0767] A UI Designer or other person could manually and explicitly determine a task characteristic and the computing system could automatically derive additional values from the manual characterization. For example, if a UI Designer characterized cognitive load as “high,” then the computing system might infer that the values of task complexity and task length are “high” and “long,” respectively.

[0768] Another manual and automatic characterization is to group together tasks can as a series of interconnected subtasks, creating both a micro-level view of intermediary steps as well as a macro-level view of the method for accomplishing an overall user task. This applies to tasks that range from simple single steps to complicated parallel and serial tasks that can also include calculations, logic, and nondeterministic subtask paths through the overall task completion process.

[0769] Macro-level task characterizations can then be assessed at design time, such as task length, number of steps, depth of task flow hierarchy, number of potential options, complexity of logic, amount of user inputs required, and serial vs. parallel vs. nondeterministic subtask paths.

[0770] Micro-level task characterizations can also be determined to include subtask content and expected task performance based on prior historical databases of task performance relative to user, task type, user and computing system context, and relevant task completion requirements.

[0771] Examples of methods include:

[0772] Add together and utilize a weighting algorithm across the number of exit options from the current state of the procedure.

[0773] Calculate depth and size of associated text (more text implying longer time needs and more complexity, and vice versa), graphics, and content types (audio, visual, and other input/output modalities).

[0774] Determine number/type of steps and number/type of follow-on calculations affected.

[0775] Use associated metadata based on historical databases of relevant actual time, complexity, and user context metrics.

[0776] Bound the overall task sequence and associate them as a subroutine, and then all intermediary steps can be individually assessed and added together for cumulative and synergistic characterization of the task. Cumulative characterization will add together specific metrics over all subtasks within the overall task, and synergistic characterization will include user response variables to certain subtask sequences (example: multiple long text descriptions may generally be skimmed by the user to decrease overall time commitment to the task, thereby providing a sliding scale weight relating text length to actual time to read and understand).

[0777] Determine level of input(s) needed by whether the subtask options are predetermined or require independent thought, creation, and input into the system for nondeterministic potential task flow inputs and outcomes.

[0778] Pre-set task feasibility factors at design time to include the needs and relative weighting factors for related software, hardware, I/O device availability, task length, task privacy, and other characteristics for task completion and/or for expediting completion of task. Compare these values to real time/run time values to determine expected effects for different value ranges for task characterizations.

[0779] Automatic Characterization

[0780] The following list contains some ways in which the previously described methods of task characterization could be automatically exposed to the computing system.

[0781] The computing system examines the structure of the task and automatically evaluates calculates the task characterization method. For example, an application could evaluate how many steps there are in a wizard to task assistant to determine task complexity. The more steps, the higher the task complexity.

[0782] The computing system could apply patterns of use to establish implicit characterizations. For example, characteristics can be based on historic use. A task could have associated with is a list of selected UI designs. A task could therefore have an arbitrary characteristics, such as “activity” with associated values, such as “driving.” A pattern recognition engine determines a predictive correlation using a mechanism such as neural networks.

[0783] Characterizing I/O Devices' UI Requirements Characterized I/O Device Attributes

[0784] The described model for optimal UI design characterization includes at least the following categories of attributes when determining the optimal UI design:

[0785] All available attributes. The model is dynamic so it can accommodate for any and all attributes that could affect the optimal UI design for a user's context. For example, this model could accommodate for temperature, weather conditions, time of day, available I/O devices, preferred volume level, desired level of privacy, and so on.

[0786] Significant attributes. Some attributes have a more significant influence on the optimal UI design than others. Significant attributes include, but are not limited to, the following:

[0787] The user can see video.

[0788] The user can hear audio.

[0789] The computing system can hear the user.

[0790] The interaction between the user and the computing system must be private.

[0791] The user's hands are occupied.

[0792] Attributes that correspond to a theme. Specific or programmatic. Individual or group.

[0793] The attributes described in this section are example important attributes for determining an optimal UI. Any of the listed attributes can have additional supplemental characterizations. For clarity, each attribute described in this topic is presented with a scale and some include design examples. It is important to note that any of the attributes mentioned in this document are just examples. There are other attributes that can cause a UI to change that are not listed in this document. However, the dynamic model can account for additional attribute triggers.

[0794] Physical Availability

[0795] Physical availability is the degree to which a person is able to perceive and manipulate a device. For example, an airplane mechanic who is repairing an engine does not have hands available to input indications to the computing systems by using a keyboard.

[0796] I/O Device Selection

[0797] Users may have access to multiple input and output (I/O) devices. Which input or output devices they use depends on their context. The UI should pick the ideal input and output devices so the user can interact effectively and efficiently with the computer or computing device.

[0798] Redundant Controls

[0799] Privacy

[0800] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be an HMD and the preferred input device might be an eye-tracking device.

[0801] Hardware Affinity for Privacy

[0802] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[0803] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[0804] Example Privacy Characterization Values

[0805] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[0806] Using no privacy and fully private as the scale endpoints, the following table lists an example privacy characterization scale.

[0807] No privacy is needed for input or output interaction The UI is not restricted to any particular I/O device for presentation and interaction. For example, the UI could present content to the user through speakers on a large monitor in a busy office.

[0808] The input must be semi-private. The output does not need to be private.

[0809] Coded speech commands, and keyboard methods are appropriate. No restrictions on output presentation.

[0810] The input must be fully private. The output does not need to be private.

[0811] No speech commands. No restriction on output presentation.

[0812] The input must be fully private. The output must be semi-private. No speech commands. No LCD panel.

[0813] The input does not need to be private. The output must be fully private.

[0814] No restrictions on input interaction. The output is restricted to an HMD device and/or an earphone.

[0815] The input does not need to be private. The output must be semi-private.

[0816] No restrictions on input interaction. The output is restricted to HMD device, earphone, and/or an LCD panel.

[0817] The input must be semi-private. The output must be semi-private. Coded speech commands and keyboard methods are appropriate. Output is restricted to an HMD device, earphone or an LCD panel.

[0818] The input and output interaction must be fully private. No speech commands. Keyboard devices might be acceptable. Output is restricted to and HMD device and/or an earphone.

[0819] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[0820] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[0821] Computing Hardware Capability

[0822] For purposes of user interfaces designs, there are four categories of hardware:

[0823] Input/output devices

[0824] Storage (e.g. RAM)

[0825] Processing capabilities

[0826] Power supply

[0827] The hardware discussed in this topic can be the hardware that is always available to the computing system. This type of hardware is usually local to the user. Or the hardware could sometimes be available to the computing system. When a computing system uses resources that are sometimes available to it, this can be called an opportunistic use of resources.

[0828] I/O Devices

[0829] Scales for input and output devices are described later in this document.

[0830] Storage

[0831] Storage capacity refers to how much random access memory (RAM) and/or other storage is available to the computing system at any given moment. This number is not considered to be constant because the computing system might avail itself to the opportunistic use of memory.

[0832] Usually the user does not need to be aware of how much storage is available unless they are engaged in a task that might require more memory than to which they reliably have access. This might happen when the computing system engages in opportunistic use of memory. For example, if an in-motion user is engaged in a task that requires the opportunistic use of memory and that user decides to change location (e.g. they are moving from their vehicle to a utility pole where they must complete other tasks), the UI might warn the user that if they leave the current location, the computing system may not be able to complete the task or the task might not get completed as quickly.

[0833] Example Storage Characterization Values

[0834] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no RAM is available/all RAM is available.

[0835] Using no RAM is available and all RAM is available, the following table lists an example storage characterization scale.

[0836] No RAM is available to the computing system If no RAM is available, there is no UI available.—Or—There is no change to the UI.

[0837] Of the RAM available to the computing system, only the opportunistic use of RAM is available. The UI is restricted to the opportunistic use of RAM.

[0838] Of the RAM that is available to the computing system, only the local RAM is accessible The UI is restricted to using local RAM.

[0839] Of the RAM that is available to the computing system, the RAM local to the computing system and a portion of the opportunistic use of RAM is available.

[0840] Of the RAM that is available to the computing system, the local RAM is available and the user is about to lose opportunistic use of RAM. The UI might warn the user that if they lose opportunistic use of memory, the computing system might not be able to complete the task, or the task might not be completed as quickly.

[0841] Of the total possible RAM available to the computing system, all of it is available. If there is enough memory available to the computing system to fully function at a high level, the UI may not need to inform the user. If the user indicates to the computing system that they want a task completed that requires more memory, the UI might suggest that the user change locations to take advantage of additional opportunistic use of memory.

[0842] Processing Capabilities

[0843] Processing capabilities fall into two general categories:

[0844] Speed. The processing speed of a computing system is measured in megahertz (MHz). Processing speed can be reflected as the rate of logic calculation and the rate of content delivery. The more processing power a computing system has, the faster it can calculate logic and deliver content to the user.

[0845] CPU usage. The degree of CPU usage does not affect the UI explicitly. With current UI design, if the CPU becomes too busy, the UI Typically “freezes” and the user is unable to interact with the computing system. If the CPU usage is too high, the UI will change to accommodate the CPU capabilities. For example, if the processor cannot handle the demands, the UI can simplify to reduce demand on the processor.

[0846] Example Processing Capability Characterization Values

[0847] This UI characterization is scalar, with the minimum range being binary. Example binary or scale endpoints are: no processing capability is available/all processing capability is available.

[0848] Using no processing capability is available and all processing capability as scale endpoints, the following table lists an example processing capability scale.

[0849] No processing power is available to the computing system There is no change to the UI.

[0850] The computing system has access to a slower speed CPU. The UI might be audio or text only.

[0851] The computing system has access to a high speed CPU The UI might choose to use video in the presentation instead of a still picture.

[0852] The computing system has access to and control of all processing power available to the computing system. There are no restrictions on the UI based on processing power.

[0853] Power Supply

[0854] There are two types of power supplies available to computing systems alternating current (AC) and direct current (DC). Specific scale attributes for AC power supplies are represented by the extremes of the exemplary scale. However, if a user is connected to an AC power supply, it may be useful for the UI to warn an in-motion user when they're leaving an AC power supply. The user might need to switch to a DC power supply if they wish to continue interacting with the computing system while in motion. However, the switch from AC to DC power should be an automatic function of the computing system and not a function of the

[0855] On the other hand, many computing devices, such as WPCs, laptops, and PDAs, operate using a battery to enable the user to be mobile. As the battery power wanes, the UI might suggest the elimination of video presentations to extend battery life. Or the UI could display a VU meter that visually demonstrates the available battery power so the user can implement their preferences accordingly.

[0856] Example Power Supply Characterization Values

[0857] This task characterization is binary if the power supply is AC and scalar if the power supply is DC. Example binary values are: no power/full power. Example scale endpoints are: no power/all power.

[0858] Using no power and full power as scale endpoints, the following tables lists an example power supply scale.

[0859] There is no power to the computing system. No changes to the UI are possible

[0860] There is an imminent exhaustion of power to the computing system.

[0861] The UI might suggest that the user power down the computing system before critical data is lost, or system could write most significant/useful data to display that does not require power

[0862] There is an inadequate supply of power to the computing system. If a user is listening to music, the UI might suggest that the user stop entertainment uses of the system to preserve the power supply of the computing system for critical tasks.

[0863] There is a limited, but potentially inadequate supply of power to the computing system. If the battery life is 6 hours and the computing system logic determines that the user will be away from a power source for more than 6 hours, the UI might suggest that the user conserve battery power. Or the UI might automatically operate in a “conserve power mode,” by showing still pictures instead of video or using audio instead of a visual display when appropriate.

[0864] There is a limited but adequate power supply to the computing system.

[0865] The UI might alert the user about how many hours are available in the power supply.

[0866] There is an unlimited supply of power to the computing system. The UI can use any device for presentation and interaction without restriction.

[0867] Exemplary UI Design Implementations

[0868] The following list contains examples of UI design implementations for how the computing system might respond to a change in the power supply capacity.

[0869] If there is minimal power remaining in a battery that is supporting a computing system, the UI might:

[0870] Power down any visual presentation surfaces, such as an LCD.

[0871] Use audio output only.

[0872] If there is minimal power remaining in a battery and the UI is already audio-only, the UI might:

[0873] Decrease the audio output volume.

[0874] Decrease the number of speakers that receive the audio output or use earplugs only.

[0875] Use mono versus stereo output.

[0876] Decrease the number of confirmations to the user.

[0877] If there is, for example, six hours of maximum-use battery life available and the computing system determines that the user not have access to a different power source for 8 hours, the UI might:

[0878] Decrease the luminosity of any visual display by displaying line drawings instead of 3-dimensional illustrations.

[0879] Change the chrominance from color to black and white.

[0880] Refresh the visual display less often.

[0881] Decrease the number of confirmations to the user.

[0882] Use audio output only.

[0883] Decrease the audio output volume.

[0884] Computing Hardware Characteristics

[0885] The following is a list of some of the other hardware characteristics that may be influence what is an optimal UI design.

[0886] Cost

[0887] Waterproof

[0888] Ruggedness

[0889] Mobility

[0890] Again, there are other characteristics that could be added to this list. However, it is not possible to list all computing hardware attributes that might influence what is considered to be an optimal UI design until run time.

[0891] Input/Output Devices

[0892] Different presentation and manipulation technologies typically have different maximum usable information densities.

[0893] Visual

[0894] Visual output refers to the available visual density of the display surface is characterized by the amount of content a presentation surface can present to a user. For example, an LED output device, desktop monitor, dashboard display, hand-held device, and head mounted display all have different amounts of visual density. UI designs that are appropriate for a desktop monitor are very different than those that are appropriate for head-mounted displays. In short, what is considered to be the optimal UI will change based on what visual output device(s) is available.

[0895] In addition to density, visual display surfaces have the following characteristics:

[0896] Color. This characterizes whether or not the presentation surface displays color. Color can be directly related to the ability of the presentation surface, of it could be assigned as a user preference.

[0897] Chrominance. The color information in a video signal. See luminance for an explanation of chrominance and luminance.

[0898] Motion. This characterizes whether or not a presentation surface presents motion to the user.

[0899] Field of view. A presentation surface can display content in the focus of a user's vision, in the user's periphery, or both.

[0900] Depth. A presentation surface can display content in 2 dimensions (e.g. a desktop monitor) or 3 dimensions (a holographic projection).

[0901] Luminance. The amount of brightness, measured in lumens, which is given off by a pixel or area on a screen. It is the black/gray/white information in a video signal. Color information is transmitted as luminance (brightness) and chrominance (color). For example, dark red and bright red would have the same chrominance, but a different luminance. Bright red and bright green could have the same luminance, but would always have a different chrominance.

[0902] Reflectivity. The fraction of the total radiant flux incident upon a surface that is reflected and that varies according to the wavelength distribution of the incident radiation.

[0903] Size. Refers to the actual size of the visual presentation surface.

[0904] Position/location of visual display surface in relation to the user and the task that they're performing.

[0905] Number of focal points. A UI can have more than one focal point and each focal point can display different information.

[0906] Distance of focal points from the user. A focal point can be near the user or it can be far away. The amount distance can help dictate what kind and how much information is presented to the user.

[0907] Location of focal points in relation to the user. A focal point can be to the left of the user's vision, to the right, up, or down.

[0908] With which eye(s) the output is associated. Output can be associated with a specific eye or both eyes.

[0909] Ambient light.

[0910] Others

[0911] Example Visual Density Characterization Values

[0912] This UI characterization is scalar, with the minimum range being binary Example binary values or scale endpoints are: no visual density/full visual density.

[0913] Using no visual density and full visual density as scale endpoints, the following table lists an example visual density scale.

[0914] There is no visual density The UI is restricted to non-visual output such as audio, haptic, and chemical.

[0915] Visual density is very low The UI is restricted to a very simple output, such as single binary output devices (a single LED) or other simple configurations and arrays of light. No text is possible.

[0916] Visual density is low The UI can handle text, but is restricted to simple prompts or the bouncing ball.

[0917] Visual density is medium The UI can display text, simple prompts or the bouncing ball, and very simple graphics.

[0918] Visual density is high The visual display has fewer restrictions. Visually dense items such as windows, icons, menus, and prompts are available as well as streaming video, detailed graphics and so on.

[0919] Visual density is very high

[0920] Visual density is the highest available The UI is not restricted by visual density. A visual display that mirrors reality (e.g. 3-dimensional) is possible and appropriate.

[0921] Example Color Characterization Values

[0922] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no color/full color.

[0923] Using no color and full color as scale endpoints, the following table lists an example color scale.

No color is available.   The UI visual presentation is monochrome.
One color is available.  The UI visual presentation is monochrome plus
one color.
Two colors are available The UI visual presentation is monochrome plus
                         two colors or any combination
                         of the two colors.
Full color is available. The UI is not restricted by color.

[0924] Example Motion Characterization Values

[0925] This UI characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: no motion is available/full motion is available.

[0926] Using no motion is available and full motion is available as scale endpoints, the following table lists an example motion scale.

No motion is available  The UI is restricted by motion. There are no
videos, streaming videos moving text, and so on.
Limited motion is available
Moderate motion is available
Full range of motion is available The UI is not restricted by motion.

[0927] Example Field of View Characterization Values

[0928] This UI characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: peripheral vision only/field of focus and peripheral vision is available.

[0929] Using peripheral vision only and field of focus and peripheral vision is available as scale endpoints, the following tables lists an example field of view scale.

[0930] All visual display is in the peripheral vision of the user The UI is restricted to using the peripheral vision of the user. Lights, colors and other simple visual display are appropriate. Text is not appropriate.

Only the user's field of focus is available.  The UI is restricted to using
the users field of vision only. Text and other complex visual displays are
appropriate.
Both field of focus and the peripheral vision of the user are used.
The UI is not restricted by the user's field of view.

[0931] Exemplary UI Design Implementation for Changes in Field of View

[0932] The following list contains examples of UI design implementations for how the computing system might respond to a change in field of view.

[0933] If the field of view for the visual presentation is more than 28°, then the UI might:

[0934] Display the most important information at the center of the visual presentation surface.

[0935] Devote more of the UI to text

[0936] Use periphicons outside of the field of view.

[0937] If the field of view for the visual presentation is less than 28°, then the UI might:

[0938] Restrict the size of the font allowed in the visual presentation. For example, instead of listing “Monday, Tuesday, and Wednesday,” and so on as choices, the UI might list “M, Tu, W” instead.

[0939] The body or environment stabilized image can scroll.

[0940] Example Depth Characterization Values

[0941] This characterization is binary and the values are: 2 dimensions, 3 dimensions.

[0942] Exemplary UI design implementation for changes in reflectivity

[0943] The following list contains examples of UI design implementations for how the computing system might respond to a change in reflectivity.

[0944] If the output device has high reflectivity—a lot of glare—then the visual presentation will change to a light colored UI.

[0945] Audio

[0946] Audio input and output refers to the UI's ability to present and receive audio signals. While the UI might be able to present or receive any audio signal strength, if the audio signal is outside the human hearing range (approximately 20 Hz to 20,000 Hz) it is converted so that it is within the human hearing range, or it is transformed into a different presentation, such as haptic output, to provide feedback, status, and so on to the user.

[0947] Factors that influence audio input and output include (but this is not an inclusive list):

[0948] Level of ambient noise (this is an environmental characterization)

[0949] Directionality of the audio signal

[0950] Head stabilized output (e.g. earphones)

[0951] Environment stabilized output (e.g. speakers)

[0952] Spatial layout (3-D audio)

[0953] Proximity of the audio signal to the user

[0954] Frequency range of the speaker

[0955] Fidelity of the speaker, e.g. total harmonic distortion

[0956] Left, right, or both ears

[0957] What kind of noise is it?

[0958] Others

[0959] Example Audio Output Characterization Values

[0960] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user cannot hear the computing system/the user can hear the computing system.

[0961] Using the user cannot hear the computing system and the user can hear the computing system as scale endpoints, the following table lists an example audio output characterization scale.

[0962] The user cannot hear the computing system. The UI cannot use audio to give the user choices, feedback, and so on.

[0963] The user can hear audible whispers (approximately 10-30 dBA). The UI might offer the user choices, feedback, and so on by using the earphone only.

[0964] The user can hear normal conversation (approximately 50-60 dBA).

[0965] The UI might offer the user choices, feedback, and so on by using a speaker(s) connected to the computing system.

[0966] The user can hear communications from the computing system without restrictions. The UI is not restricted by audio signal strength needs or concerns.

[0967] Possible ear damage (approximately 85+ dBA) The UI will not output audio for extended periods of time that will damage the user's hearing.

[0968] Example Audio Input Characterization Values

[0969] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the computing system cannot hear the user/the computing system can hear the user.

[0970] Using the computing system cannot hear the user and the computing system can hear the user as scale endpoints, the following table lists an example audio input scale.

[0971] The computing system cannot receive audio input from the user. When the computing system cannot receive audio input from the user, the UI will notify the user that audio input is not available.

[0972] The computing system is able to receive audible whispers from the user (approximate 10-30 dBA).

[0973] The computing system is able to receive normal conversational tones from the user (approximate 50-60 dBA).

[0974] The computing system can receive audio input from the user without restrictions. The UI is not restricted by audio signal strength needs or concerns.

[0975] The computing system can receive only high volume audio input from the user. The computing system will not require the user to give indications using a high volume. If a high volume is required, then the UI will notify the user that the computing system cannot receive audio input from the user.

[0976] Haptics

[0977] Haptics refers to interacting with the computing system using a tactile method. Haptic input includes the computing system's ability to sense the user's body movement, such as finger or head movement. Haptic output can include applying pressure to the user's skin. For haptic output, the more transducers, the more skin covered, the more resolution for presentation of information. That is if the user is covered with transducers, the computing system receives a lot more input from the user. Additionally, the ability for haptically-oriented output presentations is far more flexible.

[0978] Example Haptic Input Characterization Values

[0979] This characteristic is enumerated. Possible values include accuracy, precision, and range of:

[0980] Pressure

[0981] Velocity

[0982] Temperature

[0983] Acceleration

[0984] Torque

[0985] Tension

[0986] Distance

[0987] Electrical resistance

[0988] Texture

[0989] Elasticity

[0990] Wetness

[0991] Additionally, the characteristics listed previously are enhanced by:

[0992] Number of dimensions

[0993] Density and quantity of sensors (e.g. a 2 dimensional array of sensors. The sensors could measure the characteristics previously listed).

[0994] Chemical Output

[0995] Chemical output refers to using chemicals to present feedback, status, and so on to the user. Chemical output can include:

[0996] Things a user can taste

[0997] Things a user can smell

[0998] Characteristics of taste include:

[0999] Bitter

[1000] Sweet

[1001] Salty

[1002] Sour

[1003] Characteristics of smell include:

[1004] Strong/weak

[1005] Pungent/bland

[1006] Pleasant/unpleasant

[1007] Intrinsic, or signaling

[1008] Electrical Input

[1009] Electrical input refers to a user's ability to actively control electrical impulses to send indications to the computing system.

[1010] Brain activity

[1011] Muscle activity

[1012] Characteristics of electrical input can include:

[1013] Strength of impulse

[1014] Bandwidth

[1015] There are different types of bandwidth, for instance:

[1016] Network bandwidth

[1017] Inter-device bandwidth

[1018] Network Bandwidth

[1019] Network bandwidth is the computing system's ability to connect to other computing resources such as servers, computers, printers, and so on. A network can be a local area network (LAN), wide area network (WAN), peer-to-peer, and so on. For example, if the user's preferences are stored at a remote location and the computing system determines that the remote resources will not always be available, the system might cache the user's preferences locally to keep the UI consistent. As the cache may consume some of the available RAM resources, the UI might be restricted to simpler presentations, such as text or audio only.

[1020] If user preferences cannot be cached, then the UI might offer the user choices about what UI design families are available and the user can indicate their design family preference to the computing system.

[1021] Example Network Bandwidth Characterization Values

[1022] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no network access/full network access.

[1023] Using no network access and full network access as scale endpoints, the following table lists an example network bandwidth scale.

[1024] The computing system does not have a connection to network resources.

[1025] The UI is restricted to using local computing resources only. If user preferences are stored remotely, then the UI might not account for user preferences.

[1026] The computing system has an unstable connection to network resources.

[1027] The UI might warn the user that the connection to remote resources might be interrupted. The UI might ask the user if they want to cache appropriate information to accommodate for the unstable connection to network resources.

[1028] The computing system has a slow connection to network resources.

[1029] The UI might simplify, such as offer audio or text only, to accommodate for the slow connection. Or the computing system might cache appropriate data for the UI so the UI can always be optimized without restriction of the slow connection.

[1030] The computing system has a high speed, yet limited (by time) access to network resources. In the present moment, the UI does not have any restrictions based on access to network resources. If the computing system determines that it will lose a network connection, then the UI can warn the user and offer choices, such as, does the user want to cache appropriate information, about what to do.

[1031] The computing system has a very high-speed connection to network resources. There are no restrictions to the UI based on access to network resources. The UI can offer text, audio, video, haptic output, and so on.

[1032] Inter-Device Bandwidth

[1033] Inter-device bandwidth is the ability of the devices that are local to the user to communicate with each other. Inter-device bandwidth can affect the UI in that if there is low inter-device bandwidth, then the computing system cannot compute logic and deliver content as quickly. Therefore, the UI design might be restricted to a simpler interaction and presentation, such as audio or text only. If bandwidth is optimal, then there are no restrictions on the UI based on bandwidth. For example, the UI might offer text, audio, and 3-D moving graphics if appropriate for the user's context.

[1034] Example Inter-Device Bandwidth Characterization Values

[1035] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no inter-device bandwidth/full inter-device bandwidth.

[1036] Using no inter-device bandwidth and full inter-device bandwidth as scale endpoints, the following table lists an example inter-device bandwidth scale.

[1037] The computing system does not have inter-device connectivity. Input and output is restricted to each of the disconnected devices. The UI is restricted to the capability of each device as a stand-alone device.

[1038] Some devices have connectivity and others do not. It depends

[1039] The computing system has slow inter-device bandwidth. The task that the user wants to complete might require more bandwidth that is available among devices. In this case, the UI can offer the user a choice. Does the user want to continue and encounter slow performance? Or, does the user want to acquire more bandwidth by moving to a different location and taking advantage of opportunistic use of bandwidth?

[1040] The computing system has fast inter-device bandwidth. There are few, if any, restrictions on the interaction and presentation between the user and the computing system. The UI sends a warning message only if there is not enough bandwidth between devices.

[1041] The computing system has very high-speed inter-device connectivity.

[1042] There are no restrictions on the UI based on inter-device connectivity.

[1043] Exposing Device Characterization to the Computing System

[1044] There are many ways to expose the context characterization to the computing system, as shown by the following three examples.

[1045] Numeric Key

[1046] A context characterization can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[1047] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent the need for a visual display device capable of displaying at least 24 characters of text in an unbroken series. Therefore a UI characterization of decimal 5 would require such a display to optimally display its content.

[1048] XML Tags

[1049] A UI's characterization can be exposed to the system with a string of characters conforming to the XML structure.

[1050] For instance, a context characterization might be represented by the following:

[1051] <Context Characterization>

[1052] <Theme>Work </Theme>

[1053] <Bandwidth>High Speed LAN Network Connection</Bandwidth>

[1054] <Field of View>28°</Field of View>

[1055] <Privacy>None </Privacy>

[1056] </Context Characterization>

[1057] One significant advantage of the mechanism is that it is easily extensible.

[1058] Programming Interface

[1059] A context characterization can be exposed to the computing system by associating the design with a specific program call.

[1060] For instance:

[1061] GetSecureContext can return a handle to the computing system that describes a UI a high security user context.

[1062] Name/Value Pairs

[1063] A context is modeled or represented with multiple attributes that each correspond to a specific element of the context (e.g., ambient temperature, location or a current user activity), and the value of an attribute represents a specific measure of that element. Thus, for example, for an attribute that represents the temperature of the surrounding air, an 80° Fahrenheit value represents a specific measurement of that temperature. Each attribute preferably has the following properties: a name, a value, an uncertainty level, units, and a timestamp. Thus, for example, the name of the air temperature attribute may be “ambient-temperature,” its units may be degrees Fahrenheit, and its value at a particular time may by 80. Associated with the current value may be a timestamp of 02/27/99 13:07 PST that indicates when the value was generated, and an uncertainty level of +/−1 degrees.

[1064] Determining UI Requirements for an Optimal or Appropriate UI

[1065] Considered singularly, many of the characteristics described below can be beneficially used to inform a computing system when to change. However, with an extensible system, additional characteristics can be considered (or ignored) at anytime, providing precision to the optimization.

[1066] Attributes Analyzed

[1067] At least the following categories of attributes can be used when determining the optimal UI design:

[1068] All available attributes. The model is dynamic so it can accommodate for any and all attributes that could affect the optimal UI design for a user's context. For example, this model could accommodate for temperature, weather conditions, time of day, available I/O devices, preferred volume level, desired level of privacy, and so on.

[1069] Significant attributes. Some attributes have a more significant influence on the optimal UI design than others. Significant attributes include, but are not limited to, the following:

[1070] The user can see video.

[1071] The user can hear audio.

[1072] The computing system can hear the user.

[1073] The interaction between the user and the computing system must be private.

[1074] The user's hands are occupied.

[1075] Attributes that correspond to a theme. Specific or programmatic. Individual or group.

[1076] The attributes discussed below are meant to be illustrative because it is often not possible to know all of the attributes that will affect a UI design until run time. Thus, the described techniques are dynamic to allowing accounting for unknown attributes. For clarity, attributes described below are presented with a scale and some include design examples. It is important to note that any of the attributes mentioned in this document are just examples. There are other attributes that can cause a UI to change that are not listed in this document. However, the dynamic model can account for additional attributes.

[1077] I/O Devices

[1078] Output—Devices that are directly perceivable by the user. For example, a visual output device creates photons that enter the user's eye. Output devices are always local to the user.

[1079] Input—A device that can be directly manipulated by the user. For example, a microphone translates energy created by the user's voice into electrical signals that can control a computer. Input devices are always local to the user.

[1080] The input devices to which the user has access to interact with the computer in ways that convey choices include, but are not limited to:

[1081] Keyboards

[1082] Touch pads

[1083] Mice

[1084] Trackballs

[1085] Microphones

[1086] Rolling/pointing/pressing/bending/turning/twisting/switching/rubbing/zipping cursor controllers—anything that the user's manipulation of can be sensed by the computer, this includes body movement that forms recognizable gestures.

[1087] Buttons, etc.

[1088] Output devices allow the presentation of computer-controlled information and content to the user, and include:

[1089] Speakers

[1090] Monitors

[1091] Pressure actuators, etc.

[1092] Input Device Types

[1093] Some characterizations of input devices are a direct result of the device itself.

[1094] Touch Screen

[1095] A display screen that is sensitive to the touch of a finger or stylus. Touch screens are very resistant to harsh environments where keyboards might eventually fail. They are often used with custom-designed applications so that the on-screen buttons are large enough to be pressed with the finger. Applications are typically very specialized and greatly simplified so they can be used by anyone. However, touch screens are also very popular on PDAs and full-size computers with standard applications, where a stylus is required for precise interaction with screen objects.

[1096] Example Touch Screen Attribute Characteristic Values

[1097] This characteristic is enumerated. Some example values are:

[1098] Screen objects must be at least 1 centimeter square

[1099] The user can see the touch screen directly

[1100] The user can see the touch screen indirectly (e.g. by using a monitor)

[1101] Audio feedback is available

[1102] Spatial input is difficult

[1103] Feedback to the user is presented to the user through a visual presentation surface.

[1104] Pointing Device

[1105] An input device used to move the pointer (cursor) on screen.

[1106] Example Pointing Device Characteristic Values

[1107] This characteristic is enumerated. Some example values are:

[1108] 1-dimension (D) pointing device

[1109] 2-D pointing device

[1110] 3-D pointing device

[1111] Position control device

[1112] Range control device

[1113] Feedback to the user is presented through a visual presentation surface.

[1114] Speech

[1115] The conversion of spoken words into computer text. Speech is first digitized and then matched against a dictionary of coded waveforms. The matches are converted into text as if the words were typed on the keyboard.

[1116] Example Speech Characteristic Values

[1117] This characteristic is enumerated. Example values are:

[1118] Command and control

[1119] Dictation

[1120] Constrained grammar

[1121] Unconstrained grammar

[1122] Keyboard

[1123] A set of input keys. On terminals and personal computers, it includes the standard typewriter keys, several specialized keys and the features outlined below.

[1124] Example Keyboard Characteristic Values

[1125] This characteristic is enumerated. Example values are:

[1126] Numeric

[1127] Alphanumeric

[1128] Optimized for discreet input

[1129] Pen Tablet

[1130] A digitizer tablet that is specialized for handwriting and hand marking. LCD-based tablets emulate the flow of ink as the tip touches the surface and pressure is applied. Non-display tablets display the handwriting on a separate computer screen.

[1131] Example Pen Tablet Characteristic Values

[1132] This characteristic is enumerated. Example values include:

[1133] Direct manipulation device

[1134] Feedback is presented to the user through a visual presentation surface

[1135] Supplemental feedback can be presented to the user using audio output.

[1136] Optimized for special input

[1137] Optimized for data entry

[1138] Eye Tracking

[1139] An eye-tracking device is a device that uses eye movement to send user indications about choices to the computing system. Eye tracking devices are well suited for situations where there is little to no motion from the user (e.g. the user is sitting at a desk) and has much potential for non-command user interfaces.

[1140] Example Eye Tracking Characteristic Values

[1141] This characteristic is enumerated. Example values include:

[1142] 2-D pointing device

[1143] User motion=still

[1144] Privacy=high

[1145] Output Device Types

[1146] Some characterizations of input devices are a direct result of the device itself.

[1147] HMD

[1148] Head Mounted Display) A display system built and worn like goggles that gives the illusion of a floating monitor in front of the user's face. The HMD is an important component of a body-worn computer (wearable computer). Single-eye units are used to display hands-free instructional material, and dual-eye, or stereoscopic, units are used for virtual reality applications.

[1149] Example HMD Characteristic Values

[1150] This characteristic is enumerated. Example values include:

[1151] Field of view>28°

[1152] User's hands=not available

[1153] User's eyes=forward and out

[1154] User's reality=augmented, mediated, or virtual

[1155] Monitors

[1156] A display screen used to present output from a computer, camera, VCR or other video generator. A monitor's clarity is based on video bandwidth, dot pitch, refresh rate, and convergence.

[1157] Example Monitor Characteristic Values

[1158] This characteristic is enumerated. Some example values include:

[1159] Required graphical resolution=high

[1160] User location=stationary

[1161] User attention=high

[1162] Visual density=high

[1163] Animation=yes

[1164] Simultaneous presentation of information=yes (e.g. text and image)

[1165] Spatial content=yes

[1166] I/O Device Use

[1167] This attribute characterizes how or for what an input or output device can be optimized for use. For example, a keyboard is optimized for entering alphanumeric text characters and monitor, head mounted display (HMD), or LCD panel is optimized for displaying those characters and other visual information.

[1168] Example Device Use Characterization Values

[1169] This characterization is enumerated. Example values include:

[1170] Speech recognition

[1171] Alphanumeric character input

[1172] Handwriting recognition

[1173] Visual presentation

[1174] Audio presentation

[1175] Haptic presentation

[1176] Chemical presentation

[1177] Redundant Controls

[1178] The user may have more than one way to perceive or manipulate the computing environment. For instance, they may be able to indicate choices by manipulating a mouse, or speaking.

[1179] By providing UI designs that have more than one I/O modality (also known as “multi-modal”), greater flexibility can be provided to the user. However, there are times when this is not appropriate. For instance, the devices may not be constantly available (user's hands are occupied, the ambient noise increases defeating voice recognition).

[1180] Example Redundant Controls Characterization Values

[1181] As a minimum, a numeric value could be associated with a configuration of devices.

[1182] 1—keyboard and touch screen

[1183] 2—HMD and 2-D pointing device

[1184] Alternately, a standardized list of available, preferred, or historically used devices could be used.

[1185] QWERTY keyboard

[1186] Twiddler

[1187] HMD

[1188] VGA monitor

[1189] SVGA monitor

[1190] LCD display

[1191] LCD panel

[1192] Privacy

[1193] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be an HMD and the preferred input device might be an eye-tracking device.

[1194] Hardware Affinity for Privacy

[1195] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[1196] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[1197] Example Privacy Characterization Values

[1198] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[1199] Using no privacy and fully private as the scale endpoints, the following table lists an example privacy characterization scale.

Scale attribute                  Implication/Example
No privacy is needed for input or The UI is not restricted to any
output interaction               particular I/O device for presentation
                                 and interaction. For example, the UI
                                 could present content to the user
                                 through speakers on a large
                                 monitor in a busy office.
The input must be semi-private.  Coded speech commands, and
The output does not need to be   keyboard methods are appropriate.
private.                         No restrictions on output
                                 presentation.
The input must be fully private. No speech commands. No
The output does not need to be   restriction on output presentation.
private.
The input must be fully private. No speech commands. No LCD
The output must be semi-private, panel.
The input does not need to be    No restrictions on input
private. The output must be fully interaction. The output is restricted to
private.                         an HMD device and/or an earphone.
The input does not need to be    No restrictions on input
private. The output must be semi- interaction. The output is restricted to
private.                         HMD device, earphone, and/or
                                 an LCD panel.
The input must be semi-private.  Coded speech commands and
The output must be semi-private. keyboard methods are appropriate.
                                 Output is restricted to an HMD
                                 device, earphone or an LCD panel.
The input and output interaction No speech commands. Keyboard
must be fully private.           devices might be acceptable.
                                 Output is restricted to and
                                 HMD device and/or an earphone.
* Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.
* Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[1200] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[1201] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[1202] Visual

[1203] Visual output refers to the available visual density of the display surface is characterized by the amount of content a presentation surface can present to a user. For example, an LED output device, desktop monitor, dashboard display, hand-held device, and head mounted display all have different amounts of visual density. UI designs that are appropriate for a desktop monitor are very different than those that are appropriate for head-mounted displays. In short, what is considered to be the optimal UI will change based on what visual output device(s) is available.

[1204] In addition to density, visual display surfaces have the following characteristics:

[1205] Color

[1206] Motion

[1207] Field of view

[1208] Depth

[1209] Reflectivity

[1210] Size. Refers to the actual size of the visual presentation surface.

[1211] Position/location of visual display surface in relation to the user and the task that they're performing.

[1212] Number of focal points. A UI can have more than one focal point and each focal point can display different information.

[1213] Distance of focal points from the user. A focal point can be near the user or it can be far away. The amount distance can help dictate what kind and how much information is presented to the user.

[1214] Location of focal points in relation to the user. A focal point can be to the left of the user's vision, to the right, up, or down.

[1215] With which eye(s) the output is associated. Output can be associated with a specific eye or both eyes.

[1216] Ambient light.

[1217] Others (e.g., cost, flexibility, breakability, mobility, exit pupil, . . . )

[1218] The topics in this section describe in further detail the characteristics of some of these previously listed attributes.

[1219] Example Visual Density Characterization Values

[1220] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no visual density/full visual density.

[1221] Using no visual density and full visual density as scale endpoints, the following table lists an example visual density scale. Note that in some situations density might not be uniform across the presentation surface. For example, it may mimic the eye and have high resolution toward the center where text could be supported, but low resolution at the periphery where graphics are appropriate.

Scale attribute               Implication/Design example
There is no visual density    The UI is restricted to non-visual
                              output such as audio, haptic, and
                              chemical.
Visual density is very low    The UI is restricted to a very
                              simple output, such as single binary
                              output devices (a single LED) or other
                              simple configurations and arrays of light.
                              No text is possible.
Visual density is low         The UI can handle text, but is
                              restricted to simple prompts or the
                              bouncing ball.
Visual density is medium      The UI can display text, simple
                              prompts or the bouncing ball, and very
                              simple graphics.
Visual density is high        The visual display has fewer
                              restrictions. Visually dense items such
                              as windows, icons, menus, and prompts
                              are available as well as streaming video,
                              detailed graphics and so on.
Visual density is the highest The UI is not restricted by visual
available                     density. A visual display that mirrors
                              reality (e.g. 3-dimensional) is possible
                              and appropriate.

[1222] Color

[1223] This characterizes whether or not the presentation surface displays color. Color can be directly related to the ability of the presentation surface, or it could be assigned as a user preference.

[1224] Chrominance. The color information in a video signal.

[1225] Luminance. The amount of brightness, measured in lumens, which is given off by a pixel or area on a screen. It is the black/gray/white information in a video signal. Color information is transmitted as luminance (brightness) and chrominance (color). For example, dark red and bright red would have the same chrominance, but a different luminance. Bright red and bright green could have the same luminance, but would always have a different chrominance.

[1226] Example Color Characterization Values

[1227] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no color/full color.

[1228] Using no color and full color as scale endpoints, the following table lists an example color scale.

Scale attribute          Implication/Design example
No color is available.   The UI visual presentation is
                         monochrome.
One color is available.  The UI visual presentation is
                         monochrome plus one color.
Two colors are available The UI visual presentation is
                         monochrome plus two colors or
                         any combined of the two colors.
Full color is available. The UI is not restricted by
                         color.

[1229] Motion

[1230] This characterizes whether or not a presentation surface has the ability to present motion to the user. Motion can be considered as a stand-alone attribute or as a composite attribute.

[1231] Example Motion Characterization Values

[1232] As a stand-alone attribute, this characterization is binary. Example binary values are: no animation available/animation available.

[1233] As a composite attribute, this characterization is scalar. Example scale endpoints include no motion/motion available, no animation available/animation available, or no video/video. The values between the endpoints depend on the other characterizations that are included in the composite. For example, the attributes color, visual density, and frames per second, etc. change the values between no motion and motion available.

[1234] Field of View

[1235] A presentation surface can display content in the focus of a user's vision, in the user's periphery, or both.

[1236] Example Field of View Characterization Values

[1237] This UI characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: peripheral vision only/field of focus and peripheral vision is available.

[1238] Using peripheral vision only and field of focus and peripheral vision is available as scale endpoints, the following tables lists an example field of view scale.

Scale attribute                  Implication
All visual display is in the     The UI is restricted to using the
peripheral vision of the user    peripheral vision of the user. Lights,
                                 colors and other simple visual display
                                 are appropriate. Text is not appropriate.
Only the user's field of focus is The UI is restricted to using the
available.                       users field of vision only.
Text and other complex visual
                                 displays are appropriate.
Both field of focus and the      The UI is not restricted by the
peripheral vision of the user    user's field of view.
are used.

[1239] Exemplary UI Design Implementation for Changes in Field of View

[1240] The following list contains examples of UI design implementations for how the computing system might respond to a change in field of view.

[1241] If the field of view for the visual presentation is more than 28°, then the UI might:

[1242] Display the most important information at the center of the visual presentation surface.

[1243] Devote more of the UI to text

[1244] Use periphicons outside of the field of view.

[1245] If the field of view for the visual presentation is less than 28°, then the UI might:

[1246] Restrict the size of the font allowed in the visual presentation. For example, instead of listing “Monday, Tuesday, and Wednesday,” and so on as choices, the UI might list “M, Tu, W” instead.

[1247] The body or environment stabilized image can scroll.

[1248] Depth

[1249] A presentation surface can display content in 2 dimensions (e.g., a desktop monitor) or 3 dimensions (a holographic projection).

[1250] Example Depth Characterization Values

[1251] This characterization is binary and the values are: 2 dimensions, 3 dimensions.

[1252] Reflectivity

[1253] The fraction of the total radiant flux incident upon a surface that is reflected and that varies according to the wavelength distribution of the incident radiation.

[1254] Example Reflectivity Characterization Values

[1255] This characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not reflective/highly reflective or no glare/high glare.

[1256] Using not reflective and highly reflective as scale endpoints, the following list is an example of a reflectivity scale.

[1257] Not reflective (no surface reflectivity).

[1258] 10% surface reflectivity

[1259] 20% surface reflectivity

[1260] 30% surface reflectivity

[1261] 40% surface reflectivity

[1262] 50% surface reflectivity

[1263] 60% surface reflectivity

[1264] 70% surface reflectivity

[1265] 80% surface reflectivity

[1266] 90% surface reflectivity

[1267] Highly reflective (100% surface reflectivity)

[1268] Exemplary UI Design Implementation for Changes in Reflectivity

[1269] The following list contains examples of UI design implementations for how the computing system might respond to a change in reflectivity.

[1270] If the output device has high reflectivity—a lot of glare—then the visual presentation will change to a light colored UI.

[1271] Audio

[1272] Audio input and output refers to the UI's ability to present and receive audio signals. While the UI might be able to present or receive any audio signal strength, if the audio signal is outside the human hearing range (approximately 20 Hz to 20,000 Hz) it is converted so that it is within the human hearing range, or it is transformed into a different presentation, such as haptic output, to provide feedback, status, and so on to the user

[1273] Factors that influence audio input and output include (but this is not an inclusive list):

[1274] Level of ambient noise (this is an environmental characterization)

[1275] Directionality of the audio signal

[1276] Head-stabilized output (e.g. earphones)

[1277] Environment-stabilized output (e.g. speakers)

[1278] Spatial layout (3-D audio)

[1279] Proximity of the audio signal to the user

[1280] Frequency range of the speaker

[1281] Fidelity of the speaker, e.g. total harmonic distortion

[1282] Left, right, or both ears

[1283] What kind of noise is it?

[1284] Others (e.g., cost, proximity to other people, . . . )

[1285] Example Audio Output Characterization Values

[1286] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user cannot hear the computing system/the user can hear the computing system.

[1287] Using the user cannot hear the computing system and the user can hear the computing system as scale endpoints, the following table lists an example audio output characterization scale.

Scale attribute               Implication
The user cannot hear the      The UI cannot use audio to give
computing system.             the user choices, feedback, and so on.
The user can hear audible     The UI might offer the user
whispers (approximately 10-30 choices, feedback, and so on by using
dBA).                         the earphone only.
The user can hear normal      The UI might offer the user
conversation (approximately   choices, feedback, and so on by using
50-60 dBA).                   a speaker(s) connected to the
                              computing system.
The user can hear             The UI is not restricted by audio
communications from the       signal strength needs or concerns.
computing system without
restrictions.
Possible ear damage           The UI will not output audio for
(approximately 85+ dBA)       extended periods of time that will
                              damage the user's hearing.

[1288] Example Audio Input Characterization Values

[1289] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the computing system cannot hear the user/the computing system can hear the user.

[1290] Using the computing system cannot hear the user and the computing system can hear the user as scale endpoints, the following table lists an example audio input scale.

Scale attribute              Implication
The computing system cannot  When the computing system
receive audio input from     cannot receive audio input from the
the user.                    user, the UI will notify the user that
                             audio input is not available.
The computing system is able to
receive audible whispers from
the user (approximate 10-30
dBA).
The computing system is able to
receive normal conversational
tones from the user (approximate
50-60 dBA).
The computing system can     The UI is not restricted by audio
receive audio input from the signal strength needs or concerns.
user without restrictions.
The computing system can     The computing system will not
receive only high volume     require the user to give indications
audio input from the user.   using a high volume. If a high volume
                             is required, then the UI will notify
                             the user that the computing system
                             cannot receive audio input from the
                             user.

[1291] Haptics

[1292] Haptics refers to interacting with the computing system using a tactile method. Haptic input includes the computing system's ability to sense the user's body movement, such as finger or head movement. Haptic output can include applying pressure to the user's skin. For haptic output, the more transducers, the more skin covered, the more resolution for presentation of information. That is if the user is covered with transducers, the computing system receives a lot more input from the user. Additionally, the ability for haptically-oriented output presentations is far more flexible.

[1293] Example Haptic Input Characterization Values

[1294] This characteristic is enumerated. Possible values include accuracy, precision, and range of:

[1295] Pressure

[1296] Velocity

[1297] Temperature

[1298] Acceleration

[1299] Torque

[1300] Tension

[1301] Distance

[1302] Electrical resistance

[1303] Texture

[1304] Elasticity

[1305] Wetness

[1306] Additionally, the characteristics listed previously are enhanced by:

[1307] Number of dimensions

[1308] Density and quantity of sensors (e.g., a 2 dimensional array of sensors. The sensors could measure the characteristics previously listed).

[1309] Chemical Output

[1310] Chemical output refers to using chemicals to present feedback, status, and so on to the user. Chemical output can include:

[1311] Things a user can taste

[1312] Things a user can smell

[1313] Example Taste Characteristic Values

[1314] This characteristic is enumerated. Example characteristic values of taste include:

[1315] Bitter

[1316] Sweet

[1317] Salty

[1318] Sour

[1319] Example Smell Characteristic Values

[1320] This characteristic is enumerated. Example characteristic values of smell include:

[1321] Strong/weak

[1322] Pungent/bland

[1323] Pleasant/unpleasant

[1324] Intrinsic, or signaling

[1325] Electrical Input

[1326] Electrical input refers to a user's ability to actively control electrical impulses to send indications to the computing system.

[1327] Brain activity

[1328] Muscle activity

[1329] Example Electrical Input Characterization Values

[1330] This characteristic is enumerated. Example values of electrical input can include:

[1331] Strength of impulse

[1332] Frequency

[1333] User Characterizations

[1334] This section describes the characteristics that are related to the user.

[1335] User Preferences

[1336] User preferences are a set of attributes that reflect the user's likes and dislikes, such as I/O devices preferences, volume of audio output, amount of haptic pressure, and font size and color for visual display surfaces. User preferences can be classified in the following categories:

[1337] Self characterization. Self-characterized user preferences are indications from the user to the computing system about themselves. The self-characterizations can be explicit or implicit. An explicit, self-characterized user preference results in a tangible change in the interaction and presentation of the UI. An example of an explicit, self characterized user preference is “Always use the font size 18” or “The volume is always off.” An implicit, self-characterized user preference results in a change in the interaction and presentation of the UI, but it might be not be immediately tangible to the user. A learning style is an implicit self-characterization. The user's learning style could affect the UI design, but the change is not as tangible as an explicit, self-characterized user preference.

[1338] If a user characterizes themselves to a computing system as a “visually impaired, expert computer user,” the UI might respond by always using 24-point font and monochrome with any visual display surface. Additionally, tasks would be chunked differently, shortcuts would be available immediately, and other accommodations would be made to tailor the UI to the expert user.

[1339] Theme selection. In some situations, it is appropriate for the computing system to change the UI based on a specific theme. For example, a high school student in public school 1420 who is attending a chemistry class could have a UI appropriate for performing chemistry experiments. Likewise, an airplane mechanic could also have a UI appropriate for repairing airplane engines. While both of these UIs would benefit from hands free, eyes out computing, the UI would be specifically and distinctively characterized for that particular system.

[1340] System characterization. When a computing system somehow infers a user's preferences and uses those preferences to design an optimal UI, the user preferences are considered to be system characterizations. These types of user preferences can be analyzed by the computing system over a specified period on time in which the computing system specifically detects patterns of use, learning style, level of expertise, and so on. Or, the user can play a game with the computing system that is specifically designed to detect these same characteristics.

[1341] Pre-configured. Some characterizations can be common and the UI can have a variety of pre-configured settings that the user can easily indicate to the UI. Pre-configured settings can include system settings and other popular user changes to default settings.

[1342] Remotely controlled. From time to time, it may be appropriate for someone or something other than the user to control the UI that is displayed.

[1343] Example User Preference Characterization Values

[1344] This UI characterization scale is enumerated. Some example values include:

[1345] Self characterization

[1346] Theme selection

[1347] System characterization

[1348] Pre-configured

[1349] Remotely controlled

[1350] Theme

[1351] A theme is a related set of measures of specific context elements, such as ambient temperature, current user task, and latitude, which reflect the context of the user. In other words, theme is a name collection of attributes, attribute values, and logic that relates these things. Typically, themes are associated with user goals, activities, or preferences. The context of the user includes:

[1352] The user's mental state, emotional state, and physical or health condition.

[1353] The user's setting, situation or physical environment. This includes factors external to the user that can be observed and/or manipulated by the user, such as the state of the user's computing system.

[1354] The user's logical and data telecommunications environment (or “cyber-environment,” including information such as email addresses, nearby telecommunications access such as cell sites, wireless computer ports, etc.).

[1355] Some examples of different themes include: home, work, school, and so on. Like user preferences, themes can be self characterized, system characterized, inferred, pre-configured, or remotely controlled.

[1356] Example Theme Characterization Values

[1357] This characteristic is enumerated. The following list contains example enumerated values for theme.

[1358] No theme

[1359] The user's theme is inferred.

[1360] The user's theme is pre-configured.

[1361] The user's theme is remotely controlled.

[1362] The user's theme is self characterized.

[1363] The user's theme is system characterized.

[1364] User Characteristics

[1365] User characteristics include:

[1366] Emotional state

[1367] Physical state

[1368] Cognitive state

[1369] Social state

[1370] Example User Characteristics Characterization Values

[1371] This UI characterization scale is enumerated. The following lists contain some of the enumerated values for each of the user characteristic qualities listed above.

* Emotional state.
* Happiness
* Sadness
* Anger
* Frustration
* Confusion
* Physical state
* Body
* Biometrics
* Posture
* Motion
* Physical Availability
* Senses
* Eyes
* Ears
* Tactile
* Hands
* Nose
* Tongue
* Workload demands/effects
* Interaction with computer devices
* Interaction with people
* Physical Health
* Environment
* Time/Space
* Objects
* Persons
* Audience/Privacy Availability
* Scope of Disclosure
* Hardware affinity for privacy
* Privacy indicator for user
* Privacy indicator for public
* Watching indicator
* Being observed indicator
* Ambient Interference
* Visual
* Audio
* Tactile
* Location.
* Place_name
* Latitude
* Longitude
* Altitude
* Room
* Floor
* Building
* Address
* Street
* City
* County
* State
* Country
* Postal_Code
* Physiology.
* Pulse
* Body_temperature
* Blood_pressure
* Respiration
* Activity
* Driving
* Eating
* Running
* Sleeping
* Talking
* Typing
* Walking
*Cognitive state
* Meaning
* Cognition
* Divided User Attention
* Task Switching
* Background Awareness
* Solitude
* Privacy
* Desired Privacy
* Perceived Privacy
* Social Context
* Affect
* Social state
* Whether the user is alone or if others are present
* Whether the user is being observed (e.g., by a camera)
* The user's perceptions of the people around them and the user's
perceptions of the intentions of the people that surround them.
* The user's social role (e.g. they are a prisoner, they are a guard,
they are a nurse, they are a teacher, they are a student, etc.)

[1372] Cognitive Availability

[1373] There are three kinds of user tasks: focus, routine, and awareness and three main categories of user attention: background awareness, task switched attention, and parallel. Each type of task is associated with a different category of attention. Focus tasks require the highest amount of user attention and are typically associated with task-switched attention. Routine tasks require a minimal amount of user attention or a user's divided attention and are typically associated with parallel attention. Awareness tasks appeals to a user's precognitive state or attention and are typically associated with background awareness. When there is an abrupt change in the sound, such as changing from a trickle to a waterfall, the user is notified of the change in activity.

[1374] Background Awareness

[1375] Background awareness is a non-focus output stimulus that allows the user to monitor information without devoting significant attention or cognition.

[1376] Example Background Awareness Characterization Values

[1377] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user has no awareness of the computing system/the user has background awareness of the computing system.

[1378] Using these values as scale endpoints, the following list is an example background awareness scale.

[1379] No background awareness is available. A user's pre-cognitive state is unavailable.

[1380] A user has enough background awareness available to the computing system to receive one type of feedback or status.

[1381] A user has enough background awareness available to the computing system to receive more than one type of feedback, status and so on.

[1382] A user's background awareness is fully available to the computing system. A user has enough background awareness available for the computing system such that they can perceive more than two types of feedback or status from the computing system.

[1383] Exemplary UI Design Implementation for Background Awareness

[1384] The following list contains examples of UI design implementations for how a computing system might respond to a change in background awareness.

[1385] If a user does not have any attention for the computing system, that implies that no input or output are needed.

[1386] If a user has enough background awareness available to receive one type of feedback, the UI might:

[1387] Present a single light in the peripheral vision of a user. For example, this light can represent the amount of battery power available to the computing system. As the battery life weakens, the light gets dimmer. If the battery is recharging, the light gets stronger.

[1388] If a user has enough background awareness available to receive more than one type of feedback, the UI might:

[1389] Present a single light in the peripheral vision of the user that signifies available battery power and the sound of water to represent data connectivity.

[1390] If a user has full background awareness, then the UI might:

[1391] Present a single light in the peripheral vision of the user that signifies available battery power, the sound of water that represents data connectivity, and pressure on the skin to represent the amount of memory available to the computing system.

[1392] Task Switched Attention

[1393] When the user is engaged in more than one focus task, the user's attention can be considered to be task switched.

[1394] Example Task Switched Attention Characterization Values

[1395] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have any attention for a focus task/the user has full attention for a focus task.

[1396] Using these characteristics as the scale endpoints, the following list is an example of a task switched attention scale.

[1397] A user does not have any attention for a focus task.

[1398] A user does not have enough attention to complete a simple focus task. The time between focus tasks is long.

[1399] A user has enough attention to complete a simple focus task. The time between focus tasks is long.

[1400] A user does not have enough attention to complete a simple focus task. The time between focus tasks is moderately long.

[1401] A user has enough attention to complete a simple focus task. The time between tasks is moderately long.

[1402] A user does not have enough attention to complete a simple focus task. The time between focus tasks is short.

[1403] A user has enough attention to complete a simple focus task. The time between focus tasks is short.

[1404] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[1405] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[1406] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is moderately long.

[1407] A user has enough attention to complete a moderately complex focus task. The time between tasks is moderately long.

[1408] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[1409] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[1410] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[1411] A user has enough attention to complete a complex focus task. The time between focus tasks is long.

[1412] A user does not have enough attention to complete a complex focus task. The time between focus tasks is moderately long.

[1413] A user has enough attention to complete a complex focus task. The time between tasks is moderately long.

[1414] A user does not have enough attention to complete a complex focus task. The time between focus tasks is short.

[1415] A user has enough attention to complete a complex focus task. The time between focus tasks is short.

[1416] A user has enough attention to complete a very complex, multi-stage focus task before moving to a different focus task.

[1417] Parallel

[1418] Parallel attention can consist of focus tasks interspersed with routine tasks (focus task+routine task) or a series of routine tasks (routine task+routine task).

[1419] Example Parallel Attention Characterization Values

[1420] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have enough attention for a parallel task/the user has full attention for a parallel task.

[1421] Using these characteristics as scale endpoints, the following list is an example of a parallel attention scale.

[1422] A user has enough available attention for one routine task and that task is not with the computing system.

[1423] A user has enough available attention for one routine task and that task is with the computing system.

[1424] A user has enough attention to perform two routine tasks and at least of the routine tasks is with the computing system.

[1425] A user has enough attention to perform a focus task and a routine task. At least one of the tasks is with the computing system.

[1426] A user has enough attention to perform three or more parallel tasks and at least one of those tasks is in the computing system.

[1427] Physical Availability

[1428] Physical availability is the degree to which a person is able to perceive and manipulate a device. For example, an airplane mechanic who is repairing an engine does not have hands available to input indications to the computing systems by using a keyboard.

[1429] Learning Profile

[1430] A user's learning style is based on their preference for sensory intake of information. That is, most users have a preference for which sense they use to assimilate new information.

[1431] Example Learning Style Characterization Values

[1432] This characterization is enumerated. The following list is an example of learning style characterization values.

[1433] Auditory

[1434] Visual

[1435] Tactile

[1436] Exemplary UI Design Implementation for Learning Style

[1437] The following list contains examples of UI design implementations for how the computing system might respond to a learning style.

[1438] If a user is a auditory learner, the UI might:

[1439] Present content to the user by using audio more frequently.

[1440] Limit the amount of information presented to a user if these is a lot of ambient noise.

[1441] If a user is a visual learner, the UI might:

[1442] Present content to the user in a visual format whenever possible.

[1443] Use different colors to group different concepts or ideas together.

[1444] Use illustrations, graphs, charts, and diagrams to demonstrate content when appropriate.

[1445] If a user is a tactile learner, the UI might:

[1446] Present content to the user by using tactile output.

[1447] Increase the affordance of tactile methods of input (e.g. increase the affordance of keyboards).

[1448] Software Accessibility

[1449] If an application requires a media-specific plug-in, and the user does not have a network connection, then a user might not be able to accomplish a task.

[1450] Example Software Accessibility Characterization Values

[1451] This characterization is enumerated. The following list is an example of software accessibility values.

[1452] The computing system does not have access to software.

[1453] The computing system has access to some of the local software resources.

[1454] The computing system has access to all of the local software resources.

[1455] The computing system has access to all of the local software resources and some of the remote software resources by availing itself to opportunistic user of software resources.

[1456] The computing system has access to all of the local software resources and all remote software resources by availing itself to the opportunistic user of software resources.

[1457] The computing system has access to all software resources that are local and remote.

[1458] Perception of Solitude

[1459] Solitude is a user's desire for, and perception of, freedom from input. To meet a user's desire for solitude, the UI can do things like:

[1460] Cancel unwanted ambient noise

[1461] Block out human made symbols generated by other humans and machines

[1462] Example Solitude Characterization Values

[1463] This characterization is scalar, with the minimum range being binary. Example binary values, or scalar endpoints, are: no solitude/complete solitude.

[1464] Using these characteristics as scale endpoints, the following list is an example of a solitude scale.

[1465] No solitude

[1466] Some solitude

[1467] Complete solitude

[1468] Privacy

[1469] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be a head mounted display (HMD) and the preferred input device might be an eye-tracking device.

[1470] Hardware Affinity for Privacy

[1471] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[1472] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[1473] Example Privacy Characterization Values

[1474] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[1475] Using no privacy and fully private as the scale endpoints, the following list is an example privacy characterization scale.

[1476] No privacy is needed for input or output interaction

[1477] The input must be semi-private. The output does not need to be private.

[1478] The input must be fully private. The output does not need to be private.

[1479] The input must be fully private. The output must be semi-private.

[1480] The input does not need to be private. The output must be fully private.

[1481] The input does not need to be private. The output must be semi-private.

[1482] The input must be semi-private. The output must be semi-private.

[1483] The input and output interaction must be fully private.

[1484] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[1485] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[1486] Exemplary UI Design Implementation for Privacy

[1487] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[1488] If no privacy is needed for input or output interaction:

[1489] The UI is not restricted to any particular I/O device for presentation and interaction. For example, the UI could present content to the user through speakers on a large monitor in a busy office.

[1490] If the input must be semi-private and if the output does not need to be private, the UI might:

[1491] Encourage the user to use coded speech commands or use a keyboard if one is available. There are no restrictions on output presentation.

[1492] If the input must be fully private and if the output does not need to be private, the UI might:

[1493] Not allow speech commands. There are no restrictions on output presentation.

[1494] If the input must be fully private and if the output needs to be semi-private, the UI might:

[1495] Not allow speech commands (allow only keyboard commands). Not allow an LCD panel and use earphones to provide audio response to the user.

[1496] If the output must be semi-private and if the input does not need to be private, the UI might:

[1497] Restrict users to an HMD device and/or an earphone for output. There are no restrictions on input interaction.

[1498] If the output must be semi-private and if the input does not need to be private, the UI might:

[1499] Restrict users to HMD devices, earphones, and/or LCD panels. There are no restrictions on input interaction.

[1500] If the input and output must be semi-private, the UI might:

[1501] Encourage the user to use coded speech commands and keyboard methods for input. Output may be restricted to HMD devices, earphones or LCD panels.

[1502] If the input and output interaction must be completely private, the UI might:

[1503] Not allow speech commands and encourage the user of keyboard methods of input. Output is restricted to HMD devices and/or earphones.

[1504] User Expertise

[1505] As the user becomes more familiar with the computing system or the UI, they may be able to navigate through the UI more quickly. Various levels of user expertise can be accommodated. For example, instead of configuring all the settings to make an appointment, users can recite all the appropriate commands in the correct order to make an appointment. Or users might be able to use shortcuts to advance or move back to specific screens in the UI. Additionally, expert users may not need as many prompts as novice users. The UI should adapt to the expertise level of the user.

[1506] Example User Expertise Characterization Values

[1507] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: new user/not new user, not an expert user/expert user, new user/expert user, and novice/expert.

[1508] Using novice and expert as scale endpoints, the following list is an example user expertise scale.

[1509] The user is new to the computing system and to computing in general.

[1510] The user is new to the computing system and is an intermediate computer user.

[1511] The user is new to the computing system, but is an expert computer user.

[1512] The user is an intermediate user in the computing system.

[1513] The user is an expert user in the computing system.

[1514] Exemplary UI Design Implementation for User Expertise

[1515] The following are characteristics of an exemplary audio UI design for novice and expert computer users.

[1516] The computing system speaks a prompt to the user and waits for a response.

[1517] If the user responds in x seconds or less, then the user is an expert. The computing system gives the user prompts only.

[1518] If the user responds in >x seconds, then the user is a novice and the computing system begins enumerating the choices available.

[1519] This type of UI design works well when more than 1 user accesses the same computing system and the computing system and the users do not know if they are a novice or an expert.

[1520] Language

[1521] User context may include language, as in the language they are currently speaking (e.g. English, German, Japanese, Spanish, etc.).

[1522] Example Language Characterization Values

[1523] This characteristic is enumerated. Example values include:

[1524] American English

[1525] British English

[1526] German

[1527] Spanish

[1528] Japanese

[1529] Chinese

[1530] Vietnamese

[1531] Russian

[1532] French

[1533] Computing System

[1534] This section describes attributes associated with the computing system that may cause a UI to change.

[1535] Computing hardware capability.

[1536] For purposes of user interfaces designs, there are four categories of hardware:

[1537] Input/output devices

[1538] Storage (e.g. RAM)

[1539] Processing capabilities

[1540] Power supply

[1541] The hardware discussed in this topic can be the hardware that is always available to the computing system. This type of hardware is usually local to the user. Or the hardware could sometimes be available to the computing system. When a computing system uses resources that are sometimes available to it, this can be called an opportunistic use of resources.

[1542] Storage

[1543] Storage capacity refers to how much random access memory (RAM) is available to the computing system at any given moment. This number is not considered to be constant because the computing system might avail itself to the opportunistic use of memory.

[1544] Usually the user does not need to be aware of how much storage is available unless they are engaged in a task that might require more memory than to which they reliably have access. This might happen when the computing system engages in opportunistic use of memory. For example, if an in-motion user is engaged in a task that requires the opportunistic use of memory and that user decides to change location (e.g. they are moving from their vehicle to a utility pole where they must complete other tasks), the UI might warn the user that if they leave the current location, the computing system may not be able to complete the task or the task might not get completed as quickly.

[1545] Example Storage Characterization Values

[1546] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no RAM is available/all RAM is available.

[1547] Using no RAM is available and all RAM is available, the following table lists an example storage characterization scale.

Scale attribute               Implication
No RAM is available to the    If no RAM is available, there is
computing system              no UI available.-Or-There is no
                              change to the UI.
Of the RAM available to the   The UI is restricted to the
computing system, only the    opportunistic use of RAM.
opportunistic use of RAM
is available.
Of the RAM that is available  The UI is restricted to using
to the computing system, only RAM.
the local RAM is accessible
Of the RAM that is available  The UI might warn the user that
to the computing system, the  if they lose oppportunistic use
local RAM is available and    of memory, the computing system
the user is about to lose     might not be able to complete
opportunistic use of RAM.     the task, or the task might
                              not be completed as quickly.
Of the total possible RAM     If there is enough memory
available to the computing    available to the computing
system, all of it is          system to fully function at a
available.                    high level, the UI may not need
                              to inform the user. If the user
                              indicates to the computing system
                              that they want a task completed that
                              requires more memory, the UI might
                              suggest that the user change
                              locations to take advantage of
                              additional opportunistic use of
                              memory

[1548] Processing Capabilities

[1549] Processing capabilities fall into two general categories:

[1550] Speed. The processing speed of a computing system is measured in megahertz (MHz). Processing speed can be reflected as the rate of logic calculation and the rate of content delivery. The more processing power a computing system has, the faster it can calculate logic and deliver content to the user.

[1551] CPU usage. The degree of CPU usage does not affect the UI explicitly. With current UI design, if the CPU becomes too busy, the UI Typically “freezes” and the user is unable to interact with the computing system. If the CPU usage is too high, the UI will change to accommodate the CPU capabilities. For example, if the processor cannot handle the demands, the UI can simplify to reduce demand on the processor.

[1552] Example Processing Capability Characterization Values

[1553] This UI characterization is scalar, with the minimum range being binary. Example binary or scale endpoints are: no processing capability is available/all processing capability is available.

[1554] Using no processing capability is available and all processing capability as scale endpoints, the following table lists an example processing capability scale.

Scale attribute               Implication
No processing power is        There is no change to the UI.
available to the computing system
The computing system has      The UI might be audio or text
access to a slower speed CPU. only.
The computing system has      The UI might choose to use
access to a high speed CPU    video in the presentation instead of a
                              still picture.
The computing system has      There are no restrictions on the
access to and control of all  UI based on processing power.
processing power available to
the computing system.

[1555] Power Supply

[1556] There are two types of power supplies available to computing systems: alternating current (AC) and direct current (DC). Specific scale attributes for AC power supplies are represented by the extremes of the exemplary scale. However, if a user is connected to an AC power supply, it may be useful for the UI to warn an in-motion user when they're leaving an AC power supply. The user might need to switch to a DC power supply if they wish to continue interacting with the computing system while in motion. However, the switch from AC to DC power should be an automatic function of the computing system and not a function of the UI.

[1557] On the other hand, many computing devices, such as wearable personal computers (WPCs), laptops, and PDAs, operate using a battery to enable the user to be mobile. As the battery power wanes, the UI might suggest the elimination of video presentations to extend battery life. Or the UI could display a VU meter that visually demonstrates the available battery power so the user can implement their preferences accordingly.

[1558] Example Power Supply Characterization Values

[1559] This task characterization is binary if the power supply is AC and scalar if the power supply is DC. Example binary values are: no power/full power. Example scale endpoints are: no power/all power.

[1560] Using no power and full power as scale endpoints, the following list is an example power supply scale.

[1561] There is no power to the computing system.

[1562] There is an imminent exhaustion of power to the computing system.

[1563] There is an inadequate supply of power to the computing system.

[1564] There is a limited, but potentially inadequate supply of power to the computing system.

[1565] There is a limited but adequate power supply to the computing system.

[1566] There is an unlimited supply of power to the computing system.

[1567] Exemplary UI Design Implementation for Power Supply

[1568] The following list contains examples of UI design implementations for how the computing system might respond to a change in the power supply capacity.

[1569] If there is minimal power remaining in a battery that is supporting a computing system, the UI might:

[1570] Power down any visual presentation surfaces, such as an LCD.

[1571] Use audio output only.

[1572] If there is minimal power remaining in a battery and the UI is already audio-only, the UI might:

[1573] Decrease the audio output volume.

[1574] Decrease the number of speakers that receive the audio output or use earplugs only.

[1575] Use mono versus stereo output.

[1576] Decrease the number of confirmations to the user.

[1577] If there is, for example, six hours of maximum-use battery life available and the computing system determines that the user not have access to a different power source for 8 hours, the UI might:

[1578] Decrease the luminosity of any visual display by displaying line drawings instead of 3-dimensional illustrations.

[1579] Change the chrominance from color to black and white.

[1580] Refresh the visual display less often.

[1581] Decrease the number of confirmations to the user.

[1582] Use audio output only.

[1583] Decrease the audio output volume.

[1584] Computing Hardware Characteristics

[1585] The following is a list of some of the other hardware characteristics that may be influence what is an optimal UI design.

[1586] Cost

[1587] Waterproof

[1588] Ruggedness

[1589] Mobility

[1590] Again, there are other characteristics that could be added to this list. However, it is not possible to list all computing hardware attributes that might influence what is considered to be an optimal UI design until run time.

[1591] Bandwidth

[1592] There are different types of bandwidth, for instance:

[1593] Network bandwidth

[1594] Inter-device bandwidth

[1595] Network Bandwidth

[1596] Network bandwidth is the computing system's ability to connect to other computing resources such as servers, computers, printers, and so on. A network can be a local area network (LAN), wide area network (WAN), peer-to-peer, and so on. For example, if the user's preferences are stored at a remote location and the computing system determines that the remote resources will not always be available, the system might cache the user's preferences locally to keep the UI consistent. As the cache may consume some of the available RAM resources, the UI might be restricted to simpler presentations, such as text or audio only.

[1597] If user preferences cannot be cached, then the UI might offer the user choices about what UI design families are available and the user can indicate their design family preference to the computing system.

[1598] Example Network Bandwidth Characterization Values

[1599] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no network access/full network access.

[1600] Using no network access and full network access as scale endpoints, the following table lists an example network bandwidth scale.

Scale attribute                Implication
The computing system does not  The UI is restricted to using local
have a connection to network   computing resources only. If user
resources.                     preferences are stored remotely, then
                               the UI might not account for user
                               preferences.
The computing system has an    The UI might warn the user that
unstable connection to network the connection to remote resources
resources.                     might be interrupted. The UI might ask
                               the user if they want to cache
                               appropriate information to
                               accommodate for the unstable
                               connection to network resources.
The computing system has a     The UI might simplify, such as
slow connection to network     offer audio or text only, to
resources.                     accommodate for the slow connection.
                               Or the computing system might cache
                               appropriate data for the UI so the UI
                               can always be optimized without
                               restriction of the slow connection.
The computing system has a     In the present moment, the UI
high speed, yet limited (by    does not have any restrictions based on
time) access to network        access to network resources. If the
resources.                     computing system determines that it
                               will lose a network connection, then the
                               UI can warn the user and offer choices,
                               such as does the user want to cache
                               appropriate information, about what to
                               do.
The computing system has a     There are no restrictions to the
very high-speed connection to  UI based on access to network
network resources.             resources. The UI can offer text, audio,
                               video, haptic output, and so on.

[1601] Inter-device Bandwidth

[1602] Inter-device bandwidth is the ability of the devices that are local to the user to communicate with each other. Inter-device bandwidth can affect the UI in that if there is low inter-device bandwidth, then the computing system cannot compute logic and deliver content as quickly. Therefore, the UI design might be restricted to a simpler interaction and presentation, such as audio or text only. If bandwidth is optimal, then there are no restrictions on the UI based on bandwidth. For example, the UI might offer text, audio, and 3-D moving graphics if appropriate for the user's context.

[1603] Example Inter-device Bandwidth Characterization Values

[1604] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no inter-device bandwidth/full inter-device bandwidth.

[1605] Using no inter-device bandwidth and full inter-device bandwidth as scale endpoints, the following table lists an example inter-device bandwidth scale.

Scale attribute                Implication
The computing system           Input and output is restricted to
does not have inter-device     each of the disconnected devices. The
connectivity.                  UI is restricted to the capability
                               of each device as a stand-alone
                               device.
Some devices have connectivity It depends
and others do not.
The computing system has slow  The task that the user wants to
inter-device bandwidth.        complete might require more
                               bandwidth that is available among
                               devices. In this case, the UI can
                               offer the user a choice. Does the
                               user want to continue and encounter
                               slow performance? Or, does
                               the user want to acquire more
                               bandwidth by moving to a different
                               location and taking advantage of
                               opportunistic use of bandwidth?
The computing system has       There are few, if any, restrictions
fast inter-device              on the interaction and presentation
bandwidth.                     between the user and the computing
                               system. The UI sends a warning
                               message only if there is not enough
                               bandwidth between devices.
The computing system has       There are no restrictions on the
very high-speed                UI based on inter-device
inter-device connectivity.     connectivity.

[1606] Context Availability

[1607] Context availability is related to whether the information about the model of the user context is accessible. If the information about the model of the context is intermittent, deemed inaccurate, and so on, then the computing system might not have access to the user's context.

[1608] Example Context Availability Characterization Values

[1609] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: context not available/context available.

[1610] Using context not available and context available as scale endpoints, the following list is an example context availability scale.

[1611] No context is available to the computing system.

[1612] Some of the user's context is available to the computing system.

[1613] A moderate amount of the user's context is available to the computing system.

[1614] Most of the user's context is available to the computing system.

[1615] All of the user's context is available to the computing system.

[1616] Exemplary UI Design for Context Availability

[1617] The following list contains examples of UI design implementations for how the computing system might respond to a change in context availability.

[1618] If the information about the model of context is intermittent, deemed inaccurate, or otherwise unavailable, the UI might:

[1619] Stay the same.

[1620] Ask the user if the UI needs to change.

[1621] Infer a UI from a previous pattern if the user's context history is available.

[1622] Change the UI based on all other attributes except for user context (e.g. I/O device availability, privacy, task characteristics, etc.)

[1623] Use a default UI.

[1624] Opportunistic Use of Resources

[1625] Some UI components, or other enabling UI content, may allow acquisition from outside sources. For example, if a person is using a wearable computer and they sit at a desk that has a monitor on it, the wearable computer might be able to use the desktop monitor as an output device.

[1626] Example Opportunistic Use of Resources Characterization Scale

[1627] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: no opportunistic use of resources/use of all opportunistic resources.

[1628] Using these characteristics, the following list is an example of an opportunistic use of resources scale.

[1629] The circumstances do not allow for the opportunistic use of resources in the computing system.

[1630] Of the resources available to the computing system, there is a possibility to make opportunistic use of resources.

[1631] Of the resources available to the computing system, the computing system can make opportunistic use of most of the resources.

[1632] Of the resources available to the computing system, all are accessible and available.

[1633] Additional information corresponding to this list can be found below in sections related to exemplary scale for storage, exemplary scale for processing capability, and exemplary scale for power supply

[1634] Content

[1635] Content is defined as information or data that is part of or provided by a task. Content, in contrast to UI elements, does not serve a specific role in the user/computer dialog. It provides informative or entertaining information to the user. It is not a control. For example a radio has controls (knobs, buttons) used to choose and format (tune a station, adjust the volume & tone) of broadcasted audio content.

[1636] Sometimes content has associated metadata, but it is not necessary.

[1637] Example content characterization values.

[1638] This characterization is enumerated. Example values include:

[1639] Quality

[1640] Static/streamlined

[1641] Passive/interactive

[1642] Type

[1643] Output device required

[1644] Output device affinity

[1645] Output device preference

[1646] Rendering software

[1647] Implicit. The computing system can use characteristics that can be inferred from the information itself, such as message characteristics for received messages.

[1648] Source. A type or instance of carrier, media, channel or network path.

[1649] Destination. Address used to reach the user (e.g., a user typically has multiple address, phone numbers, etc.).

[1650] Message content. (parseable or described in metadata)

[1651] Data format type.

[1652] Arrival time.

[1653] Size.

[1654] Previous messages. Inference based on examination of log of actions on similar messages.

[1655] Explicit. Many message formats explicitly include message-characterizing information, which can provide additional filtering criteria.

[1656] Title.

[1657] Originator identification. (e.g., email author)

[1658] Origination date & time.

[1659] Routing. (e.g., email often shows path through network routers)

[1660] Priority.

[1661] Sensitivity. Security levels and permissions

[1662] Encryption type.

[1663] File format. Might be indicated by file name extension.

[1664] Language. May include preferred or required font or font type.

[1665] Other recipients (e.g., email cc field).

[1666] Required software.

[1667] Certification. A trusted indication that the offer characteristics are dependable and accurate.

[1668] Recommendations. Outside agencies can offer opinions on what information may be appropriate to a particular type of user or situation.

[1669] Security

[1670] Controlling security is controlling a user's access to resources and data available in a computing system. For example when a user logs on a network, they must supply a valid user name and password to gain access to resource on the network such as, applications, data, and so on.

[1671] In this sense, security is associated with the capability of a user or outside agencies in relation to a user's data or access to data, and does not specify what mechanisms are employed to assure the security.

[1672] Security mechanisms can also be separately and specifically enumerated with characterizing attributes.

[1673] Permission is related to security. Permission is the security authorization presented to outside people or agencies. This characterization could inform UI creation/selection by giving a distinct indication when the user is presented information that they have given permission to others to access.

[1674] Example Security Characterization Values

[1675] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints are: no authorized user access/all user access, no authorized user access/public access, and no public access/public access.

[1676] Using no authorized user access and public access as scale endpoints, the following list is an example security scale.

[1677] No authorized access.

[1678] Single authorized user access.

[1679] Authorized access to more than one person.

[1680] Authorized access for more than one group of people.

[1681] Public access.

[1682] Single authorized user only access. The only person who has authorized access to the computing system is a specific user with valid user credentials.

[1683] Public access. There are no restrictions on who has access to the computing system. Anyone and everyone can access the computing system.

[1684] Task Characterizations

[1685] A task is a user-perceived objective comprising steps. The topics in this section enumerate some of the important characteristics that can be used to describe tasks. In general, characterizations are needed only if they require a change in the UI design.

[1686] The topics in this section include examples of task characterizations, example characterization values, and in some cases, example UI designs or design characteristics.

[1687] Task Length

[1688] Whether a task is short or long depends upon how long it takes a target user to complete the task. That is, a short task takes a lesser amount of time to complete than a long task. For example, a short task might be creating an appointment. A long task might be playing a game of chess.

[1689] Example Task Length Characterization Values

[1690] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: short/not short, long/not long, or short/long.

[1691] Using short/long as scale endpoints, the list is an example task length scale.

[1692] The task is very short and can be completed in 30 seconds or less

[1693] The task is moderately short and can be completed in 31-60 seconds.

[1694] The task is short and can be completed in 61-90 seconds.

[1695] The task is slightly long and can be completed in 91-300 seconds.

[1696] The task is moderately long and can be completed in 301-1,200 seconds.

[1697] The task is long and can be completed in 1,201-3,600 seconds.

[1698] The task is very long and can be completed in 3,601 seconds or more.

[1699] Task Complexity

[1700] Task complexity is measured using the following criteria:

[1701] Number of elements in the task. The greater the number of elements, the more likely the task is complex.

[1702] Element interrelation. If the elements have a high degree of interrelation, then the more likely the task is complex.

[1703] User knowledge of structure. If the structure, or relationships, between the elements in the task is unclear, then the more likely the task is considered to be complex.

[1704] If a task has a large number of highly interrelated elements and the relationship between the elements is not known to the user, then the task is considered to be complex. On the other hand, if there are a few elements in the task and their relationship is easily understood by the user, then the task is considered to be well-structured. Sometimes a well-structured task can also be considered simple.

[1705] Example Task Complexity Characterization Values

[1706] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: simple/not simple, complex/not complex, simple/complex, well-structured/not well-structured, or well-structured/complex.

[1707] Using simple/complex as scale endpoints, the list is an example task complexity scale.

[1708] There is one, very simple task composed of 1-5 interrelated elements whose relationship is well understood.

[1709] There is one simple task composed of 6-10 interrelated elements whose relationship is understood.

[1710] There is more than one very simple task and each task is composed of 1-5 elements whose relationship is well understood.

[1711] There is one moderately simple task composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[1712] There is more than one simple task and each task is composed of 6-10 interrelated whose relationship is understood by the user.

[1713] There is one somewhat simple task composed of 16-20 interrelated elements whose relationship is understood by the user.

[1714] There is more than one moderately simple task and each task is composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[1715] There is one complex task complex task composed of 21-35 interrelated elements whose relationship is 60-79% understood by the user.

[1716] There is more than one somewhat complex task and each task is composed of 16-20 interrelated elements whose relationship is understood by the user.

[1717] There is one moderately complex task composed of 36-50 elements whose relationship is 80-90% understood by the user.

[1718] There is more than one complex task and each task is composed of 21-35 elements whose relationship is 60-79% understood by the user.

[1719] There is one very complex task composed of 51 or more elements whose relationship is 40-60% understood by the user.

[1720] There is more than one complex task and each task is composed of 36-50 elements whose relationship is 40-60% understood by the user.

[1721] There is more than one very complex task and each part is composed of 51 or more elements whose relationship is 20-40% understood by the user.

[1722] Exemplary UI Design Implementation for Task Complexity

[1723] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[1724] For a task that is long and simple (well-structured), the UI might:

[1725] Give prominence to information that could be used to complete the task.

[1726] Vary the text-to-speech output to keep the user's interest or attention.

[1727] For a task that is short and simple, the UI might:

[1728] Optimize to receive input from the best device. That is, allow only input that is most convenient for the user to use at that particular moment.

[1729] If a visual presentation is used, such as an LCD panel or monitor, prominence may be implemented using visual presentation only.

[1730] For a task that is long and complex, the UI might:

[1731] Increase the orientation to information and devices.

[1732] Increase affordance to pause in the middle of a task. That is, make it easy for a user to stop in the middle of the task and then return to the task.

[1733] For a task that is short and complex, the UI might:

[1734] Default to expert mode.

[1735] Suppress elements not involved in choices directly related to the current task.

[1736] Change modality.

[1737] Task Familiarity

[1738] Task familiarity is related to how well acquainted a user is with a particular task. If a user has never completed a specific task, they might benefit from more instruction from the computing environment than a user who completes the same task daily. For example, the first time a car rental associate rents a car to a consumer, the task is very unfamiliar. However, after about a month, the car rental associate is very familiar with renting cars to consumers.

[1739] Example Task Familiarity Characterization Values

[1740] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: familiar/not familiar, not unfamiliar/unfamiliar, and unfamiliar/familiar.

[1741] Using unfamiliar and familiar as scale endpoints, the list is an example task familiarity scale.

[1742] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 1.

[1743] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 2.

[1744] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 3.

[1745] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 4.

[1746] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 5.

[1747] Exemplary UI Design Implementation for Task Familiarity

[1748] The following list contains examples of UI design implementations for how the computing system might respond to a change in task familiarity.

[1749] For a task that is unfamiliar, the UI might:

[1750] Increase task orientation to provide a high level schema for the task.

[1751] Offer detailed help.

[1752] Present the task in a greater number of steps.

[1753] Offer more detailed prompts.

[1754] Provide information in as many modalities as possible.

[1755] For a task that is familiar, the UI might:

[1756] Decrease the affordances for help.

[1757] Offer summary help.

[1758] Offer terse prompts.

[1759] Decrease the amount of detail given to the user.

[1760] Use auto-prompt and auto-complete (that is, make suggestions based on past choices made by the user).

[1761] The ability to barge ahead is available.

[1762] Use user-preferred modalities.

[1763] Task Sequence

[1764] A task can have steps that must be performed in a specific order. For example, if a user wants to place a phone call, the user must dial or send a phone number before they are connected to and can talk with another person. On the other hand, a task, such as searching the Internet for a specific topic, can have steps that do not have to be performed in a specific order.

[1765] Example Task Sequence Characterization Values

[1766] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: scripted/not scripted, nondeterministic/not nondeterministic, or scripted/nondeterministic.

[1767] Using scripted/nondeterministic as scale endpoints, the following list is an example task sequence scale.

[1768] The each step in the task is completely scripted.

[1769] The general order of the task is scripted. Some of the intermediary steps can be performed out of order.

[1770] The first and last steps of the task are scripted. The remaining steps can be performed in any order.

[1771] The steps in the task do not have to be performed in any order.

[1772] Exemplary UI Design Implementation for Task Sequence

[1773] The following list contains examples of UI design implementations for how the computing system might respond to a change in task sequence.

[1774] For a task that is scripted, the UI might:

[1775] Present only valid choices.

[1776] Present more information about a choice so a user can understand the choice thoroughly.

[1777] Decrease the prominence or affordance of navigational controls.

[1778] For a task that is nondeterministic, the UI might:

[1779] Present a wider range of choices to the user.

[1780] Present information about the choices only upon request by the user.

[1781] Increase the prominence or affordance of navigational controls.

[1782] Task Independence

[1783] The UI can coach a user though a task or the user can complete the task without any assistance from the UI. For example, if a user is performing a safety check of an aircraft, the UI can coach the user about what questions to ask, what items to inspect, and so on. On the other hand, if the user is creating an appointment or driving home, they might not need input from the computing system about how to successfully achieve their objective.

[1784] Example Task Independence Characterization Values

[1785] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: coached/not coached, not independently executed/independently executed, or coached/independently executed.

[1786] Using coached/independently executed as scale endpoints, the following list is an example task guidance scale.

[1787] Each step in the task is completely scripted.

[1788] The general order of the task is scripted. Some of the intermediary steps can be performed out of order.

[1789] The first and last steps of the task are scripted. The remaining steps can be performed in any order.

[1790] The steps in the task do not have to be performed in any order.

[1791] Task Creativity

[1792] A formulaic task is a task in which the computing system can precisely instruct the user about how to perform the task. A creative task is a task in which the computing system can provide general instructions to the user, but the user uses their knowledge, experience, and/or creativity to complete the task. For example, the computing system can instruct the user about how to write a sonnet. However, the user must ultimately decide if the combination of words is meaningful or poetic.

[1793] Example Task Creativity Characterization Values

[1794] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints could be defined as formulaic/not formulaic, creative/not creative, or formulaic/creative.

[1795] Using formulaic and creative as scale endpoints, the following list is an example task creativity scale.

[1796] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 1.

[1797] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 2.

[1798] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 3.

[1799] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 4.

[1800] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 5.

[1801] Software Requirements

[1802] Tasks can be intimately related to software requirements. For example, a user cannot create a complicated database without software.

[1803] Example Software Requirements Characterization Values

[1804] This task characterization is enumerated. Example values include.

[1805] JPEG viewer

[1806] PDF reader

[1807] Microsoft Word

[1808] Microsoft Access

[1809] Microsoft Office

[1810] Lotus Notes

[1811] Windows NT 4.0

[1812] Mac OS 10

[1813] Task Privacy

[1814] Task privacy is related to the quality or state of being apart from company or observation. Some tasks have a higher level of desired privacy than others. For example, calling a physician to receive medical test results has a higher level of privacy than making an appointment for a meeting with a co-worker.

[1815] Example Task Privacy Characterization Values

[1816] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: private/not private, public/not public, or private/public.

[1817] Using private/public as scale endpoints, the following table is an example task privacy scale.

[1818] The task is not public. Anyone can have knowledge of the task.

[1819] The task is semi-private. The user and at least one other person have knowledge of the task.

[1820] The task is fully private. Only the user can have knowledge of the task.

[1821] Hardware Requirements

[1822] A task can have different hardware requirements. For example, talking on the phone requires audio input and output while entering information into a database has an affinity for a visual display surface and a keyboard.

[1823] Example Hardware Requirements Characterization Values

[1824] This task characterization is enumerated. Example values include:

[1825] 10 MB available of storage

[1826] 1 hour of power supply

[1827] A free USB connection

[1828] Task Collaboration

[1829] A task can be associated with a single user or more than one user. Most current computer-assisted tasks are designed as single-user tasks. Examples of collaborative computer-assisted tasks include participating in a multi-player video game or making a phone call.

[1830] Example Task Collaboration Characterization Values

[1831] This task characterization is binary. Example binary values are single user/collaboration.

[1832] Task Relation

[1833] A task can be associated with other tasks people, applications, and so on. Or a task can stand alone on it's own.

[1834] Example Task Relation Characterization Values

[1835] This task characterization is binary. Example binary values are unrelated task/related task.

[1836] Task Completion

[1837] There are some tasks that must be completed once they are started and others that do not have to be completed. For example, if a user is scuba diving and is using a computing system while completing the task of decompressing, it is essential that the task complete once it is started. To ensure the physical safety of the user, the software must maintain continuous monitoring of the user's elapsed time, water pressure, and air supply pressure/quantity. The computing system instructs the user about when and how to safely decompress. If this task is stopped for any reason, the physical safety of the user could be compromised.

[1838] Example Task Completion Characterization Values

[1839] This task characterization is enumerated. Example values are:

[1840] Must be completed

[1841] Does not have to be completed

[1842] Can be paused

[1843] Not known

[1844] Task Priority

[1845] Task priority is concerned with order. The order may refer to the order in which the steps in the task must be completed or order may refer to the order in which a series of tasks must be performed. This task characteristic is scalar. Tasks can be characterized with a priority scheme, such as (beginning at low priority) entertainment, convenience, economic/personal commitment, personal safety, personal safety and the safety of others. Task priority can be defined as giving one task preferential treatment over another. Task priority is relative to the user. For example, “all calls from mom” may be a high priority for one user, but not another user.

[1846] Example Task Privacy Characterization Values

[1847] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are no priority/high priority.

[1848] Using no priority and high priority as scale endpoints, the following list is an example task priority scale.

[1849] The current task is not a priority. This task can be completed at any time.

[1850] The current task is a low priority. This task can wait to be completed until the highest priority, high priority, and moderately high priority tasks are completed.

[1851] The current task is moderately high priority. This task can wait to be completed until the highest priority and high priority tasks are addressed.

[1852] The current task is high priority. This task must be completed immediately after the highest priority task is addressed.

[1853] The current task is of the highest priority to the user. This task must be completed first.

[1854] Task Importance

[1855] Task importance is the relative worth of a task to the user, other tasks, applications, and so on. Task importance is intrinsically associated with consequences. For example, a task has higher importance if very good or very bad consequences arise if the task is not addressed. If few consequences are associated with the task, then the task is of lower importance.

[1856] Example Task Importance Characterization Values

[1857] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not important/very important.

[1858] Using not important and very important as scale endpoints, the following list is an example task importance scale.

[1859] The task in not important to the user. This task has an importance rating of “1.”

[1860] The task is of slight importance to the user. This task has an importance rating of “2.”

[1861] The task is of moderate importance to the user. This task has an importance rating of “3.”

[1862] The task is of high importance to the user. This task has an importance rating of “4.”

[1863] The task is of the highest importance to the user. This task has an importance rating of “5.”

[1864] Task Urgency

[1865] Task urgency is related to how immediately a task should be addressed or completed. In other words, the task is time dependent. The sooner the task should be completed, the more urgent it is.

[1866] Example Task Urgency Characterization Values

[1867] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not urgent/very urgency.

[1868] Using not urgent and very urgent as scale endpoints, the following list is an example task urgency scale.

[1869] A task is not urgent. The urgency rating for this task is “1.”

[1870] A task is slightly urgent. The urgency rating for this task is “2.”

[1871] A task is moderately urgent. The urgency rating for this task is “3.”

[1872] A task is urgent. The urgency rating for this task is “4.”

[1873] A task is of the highest urgency and requires the user's immediate attention. The urgency rating for this task is “5.”

[1874] Exemplary UI Design Implementation for Task Urgency

[1875] The following list contains examples of UI design implementations for how the computing system might respond to a change in task urgency.

[1876] If the task is not very urgent (e.g. a task urgency rating of 1, using the scale from the previous list), the UI might not indicate task urgency.

[1877] If the task is slightly urgent (e.g. a task urgency rating of 2, using the scale from the previous list), and if the user is using a head mounted display (HMD), the UI might blink a small light in the peripheral vision of the user.

[1878] If the task is moderately urgent (e.g. a task urgency rating of 3, using the scale from the previous list), and if the user is using an HMD, the UI might make the light that is blinking in the peripheral vision of the user blink at a faster rate.

[1879] If the task is urgent, (e.g. a task urgency rating of 4, using the scale from the previous list), and if the user is wearing an HMD, two small lights might blink at a very fast rate in the peripheral vision of the user.

[1880] If the task is very urgent, (e.g. a task urgency rating of 5, using the scale from the previous list), and if the user is wearing an HMD, three small lights might blink at a very fast rate in the peripheral vision of the user. In addition, a notification is sent to the user's direct line of sight that warns the user about the urgency of the task. An audio notification is also presented to the user.

[1881] Task Concurrency

[1882] Mutually exclusive tasks are tasks that cannot be completed at the same time while concurrent tasks can be completed at the same time. For example, a user cannot interactively create a spreadsheet and a word processing document at the same time. These two tasks are mutually exclusive. However, a user can talk on the phone and create a spreadsheet at the same time.

[1883] Example Task Concurrency Characterization Values

[1884] This task characterization is binary. Example binary values are mutually exclusive and concurrent.

[1885] Task Continuity

[1886] Some tasks can have their continuity or uniformity broken without comprising the integrity of the task, while other cannot be interrupted without compromising the outcome of the task. The degree to which a task is associated with saving or preserving human life is often associated with the degree to which it can be interrupted. For example, if a physician is performing heart surgery, their task of performing heart surgery is less interruptible than the task of making an appointment.

[1887] Example Task Continuity Characterization Values

[1888] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are interruptible/not interruptible or abort/pause.

[1889] Using interruptible/not interruptible as scale endpoints, the following list is an example task continuity scale.

[1890] The task cannot be interrupted.

[1891] The task can be interrupted for 5 seconds at a time or less.

[1892] The task can be interrupted for 6-15 seconds at a time.

[1893] The task can be interrupted for 16-30 seconds at a time.

[1894] The task can be interrupted for 31-60 seconds at a time.

[1895] The task can be interrupted for 61-90 seconds at a time.

[1896] The task can be interrupted for 91-300 seconds at a time.

[1897] The task can be interrupted for 301-1,200 seconds at a time.

[1898] The task can be interrupted 1,201-3,600 seconds at a time.

[1899] The task can be interrupted for 3,601 seconds or more at a time.

[1900] The task can be interrupted for any length of time and for any frequency.

[1901] Cognitive Load

[1902] Cognitive load is the degree to which working memory is engaged in processing information. The more working memory is used, the higher the cognitive load. Cognitive load encompasses the following two facets: cognitive demand and cognitive availability.

[1903] Cognitive demand is the number of elements that a user processes simultaneously. To measure the user's cognitive load, the system can combine the following three metrics: number of elements, element interaction, and structure. Cognitive demand is increased by the number of elements intrinsic to the task. The higher the number of elements, the more likely the task is cognitively demanding. Second, cognitive demand is measured by the level of interrelation between the elements in the task. The higher the inter-relation between the elements, the more likely the task is cognitively demanding. Finally, cognitive load is measured by how well revealed the relationship between the elements is. If the structure of the elements is known to the user or if it's easily understood, then the cognitive demand of the task is reduced.

[1904] Cognitive availability is how much attention the user engages in during the computer-assisted task. Cognitive availability is composed of the following:

[1905] Expertise. This includes schema and whether or not it is in long term memory.

[1906] The ability to extend short term memory.

[1907] Distraction. A non-task cognitive demand.

[1908] How Cognitive Load Relates to Other Attributes

[1909] Cognitive load relates to at least the following attributes:

[1910] Learner expertise (novice/expert). Compared to novices, experts have an extensive schemata of a particular set of elements and have automaticity, the ability to automatically understand a class of elements while devoting little to no cognition to the classification. For example, a novice reader must examine every letter of the word that they're trying to read. On the other hand, an expert reader has built a schema so that elements can be “chunked” into groups and accessed as a group rather than a single element. That is, an expert reader can consume paragraphs of text at a time instead of examining each letter.

[1911] Task familiarity (unfamiliar/familiar). When a novice and an expert come across an unfamiliar task, each will handle it differently. An expert is likely to complete the task either more quickly or successfully because they access schemas that they already have and use those to solve the problem/understand the information. A novice may spend a lot of time developing a new schema to understand the information/solve the problem.

[1912] Task complexity (simple/complex or well-structured/complex). A complex task is a task whose structure is not well-known. There are many elements in the task and the elements are highly interrelated. The opposite of a complex task is well-structured. An expert is well-equipped to deal with complex problems because they have developed habits and structures that can help them decompose and solve the problem.

[1913] Task length (short/long). This relates to much a user has to retain in working memory.

[1914] Task creativity. (formulaic/creative) How well known is the structure of the interrelation between the elements?

[1915] Example Cognitive Demand Characterization Values

[1916] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are cognitively undemanding/cognitively demanding.

[1917] Exemplary UI Design Implementation for Cognitive Load

[1918] A UI design for cognitive load is influenced by a tasks intrinsic and extrinsic cognitive load. Intrinsic cognitive load is the innate complexity of the task and extrinsic cognitive load is how the information is presented. If the information is presented well (e.g. the schema of the interrelation between the elements is revealed), it reduces the overall cognitive load.

[1919] The following list contains examples of UI design implementations for how the computing system might respond to a change cognitive load.

[1920] Present information to the user by using more than one channel. For example, present choices visually to the user, but use audio for prompts.

[1921] Use a visual presentation to reveal the relationships between the elements. For example if a family tree is revealed, use colors and shapes to represent male and female members of the tree or shapes and colors can be used to represent different family units.

[1922] Reduce the redundancy. For example, if the structure of the elements is revealed visually, do not use audio to explain the same structure to the user.

[1923] Keep complementary or associated information together. For example, if creating a dialog box so a user can print, create a button that has the word “Print” on it instead of a dialog box that has a question “Do you want to print?” with a button with the work “OK” on it.

[1924] Task Alterability

[1925] Some task can be altered after they are completed while others cannot be changed. For example, if a user moves a file to the Recycle Bin, they can later retrieve the file. Thus, the task of moving the file to the Recycle Bin is alterable. However, if the user deletes the file from the Recycle Bin, they cannot retrieve it at a later time. In this situation, the task is irrevocable.

[1926] Example Task Alterability Characterization Values

[1927] This task characterization is binary, with the minimum range being binary. Example binary values or scale endpoints are alterable/not alterable, irrevocable/revocable, or alterable/irrevocable.

[1928] Task Content Type

[1929] This task characteristic describes the type of content to be used with the task. For example, text, audio, video, still pictures, and so on.

[1930] Example Content Type Characteristics Values

[1931] This task characterization is an enumeration. Some example values are:

[1932] asp

[1933] .jpeg

[1934] .avi

[1935] .jpg

[1936] .bmp

[1937] .jsp

[1938] .gif

[1939] .php

[1940] .htm

[1941] .txt

[1942] .html

[1943] .wav

[1944] .doc

[1945] .xls

[1946] .mdb

[1947] .vbs

[1948] .mpg

[1949] Again, this list is meant to be illustrative, not exhaustive.

[1950] Task Type

[1951] A task can be performed in many types of situations. For example, a task that is performed in an augmented reality setting might be presented differently to the user than the same task that is executed in a supplemental setting.

[1952] Example Task Type Characteristics Values

[1953] This task characterization is an enumeration. Example values can include:

[1954] Supplemental

[1955] Augmentative

[1956] Mediated

[1957] Methods of Evaluating Attributes

[1958] This section describes some of the ways in which the UI needs can be passed to the computing system.

[1959] Predetermined Logic

[1960] A human, such as a UI Designer, Software Developer, or outside agency (military, school system, employer, etc.,) can create logic at design time that determines which attributes are passed to the computing system and how they are passed to the computing system. For example, a human could prioritize all of the known attributes. If any of those attributes were present, they would take priority in a very specific order, such as safety, privacy, user preferences and I/O device type.

[1961] Predetermined logic can include, but is not limited to, one or more of the following methods:

[1962] Numeric key

[1963] XML tags

[1964] Programmatic interface

[1965] Name/value pairs

[1966] Numeric Key

[1967] UI needs characterizations can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[1968] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent task hardware requirements. Therefore a task characterization of decimal 5 would indicate that minimal processing power is required to complete the task.

[1969] XML Tags

[1970] UI needs can be exposed to the system with a string of characters conforming to the XML structure.

[1971] For instance, a simple and important task could be represented as:

[1972] <Task Characterization> <Task Complexity=“0” Task Length=“9”> </Task Characterization>

[1973] And a context characterization might be represented by the following:

[1974] <Context Characterization>

[1975] <Theme>Work </Theme>

[1976] <Bandwidth>High Speed LAN Network Connection</Bandwidth>

[1977] <Field of View>28°</Field of View>

[1978] <Privacy>None </Privacy>

[1979] </Context Characterization>

[1980] And an I/O device characterization might be represented by the following:

[1981] <IO Device Characterization>

[1982] <Input>Keyboard</Input>

[1983] <Input>Mouse</Input>

[1984] <Output>Monitor</Output>

[1985] <Audio>None</Audio>

[1986] </IO Device Characterization>

[1987] Note: One significant advantage of this mechanism is that it is easily extensible.

[1988] Programming Interface

[1989] A task characterization can be exposed to the system by associating a task characteristic with a specific program call.

[1990] For instance:

[1991] GetUrgentTask can return a handle to that communicates that task urgency to the UI.

[1992] Or it could be:

[1993] GetHMDDevice can return a handle to the computing system that describes a UI for an HMD.

[1994] Or it could be:

[1995] GetSecureContext can return a handle to the computing system that describes a UI a high security user context.

[1996] Name/Value Pairs

[1997] UI needs can be modeled or represented with multiple attributes that each correspond to specific elements of the task (e.g., complexity, cognitive load or task length), user needs (e.g. privacy, safety, preferences, characteristics) and I/O devices (e.g. device type, redundant controls, audio availability, etc.) and the value of an attribute represents a specific measure of that element. For example, for an attribute that represents the task complexity, a value of “5” represents a specific measurement of complexity. Or an attribute that represents an output device type, a value of “HMD” represents a specific device. Or an attribute that represents the a user's privacy needs, a value of “5” represents a specific measurement of privacy.

[1998] Each attribute preferably has the following properties: a name, a value, a timestamp and in some cases (user and task attributes) an uncertainty level. For example, the name of the complexity attribute may be “task complexity” and its value at a particular time may be 5. Associated with the current value may be a timestamp of Aug. 1, 2001 13:07 PST that indicates when the value was generated, and an uncertainty level of +/−1 degrees. Or the name of the output device type attribute may be “output device,” and its value at a particular time may be “HMD” Associated with the current value may be a timestamp of Aug. 7, 2001 13:07 PST that indicates when the value was generated. Or the name of the privacy attribute may be “User Privacy” and its value at a particular time may be 5. Associated with the current value may be a timestamp of Aug. 1, 2001 13:07 PST that indicates when the value was generated, and an uncertainty level of +/−1 degrees.

[1999] User Feedback

[2000] Another embodiment is for the computing system to implement user feedback. In this embodiment, the computing system is designed to provide choices to the user and seek feedback about what attribute is most important. This can be implemented when a new attribute becomes available at run time. If the computing system does not recognize the attribute, the user can be queried about how to characterize the attribute. For example, if task privacy had not been previously characterized, the computing system could query the user about how to handle the task (e.g. which I/O devices should be used, hardware affinity, software requirements, and so on).

[2001] Pattern Recognition

[2002] By using pattern recognition algorithms (e.g. neural networks), implicit correlators over time between particular UI designs used and any context attribute (including task, user, and device) can be discovered and used predictively.

[2003] Characterizing Computer UI Designs with Respect to UI Requirements

[2004] For a system to accurately choose a UI design that is appropriate or optimal for the user's current computing context, it is useful to determine the design's intended use, required computer configuration, user task, user preferences and other attributes. This section describes an explicit extensible method to characterize UIs.

[2005] In general, any design considerations can be considered when choosing between different UI designs, if they are exposed in a way that the system can interpret.

[2006] This disclosure focuses on the first of the following three types of UI designs:

[2007] Supplemental—a software application that runs without integration with the current real world context, such as when the real world context is not even considered.

[2008] Augmentative—a software application that presents information in meaningful relationship to the user's perception of the real-world. An example of a UI design characteristic unique to this type of UI design is an indication of whether the design elements are curvaceous or rectilinear. The former is useful when seeking to differentiate the UI elements from man-made environments, the latter from natural environments.

[2009] Mediated—a software application that allows the user to perceive and manipulate the real-world from a remote location. An example of a UI design characteristic unique to this type of UI design is whether the design assumes a low time latency between the remote environment and the user (i.e., fast refresh of sounds and images) or one that is optimized for a significant delay.

[2010] There are two important aspects to characterizing UI designs: what UI design attributes are exposed and how are they exposed.

[2011] Characterized Attributes

[2012] In some embodiments, a human prepares an explicit characterization of a design before, during, and/or immediately after that UI is designed.

[2013] The characterization can be very simple, such as an indication whether the UI makes use of audio or not. Or the characterization can be arbitrarily complex For example, one or more of the following attributes could be used to characterize a UI.

[2014] Identification (ID). The identifier for a UI design. Any design can have more than one ID. For example, it can have an associated text string designed to be easy to recall by a user, and simultaneously a secure code component that is programmatically recognized.

[2015] Source. An identification of the originator or distributor of the design. Like the ID, this can include a user readable description and/or a machine-readable description.

[2016] Date. The date for the UI design. Any design can have more than one date. Some relevant dates include when the design was created, updated, or provided.

[2017] Version. The version indicates when modifications to existing designs are provided or anticipated.

[2018] Input/output device. Many of the methods of presenting or interacting with UI's are dependent on what devices the user can directly manipulate or perceive. Therefore a description of the hardware requirements or affinity is useful.

[2019] Cost. Since UI designs can be provided by commercial software vendors, who may or may not require payment, the cost to the consumer may be significant in deciding on whether to use a particular design.

[2020] Design elements. A UI can be characterized as being composed of particular graphically-described design elements.

[2021] Functional elements. A UI can be constructed of abstracted UI elements defined by their function, rather than their presentation. A design characterization can include a list of the required elements, allowing the system to choose.

[2022] Use. A description of intended or appropriate use of a design can be implicit in the characterization of dependencies such as hardware, software, or user profile and preference, or it can be explicitly described. For instance, a design can be characterized as a “deep sea diving” UI.

[2023] Content. The supported, required, or affinities for specific types of content can be characterized. For instance, a design intended to be used as a virtual radio appliance could enumerate two channels of 44.2 kHz audio as part of its provided content. Or a design could note that though it can display and control motion video, it has been optimized for the slow transition of a series of still images.

[2024] The useful consideration as to whether an attribute should be added to a UI design characterization is whether a change in the attribute would result in the choice of a different design. For example, characterizing the design's intent of working with a head-mounted video display can be important, while noting that the design was created on a Tuesday is not.

[2025] How the Characterization is Exposed to the System

[2026] There are many ways to expose the UI's characterization to the system, as shown by the following three examples.

[2027] Numeric Key

[2028] A UI's characterization can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[2029] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent the need for a visual display device capable of displaying at least 24 characters of text in an unbroken series. Therefore a UI characterization of decimal 5 would require such a display to optimally display its content.

[2030] XML Tags

[2031] A UI's characterization can be exposed to the system with a string of characters conforming to the XML structure.

[2032] For instance, a UI design optimized for an audio presentation can include:

[2033] <UI Characterization> <Video Display Required=“0” Audio Output=“1”></UI Characterization>

[2034] One significant advantage of the mechanism is that it is easily extensible.

[2035] Programming Interface

[2036] A UI's characterization can be exposed to the system by associating the design with a specific program call.

[2037] For instance:

[2038] GetAudioOnlyUI can return a handle to a UI optimized for audio.

[2039] Illustrative UI Design Attributes

[2040] The attributes listed in this spreadsheet are intended to be illustrative. There could be many more attributes that characterize a UI design.

Attribute           Description
Content             Characterizes how a UI design presents content
                    to the user. For example, if the UI design is for a LCD,
                    this attribute characterization might communicate to
                    the computing environment that all task content and
                    feedback is on the right side of the display and all user
                    choices are offered in a menu on the left side of the
                    screen.
Cost                Characterizes the purchase price of the UI
                    design.
Date                The date for the UI design. Any design can have
                    more than one date. Some relevant dates include
                    when the design was created, updated, or provided.
Design elements     Characterizes how the graphically described
                    design elements are assembled in a UI design.
Functional          Characterizes how and which abstracted UI
elements            elements defined by their function are assembled in a
                    UI design. A design characterization can include a list
                    of the required elements, allowing the system to
                    choose.
Hardware affinity   Characterizes with which hardware the UI
                    design has affinity. This characteristic does not include
                    output devices.
Identification (ID) The identifier for a UI design. Any design can
                    have more than one ID.
Importance          Characterizes the UI design for task importance.
Input and output    Characterizes for which input and output
devices             devices have affinity for this particular UI design.
Language            Characterizes for which language(is) the UI
                    design is optimized.
Learning profile    Characterizes the learning style built into the UI.
Length              Characterizes how the UI design accommodates
                    the task length.
Name                The name of the UI design.
Physical            Characterizes how the UI design accommodates
availability        different levels of physical availability (the
                    degree to which user'is body or part of their
                    body is in use). For
                    example, a UI designed to work with speech
                    commands accommodates users who hands are
                    physically unavailable because the user is repairing an
                    airplane engine.
Power supply        Characterizes how much power the UI design
                    uses. Typically, this is determined by the type of
                    hardware the design requires.
Priority            Characterizes how the UI design presents task
                    priority.
Privacy             Characterizes the level of privacy built in to the
                    UI design. For example, a UI that is designed to use
                    coded speech commands and a head mounted display
                    is more private than a UI designed to use non-coded
                    speech commands and a desktop monitor.
Processing          Characterizes the speed and CPU usage
                    capabilities required for a UI design.
Safety              Characterizes the safety precautions built into
                    the UI design. For instance, designs that require
                    greater user attention may be characterized as less
                    safe.
Security            Characterizes a the level of security built into a
                    UI design.
Software            Characterizes the ability of the software
capability          available to the computing environment.
Source              Indicates the person, organization, business, or
                    otherwise who created the UI design. This attribute can
                    include a user readable description and/or a machine-
                    readable description.
Storage             Characterizes the amount of storage (e.g. RAM)
                    needed by the UI design.
System audio        Characterizes whether the UI is capable to
                    receive audio signals from the user on behalf of the
                    computing environment.
Task complexity     Characterizes the UI design for task complexity.
                    For example, if the UI is output to a visual
                    presentation surface and the task is simple, the
                    entire task might be encapsulated in one screen.
                    If the task is complex, the task might be
                    separated into multiple steps.
Theme               Characterizes a related set of measures of
                    specific context elements, such as ambient
                    temperature and current task, built into the UI design.
Urgency             Characterizes how the UI design presents task
                    urgency to the user.
Use                 The explicit characterization of the intended
                    purpose or use of a UI design. For instance, a design
                    can be characterized as a “deep sea diving” UI.
User attention      Characterizes the UI design for user attention.
                    For example, if the user has full attention for the
                    computing environment, the UI may be more
                    complicated than a UI design for a user who has only
                    background attention for the computing environment.
User audio          Characterizes the UI'is ability to present audio
                    signals to the user.
User                Characterizes how the UI design accommodates
characteristics     for user characteristics such as emotional and physical
                    states.
User expertise      Characterizes how the UI design accommodates
                    user expertise.
User preferences    Characterizes how a UI design accommodates
                    for a set of attributes that reflect user likes and
                    dislikes, such as I/O devices preferences, volume of
                    audio output, amount of haptic pressure, and font size
                    and color for visual display surfaces.
Version             The version indicates when modifications to
                    existing designs are provided or anticipated.
Video               Characterizes whether the UI design presents
                    visual output to the user through a visual presentation
                    surface such as a head mounted display, monitor, or
                    LCD.

[2041] Automated Selection of Appropriate or Optimal Computer UI

[2042] This section describes techniques to enable a computing system to change the user interface by choosing from a group of preexisting UI designs at run time. FIG. 6 provides an overview of how this is accomplished.

[2043] The left side of FIG. 6 shows how the characterizations of the user's task functionality, I/O devices local to the user, and context are combined to create a description of the optimal UI for the current situation. The right side of FIG. 6 shows UI designs that have been explicitly characterized. These optimal UI characterizations are compared to the available UI characterizations and when a match is found, that UI is used.

[2044] To accurately choose which UI design is optimal for the user's current computing context, a system compares a design's intended use to the current requirements for a UI. This disclosure describes an explicit extensible method to dynamically compare the characterizations of UI designs to the characterization of the current UI needs and then choose a UI design based on how the characterizations match run time. FIG. 6 shows the overall logic.

[2045] 3001 : Characterized UI Designs

[2046] FIG. 7 illustrates a variety of characterized UI designs 3001. These UI designs can be characterized in various ways, such as by a human preparing an explicit characterization of that design before, during or immediately after a UI is designed. The characterization can be very simple, such as an indication whether the UI makes use of audio or not. Or the characterization can be arbitrarily complex. For example, one or more of the following attributes could be used to characterize a UI.

[2047] Identification (ID). The identifier for a UI design. Any design can have more than one ID. For example, it can have an associated text string designed to be easy to recall by a user, and simultaneously a secure code component that is programmatically recognized.

[2048] Source. An identification of the originator or distributor of the design. Like the ID, this can include a user readable description and/or a machine-readable description.

[2049] Date. The date for the UI design. Any design can have more than one date. Some relevant dates include when the design was created, updated, or provided.

[2050] Version. The version indicates when modifications to existing designs are provided or anticipated.

[2051] Input/output device. Many of the methods of presenting or interacting with UI's are dependent on what devices the user can directly manipulate or perceive. Therefore a description of the hardware requirements or affinity is useful.

[2052] Cost. Since UI designs can be provided by commercial software vendors, who may or may not require payment, the cost to the consumer may be significant in deciding on whether to use a particular design.

[2053] Design elements. A UI can be characterized as being composed of particular graphically-described design elements.

[2054] Functional elements. A UI can be constructed of abstracted UI elements defined by their function, rather than their presentation. A design characterization can include a list of the required elements, allowing the system to choose.

[2055] Use. A description of intended or appropriate use of a design can be implicit in the characterization of dependencies such as hardware, software, or user profile and preference, or it can be explicitly described. For instance, a design can be characterized as a “deep sea diving” UI.

[2056] Content. The supported, required, or affinities for specific types of content can be characterized. For instance, a design intended to be used as a virtual radio appliance could enumerate two channels of 44.2 kHz audio as part of its provided content. Or a design could note that though it can display and control motion video, it has been optimized for the slow transition of a series of still images.

[2057] The useful consideration as to whether an attribute should be added to a UI design characterization is whether a change in the attribute would result in the choice of a different design. For example, characterizing the design's intent of working with a head-mounted video display can be important, while noting that the design was created on a Tuesday is not.

[2058] How the Characterization is Exposed to the System

[2059] There are many ways to expose the UI's characterization to the system, as shown by the following three examples.

[2060] Numeric Key

[2061] A UI's characterization can be exposed to the system with a numeric value corresponding to values of a predefined data structure.

[2062] For instance, a binary number can have each of the bit positions associated with a specific characteristic. The least significant bit may represent the need for a visual display device capable of displaying at least 24 characters of text in an unbroken series. Therefore a UI characterization of decimal 5 would require such a display to optimally display its content.

[2063] XML Tags

[2064] A UI's characterization can be exposed to the system with a string of characters conforming to the XML structure.

[2065] For instance, a UI design optimized for an audio presentation can include:

[2066] <UI Characterization><Video Display Required=“0” Audio Output=“1”></UI Characterization>

[2067] One significant advantage of the mechanism is that it is easily extensible.

[2068] Programming Interface

[2069] A UI's characterization can be exposed to the system by associating the design with a specific program call.

[2070] For instance:

[2071] GetAudioOnlyUI can return a handle to a UI optimized for audio.

[2072] 3002 : Optimal UI Characterizations

[2073] This section describes modeled real-world and virtual contexts to which the described techniques can respond. The described model for optimal UI design characterization includes at least the following categories of attributes when determining the optimal UI design:

[2074] All available attributes. The model is dynamic so it can accommodate for any and all attributes that could affect the optimal UI design for a user's context. For example, this model could accommodate for temperature, weather conditions, time of day, available I/O devices, preferred volume level, desired level of privacy, and so on.

[2075] Significant attributes. Some attributes have a more significant influence on the optimal UI design than others. Significant attributes include, but are not limited to, the following:

[2076] The user can see video.

[2077] The user can hear audio.

[2078] The computing system can hear the user.

[2079] The interaction between the user and the computing system must be private.

[2080] The user's hands are occupied.

[2081] Attributes that correspond to a theme. Specific or programmatic. Individual or group.

[2082] For clarity, many of the example attributes described in this topic is presented with a scale and some include design examples. It is important to note that any of the attributes mentioned in this document are just examples, however. There are other attributes that can cause a UI to change that are not listed in this document. The described dynamic model can account for additional attributes.

[2083] I/O Devices

[2084] Output—Devices that are directly perceivable by the user. For example, a visual output device creates photons that enter the user's eye. Output devices are always local to the user.

[2085] Input—A device that can be directly manipulated by the user. For example, a microphone translates energy created by the user's voice into electrical signals that can control a computer. Input devices are always local to the user.

[2086] The input devices to which the user has access to interact with the computer in ways that convey choices include, but is not limited to:

[2087] Keyboards

[2088] Touch pads

[2089] Mice

[2090] Trackballs

[2091] Microphones

[2092] Rolling/pointing/pressing/bending/turning/twisting/switching/rubbing/zipping cursor controllers—anything that the user's manipulation of can be sensed by the computer, this includes body movement that forms recognizable gestures.

[2093] Buttons, etc.

[2094] Output devices allow the presentation of computer-controlled information and content to the user, and includes:

[2095] Speakers

[2096] Monitors

[2097] Pressure actuators, etc.

[2098] Input Device Types

[2099] Some characterizations of input devices are a direct result of the device itself.

[2100] Touch Screen

[2101] A display screen that is sensitive to the touch of a finger or stylus. Touch screens are very resistant to harsh environments where keyboards might eventually fail. They are often used with custom-designed applications so that the on-screen buttons are large enough to be pressed with the finger. Applications are typically very specialized and greatly simplified so they can be used by anyone. However, touch screens are also very popular on PDAs and full-size computers with standard applications, where a stylus is required for precise interaction with screen objects.

[2102] Example Touch Screen Attribute Characteristic Values

[2103] This characteristic is enumerated. Some example values are:

[2104] Screen objects must be at least 1 centimeter square

[2105] The user can see the touch screen directly

[2106] The user can see the touch screen indirectly (e.g. by using a monitor)

[2107] Audio feedback is available

[2108] Spatial input is difficult

[2109] Feedback to the user is presented to the user through a visual presentation surface.

[2110] Pointing Device

[2111] An input device used to move the pointer (cursor) on screen.

[2112] Example Pointing Device Characteristic Values

[2113] This characteristic is enumerated. Some example values are:

[2114] 1-dimension (D) pointing device

[2115] 2-D pointing device

[2116] 3-D pointing device

[2117] Position control device

[2118] Range control device

[2119] Feedback to the user is presented through a visual presentation surface.

[2120] Speech

[2121] The conversion of spoken words into computer text. Speech is first digitized and then matched against a dictionary of coded waveforms. The matches are converted into text as if the words were typed on the keyboard.

[2122] Example Speech Characteristic Values

[2123] This characteristic is enumerated. Example values are:

[2124] Command and control

[2125] Dictation

[2126] Constrained grammar

[2127] Unconstrained grammar

[2128] Keyboard

[2129] A set of input keys. On terminals and personal computers, it includes the standard typewriter keys, several specialized keys and the features outlined below.

[2130] Example Keyboard Characteristic Values

[2131] This characteristic is enumerated. Example values are:

[2132] Numeric

[2133] Alphanumeric

[2134] Optimized for discreet input

[2135] Pen Tablet

[2136] A digitizer tablet that is specialized for handwriting and hand marking. LCD-based tablets emulate the flow of ink as the tip touches the surface and pressure is applied. Non-display tablets display the handwriting on a separate computer screen.

[2137] Example Pen Tablet Characteristic Values

[2138] This characteristic is enumerated. Example values include:

[2139] Direct manipulation device

[2140] Feedback is presented to the user through a visual presentation surface

[2141] Supplemental feedback can be presented to the user using audio output.

[2142] Optimized for special input

[2143] Optimized for data entry

[2144] Eye Tracking

[2145] An eye-tracking device is a device that uses eye movement to send user indications about choices to the computing system. Eye tracking devices are well suited for situations where there is little to no motion from the user (e.g. the user is sitting at a desk) and has much potential for non-command user interfaces.

[2146] Example Eye Tracking Characteristic Values

[2147] This characteristic is enumerated. Example values include:

[2148] 2-D pointing device

[2149] User motion=still

[2150] Privacy=high

[2151] Output Device Types

[2152] Some characterizations of input devices are a direct result of the device itself.

[2153] HMD

[2154] Head Mounted Display) A display system built and worn like goggles that gives the illusion of a floating monitor in front of the user's face. The HMD is an important component of a body-worn computer (wearable computer). Single-eye units are used to display hands-free instructional material, and dual-eye, or stereoscopic, units are used for virtual reality applications.

[2155] Example HMD Characteristic Values

[2156] This characteristic is enumerated. Example values include:

[2157] Field of view >28°

[2158] User's hands=not available

[2159] User's eyes=forward and out

[2160] User's reality=augmented, mediated, or virtual

[2161] Monitors

[2162] A display screen used to present output from a computer, camera, VCR or other video generator. A monitor's clarity is based on video bandwidth, dot pitch, refresh rate, and convergence.

[2163] Example Monitor Characteristic Values

[2164] This characteristic is enumerated. Some example values include:

[2165] Required graphical resolution=high

[2166] User location=stationary

[2167] User attention=high

[2168] Visual density=high

[2169] Animation=yes

[2170] Simultaneous presentation of information=yes (e.g. text and image)

[2171] Spatial content=yes

[2172] I/O Device Use

[2173] This attribute characterizes how or for what an input or output device can be optimized for use. For example, a keyboard is optimized for entering alphanumeric text characters and monitor, head mounted display (HMD), or LCD panel is optimized for displaying those characters and other visual information.

[2174] Example Device Use Characterization Values

[2175] This characterization is enumerated. Example values include:

[2176] Speech recognition

[2177] Alphanumeric character input

[2178] Handwriting recognition

[2179] Visual presentation

[2180] Audio presentation

[2181] Haptic presentation

[2182] Chemical presentation

[2183] Redundant Controls

[2184] The user may have more than one way to perceive or manipulate the computing environment. For instance, they may be able to indicate choices by manipulating a mouse, or speaking.

[2185] By providing UI designs that have more than one I/O modality (also known as “multi-modal”), greater flexibility can be provided to the user. However, there are times when this is not appropriate. For instance, the devices may not be constantly available (user's hands are occupied, the ambient noise increases defeating voice recognition).

[2186] Example Redundant Controls Characterization Values

[2187] As a minimum, a numeric value could be associated with a configuration of devices.

[2188] 1—keyboard and touch screen

[2189] 2—HMD and 2-D pointing device

[2190] Alternately, a standardized list of available, preferred, or historically used devices could be used.

[2191] QWERTY keyboard

[2192] Twiddler

[2193] HMD

[2194] VGA monitor

[2195] SVGA monitor

[2196] LCD display

[2197] LCD panel

[2198] Privacy

[2199] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be an HMD and the preferred input device might be an eye-tracking device.

[2200] Hardware Affinity for Privacy

[2201] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[2202] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[2203] Example Privacy Characterization Values

[2204] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[2205] Using no privacy and fully private as the scale endpoints, the following table lists an example privacy characterization scale.

Scale attribute                  Implication/Example
No privacy is needed for         The UI is not restricted to any
input or output interaction      particular I/O device for presentation
                                 and interaction. For example, the UI
                                 could present content to the user
                                 through speakers on a large monitor in
                                 a busy office.
The input must be semi-private.  Coded speech commands, and
The output does not need to be   keyboard methods are appropriate. No
private.                         restrictions on output presentation.
The input must be fully private. No speech commands. No
The output does not need to be   restriction on output presentation.
private.
The input must be fully private. No speech commands. No LCD
The output must be semi-private. panel.
The input does not need to be    No restrictions on input
private. The output must be      interaction. The output is restricted to
fully private.                   an HMD device and/or an earphone.
The input does not need to be    No restrictions on input
private. The output must be      interaction. The output is restricted to
semi-private.                    HMD device, earphone, and/or an LCD
                                 panel.
The input must be semi-private.  Coded speech commands and
The output must be semi-private. keyboard methods are appropriate.
                                 Output is restricted to an HMD device,
                                 earphone or an LCD panel.
The input and output interaction No speech commands. Keyboard
must be fully private.           devices might be acceptable. Output is
                                 restricted to and HMD device and/or an
                                 earphone.
* Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.
* Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[2206] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[2207] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[2208] Visual

[2209] Visual output refers to the available visual density of the display surface is characterized by the amount of content a presentation surface can present to a user. For example, an LED output device, desktop monitor, dashboard display, hand-held device, and head mounted display all have different amounts of visual density. UI designs that are appropriate for a desktop monitor are very different than those that are appropriate for head-mounted displays. In short, what is considered to be the optimal UI will change based on what visual output device(s) is available.

[2210] In addition to density, visual display surfaces have the following characteristics:

[2211] Color

[2212] Motion

[2213] Field of view

[2214] Depth

[2215] Reflectivity

[2216] Size. Refers to the actual size of the visual presentation surface.

[2217] Position/location of visual display surface in relation to the user and the task that they're performing.

[2218] Number of focal points. A UI can have more than one focal point and each focal point can display different information.

[2219] Distance of focal points from the user. A focal point can be near the user or it can be far away. The amount distance can help dictate what kind and how much information is presented to the user.

[2220] Location of focal points in relation to the user. A focal point can be to the left of the user's vision, to the right, up, or down.

[2221] With which eye(s) the output is associated. Output can be associated with a specific eye or both eyes.

[2222] Ambient light.

[2223] Others

[2224] The topics in this section describe in further detail the characteristics of some of these previously listed attributes.

[2225] Example Visual Density Characterization Values

[2226] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no visual density/full visual density.

[2227] Using no visual density and full visual density as scale endpoints, the following table lists an example visual density scale.

Scale attribute               Implication/Design example
There is no visual density    The UI is restricted to non-visual
                              output such as audio, haptic, and
                              chemical.
Visual density is very low    The UI is restricted to a very
                              simple output, such as single binary
                              output devices (a single LED) or other
                              simple configurations and arrays of
                              light. No text is possible.
Visual density is low         The UI can handle text, but is
                              restricted to simple prompts or the
                              bouncing ball.
Visual density is medium      The UI can display text, simple
                              prompts or the bouncing ball, and very
                              simple graphics.
Visual density is high        The visual display has fewer
                              restrictions. Visually dense items such
                              as windows, icons, menus, and prompts
                              are available as well as streaming
                              video, detailed graphics and so on.
Visual density is the highest The UI is not restricted by visual
available                     density. A visual display that mirrors
                              reality (e.g. 3-dimensional) is possible
                              and appropriate.

[2228] Color

[2229] This characterizes whether or not the presentation surface displays color. Color can be directly related to the ability of the presentation surface, or it could be assigned as a user preference.

[2230] Chrominance. The color information in a video signal.

[2231] Luminance. The amount of brightness, measured in lumens, which is given off by a pixel or area on a screen. It is the black/gray/white information in a video signal. Color information is transmitted as luminance (brightness) and chrominance (color). For example, dark red and bright red would have the same chrominance, but a different luminance. Bright red and bright green could have the same luminance, but would always have a different chrominance.

[2232] Example Color Characterization Values

[2233] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no color/full color.

[2234] Using no color and full color as scale endpoints, the following table lists an example color scale.

Scale attribute          Implication/Design example
No color is available.   The UI visual presentation is
                         monochrome.
One color is available.  The UI visual presentation is
                         monochrome plus one color.
Two colors are available The UI visual presentation is
                         monochrome plus two colors or any
                         combination of the two colors.
Full color is available. The UI is not restricted by color.

[2235] Motion

[2236] This characterizes whether or not a presentation surface has the ability to present motion to the user. Motion can be considered as a stand-alone attribute or as a composite attribute.

[2237] Example Motion Characterization Values

[2238] As a stand-alone attribute, this characterization is binary. Example binary values are: no animation available/animation available.

[2239] As a composite attribute, this characterization is scalar. Example scale endpoints include no motion/motion available, no animation available/animation available, or no video/video. The values between the endpoints depend on the other characterizations that are included in the composite. For example, the attributes color, visual density, and frames per second, etc. change the values between no motion and motion available.

[2240] Field of View

[2241] A presentation surface can display content in the focus of a user's vision, in the user's periphery, or both.

[2242] Example Field of View Characterization Values

[2243] This UI characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: peripheral vision only/field of focus and peripheral vision is available.

[2244] Using peripheral vision only and field of focus and peripheral vision is available as scale endpoints, the following tables lists an example field of view scale.

Scale attribute               Implication
All visual display is in the  The UI is restricted to using the
peripheral vision of the user peripheral vision of the user. Lights,
                              colors and other simple visual display
                              are appropriate. Text is not appropriate.
Only the user's field of      The UI is restricted to using the
focus is available.           users field of vision only. Text and
                              other complex visual displays are
                              appropriate.
Both field of focus and the   The UI is not restricted by the
peripheral vision of the user user's field of view.
are used.

[2245] Exemplary UI Design Implementation for Changes in Field of View

[2246] The following list contains examples of UI design implementations for how the computing system might respond to a change in field of view.

[2247] If the field of view for the visual presentation is more than 28°, then the UI might:

[2248] Display the most important information at the center of the visual presentation surface.

[2249] Devote more of the UI to text

[2250] Use periphicons outside of the field of view.

[2251] If the field of view for the visual presentation is less than 28°, then the UI might:

[2252] Restrict the size of the font allowed in the visual presentation. For example, instead of listing “Monday, Tuesday, and Wednesday,” and so on as choices, the UI might list “M, Tu, W” instead.

[2253] The body or environment stabilized image can scroll.

[2254] Depth

[2255] A presentation surface can display content in 2 dimensions (e.g. a desktop monitor) or 3 dimensions (a holographic projection).

[2256] Example Depth Characterization Values

[2257] This characterization is binary and the values are: 2 dimensions 3 dimensions.

[2258] Reflectivity

[2259] The fraction of the total radiant flux incident upon a surface that is reflected and that varies according to the wavelength distribution of the incident radiation.

[2260] Example Reflectivity Characterization Values

[2261] This characterization is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not reflective/highly reflective or no glare/high glare.

[2262] Using not reflective and highly reflective as scale endpoints, the following list is an example of a reflectivity scale.

[2263] Not reflective (no surface reflectivity).

[2264] 10% surface reflectivity

[2265] 20% surface reflectivity

[2266] 30% surface reflectivity

[2267] 40% surface reflectivity

[2268] 50% surface reflectivity

[2269] 60% surface reflectivity

[2270] 70% surface reflectivity

[2271] 80% surface reflectivity

[2272] 90% surface reflectivity

[2273] Highly reflective (100% surface reflectivity)

[2274] Exemplary UI Design Implementation for Changes in Reflectivity

[2275] The following list contains examples of UI design implementations for how the computing system might respond to a change in reflectivity.

[2276] If the output device has high reflectivity—a lot of glare—then the visual presentation will change to a light colored UI.

[2277] Audio

[2278] Audio input and output refers to the UI's ability to present and receive audio signals. While the UI might be able to present or receive any audio signal strength, if the audio signal is outside the human hearing range (approximately 20 Hz to 20,000 Hz) it is converted so that it is within the human hearing range, or it is transformed into a different presentation, such as haptic output, to provide feedback, status, and so on to the user

[2279] Factors that influence audio input and output include (but this is not an inclusive list):

[2280] Level of ambient noise (this is an environmental characterization)

[2281] Directionality of the audio signal

[2282] Head-stabilized output (e.g. earphones)

[2283] Environment-stabilized output (e.g. speakers)

[2284] Spatial layout (3-D audio)

[2285] Proximity of the audio signal to the user

[2286] Frequency range of the speaker

[2287] Fidelity of the speaker, e.g. total harmonic distortion

[2288] Left, right, or both ears

[2289] What kind of noise is it?

[2290] Others

[2291] Example Audio Output Characterization Values

[2292] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user cannot hear the computing system/the user can hear the computing system.

[2293] Using the user cannot hear the computing system and the user can hear the computing system as scale endpoints, the following table lists an example audio output characterization scale.

Scale attribute                  Implication
The user cannot hear the         The UI cannot use audio to
computing system.                give the user choices, feedback,
                                 and so on.
The user can hear audible        The UI might offer the user
whispers (approximately          choices, feedback, and so on by
10-30 dBA).                      using the earphone only.
The user can hear normal         The UI might offer the user
conversation (approximately      choices, feedback, and so on
50-60 dBA).                      by using a speaker(s) connected
                                 to the computing system.
The user can hear                The UI is not restricted by
communications from the computing audio signal strength needs or
system without restrictions.     concerns.
Possible ear damage              The UI will not output audio for
(approximately 85+ dBA)          extended periods of time that will
                                 damage the user's hearing.

[2294] Example Audio Input Characterization Values

[2295] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the computing system cannot hear the user/the computing system can hear the user.

[2296] Using the computing system cannot hear the user and the computing system can hear the user as scale endpoints, the following table lists an example audio input scale.

Scale attribute                Implication
The computing system cannot    When the computing system
receive audio input from       cannot receive audio input from the
the user.                      user, the UI will notify the user
                               that audio input is not available.
The computing system is able
to receive audible whispers
from the user (approximate
10-30 dBA).
The computing system is able to
receive normal conversational
tones from the user (approximate
50-60 dBA).
The computing system can       The UI is not restricted by audio
receive audio input from the   signal strength needs or concerns.
user without restrictions.
The computing system can       The computing system will not
receive only high volume audio require the user to give indications
input from the user.           using a high volume. If a high volume
                               is required, then the UI will notify
                               the user that the computing system
                               cannot receive audio input from the
                               user.

[2297] Haptics

[2298] Haptics refers to interacting with the computing system using a tactile method. Haptic input includes the computing system's ability to sense the user's body movement, such as finger or head movement. Haptic output can include applying pressure to the user's skin. For haptic output, the more transducers, the more skin covered, the more resolution for presentation of information. That is if the user is covered with transducers, the computing system receives a lot more input from the user. Additionally, the ability for haptically-oriented output presentations is far more flexible.

[2299] Example Haptic Input Characterization Values

[2300] This characteristic is enumerated. Possible values include accuracy, precision, and range of:

[2301] Pressure

[2302] Velocity

[2303] Temperature

[2304] Acceleration

[2305] Torque

[2306] Tension

[2307] Distance

[2308] Electrical resistance

[2309] Texture

[2310] Elasticity

[2311] Wetness

[2312] Additionally, the characteristics listed previously are enhanced by:

[2313] Number of dimensions

[2314] Density and quantity of sensors (e.g. a 2 dimensional array of sensors. The sensors could measure the characteristics previously listed).

[2315] Chemical Output

[2316] Chemical output refers to using chemicals to present feedback, status, and so on to the user. Chemical output can include:

[2317] Things a user can taste

[2318] Things a user can smell

[2319] Example Taste Characteristic Values

[2320] This characteristic is enumerated. Example characteristic values of taste include:

[2321] Bitter

[2322] Sweet

[2323] Salty

[2324] Sour

[2325] Example Smell Characteristic Values

[2326] This characteristic is enumerated. Example characteristic values of smell include:

[2327] Strong/weak

[2328] Pungent/bland

[2329] Pleasant/unpleasant

[2330] Intrinsic, or signaling

[2331] Electrical Input

[2332] Electrical input refers to a user's ability to actively control electrical impulses to send indications to the computing system.

[2333] Brain activity

[2334] Muscle activity

[2335] Example Electrical Input Characterization Values

[2336] This characteristic is enumerated. Example values of electrical input can include:

[2337] Strength of impulse

[2338] Frequency

[2339] User Characterizations

[2340] This section describes the characteristics that are related to the user.

[2341] User Preferences

[2342] User preferences are a set of attributes that reflect the user's likes and dislikes, such as I/O devices preferences, volume of audio output, amount of haptic pressure, and font size and color for visual display surfaces. User preferences can be classified in the following categories:

[2343] Self characterization. Self-characterized user preferences are indications from the user to the computing system about themselves. The self-characterizations can be explicit or implicit. An explicit, self-characterized user preference results in a tangible change in the interaction and presentation of the UI. An example of an explicit, self characterized user preference is “Always use the font size 18” or “The volume is always off.” An implicit, self-characterized user preference results in a change in the interaction and presentation of the UI, but it might be not be immediately tangible to the user. A learning style is an implicit self-characterization. The user's learning style could affect the UI design, but the change is not as tangible as an explicit, self-characterized user preference. If a user characterizes themselves to a computing system as a “visually impaired, expert computer user,” the UI might respond by always using 24-point font and monochrome with any visual display surface. Additionally, tasks would be chunked differently, shortcuts would be available immediately, and other accommodations would be made to tailor the UI to the expert user.

[2344] Theme selection. In some situations, it is appropriate for the computing system to change the UI based on a specific theme. For example, a high school student in public school 1420 who is attending a chemistry class could have a UI appropriate for performing chemistry experiments. Likewise, an airplane mechanic could also have a UI appropriate for repairing airplane engines. While both of these UIs would benefit from hands free, eyes out computing, the UI would be specifically and distinctively characterized for that particular system.

[2345] System characterization. When a computing system somehow infers a user's preferences and uses those preferences to design an optimal UI, the user preferences are considered to be system characterizations. These types of user preferences can be analyzed by the computing system over a specified period on time in which the computing system specifically detects patterns of use, learning style, level of expertise, and so on. Or, the user can play a game with the computing system that is specifically designed to detect these same characteristics.

[2346] Pre-configured. Some characterizations can be common and the UI can have a variety of pre-configured settings that the user can easily indicate to the UI. Pre-configured settings can include system settings and other popular user changes to default settings.

[2347] Remotely controlled. From time to time, it may be appropriate for someone or something other than the user to control the UI that is displayed.

[2348] Example User Preference Characterization Values

[2349] This UI characterization scale is enumerated. Some example values include:

[2350] Self characterization

[2351] Theme selection

[2352] System characterization

[2353] Pre-configured

[2354] Remotely controlled

[2355] Theme

[2356] A theme is a related set of measures of specific context elements, such as ambient temperature, current user task, and latitude, which reflect the context of the user. In other words, theme is a name collection of attributes, attribute values, and logic that relates these things. Typically, themes are associated with user goals, activities, or preferences. The context of the user includes:

[2357] The user's mental state, emotional state, and physical or health condition.

[2358] The user's setting, situation or physical environment. This includes factors external to the user that can be observed and/or manipulated by the user, such as the state of the user's computing system.

[2359] The user's logical and data telecommunications environment (or “cyber-environment,” including information such as email addresses, nearby telecommunications access such as cell sites, wireless computer ports, etc.).

[2360] Some examples of different themes include: home, work, school, and so on. Like user preferences, themes can be self characterized, system characterized, inferred, pre-configured, or remotely controlled.

[2361] Example Theme Characterization Values

[2362] This characteristic is enumerated. The following list contains example enumerated values for theme.

[2363] No theme

[2364] The user's theme is inferred.

[2365] The user's theme is pre-configured.

[2366] The user's theme is remotely controlled.

[2367] The user's theme is self characterized.

[2368] The user's theme is system characterized.

[2369] User Characteristics

[2370] User characteristics include:

[2371] Emotional state

[2372] Physical state

[2373] Cognitive state

[2374] Social state

[2375] Example User Characteristics Characterization Values

[2376] This UI characterization scale is enumerated. The following lists contain some of the enumerated values for each of the user characteristic qualities listed above.

* Emotional state.
* Happiness
* Sadness
* Anger
* Frustration
* Confusion
* Physical state
* Body
* Biometrics
* Posture
* Motion
* Physical Availability
* Senses
* Eyes
* Ears
* Tactile
* Hands
* Nose
* Tongue
* Workload demands/effects
* Interaction with computer devices
* Interaction with people
* Physical Health
* Environment
* Time/Space
* Objects
* Persons
* Audience/Privacy Availability
* Scope of Disclosure
* Hardware affinity for privacy
* Privacy indicator for user
* Privacy indicator for public
* Watching indicator
* Being observed indicator
* Ambient Interference
* Visual
* Audio
* Tactile
* Location.
* Place_name
* Latitude
* Longitude
* Altitude
* Room
* Floor
* Building
* Address
* Street
* City
* County
* State
* Country
* Postal_Code
* Physiology.
* Pulse
* Body_temperature
* Blood_pressure
* Respiration
* Activity
* Driving
* Eating
* Running
* Sleeping
* Talking
* Typing
* Walking
*Cognitive state
* Meaning
* Cognition
* Divided User Attention
* Task Switching
* Background Awareness
* Solitude
* Privacy
* Desired Privacy
* Perceived Privacy
* Social Context
* Affect
* Social state
* Whether the user is alone or if others are present
* Whether the user is being observed (e.g., by a camera)
* The user's perceptions of the people around them and the user's
perceptions of the intentions of the people that surround them.
* The user's social role (e.g they are a prisoner, they are a guard,
they are a nurse, they are a teacher, they are a student, etc.)

[2377] Cognitive Availability

[2378] There are three kinds of user tasks: focus, routine, and awareness and three main categories of user attention: background awareness, task switched attention, and parallel. Each type of task is associated with a different category of attention. Focus tasks require the highest amount of user attention and are typically associated with task-switched attention. Routine tasks require a minimal amount of user attention or a user's divided attention and are typically associated with parallel attention. Awareness tasks appeals to a user's precognitive state or attention and are typically associated with background awareness. When there is an abrupt change in the sound, such as changing from a trickle to a waterfall, the user is notified of the change in activity.

[2379] Background Awareness

[2380] Background awareness is a non-focus output stimulus that allows the user to monitor information without devoting significant attention or cognition.

[2381] Example Background Awareness Characterization Values

[2382] This characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: the user has no awareness of the computing system/the user has background awareness of the computing system.

[2383] Using these values as scale endpoints, the following list is an example background awareness scale.

[2384] No background awareness is available. A user's pre-cognitive state is unavailable.

[2385] A user has enough background awareness available to the computing system to receive one type of feedback or status.

[2386] A user has enough background awareness available to the computing system to receive more than one type of feedback, status and so on.

[2387] A user's background awareness is fully available to the computing system. A user has enough background awareness available for the computing system such that they can perceive more than two types of feedback or status from the computing system.

[2388] Exemplary UI Design Implementations for Background Awareness

[2389] The following list contains examples of UI design implementations for how a computing system might respond to a change in background awareness.

[2390] If a user does not have any attention for the computing system, that implies that no input or output are needed.

[2391] If a user has enough background awareness available to receive one type of feedback, the UI might:

[2392] Present a single light in the peripheral vision of a user. For example, this light can represent the amount of battery power available to the computing system. As the battery life weakens, the light gets dimmer. If the battery is recharging, the light gets stronger.

[2393] If a user has enough background awareness available to receive more than one type of feedback, the UI might:

[2394] Present a single light in the peripheral vision of the user that signifies available battery power and the sound of water to represent data connectivity.

[2395] If a user has full background awareness, then the UI might:

[2396] Present a single light in the peripheral vision of the user that signifies available battery power, the sound of water that represents data connectivity, and pressure on the skin to represent the amount of memory available to the computing system.

[2397] Task Switched Attention

[2398] When the user is engaged in more than one focus task, the user's attention can be considered to be task switched.

[2399] Example Task Switched Attention Characterization Values

[2400] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have any attention for a focus task/the user has full attention for a focus task.

[2401] Using these characteristics as the scale endpoints, the following list is an example of a task switched attention scale.

[2402] A user does not have any attention for a focus task.

[2403] A user does not have enough attention to complete a simple focus task. The time between focus tasks is long.

[2404] A user has enough attention to complete a simple focus task. The time between focus tasks is long.

[2405] A user does not have enough attention to complete a simple focus task. The time between focus tasks is moderately long.

[2406] A user has enough attention to complete a simple focus task. The time between tasks is moderately long.

[2407] A user does not have enough attention to complete a simple focus task. The time between focus tasks is short.

[2408] A user has enough attention to complete a simple focus task. The time between focus tasks is short.

[2409] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[2410] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[2411] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is moderately long.

[2412] A user has enough attention to complete a moderately complex focus task. The time between tasks is moderately long.

[2413] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[2414] A user has enough attention to complete a moderately complex focus task. The time between focus tasks is short.

[2415] A user does not have enough attention to complete a moderately complex focus task. The time between focus tasks is long.

[2416] A user has enough attention to complete a complex focus task. The time between focus tasks is long.

[2417] A user does not have enough attention to complete a complex focus task. The time between focus tasks is moderately long.

[2418] A user has enough attention to complete a complex focus task. The time between tasks is moderately long.

[2419] A user does not have enough attention to complete a complex focus task. The time between focus tasks is short.

[2420] A user has enough attention to complete a complex focus task. The time between focus tasks is short.

[2421] A user has enough attention to complete a very complex, multi-stage focus task before moving to a different focus task.

[2422] Parallel

[2423] Parallel attention can consist of focus tasks interspersed with routine tasks (focus task+routine task) or a series of routine tasks (routine task+routine task).

[2424] Example Parallel Attention Characterization Values

[2425] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: the user does not have enough attention for a parallel task/the user has full attention for a parallel task.

[2426] Using these characteristics as scale endpoints, the following list is an example of a parallel attention scale.

[2427] A user has enough available attention for one routine task and that task is not with the computing system.

[2428] A user has enough available attention for one routine task and that task is with the computing system.

[2429] A user has enough attention to perform two routine tasks and at least of the routine tasks is with the computing system.

[2430] A user has enough attention to perform a focus task and a routine task. At least one of the tasks is with the computing system.

[2431] A user has enough attention to perform three or more parallel tasks and at least one of those tasks is in the computing system.

[2432] Physical Availability

[2433] Physical availability is the degree to which a person is able to perceive and manipulate a device. For example, an airplane mechanic who is repairing an engine does not have hands available to input indications to the computing systems by using a keyboard.

[2434] Learning Profile

[2435] A user's learning style is based on their preference for sensory intake of information. That is, most users have a preference for which sense they use to assimilate new information.

[2436] Example Learning Style Characterization Values

[2437] This characterization is enumerated. The following list is an example of learning style characterization values.

[2438] Auditory

[2439] Visual

[2440] Tactile

[2441] Exemplary UI Design Implementation for Learning Style

[2442] The following list contains examples of UI design implementations for how the computing system might respond to a learning style.

[2443] If a user is a auditory learner, the UI might:

[2444] Present content to the user by using audio more frequently.

[2445] Limit the amount of information presented to a user if these is a lot of ambient noise.

[2446] If a user is a visual learner, the UI might:

[2447] Present content to the user in a visual format whenever possible.

[2448] Use different colors to group different concepts or ideas together.

[2449] Use illustrations, graphs, charts, and diagrams to demonstrate content when appropriate.

[2450] If a user is a tactile learner, the UI might:

[2451] Present content to the user by using tactile output.

[2452] Increase the affordance of tactile methods of input (e.g. increase the affordance of keyboards).

[2453] Software Accessibility

[2454] If an application requires a media-specific plug-in, and the user does not have a network connection, then a user might not be able to accomplish a task.

[2455] Example Software Accessibility Characterization Values

[2456] This characterization is enumerated. The following list is an example of software accessibility values.

[2457] The computing system does not have access to software.

[2458] The computing system has access to some of the local software resources.

[2459] The computing system has access to all of the local software resources.

[2460] The computing system has access to all of the local software resources and some of the remote software resources by availing itself to opportunistic user of software resources.

[2461] The computing system has access to all of the local software resources and all remote software resources by availing itself to the opportunistic user of software resources.

[2462] The computing system has access to all software resources that are local and remote.

[2463] Perception of Solitude

[2464] Solitude is a user's desire for, and perception of, freedom from input. To meet a user's desire for solitude, the UI can do things like:

[2465] Cancel unwanted ambient noise

[2466] Block out human made symbols generated by other humans and machines

[2467] Example Solitude Characterization Values

[2468] This characterization is scalar, with the minimum range being binary. Example binary values, or scalar endpoints, are: no solitude/complete solitude.

[2469] Using these characteristics as scale endpoints, the following list is an example of a solitude scale.

[2470] No solitude

[2471] Some solitude

[2472] Complete solitude

[2473] Privacy

[2474] Privacy is the quality or state of being apart from company or observation. It includes a user's trust of audience. For example, if a user doesn't want anyone to know that they are interacting with a computing system (such as a wearable computer), the preferred output device might be a head mounted display (HMD) and the preferred input device might be an eye-tracking device.

[2475] Hardware Affinity for Privacy

[2476] Some hardware suits private interactions with a computing system more than others. For example, an HMD is a far more private output device than a desk monitor. Similarly, an earphone is more private than a speaker.

[2477] The UI should choose the correct input and output devices that are appropriate for the desired level of privacy for the user's current context and preferences.

[2478] Example Privacy Characterization Values

[2479] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: not private/private, public/not public, and public/private.

[2480] Using no privacy and fully private as the scale endpoints, the following list is an example privacy characterization scale.

[2481] No privacy is needed for input or output interaction.

[2482] The input must be semi-private. The output does not need to be private.

[2483] The input must be fully private. The output does not need to be private.

[2484] The input must be fully private. The output must be semi-private.

[2485] The input does not need to be private. The output must be fully private.

[2486] The input does not need to be private. The output must be semi-private.

[2487] The input must be semi-private. The output must be semi-private.

[2488] The input and output interaction must be fully private.

[2489] Semi-private. The user and at least one other person can have access to or knowledge of the interaction between the user and the computing system.

[2490] Fully private. Only the user can have access to or knowledge of the interaction between the user and the computing system.

[2491] Exemplary UI Design Implementation for Privacy

[2492] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[2493] If no privacy is needed for input or output interaction:

[2494] The UI is not restricted to any particular I/O device for presentation and interaction. For example, the UI could present content to the user through speakers on a large monitor in a busy office.

[2495] If the input must be semi-private and if the output does not need to be private, the UI might:

[2496] Encourage the user to use coded speech commands or use a keyboard if one is available. There are no restrictions on output presentation.

[2497] If the input must be fully private and if the output does not need to be private, the UI might:

[2498] Not allow speech commands. There are no restrictions on output presentation.

[2499] If the input must be fully private and if the output needs to be semi-private, the UI might:

[2500] Not allow speech commands (allow only keyboard commands). Not allow an LCD panel and use earphones to provide audio response to the user.

[2501] If the output must be semi-private and if the input does not need to be private, the UI might:

[2502] Restrict users to an HMD device and/or an earphone for output. There are no restrictions on input interaction.

[2503] If the output must be semi-private and if the input does not need to be private, the UI might:

[2504] Restrict users to HMD devices, earphones, and/or LCD panels. There are no restrictions on input interaction.

[2505] If the input and output must be semi-private, the UI might:

[2506] Encourage the user to use coded speech commands and keyboard methods for input. Output may be restricted to HMD devices, earphones or LCD panels.

[2507] If the input and output interaction must be completely private, the UI might:

[2508] Not allow speech commands and encourage the user of keyboard methods of input. Output is restricted to HMD devices and/or earphones.

[2509] User Expertise

[2510] As the user becomes more familiar with the computing system or the UI, they may be able to navigate through the UI more quickly. Various levels of user expertise can be accommodated. For example, instead of configuring all the settings to make an appointment, users can recite all the appropriate commands in the correct order to make an appointment. Or users might be able to use shortcuts to advance or move back to specific screens in the UI. Additionally, expert users may not need as many prompts as novice users. The UI should adapt to the expertise level of the user.

[2511] Example User Expertise Characterization Values

[2512] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: new user/not new user, not an expert user/expert user, new user/expert user, and novice/expert.

[2513] Using novice and expert as scale endpoints, the following list is an example user expertise scale.

[2514] The user is new to the computing system and to computing in general.

[2515] The user is new to the computing system and is an intermediate computer user.

[2516] The user is new to the computing system, but is an expert computer user.

[2517] The user is an intermediate user in the computing system.

[2518] The user is an expert user in the computing system.

[2519] Exemplary UI Design Implementation for User Expertise

[2520] The following are characteristics of an exemplary audio UI design for novice and expert computer users.

[2521] The computing system speaks a prompt to the user and waits for a response.

[2522] If the user responds in x seconds or less, then the user is an expert. The computing system gives the user prompts only.

[2523] If the user responds in>x seconds, then the user is a novice and the computing system begins enumerating the choices available.

[2524] This type of UI design works well when more than 1 user accesses the same computing system and the computing system and the users do not know if they are a novice or an expert.

[2525] Language

[2526] User context may include language, as in the language they are currently speaking (e.g. English, German, Japanese, Spanish, etc.).

[2527] Example Language Characterization Values

[2528] This characteristic is enumerated. Example values include:

[2529] American English

[2530] British English

[2531] German

[2532] Spanish

[2533] Japanese

[2534] Chinese

[2535] Vietnamese

[2536] Russian

[2537] French

[2538] Computing System

[2539] This section describes attributes associated with the computing system that may cause a UI to change.

[2540] Computing hardware capability

[2541] For purposes of user interfaces designs, there are four categories of hardware:

[2542] Input/output devices

[2543] Storage (e.g. RAM)

[2544] Processing capabilities

[2545] Power supply

[2546] The hardware discussed in this topic can be the hardware that is always available to the computing system. This type of hardware is usually local to the user. Or the hardware could sometimes be available to the computing system. When a computing system uses resources that are sometimes available to it, this can be called an opportunistic use of resources.

[2547] Storage

[2548] Storage capacity refers to how much random access memory (RAM) is available to the computing system at any given moment. This number is not considered to be constant because the computing system might avail itself to the opportunistic use of memory.

[2549] Usually the user does not need to be aware of how much storage is available unless they are engaged in a task that might require more memory than to which they reliably have access. This might happen when the computing system engages in opportunistic use of memory. For example, if an in-motion user is engaged in a task that requires the opportunistic use of memory and that user decides to change location (e.g. they are moving from their vehicle to a utility pole where they must complete other tasks), the UI might warn the user that if they leave the current location, the computing system may not be able to complete the task or the task might not get completed as quickly.

[2550] Example Storage Characterization Values

[2551] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no RAM is available/all RAM is available.

[2552] Using no RAM is available and all RAM is available, the following table lists an example storage characterization scale.

Scale attribute                Implication
No RAM is available to the     If no RAM is available, there is
computing system.              no UI available.-Or-There is no
                               change to the UI.
Of the RAM available to the    The UI is restricted to the
computing system, only the     opportunistic use of RAM.
opportunistic use of RAM
is available.
Of the RAM that is available   The UI is restricted to using
to the computing system,       local RAM.
only the local RAM
is accessible
Of the RAM that is available   The UI might warn the user that if
to the computing system,       they lose opportunistic use of memory,
the local RAM is available     the computing system might not be able
and the user is about to       to complete the task, or the task might
lose opportunistic use of RAM. not be completed as quickly.
Of the total possible RAM      If there is enough memory
available to the computing     available to the computing system to
system, all of it is           fully function at a high level,
available.                     the UI may not need to inform the user.
                               If the user indicates to the
                               computing system that they want a
                               task completed that requires more
                               memory, the UI might
                               suggest that the user change locations
                               to take advantage of additional
                               opportunistic use of memory.

[2553] Processing Capabilities

[2554] Processing capabilities fall into two general categories:

[2555] Speed. The processing speed of a computing system is measured in megahertz (MHz). Processing speed can be reflected as the rate of logic calculation and the rate of content delivery. The more processing power a computing system has, the faster it can calculate logic and deliver content to the user.

[2556] CPU usage. The degree of CPU usage does not affect the UI explicitly. With current UI design, if the CPU becomes too busy, the UI Typically “freezes” and the user is unable to interact with the computing system. If the CPU usage is too high, the UI will change to accommodate the CPU capabilities. For example, if the processor cannot handle the demands, the UI can simplify to reduce demand on the processor.

[2557] Example Processing Capability Characterization Values

[2558] This UI characterization is scalar, with the minimum range being binary Example binary or scale endpoints are: no processing capability is available/all processing capability is available.

[2559] Using no processing capability is available and all processing capability as scale endpoints, the following table lists an example processing capability scale.

Scale attribute                  Implication
No processing power is           There is no change to the UI.
available to the computing system
The computing system has         The UI might be audio or text
access to a slower speed CPU.    only.
The computing system has         The UI might choose to use
access to a high speed CPU       video in the presentation instead of
                                 a still picture.
The computing system has         There are no restrictions on the
access to and control of all processing UI based on processing power.
power available to the computing
system.

[2560] Power Supply

[2561] There are two types of power supplies available to computing systems: alternating current (AC) and direct current (DC). Specific scale attributes for AC power supplies are represented by the extremes of the exemplary scale. However, if a user is connected to an AC power supply, it may be useful for the UI to warn an in-motion user when they're leaving an AC power supply. The user might need to switch to a DC power supply if they wish to continue interacting with the computing system while in motion. However, the switch from AC to DC power should be an automatic function of the computing system and not a function of the UI.

[2562] On the other hand, many computing devices, such as wearable personal computers (WPCs), laptops, and PDAs, operate using a battery to enable the user to be mobile. As the battery power wanes, the UI might suggest the elimination of video presentations to extend battery life. Or the UI could display a VU meter that visually demonstrates the available battery power so the user can implement their preferences accordingly.

[2563] Example Power Supply Characterization Values

[2564] This task characterization is binary if the power supply is AC and scalar if the power supply is DC. Example binary values are: no power/full power. Example scale endpoints are: no power/all power.

[2565] Using no power and full power as scale endpoints, the following list is an example power supply scale.

[2566] There is no power to the computing system.

[2567] There is an imminent exhaustion of power to the computing system.

[2568] There is an inadequate supply of power to the computing system.

[2569] There is a limited, but potentially inadequate supply of power to the computing system.

[2570] There is a limited but adequate power supply to the computing system.

[2571] There is an unlimited supply of power to the computing system.

[2572] Exemplary UI Design Implementations for Power Supply

[2573] The following list contains examples of UI design implementations for how the computing system might respond to a change in the power supply capacity.

[2574] If there is minimal power remaining in a battery that is supporting a computing system, the UI might:

[2575] Power down any visual presentation surfaces, such as an LCD.

[2576] Use audio output only.

[2577] If there is minimal power remaining in a battery and the UI is already audio-only, the UI might:

[2578] Decrease the audio output volume.

[2579] Decrease the number of speakers that receive the audio output or use earplugs only.

[2580] Use mono versus stereo output.

[2581] Decrease the number of confirmations to the user.

[2582] If there is, for example, six hours of maximum-use battery life available and the computing system determines that the user not have access to a different power source for 8 hours, the UI might:

[2583] Decrease the luminosity of any visual display by displaying line drawings instead of 3-dimensional illustrations.

[2584] Change the chrominance from color to black and white.

[2585] Refresh the visual display less often.

[2586] Decrease the number of confirmations to the user.

[2587] Use audio output only.

[2588] Decrease the audio output volume.

[2589] Computing Hardware Characteristics

[2590] The following is a list of some of the other hardware characteristics that may be influence what is an optimal UI design.

[2591] Cost

[2592] Waterproof

[2593] Ruggedness

[2594] Mobility

[2595] Again, there are other characteristics that could be added to this list. However, it is not possible to list all computing hardware attributes that might influence what is considered to be an optimal UI design until run time.

[2596] Bandwidth

[2597] There are different types of bandwidth, for instance:

[2598] Network bandwidth

[2599] Inter-device bandwidth

[2600] Network Bandwidth

[2601] Network bandwidth is the computing system's ability to connect to other computing resources such as servers, computers, printers, and so on. A network can be a local area network (LAN), wide area network (WAN), peer-to-peer, and so on. For example, if the user's preferences are stored at a remote location and the computing system determines that the remote resources will not always be available, the system might cache the user's preferences locally to keep the UI consistent. As the cache may consume some of the available RAM resources, the UI might be restricted to simpler presentations, such as text or audio only.

[2602] If user preferences cannot be cached, then the UI might offer the user choices about what UI design families are available and the user can indicate their design family preference to the computing system.

[2603] Example Network Bandwidth Characterization Values

[2604] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no network access/full network access.

[2605] Using no network access and full network access as scale endpoints, the following table lists an example network bandwidth scale.

Scale attribute                  Implication
The computing system does        The UI is restricted to using local
not have a connection to         computing resources only. If user
network resources.               preferences are stored remotely, then
                                 the UI might not account for user
                                 preferences.
The computing system has an      The UI might warn the user that
unstable connection to           the connection to remote resources
network resources.               might be interrupted. The UI might ask
                                 the user if they want to cache
                                 appropriate information to
                                 accommodate for the unstable
                                 connection to network resources.
The computing system has a       The UI might simplify, such as
slow connection to network       offer audio or text only, to
resources.                       accommodate for the slow connection.
                                 Or the computing system might cache
                                 appropriate data for the UI so the
                                 UI can always be optimized without
                                 restriction of the slow connection.
The computing system has a       In the present moment, the UI
high speed, yet limited (by time) does not have any restrictions based on
access to network resources.     access to network resources. If the
                                 computing system determines that
                                 it will lose a network connection,
                                 then the UI can warn the user
                                 and offer choices, such as does
                                 the user want to cache
                                 appropriate information, about what to
                                 do.
The computing system has a       There are no restrictions to the UI
very high-speed connection to    based on access to network resources.
network resources.               The UI can offer text, audio, video,
                                 haptic output, and so on.

[2606] Inter-device Bandwidth

[2607] Inter-device bandwidth is the ability of the devices that are local to the user to communicate with each other. Inter-device bandwidth can affect the UI in that if there is low inter-device bandwidth, then the computing system cannot compute logic and deliver content as quickly. Therefore, the UI design might be restricted to a simpler interaction and presentation, such as audio or text only. If bandwidth is optimal, then there are no restrictions on the UI based on bandwidth. For example, the UI might offer text, audio, and 3-D moving graphics if appropriate for the user's context.

[2608] Example Inter-Device Bandwidth Characterization Values

[2609] This UI characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: no inter-device bandwidth/full inter-device bandwidth.

[2610] Using no inter-device bandwidth and full inter-device bandwidth as scale endpoints, the following table lists an example inter-device bandwidth scale.

Scale attribute                 Implication
The computing system does not   Input and output is restricted to
have inter-device connectivity. each of the disconnected devices. The
                                UI is restricted to the capability of each
                                device as a stand-alone device.
Some devices have connectivity  It depends
and others do not.
The computing system has slow   The task that the user wants to
inter-device bandwidth.         complete might require more
                                bandwidth that is available among
                                devices. In this case, the UI can offer
                                the user a choice. Does the user want
                                to continue and encounter slow
                                performance? Or, does the user want
                                to acquire more bandwidth by moving
                                to a different location and taking
                                advantage of opportunistic use of
                                bandwidth?
The computing system has fast   There are few, if any,
inter-device bandwidth.         restrictions on the interaction and
                                presentation between the user and the
                                computing system. The UI sends a
                                warning message only if there is not
                                enough bandwidth between devices.
The computing system has very   There are no restrictions on the
high-speed inter-device         UI based on inter-device connectivity.
connectivity.

[2611] Context Availability

[2612] Context availability is related to whether the information about the model of the user context is accessible. If the information about the model of the context is intermittent, deemed inaccurate, and so on, then the computing system might not have access to the user's context.

[2613] Example Context Availability Characterization Values

[2614] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: context not available/context available.

[2615] Using context not available and context available as scale endpoints, the following list is an example context availability scale.

[2616] No context is available to the computing system

[2617] Some of the user's context is available to the computing system.

[2618] A moderate amount of the user's context is available to the computing system.

[2619] Most of the user's context is available to the computing system.

[2620] All of the user's context is available to the computing system

[2621] Exemplary UI Design for Context Availability

[2622] The following list contains examples of UI design implementations for how the computing system might respond to a change in context availability.

[2623] If the information about the model of context is intermittent, deemed inaccurate, or otherwise unavailable, the UI might:

[2624] Stay the same.

[2625] Ask the user if the UI needs to change.

[2626] Infer a UI from a previous pattern if the user's context history is available.

[2627] Change the UI based on all other attributes except for user context (e.g. I/O device availability, privacy, task characteristics, etc.)

[2628] Use a default UI.

[2629] Opportunistic Use of Resources

[2630] Some UI components, or other enabling UI content, may allow acquisition from outside sources. For example, if a person is using a wearable computer and they sit at a desk that has a monitor on it, the wearable computer might be able to use the desktop monitor as an output device.

[2631] Example Opportunistic Use of Resources Characterization Scale

[2632] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints, are: no opportunistic use of resources/use of all opportunistic resources.

[2633] Using these characteristics, the following list is an example of an opportunistic use of resources scale.

[2634] The circumstances do not allow for the opportunistic use of resources in the computing system.

[2635] Of the resources available to the computing system, there is a possibility to make opportunistic use of resources.

[2636] Of the resources available to the computing system, the computing system can make opportunistic use of most of the resources.

[2637] Of the resources available to the computing system, all are accessible and available.

[2638] Content

[2639] Content is defined as information or data that is part of or provided by a task. Content, in contrast to UI elements, does not serve a specific role in the user/computer dialog. It provides informative or entertaining information to the user. It is not a control. For example a radio has controls (knobs, buttons) used to choose and format (tune a station, adjust the volume & tone) of broadcasted audio content.

[2640] Sometimes content has associated metadata, but it is not necessary.

[2641] Example content characterization values

[2642] This characterization is enumerated. Example values include:

[2643] Quality

[2644] Static/streamlined

[2645] Passive/interactive

[2646] Type

[2647] Output device required

[2648] Output device affinity

[2649] Output device preference

[2650] Rendering software

[2651] Implicit. The computing system can use characteristics that can be inferred from the information itself, such as message characteristics for received messages.

[2652] Source. A type or instance of carrier, media, channel or network path

[2653] Destination. Address used to reach the user (e.g., a user typically has multiple address, phone numbers, etc.)

[2654] Message content. (parseable or described in metadata)

[2655] Data format type.

[2656] Arrival time.

[2657] Size.

[2658] Previous messages. Inference based on examination of log of actions on similar messages.

[2659] Explicit. Many message formats explicitly include message-characterizing information, which can provide additional filtering criteria.

[2660] Title.

[2661] Originator identification. (e.g., email author)

[2662] Origination date & time

[2663] Routing. (e.g., email often shows path through network routers)

[2664] Priority

[2665] Sensitivity. Security levels and permissions

[2666] Encryption type

[2667] File format. Might be indicated by file name extension

[2668] Language. May include preferred or required font or font type

[2669] Other recipients (e.g., email cc field)

[2670] Required software

[2671] Certification. A trusted indication that the offer characteristics are dependable and accurate.

[2672] Recommendations. Outside agencies can offer opinions on what information may be appropriate to a particular type of user or situation.

[2673] Security

[2674] Controlling security is controlling a user's access to resources and data available in a computing system. For example when a user logs on a network, they must supply a valid user name and password to gain access to resource on the network such as, applications, data, and so on.

[2675] In this sense, security is associated with the capability of a user or outside agencies in relation to a user's data or access to data, and does not specify what mechanisms are employed to assure the security.

[2676] Security mechanisms can also be separately and specifically enumerated with characterizing attributes.

[2677] Permission is related to security. Permission is the security authorization presented to outside people or agencies. This characterization could inform UI creation/selection by giving a distinct indication when the user is presented information that they have given permission to others to access.

[2678] Example Security Characterization Values

[2679] This characteristic is scalar, with the minimum range being binary. Example binary values, or scale endpoints are: no authorized user access/all user access, no authorized user access/public access, and no public access/public access.

[2680] Using no authorized user access and public access as scale endpoints, the following list is an example security scale.

[2681] No authorized access.

[2682] Single authorized user access.

[2683] Authorized access to more than one person

[2684] Authorized access for more than one group of people

[2685] Public access

[2686] Single authorized user only access. The only person who has authorized access to the computing system is a specific user with valid user credentials.

[2687] Public access. There are no restrictions on who has access to the computing system. Anyone and everyone can access the computing system.

[2688] Task Characterizations

[2689] A task is a user-perceived objective comprising steps. The topics in this section enumerate some of the important characteristics that can be used to describe tasks. In general, characterizations are needed only if they require a change in the UI design.

[2690] The topics in this section include examples of task characterizations, example characterization values, and in some cases, example UI designs or design characteristics.

[2691] Task Length

[2692] Whether a task is short or long depends upon how long it takes a target user to complete the task. That is, a short task takes a lesser amount of time to complete than a long task. For example, a short task might be creating an appointment. A long task might be playing a game of chess.

[2693] Example Task Length Characterization Values

[2694] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: short/not short, long/not long, or short/long.

[2695] Using short/long as scale endpoints, the list is an example task length scale.

[2696] The task is very short and can be completed in 30 seconds or less

[2697] The task is moderately short and can be completed in 31-60 seconds.

[2698] The task is short and can be completed in 61-90 seconds.

[2699] The task is slightly long and can be completed in 91-300 seconds.

[2700] The task is moderately long and can be completed in 301-1,200 seconds.

[2701] The task is long and can be completed in 1,201-3,600 seconds.

[2702] The task is very long and can be completed in 3,601 seconds or more.

[2703] Task Complexity

[2704] Task complexity is measured using the following criteria:

[2705] Number of elements in the task. The greater the number of elements, the more likely the task is complex.

[2706] Element interrelation. If the elements have a high degree of interrelation, then the more likely the task is complex.

[2707] User knowledge of structure. If the structure, or relationships, between the elements in the task is unclear, then the more likely the task is considered to be complex.

[2708] If a task has a large number of highly interrelated elements and the relationship between the elements is not known to the user, then the task is considered to be complex. On the other hand, if there are a few elements in the task and their relationship is easily understood by the user, then the task is considered to be well-structured. Sometimes a well-structured task can also be considered simple.

[2709] Example Task Complexity Characterization Values

[2710] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: simple/not simple, complex/not complex, simple/complex, well-structured/not well-structured, or well-structured/complex.

[2711] Using simple/complex as scale endpoints, the list is an example task complexity scale.

[2712] There is one, very simple task composed of 1-5 interrelated elements whose relationship is well understood.

[2713] There is one simple task composed of 6-10 interrelated elements whose relationship is understood.

[2714] There is more than one very simple task and each task is composed of 1-5 elements whose relationship is well understood.

[2715] There is one moderately simple task composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[2716] There is more than one simple task and each task is composed of 6-10 interrelated whose relationship is understood by the user.

[2717] There is one somewhat simple task composed of 16-20 interrelated elements whose relationship is understood by the user.

[2718] There is more than one moderately simple task and each task is composed of 11-15 interrelated elements whose relationship is 80-90% understood by the user.

[2719] There is one complex task complex task composed of 21-35 interrelated elements whose relationship is 60-79% understood by the user.

[2720] There is more than one somewhat complex task and each task is composed of 16-20 interrelated elements whose relationship is understood by the user.

[2721] There is one moderately complex task composed of 36-50 elements whose relationship is 80-90% understood by the user.

[2722] There is more than one complex task and each task is composed of 21-35 elements whose relationship is 60-79% understood by the user.

[2723] There is one very complex task composed of 51 or more elements whose relationship is 40-60% understood by the user.

[2724] There is more than one complex task and each task is composed of 36-50 elements whose relationship is 40-60% understood by the user.

[2725] There is more than one very complex task and each part is composed of 51 or more elements whose relationship is 20-40% understood by the user.

[2726] Exemplary UI Design Implementation for Task Complexity

[2727] The following list contains examples of UI design implementations for how the computing system might respond to a change in task complexity.

[2728] For a task that is long and simple (well-structured), the UI might:

[2729] Give prominence to information that could be used to complete the task.

[2730] Vary the text-to-speech output to keep the user's interest or attention.

[2731] For a task that is short and simple, the UI might:

[2732] Optimize to receive input from the best device. That is, allow only input that is most convenient for the user to use at that particular moment.

[2733] If a visual presentation is used, such as an LCD panel or monitor, prominence may be implemented using visual presentation only.

[2734] For a task that is long and complex, the UI might:

[2735] Increase the orientation to information and devices

[2736] Increase affordance to pause in the middle of a task. That is, make it easy for a user to stop in the middle of the task and then return to the task.

[2737] For a task that is short and complex, the UI might:

[2738] Default to expert mode.

[2739] Suppress elements not involved in choices directly related to the current task.

[2740] Change modality

[2741] Task Familiarity

[2742] Task familiarity is related to how well acquainted a user is with a particular task. If a user has never completed a specific task, they might benefit from more instruction from the computing environment than a user who completes the same task daily. For example, the first time a car rental associate rents a car to a consumer, the task is very unfamiliar. However, after about a month, the car rental associate is very familiar with renting cars to consumers.

[2743] Example Task Familiarity Characterization Values

[2744] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: familiar/not familiar, not unfamiliar/unfamiliar, and unfamiliar/familiar.

[2745] Using unfamiliar and familiar as scale endpoints, the list is an example task familiarity scale.

[2746] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 1.

[2747] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 2.

[2748] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 3.

[2749] On a scale of I to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 4.

[2750] On a scale of 1 to 5, where one is very unfamiliar and 5 is very familiar, the task familiarity rating is 5.

[2751] Exemplary UI Design Implementation for Task Familiarity

[2752] The following list contains examples of UI design implementations for how the computing system might respond to a change in task familiarity.

[2753] For a task that is unfamiliar, the UI might:

[2754] Increase task orientation to provide a high level schema for the task.

[2755] Offer detailed help.

[2756] Present the task in a greater number of steps.

[2757] Offer more detailed prompts.

[2758] Provide information in as many modalities as possible.

[2759] For a task that is familiar, the UI might:

[2760] Decrease the affordances for help

[2761] Offer summary help

[2762] Offer terse prompts

[2763] Decrease the amount of detail given to the user

[2764] Use auto-prompt and auto-complete (that is, make suggestions based on past choices made by the user).

[2765] The ability to barge ahead is available.

[2766] Use user-preferred modalities.

[2767] Task Sequence

[2768] A task can have steps that must be performed in a specific order. For example, if a user wants to place a phone call, the user must dial or send a phone number before they are connected to and can talk with another person. On the other hand, a task, such as searching the Internet for a specific topic, can have steps that do not have to be performed in a specific order.

[2769] Example Task Sequence Characterization Values

[2770] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: scripted/not scripted, nondeterministic/not nondeterministic, or scripted/nondeterministic.

[2771] Using scripted/nondeterministic as scale endpoints, the following list is an example task sequence scale.

[2772] The each step in the task is completely scripted.

[2773] The general order of the task is scripted. Some of the intermediary steps can be performed out of order.

[2774] The first and last steps of the task are scripted. The remaining steps can be performed in any order.

[2775] The steps in the task do not have to be performed in any order.

[2776] Exemplary UI Design Implementation for Task Sequence

[2777] The following list contains examples of UI design implementations for how the computing system might respond to a change in task sequence.

[2778] For a task that is scripted, the UI might:

[2779] Present only valid choices.

[2780] Present more information about a choice so a user can understand the choice thoroughly.

[2781] Decrease the prominence or affordance of navigational controls.

[2782] For a task that is nondeterministic, the UI might:

[2783] Present a wider range of choices to the user.

[2784] Present information about the choices only upon request by the user.

[2785] Increase the prominence or affordance of navigational controls

[2786] Task Independence

[2787] The UI can coach a user though a task or the user can complete the task without any assistance from the UI. For example, if a user is performing a safety check of an aircraft, the UI can coach the user about what questions to ask, what items to inspect, and so on. On the other hand, if the user is creating an appointment or driving home, they might not need input from the computing system about how to successfully achieve their objective.

[2788] Example Task Independence Characterization Values

[2789] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: coached/not coached, not independently executed/independently executed, or coached/independently executed.

[2790] Using coached/independently executed as scale endpoints, the following list is an example task guidance scale.

[2791] Each step in the task is completely scripted.

[2792] The general order of the task is scripted. Some of the intermediary steps can be performed out of order.

[2793] The first and last steps of the task are scripted. The remaining steps can be performed in any order.

[2794] The steps in the task do not have to be performed in any order.

[2795] Task Creativity

[2796] A formulaic task is a task in which the computing system can precisely instruct the user about how to perform the task. A creative task is a task in which the computing system can provide general instructions to the user, but the user uses their knowledge, experience, and/or creativity to complete the task. For example, the computing system can instruct the user about how to write a sonnet. However, the user must ultimately decide if the combination of words is meaningful or poetic.

[2797] Example Task Creativity Characterization Values

[2798] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints could be defined as formulaic/not formulaic, creative/not creative, or formulaic/creative.

[2799] Using formulaic and creative as scale endpoints, the following list is an example task creativity scale.

[2800] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 1.

[2801] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 2.

[2802] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 3.

[2803] On a scale of 1 to five, where I is formulaic and 5 is creative, the task creativity rating is 4.

[2804] On a scale of 1 to five, where 1 is formulaic and 5 is creative, the task creativity rating is 5.

[2805] Software Requirements

[2806] Tasks can be intimately related to software requirements. For example, a user cannot create a complicated database without software.

[2807] Example Software Requirements Characterization Values

[2808] This task characterization is enumerated. Example values include:

[2809] JPEG viewer

[2810] PDF reader

[2811] Microsoft Word

[2812] Microsoft Access

[2813] Microsoft Office

[2814] Lotus Notes

[2815] Windows NT 4.0

[2816] Mac OS 10

[2817] Task Privacy

[2818] Task privacy is related to the quality or state of being apart from company or observation. Some tasks have a higher level of desired privacy than others. For example, calling a physician to receive medical test results has a higher level of privacy than making an appointment for a meeting with a co-worker.

[2819] Example Task Privacy Characterization Values

[2820] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are: private/not private, public/not public, or private/public.

[2821] Using private/public as scale endpoints, the following table is an example task privacy scale.

[2822] The task is not public. Anyone can have knowledge of the task.

[2823] The task is semi-private. The user and at least one other person have knowledge of the task.

[2824] The task is fully private. Only the user can have knowledge of the task.

[2825] Hardware Requirements

[2826] A task can have different hardware requirements. For example, talking on the phone requires audio input and output while entering information into a database has an affinity for a visual display surface and a keyboard.

[2827] Example Hardware Requirements Characterization Values

[2828] This task characterization is enumerated. Example values include:

[2829] 10 MB available of storage

[2830] 1 hour of power supply

[2831] A free USB connection

[2832] Task Collaboration

[2833] A task can be associated with a single user or more than one user. Most current computer-assisted tasks are designed as single-user tasks. Examples of collaborative computer-assisted tasks include participating in a multi-player video game or making a phone call.

[2834] Example Task Collaboration Characterization Values

[2835] This task characterization is binary. Example binary values are single user/collaboration.

[2836] Task Relation

[2837] A task can be associated with other tasks, people, applications, and so on. Or a task can stand alone on it's own.

[2838] Example Task Relation Characterization Values

[2839] This task characterization is binary. Example binary values are unrelated task/related task.

[2840] Task Completion

[2841] There are some tasks that must be completed once they are started and others that do not have to be completed. For example, if a user is scuba diving and is using a computing system while completing the task of decompressing, it is essential that the task complete once it is started. To ensure the physical safety of the user, the software must maintain continuous monitoring of the user's elapsed time, water pressure, and air supply pressure/quantity. The computing system instructs the user about when and how to safely decompress. If this task is stopped for any reason, the physical safety of the user could be compromised.

[2842] Example Task Completion Characterization Values

[2843] This task characterization is enumerated. Example values are:

[2844] Must be completed

[2845] Does not have to be completed

[2846] Can be paused

[2847] Not known

[2848] Task Priority

[2849] Task priority is concerned with order. The order may refer to the order in which the steps in the task should be completed or order may refer to the order in which a series of tasks should be performed. This task characteristic is scalar. Tasks can be characterized with a priority scheme, such as (beginning at low priority) entertainment, convenience, economic/personal commitment, personal safety, personal safety and the safety of others. Task priority can be defined as giving one task preferential treatment over another. Task priority is relative to the user. For example, “all calls from mom” may be a high priority for one user, but not another user.

[2850] Example Task Privacy Characterization Values

[2851] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are no priority/high priority.

[2852] Using no priority and high priority as scale endpoints, the following list is an example task priority scale.

[2853] The current task is not a priority. This task can be completed at any time.

[2854] The current task is a low priority. This task can wait to be completed until the highest priority, high priority, and moderately high priority tasks are completed.

[2855] The current task is moderately high priority. This task can wait to be completed until the highest priority and high priority tasks are addressed.

[2856] The current task is high priority. This task must be completed immediately after the highest priority task is addressed.

[2857] The current task is of the highest priority to the user. This task must be completed first.

[2858] Task Importance

[2859] Task importance is the relative worth of a task to the user, other tasks, applications, and so on. Task importance is intrinsically associated with consequences. For example, a task has higher importance if very good or very bad consequences arise if the task is not addressed. If few consequences are associated with the task, then the task is of lower importance.

[2860] Example Task Importance Characterization Values

[2861] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not important/very important.

[2862] Using not important and very important as scale endpoints, the following list is an example task importance scale.

[2863] The task in not important to the user. This task has an importance rating of “1.”

[2864] The task is of slight importance to the user. This task has an importance rating of “2.”

[2865] The task is of moderate importance to the user. This task has an importance rating of “3.”

[2866] The task is of high importance to the user. This task has an importance rating of “4.”

[2867] The task is of the highest importance to the user. This task has an importance rating of “5.”

[2868] Task Urgency

[2869] Task urgency is related to how immediately a task should be addressed or completed. In other words, the task is time dependent. The sooner the task should be completed, the more urgent it is.

[2870] Example Task Urgency Characterization Values

[2871] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are not urgent/very urgency.

[2872] Using not urgent and very urgent as scale endpoints, the following list is an example task urgency scale.

[2873] A task is not urgent. The urgency rating for this task is “1.”

[2874] A task is slightly urgent. The urgency rating for this task is “2.”

[2875] A task is moderately urgent. The urgency rating for this task is “3.”

[2876] A task is urgent. The urgency rating for this task is “4.”

[2877] A task is of the highest urgency and requires the user's immediate attention. The urgency rating for this task is “5.”

[2878] Exemplary UI Design Implementation for Task Urgency

[2879] The following list contains examples of UI design implementations for how the computing system might respond to a change in task urgency.

[2880] If the task is not very urgent (e.g. a task urgency rating of 1, using the scale from the previous list), the UI might not indicate task urgency.

[2881] If the task is slightly urgent (e.g. a task urgency rating of 2, using the scale from the previous list), and if the user is using a head mounted display (HMD), the UI might blink a small light in the peripheral vision of the user.

[2882] If the task is moderately urgent (e.g. a task urgency rating of 3, using the scale from the previous list), and if the user is using an HMD, the UI might make the light that is blinking in the peripheral vision of the user blink at a faster rate.

[2883] If the task is urgent, (e.g. a task urgency rating of 4, using the scale from the previous list), and if the user is wearing an HMD, two small lights might blink at a very fast rate in the peripheral vision of the user.

[2884] If the task is very urgent, (e.g. a task urgency rating of 5, using the scale from the previous list), and if the user is wearing an HMD, three small lights might blink at a very fast rate in the peripheral vision of the user. In addition, a notification is sent to the user's direct line of sight that warns the user about the urgency of the task. An audio notification is also presented to the user.

[2885] Task Concurrency

[2886] Mutually exclusive tasks are tasks that cannot be completed at the same time while concurrent tasks can be completed at the same time. For example, a user cannot interactively create a spreadsheet and a word processing document at the same time. These two tasks are mutually exclusive. However, a user can talk on the phone and create a spreadsheet at the same time.

[2887] Example Task Concurrency Characterization Values

[2888] This task characterization is binary. Example binary values are mutually exclusive and concurrent.

[2889] Task Continuity

[2890] Some tasks can have their continuity or uniformity broken without comprising the integrity of the task, while other cannot be interrupted without compromising the outcome of the task. The degree to which a task is associated with saving or preserving human life is often associated with the degree to which it can be interrupted. For example, if a physician is performing heart surgery, their task of performing heart surgery is less interruptible than the task of making an appointment.

[2891] Example Task Continuity Characterization Values

[2892] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are interruptible/not interruptible or abort/pause.

[2893] Using interruptible/not interruptible as scale endpoints, the following list is an example task continuity scale.

[2894] The task cannot be interrupted.

[2895] The task can be interrupted for 5 seconds at a time or less.

[2896] The task can be interrupted for 6-15 seconds at a time .

[2897] The task can be interrupted for 16-30 seconds at a time.

[2898] The task can be interrupted for 31-60 seconds at a time.

[2899] The task can be interrupted for 61-90 seconds at a time.

[2900] The task can be interrupted for 91-300 seconds at a time.

[2901] The task can be interrupted for 301-1,200 seconds at a time.

[2902] The task can be interrupted 1,201-3,600 seconds at a time.

[2903] The task can be interrupted for 3,601 seconds or more at a time.

[2904] The task can be interrupted for any length of time and for any frequency.

[2905] Cognitive Load

[2906] Cognitive load is the degree to which working memory is engaged in processing information. The more working memory is used, the higher the cognitive load. Cognitive load encompasses the following two facets: cognitive demand and cognitive availability.

[2907] Cognitive demand is the number of elements that a user processes simultaneously. To measure the user's cognitive load, the system can combine the following three metrics: number of elements, element interaction, and structure. Cognitive demand is increased by the number of elements intrinsic to the task. The higher the number of elements, the more likely the task is cognitively demanding. Second, cognitive demand is measured by the level of interrelation between the elements in the task. The higher the inter-relation between the elements, the more likely the task is cognitively demanding. Finally, cognitive load is measured by how well revealed the relationship between the elements is. If the structure of the elements is known to the user or if it's easily understood, then the cognitive demand of the task is reduced.

[2908] Cognitive availability is how much attention the user engages in during the computer-assisted task. Cognitive availability is composed of the following:

[2909] Expertise. This includes schema and whether or not it is in long term memory

[2910] The ability to extend short term memory.

[2911] Distraction. A non-task cognitive demand.

[2912] How Cognitive Load Relates to Other Attributes

[2913] Cognitive load relates to at least the following attributes:

[2914] Learner expertise (novice/expert). Compared to novices, experts have an extensive schemata of a particular set of elements and have automaticity, the ability to automatically understand a class of elements while devoting little to no cognition to the classification. For example, a novice reader must examine every letter of the word that they're trying to read. On the other hand, an expert reader has built a schema so that elements can be “chunked” into groups and accessed as a group rather than a single element. That is, an expert reader can consume paragraphs of text at a time instead of examining each letter.

[2915] Task familiarity (unfamiliar/familiar). When a novice and an expert come across an unfamiliar task, each will handle it differently. An expert is likely to complete the task either more quickly or successfully because they access schemas that they already have and use those to solve the problem/understand the information. A novice may spend a lot of time developing a new schema to understand the information/solve the problem.

[2916] Task complexity (simple/complex or well-structured/complex). A complex task is a task whose structure is not well-known. There are many elements in the task and the elements are highly interrelated. The opposite of a complex task is well-structured. An expert is well-equipped to deal with complex problems because they have developed habits and structures that can help them decompose and solve the problem.

[2917] Task length (short/long). This relates to how much a user has to retain in working memory.

[2918] Task creativity. (formulaic/creative) How well known is the structure of the interrelation between the elements?

[2919] Example Cognitive Demand Characterization Values

[2920] This task characterization is scalar, with the minimum range being binary. Example binary values or scale endpoints are cognitively undemanding/cognitively demanding.

[2921] Exemplary UI Design Implementation for Cognitive Load

[2922] A UI design for cognitive load is influenced by a tasks intrinsic and extrinsic cognitive load. Intrinsic cognitive load is the innate complexity of the task and extrinsic cognitive load is how the information is presented. If the information is presented well (e.g. the schema of the interrelation between the elements is revealed), it reduces the overall cognitive load.

[2923] The following list contains examples of UI design implementations for how the computing system might respond to a change cognitive load.

[2924] Present information to the user by using more than one channel. For example, present choices visually to the user, but use audio for prompts.

[2925] Use a visual presentation to reveal the relationships between the elements. For example if a family tree is revealed, use colors and shapes to represent male and female members of the tree or shapes and colors can be used to represent different family units.

[2926] Reduce the redundancy. For example, if the structure of the elements is revealed visually, do not use audio to explain the same structure to the user.

[2927] Keep complementary or associated information together. For example, if creating a dialog box so a user can print, create a button that has the word “Print” on it instead of a dialog box that has a question “Do you want to print?” with a button with the work “OK” on it.

[2928] Task Alterability

[2929] Some task can be altered after they are completed while others cannot be changed. For example, if a user moves a file to the Recycle Bin, they can later retrieve the file. Thus, the task of moving the file to the Recycle Bin is alterable. However, if the user deletes the file from the Recycle Bin, they cannot retrieve it at a later time. In this situation, the task is irrevocable.

[2930] Example Task Alterability Characterization Values

[2931] This task characterization is binary, with the minimum range being binary. Example binary values or scale endpoints are alterable/not alterable, irrevocable/revocable, or alterable/irrevocable.

[2932] Task Content Type

[2933] This task characteristic describes the type of content to be used with the task. For example, text, audio, video, still pictures, and so on.

[2934] Example Content Type Characteristics Values

[2935] This task characterization is an enumeration. Some example values are:

[2936] asp

[2937] .jpeg

[2938] .avi

[2939] .jpg

[2940] .bmp

[2941] .jsp

[2942] .gif

[2943] .php

[2944] .htm

[2945] .txt

[2946] .html

[2947] .wav

[2948] .doc

[2949] .xls

[2950] .mdb

[2951] .vbs

[2952] .mpg

[2953] Again, this list is meant to be illustrative, not exhaustive.

[2954] Task Type

[2955] A task can be performed in many types of situations. For example, a task that is performed in an augmented reality setting might be presented differently to the user than the same task that is executed in a supplemental setting.

[2956] Example Task Type Characteristics Values

[2957] This task characterization is an enumeration. Example values can include:

[2958] Supplemental

[2959] Augmentative

[2960] Mediated

[2961] 3003 : Compare UI Designs with UI Needs

[2962] 3003 in FIG. 7 describes how to match an optimal UI characterization with a UI design characterization, as shown by the double-headed arrow in FIG. 1. First, the UI design characterizations are compared to the optimal UI characterizations (3004). This can be done, for example, by assembling the sets of characterizations into rows and columns of a look-up table. The following is a simple example of such a lookup table. The rows correspond to the UI design characterizations and the columns correspond to the UI needs characterizations.

		Output	Cognitive
Design	Input device	device	load	Privacy	Safety
A	1	2	3	4
B	1	3	2	2
C	2	1	1	1

[2963] In FIG. 7, if there is not at least one match in the look-up table, then the closest match is chosen (3005). If there is more than one match, then the best match is selected (3006). Once the match is made, it is sent to the computing system (3007).

[2964] 3004 : Assembling UI Designs and UI Needs

[2965] As mentioned previously, this step of the process compares available UI design characterizations to UI needs characterizations. This can be done by matching XML metadata, numeric key metadata (such as values of a binary bit field), or assembling said metadata into rows and columns in a look-up table to determine if there is a match.

[2966] If there is a match, the request for that particular UI design is sent to the computing system and the UI changes.

[2967] 3005 : Closest Match

[2968] If there is no match for the current UI design, then the closest match is chosen. This section describes two ways to make the closest match:

[2969] Using a weighted matching index.

[2970] Creating explicit rules or logic

[2971] Weighted Matching Index

[2972] In this embodiment, the optimal UI needs and UI design characterizations are assembled into a look-up table in 3004. If there is no match in the lookup table, then the characterizations of the current UI needs are weighted against the available UI designs and then the closest match is chosen. FIG. 8 shows how this is done.

[2973] In FIG. 8, a weight is assigned to a particular characteristic or characteristics (4001, 4002, 4003, 4004). If the characterization in a design matches a UI design requirement, then the weighted number is added to the total. If a UI design characterization does not match a UI design requirement, then no value is added. For example, in the FIG. 8, the weighted matching index value for design A is “21.” The logic used to determine this value is as follows:

[2974] If A(Input device) matches the first UI design requirement characterization value, then add 8. If it does not match, then do not add any value.

[2975] If A(Cognitive load) matches the cognitive load UI design requirement characterization value, then add 3. If there is no match, then do not add any value.

[2976] If A(Privacy) matches the Privacy UI design requirement characterization value, then add 10. If there is no match, then do not add any value.

[2977] However, there are times when some characteristics override all others. FIG. 9 shows an example of such a situation.

[2978] In FIG. 9, even though attributes 5001, 5002, and 5003 do not match any available designs, 4004 matches the Safety characterization for design D. In this case, the logic used is as follows.

[2979] If A(Input device) matches the first UI design requirement characterization value, then add 8. If it does not match, then do not add any value.

[2980] If A(Cognitive load) matches the cognitive load UI design requirement characterization value, then add 3. If there is no match, then do not add any value.

[2981] If A(Privacy) matches the Privacy UI design requirement characterization value, then add 10. If there is no match, then do not add any value.

[2982] If A(Safety) matches the Safety UI design requirement characterization value, then choose design D.

[2983] The values for Input device, Cognitive load, Privacy, and Safety are determined by whether or not the characteristics are desirable, supplemental, or necessary. If a characteristic is necessary, then is gets a high weighted value. If a characteristic is desirable, then it gets next highest weighted value. If a characteristic is supplemental, then it gets the least amount of weight. In FIG. 8, 4004 is a necessary characteristic, 4001 and 4003 are desired characteristics, and 4002 is a supplemental characteristic.

[2984] Explicit Rules

[2985] Explicit rules can be implements before (pre-matching logic), during (rules), or after (post-matching logic) the UI design choice is made.

[2986] Pre-Matching Logic

[2987] The following is an example of pre-matching logic that can be applied to a look-up table to decrease the number of possible rows and/or columns in the table.

[2988] If personal risk is>moderate, then

[2989] If activity driving, then choose design D, else

[2990] If activity=sitting, then choose design B, else

[2991] Rules

[2992] The following is an example of an explicit rule that can be applied to a look-up table.

[2993] If Need=(Audio (Y)+Safety (high)), then choose only design B12.

[2994] Note: In this example, design B12 is the “Audio safety UI.”

[2995] Post-Matching Logic

[2996] At this step in the process, the computing system can verify with a user whether the choice is appropriate. This is optional. Example logic includes:

[2997] If the design has not been previously used, then verify with user.

[2998] 3006 : Selecting the Best Match

[2999] There are two types of multiple matches. There are conditions in which more than one design is potentially suitable for a context characterization. Similarly, there are conditions in which a single UI design is suitable for more than one context characterization.

[3000] UI Family Match

[3001] If a context characterization has more than one UI design match (e.g. there are multiple UI characterizations that match a context characterization), then the UI that is in the same UI family is chosen. UI family membership is part of the metadata that characterizes a UI design.

[3002] Non UI Family Match

[3003] If none of the matches are in the same UI family, then the same mechanisms as described above can be used (weighted matching index, explicit logic, pre-matching logic, and post-matching logic.

[3004] In FIG. 10, design D is the design of choice due to the following logic:

[3005] If A(Input device) matches the first UI design requirement characterization value, then add 8. If it does not match, then do not add any value.

[3006] If A(Cognitive load) matches the cognitive load UI design requirement characterization value, then add 3. If there is no match, then do not add any value.

[3007] If A(Privacy) matches the Privacy UI design requirement characterization value, then add 10. If there is no match, then do not add any value.

[3008] If A(Safety) matches the Safety UI design requirement characterization value, then choose design D, regardless of other characterization value matches.

[3009] Dynamically Optimizing Computer UIS

[3010] By characterizing the function of user interface independently from its presentation and interaction with a broad set of attributes related to the changing needs of the user, in particularly to their changing contexts, a computer can make use of the various methods for optimizing a UI. These methods include the modification of:

[3011] Prominence—conspicuousness of a UI element.

[3012] Association—he indication of relationship between UI elements through similarity or grouping.

[3013] Metaphor

[3014] Sensory Analogy

[3015] Background Awareness

[3016] Invitation—Creating a sense of enticement or allurement to engage in interaction with a UI element(s).

[3017] Safety—A computer can enhance the safety of the user by either providing or emphasizing information that identifies real or potential danger or suggests a course of action that would allow the user to avoid danger, or a computer can suppress the presentation of information that may distract the user from safe actions, or it can offer modes of interaction that avoid either distraction or actual physical danger.

[3018] Example Characteristics of an Example WPC

[3019] “Wearable” is a bit of a misnomer in that the defining characteristic of a WPC isn't that it is worn or integrated into clothing, but that it travels with you at all times, is not removed or set down, and is considered by you and those around you as integral to your person, much as eyeglasses or a wristwatch or memories are. With such integration, wearable computers can truly become a component of you.

[3020] A wearable computer can also be distinguished by its ultimate promise: to serve as a capable, general-purpose computational platform which can, because it is always present, wholly integrate with your daily life.

[3021] The fuzzy description of a wearable computer is that it's a computer that is always with you, is comfortable and easy to keep and use, and is as unobtrusive as clothing. However, this “smart clothing” description is unsatisfactory when pushed in the details. A more specific description is that wearable computers have many of the following characteristics.

[3022] Present and Operational in all Circumstances

[3023] The most distinguishing feature of a wearable is that it can be used while walking or otherwise moving around. You do not need to arrange yourself to suit the computer. Rather, the computer provides the means by which you can operate it regardless of circumstances. A wearable is designed to operate on you day and night, and no “place” is needed to set it up-neither a hand nor a flat surface. This distinguishes wearable computers from both desktop and laptop computers.

[3024] Unrestrictive

[3025] A wearable is self-supporting on the body using some convenient means and works with you in all situations-walking, sitting, lying down. It doesn't necessarily impinge on your life or what you're doing. You can do other things while using it; for instance, you can walk to lunch while typing.

[3026] Integral

[3027] A wearable is a part of “you,” like a wristwatch or eyeglasses or ears or thoughts. And like a wallet or watch, it is not separable or easily lost because it resides on you and effortlessly travels with you without your keeping track of it (as opposed to a briefcase). It is also integrated into your daily processes and can supplement thought as it takes place.

[3028] Always On, Alert, and Available

[3029] By design, a wearable computer can be useful in whatever place you are in—it is always ready and responsive, reactive, proactive, and monitoring. It requires no setup time or manipulation to get started, unlike most pen-based personal digital assistants (PDAs) and laptops. (PDAs normally sit in a pocket and are only awakened when a task needs to be done; a laptop computer must be opened up, switched on, and booted up before use.) A wearable is in continuous interaction with you, even though it may not be your primary focus at all times.

[3030] Able to Attract Your Attention

[3031] A wearable can either make information available peripherally, or it can overtly interrupt you to gain your attention even when it's not actively being used. For example, if you want the computer to alert you when new e-mail arrives and to indicate its sender, the WPC can have a range of audible and visual means to communicate this depending on the urgency or importance of the e-mail, and on your willingness to deal with the notification at the time.

[3032] How a Wearable Changes the Way Computers Function

[3033] The promise of a wearable's unique characteristics make new uses of a computer inevitable.

[3034] The Computer Can Sense Context

[3035] Both interaction and information can be extremely contextual with a WPC. Given the right kind of sensors, the wearable can attend to (be aware of and draw input from) you and your environment. It could witness events around you, detect your circumstances or physical state (e.g., the level of ambient noise or privacy, whether you're sitting or standing), provide feedback about the environment (e.g., temperature, altitude), and adjust how it presents and receives information in keeping with your situation.

[3036] Always on and always sensing means a wearable might change which applications or UI elements it makes readily available as you move from work to home. Or it might tailor the UI and interaction to suit what's going on right now.

[3037] If it detects that you're flying, for instance, the wearable might automatically report your destination's local time and weather, track the status of your connecting flights, and help get you booked on another flight if your plane is going to be late. Similarly, if a wearable's sensors show that you're talking on the cell phone, the WPC might automatically turn off audio interruptions and use only a head-mount display to alert you to incoming e-mails, calls, or information you have requested.

[3038] None of these uses are possible with a PDA or other computer system.

[3039] The Computer Can Suggest and/or Direct

[3040] The better a WPC can sense context, the more appropriate and proactive its interaction can become for you. For instance, as you drive near your grocery store on the way home from work, your wearable might remind you that you should pick up cat food. This “eventing on context” gives the computer a whole new role in which it can suggest options and remind you of things like to putting out the trash on Tuesday or telling something to John as he walks into the room. You wouldn't be able to do this with a desktop or laptop system.

[3041] A computer that is with you while you're out in the world can also step you through processes and help troubleshoot problems within the very context in which they arise. This is different from a desktop system, which forces you to stay in its world, at its monitor, with your hands on its keyboard and mouse, printing out whatever instructions you may need offsite. The hands-free, always-with-you wearable can deliver procedures and instructions from any hard drive or web site at the very place where you're faced with the problem. It can even direct you verbally or visually as you perform each step.

[3042] The Computer can Augment Information, Memory, and Senses

[3043] Because a wearable computer can actively monitor, log, and preserve knowledge, it can have its own memories that you can rely on to augment your memory, intellect, or senses. For instance, its memory banks can help you recall where you parked the car at Disneyland, or replay the directions you asked for from the gas attendant. It might help you “sniff” carbon monoxide levels, see in infrared or at night, and hear ultrahigh frequencies. When you're traveling in France, it might overlay English translations onto road signs.

[3044] How a Wearable Changes the Way Computers and People Interact

[3045] Because a wearable computer is always around, always on, and always aware of you and your changing contexts, the WPC has the potential to become a working partner in almost any daily task. WPCs can prompt drastic shifts in how people interact with tools that were once viewed only as stationary, static devices.

[3046] People can be in Touch with the World in Ways Never Before Experienced

[3047] A computer that can sense can be a digital mediator to the world around you. You can hear the pronunciation of unfamiliar words, call up a thesaurus or dictionary or translator or instructions, or pull up any Internet-based fact you need when you need it. Because a wearable can talk to any device within its range, it could annotate the world around you with relevant information. For example, it might overlay people's names as you meet them, provide menus of restaurants as you pass by, and list street names or historical buildings as you visit a new city. A wearable will be able to “sense across time” to provide an instant replay of recent events or audio, in case you missed what was said or done. And unlike smart phones which have to be turned on, a WPC can provide all of this information with a whisper or a keystroke anytime it's needed.

[3048] The Computer can be Used Peripherally Throughout the Day

[3049] A wearable PC turns computing into a secondary, not primary, activity. Unlike a desktop system that becomes your sole focus because it's time to sit down in front of it, a WPC takes on an ancillary, peripheral role by being always “awake” and available when it's needed, yet staying alert in the background when you're busy with something else. Your interaction with a WPC is fluid and interruptible, allowing the computer to function as a supporting player throughout your day. This will make computer usage more incidental, with a get-in, get-out, and do-what-you-want focus.

[3050] People Can Alter Their Computer Interaction Based on Context

[3051] WPCs imply that your use of, and interaction with, the computer can dramatically change from moment to moment based on your:

[3052] Physical ability to direct the system—You and the WPC will communicate differently based on what combination of your hands, ears, eyes, and voice is busy at the moment.

[3053] Physical (whole-body) activity—Your ability or willingness to direct the WPC may be altered by what action your whole body is doing, such as driving, walking, running, sitting, etc.

[3054] Mental attention or willingness to interact with the system (your cognitive availability)—How and whether you choose to communicate with the WPC may vary if you're concentrating on a difficult task, negotiating a contract, or shooting the breeze.

[3055] Context, task, need, or purpose—What you need the WPC for will vary by your current task or topic, such as if you're going to a meeting, in a meeting, driving around doing errands, or traveling on vacation.

[3056] Location—Both the content and nature of your WPC interaction can change as you move from an airplane in the morning, to an office during the day, to a restaurant for lunch, and then to a soccer game with the kids in the evening. They can also change even as you move through three-dimensional space.

[3057] Desire for privacy, perceived situational constraints—How you interact with the WPC is likely to change many times a day to accommodate the amount of privacy you have or want, and whether you think using a WPC in a particular situation is socially acceptable.

[3058] People can Invest the Computer with More About Their Daily Lives

[3059] Things originally considered trivial will now be input into and shared with the use of a computer. The issue of privacy both in interaction and content will become more important with a WPC, as well.

[3060] Example Characteristics of a Desireable WPC UI Overview

[3061] 1. Communicate the WPC's awareness of something to the user. p1 2. Receive acknowledgement or instructions from the user.

[3062] Just as the graphical user interface and mice made it easier to do certain things in a 2-D world of bitmap screens, so would a new UI make it easier to operate in the new settings demanded by wearable computing. Interfaces such as MS-Windows fail in a WPC setting. Based on the WPC's unique qualities and uses as defined in Section 2, the following are suggested capabilities of a successful wearable computer UI.

[3063] A WPC UI Should Let the User Direct the System Under any Circumstances.

[3064] Rationale Because the user's context, need for privacy, and physical and mental availability change all the time while using a WPC, the user should be able to communicate with the WPC using the most suitable input method of the moment. For instance, if he is driving or has his hands full or covered with grease, voice input would be preferable. However, if he's in a movie theater, on a subway, or in another public space where voice input may be inappropriate, he may prefer eye tracking or manual input.

[3065] In general, a UI's input system should accommodate minute-to-minute shifts in the user's:

[3066] Physical availability to direct the actions of the WPC, either with his hands (e.g., whether he has fine/gross motor control, or left/right/both/no hands free), voice, or other methods.

[3067] Mental availability to notice the WPC output and attend to or defer responding to it.

[3068] Desired privacy of the WPC interaction or content.

[3069] Context, task, or topic—that is, what his mind is working on at the moment.

[3070] Examples One way to direct a WPC under any circumstances is to allow the user to input in multiple ways, or modes (multi-modal input). The UI might offer all modes at once, or it might offer only the most appropriate modes for the context. In the former, the user would always be allowed to select the input mode that's appropriate to the context. In the latter, the UI would provide its best guess of input options and suppress the rest (e.g., if the room were dark, the UI might ignore taps on an unlighted keyboard but accept voice input).

[3071] Typical WPC multi-modal input methods could include touch pads, 1D and 2D pointing devices, voice, keyboard, virtual keyboard, handwriting recognition, gestures, eye tracking, and other tools.

[3072] A WPC UI Should be Able to Sense the User's Context

[3073] Rationale Ideally, a computer that is always on, always available, and not always the user's primary focus should be able to transcend all activities without the user always telling it what to do next. By “understanding” a context outside of itself, the WPC can change roles with the user and become an active support system. Doing so uses a level of awareness of the computer's outside surroundings that can drive and refine the appropriateness of WPC interactions, content, and WPC-initiated activities.

[3074] Current models of the UI between man and computer promote a master/slave relationship. A PC does the user's bidding and only “senses” the outside world through direct or indirect commands (via buttons, robotics, voice) from the user. Any input sensors that exist (e.g., cameras, microphones) merely reinforce this master/slave dynamic because they are controlled at the user's discretion. The computer is in essence deaf, dumb, blind, and non-sensing.

[3075] In the WPC world, the system has the potential to use computer-controlled (passive) sensors to hear, speak, see, and sense its own environment and the user's physical, mental, and contextual (content) states. By being aware of its own surroundings, the WPC can gather whatever information it wants (or thinks it needs) in order to appropriately respond to and serve its user.

[3076] The WPC UI should promote an exchange between man and machine that is a mix of active and passive interactions. As input is gathered, the UI should opportunistically generate a conceptual model of the world. It could use this model to make decisions in the moment (such as which output method is most appropriate or whether to send the person north or south when he's lost). It can also use the model to interpret and present information and choices to the user.

[3077] Sensory information that is gathered but not relevant in the moment might also be accumulated for future action and knowledge.

[3078] Examples To become aware of its user and context, a WPC could accept input from automatic internal sensors or external devices, from the user with manual overrides (e.g., by speaking, “I'm now in the car”), or through other means.

[3079] An example of a WPC UI that mixes active and passive interaction would be when a person passes active information (choices) to the WPC while the WPC picks up on passive info (context, mood, temperature, etc). The WPC blends the active command with the passive information to build a conceptual model of what's going on and what to do next. The computer then passes active information (such as a prompt or feedback) to the person and updates its conceptual-model based on changes to its passive sensors.

[3080] A WPC UI Should Provide Output that is Appropriate to the User's Context

[3081] Rationale A WPC provides output to a user for three reasons. When it is being proactive, it initiates interaction by getting the user's attention (notification or system initiated activity). When it is being reactive, it provides a response to the user's input (feedback). When it is being passive or inactive, it could present the results of what it is sensing, such as temperature, date, or time (status).

[3082] For an output to be appropriate to the context, the UI should:

[3083] Decide how and when it is best to communicate with the user. This should be based on his available attention and his ability/willingness to sense, direct, and process what the WPC is saying. For instance, the WPC might know to not provide audio messages while the user's on the phone.

[3084] Use a suitable output mechanism to minimize the disruption to the user and those around him. For instance, if the UI alerts a person about incoming mail, it might do so with only video in a noisy room, with only audio in a car, or with a blend of video and audio while the user is walking downtown.

[3085] Wait as necessary before interrupting the user to help the user appropriately shift focus. For instance, the WPC might wait until a phone call is completed before alerting him that e-mail has arrived.

[3086] This is called having a scalable output.

[3087] Examples One way to achieve scalable output is to use multiple output modes (multi-modal output). Typical WPC output modes could include video (monitors, lights, LEDs, flashes) through head-mounted and palm-top displays; audio (speech, beeps, buzzes, and similar sounds) through speakers or earphones; and haptics (vibration or other physical stimulus) through pressure pads.

[3088] Typical ways to address the appropriateness of the interaction include using and adjusting a suitable output mode for the user's location (such as automatically upping the volume on the earphone if in an airport), and waiting as necessary before interrupting the user (such as if he's in a meeting).

[3089] A WPC UI Should Account for the User's Cognitive Availability

[3090] Rationale A human being's capacity to process information changes throughout the day. Sometimes the WPC will be a person's primary focus; at others the system will be completely peripheral to his activities. Most often, the WPC will be used in divided-attention situations, with the user alternating between interacting with the WPC and interacting with the world around him. A WPC UI should help manage this varying cognitive availability in multiple ways.

[3091] The UI Should Accommodate the User's Available Attention to Acknowledge and Interpret the WPC

[3092] Rationale An on-the-go WPC user prefers to spend the least amount of attention and mental effort trying to acknowledge and interpret what the WPC has told him. For instance, as the focus of a user's attention ebbs and flows, he might prefer to become aware of a notification, pause to instruct the WPC how to defer it, or turn his attention fully to accomplishing the related task.

[3093] Examples Ways to accommodate the user's available attention include:

[3094] Allow the user to set preferences of the intensity of an alert for a particular context.

[3095] Provide multiple and perhaps increasingly demanding output modes.

[3096] Make using the WPC a supportive, peripheral activity.

[3097] Build in shortcuts.

[3098] Use design elements such as consistency, color, prominence, positioning, size, movement, icons, and so on to make it clear what the WPC needs or expects.

[3099] The UI Should Help the User Manage and Reduce the Mental Burden of using the WPC

[3100] Rationale Because the user is likely to be multi-tasking with the WPC and the real world at the same time, the UI should seek to streamline processes so that the user can spend the least amount of time getting the system to do what he wants.

[3101] Examples Ways to reduce the burden of using WPC include:

[3102] Help chop work into manageable pieces.

[3103] Compartmentalize tasks.

[3104] Provide wizards to automate interactions.

[3105] Be proactive in providing alerts and information, so that the user can be reactive in dealing with them. (Reacting to something takes less mental energy than initiating it.)

[3106] The UI Should Help the User Rapidly Ground and Reground with Each use of the WPC

[3107] Rationale The UI should make it easy for a user to figure out what the WPC expects anytime he switches among contexts and tasks (grounding). It should also help him reestablish his mental connections, or return to a dropped task, after an interruption-such as when switching among applications, switching between use and non-use of the WPC, or switching among uses of the WPC in various contexts (regrounding).

[3108] Examples Ways to rapidly ground and reground include:

[3109] Use design devices such as prominence, consistency, and very little clutter.

[3110] Remember and redisplay the user's last WPC screen.

[3111] Keep a user log that he can be searched or backtracked.

[3112] Allow for thematic regrounding, so that the user will find the system and information as he last left them in a certain context. For instance, there could be themed settings for times when he is at home, at work, driving, doing a hobby, making home repairs, doing car maintenance, etc.

[3113] The UI Should Promote the Quick Capture and Deferral of Ideas and Actions for Later Processing

[3114] Rationale A user prefers a low-effort, low-cognitive-load way to grab a fleeting thought as it comes, save it in whatever “raw” or natural format he wants, and then deal with it later when he is in a higher productivity mode.

[3115] Examples Ways to promote quick capture of information include:

[3116] Record audio clips or .wav files and present them later as reminders.

[3117] Take photos.

[3118] Let the user capture back-of-the-napkin sketches.

[3119] A WPC UI Should Present its Underlying Conceptual Model in a Meaningful Way (Offer Consistent Affordance)

[3120] Rationale Affordance is the ability for something to inherently communicate how it is to be used. For instance, a door with a handle encourages a person to pull; one with only a metal plate encourages him to push. These are examples of affordance—the design of the tool itself, as much as possible, “affords” the information required to use the tool.

[3121] Far more so than for stationary computers, the interaction and functionality of a WPC should always be readily and naturally “grasped” if the UI is to support constant on-again, off-again use across many applications. This not only means that the UI elements should be self-evident in their purpose and functionality. It also means that the system should never leave the user guessing about what to do or say next—that is, the UI should expose, rather than conceal, as much as possible of how it “thinks.”

[3122] This underlying “conceptual model” (metaphor, structure, inherent “how-it-works”-ness) controls how every computer relates to the world. A UI that exposes its conceptual model speeds the learning curve, reinforces habit to reduce the cognitive load of using the WPC, and helps the user shortcut his way through the system without losing track of where his mind is in the real world around him. Input and output mechanisms that are this self-evident in how they are to be used are said to offer affordance. The goal of affordance is to have the user be able to say, “Oh, I know how to operate this thing,” when he is faced with something new.

[3123] Examples UI elements that replicate, as closely as possible, real-world experiences are most likely to be understood with very little training. For example, a two-state button (on/off) shouldn't be used to make a person cycle through a three-state setting (low/medium/high). Instead, a dial, a series of radio buttons, an incremented slider bar, or some other mechanism should be used to imply more than an on/off choice.

[3124] Examples of how a UI can expose its underlying model include avoiding the use of hierarchical menus, using clear layman's terms, building in idiomatic (metaphorical and consistent) operation, presenting all the major steps of a process at once to guide the user through, and making it clear which terms and commands the WPC expects to hear spoken, clicked, or input at any time.

[3125] A WPC UI Should Help the User Manage His Privacy

[3126] Rationale Desktop monitors are usually configured to be private, and are treated as such by most people. However, because a WPC is around all the time, can log and output activity regardless of context, and becomes integrated with daily life, the issue of privacy becomes much more critical. At different times, a user might prefer either his content, his interaction with the WPC, or his information to stay private. Finding an unobserved spot to use a WPC is not always feasible—and having to do so is contrary to what a WPC is all about. A UI therefore should help the user continually manage the degree to which he wants privacy as situations change around him. In this context, there are four types of privacy the UI should account for.

[3127] Privacy of the Interaction with WPC

[3128] Rationale Because social mores or circumstances may dictate that interacting overtly with the WPC is unacceptable, a user might want to command the system without others knowing he's doing so. At the user's discretion, he should be able to make his interaction private or public, whether he's in a conference room, on a subway, or at a street corner.

[3129] Examples Ways to achieve privacy of interaction include:

[3130] Use HMD and earpieces for output to the user.

[3131] Provide for non-voice input, such as eye-tracking or an unobtrusive keyboard or pointer.

[3132] Privacy of the Nature of the WPC Interaction

[3133] Rationale Even if a person doesn't mind that others know he's using the WPC, he may not want others to eavesdrop on what he's trying to know, capture, call up, or retrieve, such as information, photos, e-mail, banking information, etc. The UI should support the desire to keep any combination of what the person is doing (e.g., making an appointment), saying (e.g., recording personal information), or choosing (e.g., visiting a specific web site) secret from those around him.

[3134] Examples Ways to achieve privacy of content of the interaction include:

[3135] Use keyboard input with a head-mounted display (HMD).

[3136] Allow a user to speak his choices with codes instead of actual content (e.g., saying “3” then “5” instead of “Appointment” and “Fred Murtz” when scheduling a meeting).

[3137] Privacy of the WPC Content

[3138] Rationale Once a person has retrieved the information he wants (regardless of whether he cares if someone else knows what he's calling up) he may not want others to actually hear or view the content. The UI should let him move into “secret mode” at any time.

[3139] Examples Ways to achieve privacy of the content include:

[3140] Provide a quick way for the user to switch from speakers or LCD panel output to a private-only mode, such as an HMD or earpiece.

[3141] Let the user set preferences that instruct the UI to switch automatically to private output based on content or context.

[3142] Privacy of Personal Identity and Information (Security)

[3143] Rationale A WPC is a logical place for a user to accumulate information about his identity, family, business, finances, and other information. The UI should provide an extremely secure, unforgettable identity that allows for anonymity when it's desired, secure transactions, and protected, private information.

[3144] Examples Ways to achieve security of identity include:

[3145] Block another's access to information that is within, or broadcast by, the WPC.

[3146] Selectively send WPC data only to specific people (such as the user's current location always to the spouse and family but not to anyone else).

[3147] A WPC UI Should Scale from Private to Collaborative use

[3148] Rationale Just as there are times when two or three people should huddle around a desktop system to share ideas, so a WPC user may want to shift from private only viewing and interaction to collaborate with others. The UI should support ways to publicly share WPC content so that others can see what he sees, and perhaps also manipulate it.

[3149] Examples Collaboration can be done by using a handheld monitor that both people can use at once or, if both people have WPCs, perhaps by wirelessly sharing the same monitor image on both HMDs. For collaborating with larger groups, the UI could support a way to transfer WPC information to a desktop or projection system, yet still let the user control what is viewed using standard WPC input methods.

[3150] A WPC UI Should Accept Spoken Input

[3151] Rationale A person should be able to command a WPC in any situation in which his hands are not free to manipulate a mouse, keyboard, or similar input device, such as when driving, carrying goods, or repairing an airplane engine. Using voice to control the WPC is a natural choice for almost all hands-busy situations. The WPC UI should therefore support and utilize a speech recognition system that understands what a user will say to it.

[3152] Examples Computer-based speech recognition capability can range from recognizing everything that a person can say (understanding natural language), to recognizing words and phrases from a large predefined vocabularies (such as thousands of words), to recognizing only a few dozen select words at a time (very limited vocabulary). Another level of speech recognition involves being able to also understand the way (tone) in which something is said.

[3153] A WPC UI Should Support Text Input Methods

[3154] Rationale A user is likely to want to capture brief text strings that the WPC has never seen before, such as people's names and URLs. For this reason, a UI should allow the user to accurately save, input, and/or select custom textual information. This capability should span multiple input modes, in keeping with the WPC's value as a hands-free, use-anywhere device.

[3155] Examples Accurate text input can be provided through a keyboard, virtual keyboard, handwriting recognition, voice spelling, and similar mechanisms.

[3156] A WPC UI Should Support Multiple Kinds of Voice Input

[3157] Rationale An ordinary computer microphone cannot discern between when someone is talking to the system or to someone else in the room. A microphone-equipped WPC is supposed to be able to understand and recognize this subtlety and process a user's voice input in several listening modes, including:

[3158] Voice commands—the computer instantly responds to instructions given without a pointer or keyboard.

[3159] Phone conversation—the system recognizes when its user's voice is directed to a phone instead of to it.

[3160] Recorded voice—the computer creates a .wav file or similar image of the sound on demand; this could be used with phone input and output.

[3161] Dictation to transcript—the system converts speech into ASCII on the fly.

[3162] Dictation to text box—in this special case of transcription, the computer accepts words from a constrained vocabulary and converts them to ASCII to insert into a given field, such as saying “December 16” and having it show up on a Date field on a form.

[3163] Dictation training—the system learns an individual's idiosyncratic pronunciation of words.

[3164] Silence—the system leaves its microphone on and awaits instructions; it may passively indicate volume.

[3165] Mode switch—the system understands that the user wants to switch between listening modes, such as with, “Computer <state|context|function|user-defined>” or “Computer, end transcription.”

[3166] Speaker differentiation—the computer recognizes its own user's voice, so that when someone else gives a command either deliberately or in the background, the system ignores it.

[3167] The UI should manage each type of voice transition fluidly and (preferably) in a hands-free manner.

[3168] Examples Using a push-to-talk button can alert the system when it is being addressed, and user settings or preferences can make it clear when to record or not record, when to listen or not listen, and how to respond in each case.

[3169] A WPC UI Should Work with Multiple WPC Applications

[3170] Rationale The value of a WPC is its ability to be used in multiple ways and for multiple purposes throughout the day. Related tasks will generally be grouped into one or more WPC applications that can help organize and simplify tasks, as well as help reduce the cognitive load of using the WPC.

[3171] Examples Single and group applications for WPCs are virtually limitless. Examples include forms creation, web linking, online readers, e-mail, phone, location (GPS), a datebook, a contacts book, camera, scanning tools, video and voiceover input, and tools to capture scrawled pictures.

[3172] A WPC UI Should Allow and Assist with Multitasking and Switching among WPC Applications

[3173] Rationale Many times a day, a WPC user will require more than one WPC application running at the same time to complete a task. For instance, when making an appointment with someone, a user might use an address book application to retrieve his photo and contact information; use a phone application to call him up; use a journal application to look up the information they were last talking about; use a voice recorder application to capture the audio of a phone call; use a note-taking application to scribble down notes and share with someone else who's standing by; use an e-mail application to attach the scribble to an e-mail; and use a to-do application to check off the phone call as a completed task and flag another task for follow-up. In all cases of cross-application work, the UI should help the user keep track of where he is, where he's been, and how to get where he wants to go.

[3174] Examples Ways that a UI could help the user keep track of these applications include:

[3175] Use icons that indicate which application(s) are on and which one is active.

[3176] Include logging methods to help the user back-track to the place where he left off from application to application.

[3177] Provide tools to jump ad hoc between applications at any time.

[3178] A WPC UI Should be Extensible to Future Technologies

[3179] Rationale As the wearable gains popularity, WPC uses that are unheard of today will become standard tomorrow. For this reason, the UI should be designed so that it is open enough to fold in new functionality in a consistent manner. Such new functionality might include enriched methods for gaining the user's attention, improvements to the WPC's context-awareness sensors, and new applications.

[3180] Examples Ways to make sure a UI is extensible include utilizing and building from currently accepted standards, or coding with an open or module-based architecture.

[3181] Details of an Example UI Overview of Example WPC Software and Tools

[3182] Five example types of products for WPCs:

[3183] User Interface (UI)—what the user interacts with. The UI enables the user and the WPC to hold a dialog—that is, to exchange input and output. It amends and facilitates this conversation. The UI solves the need for a WPC that a user can command and interact with.

[3184] Applets (many may be developed by third parties)—the WPC applications that run within the interface. Applets allow the user to accomplish specific tasks with a WPC, such as make a phone call or look up an online manual. They provide a means to input information that's relevant to the task at hand, and facilitate the tasks' completion. Applets solve the need for a WPC that can be useful in real-world situations.

[3185] Characterization Module (CM)—an architectural framework that allows awareness to be added to a WPC as WPC use evolves. In particular, the CM tells the WPC about the user's context, such as his physical, environmental, social, mental, or emotional state. It senses the external world, provides status or reporting to the UI, and facilitates UI conceptual models. The CM solves the need for a WPC that can sense the world around it.

[3186] Developer tools—software kits designed to help others develop compatible software. These comprise SDKs, sample software, and other instructional materials for use by developers and OEMs. Developer tools solve the need for how others can design applications and sensors that a WPC can use.

[3187] Portal—a future web site where people can find WPC Applets, upgrades, and new WPC services from developers. The Portal solves the need for keeping developers, users, and OEMs up to date on WPC-related information and software.

[3188] The Example UI will Manage Input and Output Independently of Applet Functionality

[3189] Supported UI Requirement: A WPC UI should let the user direct the system under any circumstance.

[3190] Supported UI Requirement: A WPC UI should provide output that is appropriate to the user's context.

[3191] Supported UI Requirement: A WPC UI should allow and assist with multitasking and switching among WPC applications.

[3192] Supported UI Requirement: A WPC UI should be extensible to future technologies.

[3193] Rationale For a WPC to achieve its ultimate value throughout the day, the UI should always reveal the workings of the system, what it's looking for from the user, and what the person can do with it—all suitable to the context. Moreover, how the system handles these three facets should be consistent, so that someone doesn't have to learn a whole new WPC mechanism with every Applet or input method.

[3194] To achieve these goals, the Example UI splits the WPC experience into three interrelated facets:

[3195] Presentation—what the user sees, hears, and senses from the WPC (WPC output). Presentation determines what the UI and the Applets look like and how intuitively and quickly they can be understood. Presentation can be achieved through audio, video, physical (haptics), or some combination.

[3196] Interaction—the conversation from a person to a WPC (user input). Interaction can be achieved through speech, keyboard, pointing devices, or some combination.

[3197] Functionality—what a person is trying to get the system to do through his interaction. Functionality can be achieved through WPC Applets talking through the UI's underlying engine (the UI Framework).

[3198] This independence of functionality, presentation, and interaction has many benefits:

[3199] We can support the conceptual model that if an input option is available in the UI (presentation), a person say or choose it; if it's not available, he can't.

[3200] We can use part of the UI to orient people to where they are in the WPC and what their choices are.

[3201] The separation of an Applet from the tasks needed to run it eliminates the need for the user to be interrogated by the Applet, yet still lets the UI cue the person on what's coming up next. The user can “rattle off” all relevant information as long as it's in the right order, to become a natural response to getting something done.

[3202] Applet programmers gain a systematic way to present the Applet's information. WPC users can be encouraged to form their own idiomatic routines to reduce cognitive load.

[3203] Take advantage of current formal grammar technology by building on a simple vocabulary.

[3204] Ideas and implications This division of labor could lead to a three-part UI design that simultaneously prompts the user for input, presents him with his choices, and gives him the perception that he is commanding the Applet without actually doing so. (In technical functionality, he will “command” only the UIF, which translates to and from the Applet.)

[3205] The Example UI will Present All Available Input Options at Once

[3206] Supported UI Requirement: The UI should let the user direct the system under any circumstances.

[3207] Rationale Current sensor technology will make it very difficult for the WPC to determine the user's context enough to present and accept only the kind of input that is appropriate to the situation. Rather than have the UI make an error of omission of input methods, it will present all available input options at once and expect the user to choose which one he wants to use.

[3208] Ideas and implications One way around the all-or-nothing input options is to have the user be able to set thematic preferences, such as “When I'm in the car, don't bother to activate the keyboard.”

[3209] The Example UI will Always Make All Input Options Obvious

[3210] Rationale An overriding goal for the Example UI is to make it fast and easy for the user to get in and out of a WPC interaction. As the UI prompts him for decisions and input, the user should be able to tell the following from the UI:

[3211] When voice, keyboard, stylus, or whatever other input option can be applied.

[3212] Which words the WPC will respond to verbally.

[3213] What keyboard and mouse/stylus actions are equivalent to voice.

[3214] Ideas and implications Visual can be the default (provides parallel input for faster interaction), but the user should be able to switch to audio (provides serial input for slower interaction) if appropriate. The UI should provide multiple and consistent mechanism(s) to enter new terms, names, an URLs. For this purpose, the UI should make it clear that the WPC supports: keyboard input, virtual keyboard input, voice spelling, and handwriting recognition (rudimentary). The methods for entering new names, etc. should be consistently available and consistently operated.

[3215] The Example UI will be as Proactive as Possible with Notification Cues

[3216] Supported UI Requirement: The UI should support the user's cognitive availability.

[3217] Rationale A WPC that can detect a user's context can play a significant role if it can proactively notify the user when things happen and prompt him for decisions and input. Presenting information and staging interactions so that the user can be reactive in handling them lowers the cognitive load required and makes the WPC less of a burden to use. The level of this proactivity may be limited by current sensor technology. To be proactive, the UI's notifications and prompts should:

[3218] Be a supportive, peripheral activity that is appropriate to the context—e.g., no audio messages while the user's on the phone, or perhaps it should even wait until the phone call is completed before alerting him.

[3219] Use a suitable output mechanism—e.g., into ear or eye, preferably depending on where user is at the moment (in car, at home, at office, in airplane).

[3220] Wait as necessary before interrupting the user—e.g., if he's on the phone. The user's ability to devote divided or undivided attention to the WPC interaction determines whether he is interruptible.

[3221] the Example UI will Allow 1-D and 2-D Input, but not Depend too Heavily on it

[3222] Supported UI Requirement: The UI should let the user direct the system under any circumstances.

[3223] Supported UI Requirement: The UI should provide output that is appropriate to the user's context.

[3224] Supported UI Requirement: The UI should accept spoken input.

[3225] Supported UI Requirement: The UI should account for the available attention to acknowledge the WPC.

[3226] Rationale When the user needs hands-on input such as typing or mousing, the WPC should support standard pointing and keyboard modes. However, the WPC should also be able to be used in hands-busy and eyes-busy circumstances, which demands the use of speech input and output. However, a two-dimensional, pointer-driven UI (such as most current WIMP applications) doesn't always translate well to voice-only commands. For instance, a user should not be forced into a complicated description of where to place the pointer before selecting something, nor should he be expected to use vocal variances (e.g., trills to grunts) to tell the cursor to move up and down or left and right. The Example UI will depend more on direct voice input/output and less heavily on 2-D output and input that can't be readily translated to voice.

[3227] Ideas and implications Exposing items as a list lets users choose what they want either verbally or with a pointer.

[3228] The Example UI will Scale with the User's Expertise

[3229] Supported UI Requirement: The UI should let the user direct the system under any circumstances.

[3230] Supported UI Requirement: The UI should account for the available attention to acknowledge the WPC.

[3231] Rationale Scale on expertise—shortcuts/post processing assists with cognitive load.

[3232] The Example UI will Surface its Best Guess about the User's Context

[3233] Supported UI Requirement: The UI should provide output that is appropriate to the user's context.

[3234] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3235] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3236] Rationale Building from Characterization Module sensors, the UI should surface its best guess of the user's ability to direct, sense, and think or process at any time. Methods to set attributes could be both fine grained (“My eyes are not available now,” which could set the system to use the earpiece) and thematic (“I am driving now,” which could set information context plus eyes and hands not available). Eyes and ears can be available in diminishing capacity. Generally a person can't have fine and gross motor control simultaneously.

[3237] Ideas and implications From a UI standpoint, awareness could be manifest by changing the display to reveal what the system thinks is the context, yet still allow the user to change that context back to where he last was, or to something else altogether.

[3238] The Example UI will Reveal All of an Applet's Available Options at All Times

[3239] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3240] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3241] Supported UI Requirement: The UI should present its underlying conceptual model in a meaningful way (offer affordance).

[3242] Rationale Rather than bury commands in multiple menus that force the user to pay close attention to learning and interacting with the WPC, the Example UI should expose all available user options all the time for each active Applet. This way, the user can see all of his choices (e.g., available tasks, not all data items such as names or addresses) at once.

[3243] The Example UI will Never be a Blank Slate

[3244] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3245] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3246] Rationale By definition, a WPC that is context-aware should always be able to show information that is trenchant to the current circumstances. Even in “idle” mode, there is no reason for the WPC to be a blank slate. A continuously context-sensitive UI can help the user quickly ground when using the system, reduce the mental attention needed to use it, and depend on the WPC to provide just the right kind of information at just the right time.

[3247] Ideas and implications If the system is idle, it might display something different by default if the person is at home vs. if he's at the office. Similarly, if the person actively has an Applet running (such as a To Do list), what the UI shows could vary by where the user is—on the way home past Safeway or in an office.

[3248] The Example UI will be Consistent

[3249] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3250] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3251] Supported UI Requirement: A WPC UI should allow and assist with multitasking and switching among WPC applications.

[3252] Rationale Throughout the day, a user's interaction with the WPC will occur amidst many distractions, in differing contexts, and across multiple related WPC applications. For this reason, the UI should provide fundamentally the same kind of interaction for every similar kind of input. For instance, what works for a voice command in one situation should work for a voice command in a similar situation. This consistency enables the user to:

[3253] Quickly grasp how to first use the WPC and what it expects at any given time.

[3254] Minimize his interaction time with the WPC and gain faster, more accurate results.

[3255] Reliably extrapolate how to use new WPC functionality as it becomes available.

[3256] Ideas and implications A consistent user interface should:

[3257] Make all applications operate through the same modes in the same way (such as through consistent voice or keyboard commands).

[3258] Make text input consistently available and operated.

[3259] Make it clear at all times which part of the UI the user is supposed to interact with (vs., say, which parts he only has to read).

[3260] Use standard formats for time, dates, GPS/location, etc. so that many Applets can use them.

[3261] The Example UI will be Concise and Uncluttered

[3262] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3263] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3264] Rationale A WPC will often be used when attention to visual detail in the UI is unrealistic, such as while driving or in a meeting. The UI should therefore be concise, offering just enough information at all times. What is “just enough” should also be tempered by how much can be absorbed at one time. To promote the get-in-and-get-out nature of a WPC, the Example UI should also be designed with as little visual clutter as possible.

[3265] Ideas and implications In particular, the UI should display ear or eye output without obstructing anything else.

[3266] The Example UI will Guide the User to what is Most Important

[3267] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3268] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3269] Supported UI Requirement: A WPC UI should allow and assist with multitasking and switching among WPC applications.

[3270] Rationale A fully context-aware WPC would be able to detect and keep track of a user's priorities, and constantly present information that's relevant to his content, purpose, environment, or level of urgency. When deciding what to present and when to present it, the UI should be able to guide the customer to what is most important to deal with at any given moment.

[3271] Ideas and implications This can be done through UI design techniques such as prominence, color, and motion.

[3272] The Example UI will Guide the User About what to do Next

[3273] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3274] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3275] Supported UI Requirement: The UI should present its underlying conceptual model in a meaningful way (offer affordance).

[3276] Supported UI Requirement: A WPC UI should allow and assist with multitasking and switching among WPC applications.

[3277] Rationale As much as possible, the Example UI should assist the user so as to minimize the time to understand what to do, how to do it, and how to process what doing it has accomplished. The UI should provide a way for the user to know that a command is available and that his input has been received correctly. It should also help him reload dropped information and reground to a dropped task after or during an interruption in the task.

[3278] Ideas and implications A popular approach is to make everything that the user can do be visible and to have UI constrain what the WPC will recognize. For instance, text that is in gold can be said aloud, but text in the bouncing ball list exposes what to expect next in an Applet's process in a linear, language-oriented way. Incremental typing letters filters a list down.

[3279] The Example UI will Always Reveal the User's Place in the System

[3280] Supported UI Requirement: The UI should allow and assist with multitasking and switching among WPC applications.

[3281] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3282] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3283] Rationale Because the user's focus and attention will often shift back and forth between the WPC and his surroundings, the UI should clearly show him where he is within the UI at all times (e.g., “I'm currently operating the Calendar and am this far along in it”). This means letting him switch among Applets easily without losing track of where he's been, as well as determining and returning to his previous state if he is doing “nested” work among several Applets.

[3284] Ideas and implications Orienting can be done through UI design techniques such as color, icons, banners, title bars, etc.

[3285] The Example UI will Use a Finite Spoken Vocabulary

[3286] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3287] Supported UI Requirement: The UI should accept spoken input.

[3288] Rationale The current state of the art for speech recognition does not allow for natural language or large vocabularies. The dialog between computers and people is not like person-to-person conversation. People don't speak the same way in all settings, and the user may not be able to train the WPC. Meaning, tone, and nuance are difficult to capture accurately in a person-to-computer interaction. Voice systems are by nature linear and tedious because all interactions should be serial. Ambient sounds and quality of voice pickup dramatically affect the robustness of speech recognition programs. To succeed, the Example UI should not require a large vocabulary to use. However, the speech should be as natural as possible when using the system, not stilted or ping-pong. (That is, the system should allow the user to “rattle off” a string of items he wants, without waiting for each individual prompt to come from the WPC.)

[3289] Additional benefits Constraining the vocabulary provides several other developmental and functional benefits:

[3290] We can use a less expensive, less sophisticated speech recognition system, which means we have more vendors to choose from.

[3291] The speech system will consume less RAM, leaving more memory free for other wearable components and systems.

[3292] A constrained vocabulary requires less processing power, so speed won't be compromised.

[3293] We can use speech recognition engines that are tuned to excel in high-ambient-noise environments.

[3294] Ideas and implications The UI benefits from a dynamic vocabulary but also benefits from escape mechanisms to deal with words the engine has trouble recognizing algorithmically, such as foreign words. Thus, it is preferable to constrain grammar and vocabulary or, if unavoidable, to filter it further (e.g., 500 entries in contacts). Should make it clear which part of the UI the user is supposed to interact with, vs. which parts he's only has to read. It should accommodate the linearity of speech.

[3295] Some important words to recognize: days of the week, months of the year, 1-31, p.m., a.m., currency, system terms such as Page Down, Read, Reply, Forward, Back, Next, Previous, and Page Up. The UI should listen for certain words for itself (system terms), plus ones for the Applet (Applet terms).

[3296] The Example UI will Offer Multiple Ways to Select Items by Voice

[3297] Supported UI Requirement: The UI should let the user direct the system under any circumstances.

[3298] Supported UI Requirement: The UI should help the user manage his privacy.

[3299] Rationale Because there will be no speech training in the UI—e.g., no way to correctly pronounce Jim Rzygecki and have the WPC find it in the list—the UI should have an alternative method for accepting items it doesn't recognize. In other circumstances, the system may be able to interpret the name or command word, but the user may want to keep the content of such an interaction private while still using his voice. (For instance, if he's on a subway and doesn't want others to know he's making a stock buy with his financial advisor.)

[3300] Ideas and implications The user might be able to choose the number or letter of an item in a list rather than state the name of the item itself. He might also be able to voice-spell the first few letters of the name.

[3301] The Example UI will Work with Many WPC Applets at Once

[3302] Supported UI Requirement: The UI should work with multiple WPC applications.

[3303] Supported UI Requirement: The UI should allow and assist with multitasking and switching among WPC applications.

[3304] Supported UI Requirement: The UI should promote the quick capture and deferral of ideas for later processing.

[3305] Rationale A WPC can readily support the multi-tasked, stream-of-consciousness thinking and working methods that most people perform dozens of times a day. By combining Applets and connecting related information across them, a user can streamline his efforts and the WPC can more easily store and call up context-specific data for him.

[3306] Ideas and implications At the very least, the Example UI should support:

[3307] E-mail (MAPI)

[3308] Phone (TAPI)

[3309] Location (GPS)

[3310] Calendar/Appointments/Datebook

[3311] XML Routines

[3312] Forms creation—collect and commit information to a database

[3313] Web linking

[3314] Reading of online manuals

[3315] Camera

[3316] Scanning

[3317] Video and voiceover input—to use a radio/video machine—to talk to others and see what I see.

[3318] Capture of natural data, scan UPS codes, talk to systems, scrawl down something as pictures, take photos just to capture information.

[3319] The Example UI will let the User Defer Work and Pick Up where He Left Off

[3320] Supported UI Requirement: The UI should allow and assist with multitasking and switching among WPC applications.

[3321] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3322] Supported UI Requirement: The UI should help the user rapidly ground and reground with each use of the WPC.

[3323] Supported UI Requirement: The UI should promote the quick capture and deferral of ideas for later processing.

[3324] Rationale The interruptible nature of using a WPC means the user should be able to defer or resume an activity anytime during the day. Examples include the ability to:

[3325] Open a new contact and go to new Applet but come back to where he left off in the contact.

[3326] Put something on the back burner as-is so that he can return to in later in the same state in which he left it (rather than putting it all away and starting over).

[3327] Pull up several Applets at once if a related series of tasks has been interrupted. (I.e., sequencing as stream of consciousness from one Applet to the next pulls up all related info at once—putting all related, cross-Applet info aside temporarily, rather than closing all, filing away, and reopening everything again. A form of regrounding.)

[3328] The Example UI Should Adjust Output Modes to the Desired Level of Privacy

[3329] Supported UI Requirement: The UI should help the user manage his privacy.

[3330] Rationale As wearables become more popular, users will become more concerned about social appropriateness and accidental or deliberate eavesdropping as they use the system. The Example UI should therefore address situational constraints that include a user's desired privacy for:

[3331] His interaction with the WPC (concealing whether he's using it or not).

[3332] His context for using it (concealing whether he's setting a dinner date or selling stock).

[3333] His WPC content (concealing what he's hearing or seeing through the WPC).

[3334] His own identity information (concealing personal information or location from others who have WPCs or other systems).

[3335] Ideas and implications The UI should be able to detect the user's position anonymously rather than, say, have a building tell him (and everyone else) where he is. If the UI cannot adequately detect the user's need for privacy automatically, it should provide a means for the user to input this setting and then adjust its output modes accordingly.

[3336] The Example UI will use Lists as the Primary Unifying UI Element

[3337] Supported U Requirement: The UI should let the user direct the system under any circumstances.

[3338] Supported UI Requirement: The UI should help the user manage and reduce the mental burden of interacting with the WPC.

[3339] Supported UI Requirement: A WPC UI should-be extensible to future technologies.

[3340] Rationale If a WPC is to be used in all contexts with the least amount of mental effort, it should not have fundamentally different interaction depending on the input mode. What works for hands-on operation should also work for hands-free operation. Because speech is assumed but is inadequate for directing a mouse, the Example UI will therefore map all input devices and modes to operate from a list. This single unifying element will enable the user to perform any function by selecting individual items from groups of items.

[3341] Using lists provides the following benefits to users:

[3342] Users can select from lists using any input mode available—speech, pointer, keyboard.

[3343] Having one primary input method lets users extrapolate across the system—learn a stick shift, know all stick shifts.

[3344] Lists simplify operation and promote consistency, which reduce cognitive load and accelerate the user's expertise.

[3345] New input modes (e.g., private) and devices (e.g., eye-tracking) can be mapped in without appreciably affecting the interaction or coding.

[3346] We don't have to care what WPC Applet the list is being applied to—the user just always selects from a list.

[3347] Ideas and implications The lists are the data items that pop up to select from using the menus.

[3348] The Example UI will be Windows Compatible

[3349] Supported UI Requirement: The UI should accept spoken input.

[3350] Supported UI Requirement: The UI should work with multiple WPC applications.

[3351] Rationale This will enable us to leverage the advantages of immense PC market and produce a general-platform product that takes advantage of the uniqueness of a WPC. The Example UI will be a shell that runs inside Windows. The user launches Windows, launches the shell, and then navigates the WPC functionality he wants. The Windows task bar is still visible.

[3352] Ideas and implications To make the most of standards, the UI should rely on PC hardware standards, especially for peripherals and connectors. Any new standards we create ought to be designed to be consistent with the rest of PC market. We intend to follow the current power curve and never compromise in power or capability.

[3353] Other Considerations

[3354] Why Don't Current Platforms Work for WPC Use? They Can't be Available All the Time

[3355] Current platforms can only be interacted with sporadically. A desktop system is only available at the desk. A laptop must be removed from a briefcase, and a suitable surface located. WinCE devices and palmtops must be removed from the pocket. The result is that tasks are deferred until the user can dedicate time to interaction with the platform.

[3356] This prevents the use of information storage and retrieval to be used as pervasive memory and knowledge augmentation. It makes solutions undependable by introducing the opportunity for lost or erroneous information.

[3357] As a result of this lack of availability, the system cannot gain the user's attention or initiate tasks. This thwarts opportunities to facilitate daily life tasks.

[3358] Takeaways for the UI The wearable PC will allow you to be in constant interaction with your computer. Daily life tasks can be dealt with as they occur, eliminating the delay associated with traditional platforms. The system can act as an extension of your self, and an integral part of your daily life.

[3359] They Offer Limited Functionality

[3360] Palmtop devices accomplish greater availability by severely compromising system functionality. They are too under-powered to be good general-purpose platforms. Scaled down “partner products” are often used in lieu of the standard tools available on desktop systems, and many hardware peripherals are unavailable. In general, the ability to leverage the advantages of mainstream hardware and software is lost.

[3361] Takeaways for the UI The wearable PC will be, as far as possible, a fully powered personal computer. It will use high end processors, have large amounts of RAM, and run the Windows operating system. As such, it will leverage all of the advantages enjoyed by laptop and desktop computers.

[3362] They Can't be Used in Every Environment

[3363] Even if current computing platforms were continuously available, they would be unusable in their current form. Laptops are unusable while walking. Palmtops are unusable while driving. The sounds that a traditional computer emits are inappropriate to a variety of social settings.

[3364] Additionally, current platforms have no sense of context, and cannot modify their behavior appropriately.

[3365] Takeaways for the UI Both the wearable PC and software will be tailored to use in everyday situations. Eyeglass-mounted displays, one-handed keyboards, private listening, and voice interaction will facilitate use in a variety of real life situations.

[3366] The software will also have a sense of context, and modify its behavior appropriately to the situation. A scaling UI will adapt to accommodate the user's cognitive load, providing subtler, less intrusive feedback when the user is more highly engaged.

[3367] They are Passive Rather than Reactive

[3368] Current solutions tend to work as passive tools, reacting to the user's commands during a productivity session. This is a lost opportunity to gain the attention of the user at the appropriate time, and offer assistance that the user has not requested, and may not have been aware of.

[3369] Takeaways for the UI With a wearable PC, the system can gain your attention in order to suggest, remind, notify, and augment your world in appropriate ways. Our mantra is: “How can we make computing power a proactive participant in daily life?”

UI EXAMPLES

[3370] Prototype A

[3371] Description Built solely on a Windows interface. All visual—no voice used.

[3372] What we learned This prototype has problems because Windows is all two-dimensional. It cannot provide voice-based UI and feedback well. All-visual is sub-optimal for a WPC used in a hands-free environment. The result was a poor cousin to Outlook.

[3373] Prototype B

[3374] Description Built on voice recognition to control Outlook and Microsoft Agents to be the focal point for interactions and to handle the voice recognition. The Agents use a hierarchical menu system (HMS). Could try an all-voice, natural language interaction for no-hands use. This prototype integrated with Outlook for contacts, appointments, and e-mail; allowed the user to capture reminders as .wav files (i.e., recorded a note and then played it back at a specific time); and included an applet that we created for taking notes.

[3375] What we learned This prototype had problems because:

[3376] The HMS buried commands instead of exposing all the commands at once. It was like using a phone system that forces you to listen through all the options before choosing which one is right, and meanwhile you may have forgotten the option you wanted.

[3377] The Agents locked us into a ping-pong question-answer mode that forced you to hear a question, give a response, wait for the next screen and question, and give another response. The computer couldn't advance without you, and you couldn't advance without waiting for the computer. It was unnatural, stilted, boring, and time-consuming.

[3378] All the windows consumed a lot of display space.

[3379] This solution provided only one method of input—voice—which is not always appropriate for WPC users.

[3380] By providing a single point of action—an Agent that talked to them like a person—people wanted it to work with even more natural language, but it wouldn't. The closer it was to freeform and natural language, the more people gave it ambiguous language and treated it like a real person.

[3381] Takeaways for the UI This prototype influenced several UI decisions:

[3382] The goal is to interact with and talk to the WPC just as you would talk to a person taking an appointment. However, the tool should not use 100% natural language—it is too complicated to train the system to each user's style and vocabulary. Voice can be used if the vocabulary is constrained and the user is aware at all times of which words he's allowed to say to get a job done. A semi-formal grammar can constrain the options to specific natural-language vocabulary but still cue the user about his options. It enables the WPC to meet the user halfway.

[3383] The tool should provide an environment that's not ping-pong—it should let thoughts flow naturally from one part of a task to the next. A better solution would be to let the customer rattle off all the attributes desired (such as make an appointment with Bob for Tues June 13 at 12:30 and O'Malley's). Preferably, the system would let you say those things in any order.

[3384] The tool should provide alternatives to voice input at the same time that it provides voice input—voice alone is sub-optimal because it typically involves memorization and privacy to interact. Also, all-voice doesn't expose all the commands and options very well.

[3385] Agent technology is a poor UI choice for a WPC UI. It is bolted on to a system, rather than integral to it, and inflexible in how it can be used. In addition, its anthropomorphic nature caused people to try to interact inappropriately with the WPC.

[3386] Prototype(s) C

[3387] Description The many flavors of this version seek to blend voice, audio, and hands-on use. It uses a constrained voice recognition vocabulary and presents choices along the bottom that are specific to each Applet. (This row of choices has been referred to as the “bouncing ball.” It represents the steps the user goes through to complete any task. For instance, in the Calendar Applet, the steps for making an appointment might be Who, When, Where, What.) The choices are “meta commands” that are always present and, when selected, lead to lists that show the choices available for each step of the bouncing ball. The vocabulary can cross over to other applets using the same verbs or tasks. The words you can say are all in gold. The UI offers both audio and visual prompts to guide the user from one step to the next.

[3388] What we learned There are several elements that work well about this UI:

[3389] The consistent order of the bouncing-ball choices defines a pattern that you can learn and follow to speed up interaction. It helps you learn “the idiom”—the correct order for rattling off information at natural speaking speed so the computer can follow it. It also allows a semi-formal grammar to be imposed while still supporting voice recognition.

[3390] The bouncing ball lets you see the options before you navigate with the voice—you know what the holes are that can be filled when using the Applet.

[3391] The bouncing ball choices can be either clicked like a button or spoken, supporting both hands-free and hands-on use.

[3392] The gold text visually alerts you to what can be said. If you can't see it, you can't say it.

[3393] The who/what/where/when construction is always available—you never get a blank slate.

[3394] What you do is simple:

[3395] See the choices.

[3396] Make a choice.

[3397] Get a new set of choices.

[3398] If you want to know what you can do, look at the list, the bottom bar, or the gold text.

[3399] You only learn one input method, and it always works the same, no matter what list you're using.

[3400] The goal is to get the user to adapt to the system and to have the system meet them halfway. An all-natural-language solution would have the system totally adapting to the person.

[3401] UI Methods Supplementing Other Ideas

[3402] Learning Model—attributes that characterize the preferred learning style of the user. The UI can be changed over time as the different attributes and used to model to optimal presentation and interaction modes for the UI, including user preference.

[3403] Familiarity—a simpler model that Learning, in part, it focuses on characterizing a user's learning stage. In the designs shown, there is duplication in UI information (e.g. the prompt is large at the top of the box, implicitly duplicated in the list of choices, and it also appears in the sequence of steps in the box at the bottom of the screen). As a user becomes more familiar with a procedure, the duplication can be eliminated.

[3404] User Expertise—different from Familiarity, Expertise models a user's competence with their computing environment. This includes the use of the physical components of the system, and their competence with the software environment.

[3405] Tasks—characteristics of tasks include: complexity, seriality/parallel (e.g. you may want the system to provide the current time at any random moment, but you would not being able to use the command “Repeat” without following a multi-step procedure.), association, thread, user familiarity, security, ownership, categorization, type and quantity of attention for various use modes, use, prioritization (e.g. urgent safety override), and other attributes allowing the modeling of arbitrarily complex models of a task.

[3406] Reasons to Scale:

[3407] Urgency—especially of data

[3408] Collaboration—with other's, especially if they are interacting via their computer

[3409] Security—not the same a privacy, this is weather the user and data match minimum security levels

[3410] Prominence

[3411] Prominence is the relative conspicuousness of a UI element(s). It is typically achieved through contrast with other UI elements and/or change in presentation.

[3412] Uses

[3413] Communicate Urgency

[3414] Communicate Importance

[3415] Reduce acquisition/grounding time

[3416] Reduce cognitive load

[3417] Create simplicity

[3418] Create effectiveness

[3419] Implementation

[3420] Audio

[3421] Volume, Directionality (towards front of user), Proximity, tone, ‘irritable’ sounds (i.e. fingernails across a chalkboard), and changes in these properties.

[3422] Video

[3423] Size, intensity of color, luminosity, motion, selected video device (some have greater affinity for prominence), transparency, and changes in these properties.

[3424] Haptic

[3425] Pressure, area, location on body, frequency, and changes in these properties.

[3426] Presentation Type

[3427] Haptic vs. Audio vs. Video

[3428] Multiple types (associating audio with video; or Haptic with audio, etc.)

[3429] Order of Presentation

[3430] For example, putting the most commonly needed information towards the beginning of a process.

[3431] Association

[3432] Some examples of relationships are common goal (all file operations appearing under a file menu), hierarchy, function, etc.

[3433] Uses

[3434] Convey Source or Ownership

[3435] Reduce acquisition/grounding time

[3436] Reduce cognitive load

[3437] Create simplicity

[3438] Create effectiveness

[3439] Implementation

[3440] Similar presentation (same methods as Prominence)

[3441] Proximity of layout

[3442] Contained within a commonly bounded region. E.g. group boxes and windows

[3443] Invitation

[3444] Creating a sense of enticement or allurement to engage in interaction with a UI element(s). Beginning of Exploration. “Impulse Interaction”

[3445] Uses

[3446] Create Learnability (through explorability)

[3447] Implementation

[3448] Explicit suggestion

[3449] Safety (non-destructive, reversible)

[3450] Safety (not get lost)

[3451] Familiarity

[3452] Novel/New/Different

[3453] Uniqueness (if all familiar & one new; choose new, if all strange & one familiar; choose old)

[3454] Quick/Cheap/Instant Gratification

[3455] Simplicity of Understanding

[3456] Ease of Acquisition and Invocation/Prominence

[3457] Rest/Relaxation

[3458] Wanted/Solicited/Applause

[3459] Curiosity/Glimpse/Preview

[3460] Entertainment

[3461] Esthetics/Shiny/Bright/Colorful

[3462] Promises: titillation, macabre, health, money, self-improvement, knowledge, status, control

[3463] Stimulating (multiple sense), increased rate of change

[3464] Fear avoidance

[3465] Safety

[3466] A computer can enhance the safety of the user by either providing or emphasizing information that identifies real or potential danger or suggests a course of action that would allow the user to avoid danger, or a computer can suppress the presentation of information that may distract the user from safe actions, or it can offer modes of interaction that avoid either distraction or actual physical danger. An example of the latter case is when the physical configuration of the computer itself constitutes a hazard, such as having the physical burden of peripheral devices like keyboards which occupy the hands and offer opportunity for the device to strike or become entangled with the user or environment.

[3467] Uses

[3468] Help create learnability

[3469] Help create effectiveness

[3470] Implementation

[3471] The implication that interaction will not result in unintended or negative consequences. This can be created by:

[3472] Reversibility

[3473] Clarity/Orientation cues

[3474] Familiarity (not unknown)

[3475] Metaphor (Which button is safer? Juggling chainsaws, Grandma w/tray of cookies)

[3476] Consistent Mental Model

[3477] Full disclosure

[3478] Guardian (stop me before I do something dangerous: intervention)

[3479] Advisor (if I get confused, easy to get unconfused: solicitation)

[3480] Expert Companion (helps me make good decision)

[3481] Trusted Companionship (could be golden lab)

[3482] Metaphor

[3483] A UI element(s), with a presentation that is evocative of a real world object, implying an obvious interaction and/or function (provides “meaning”).

[3484] Uses

[3485] Create Learnability

[3486] Create Simplicity

[3487] Create Effectiveness

[3488] Reduce cognitive load

[3489] Reduce acquisition/grounding time

[3490] Implementation

[3491] Examples: Recycle Bin

[3492] Sensory Analogy

[3493] Expressing (by design) a UI Building Block(s)' presentation and or interaction with a sensory experience, in order to bypass cognition (work within the pre-attentive state) and take advantage of innate sensory understanding.

[3494] Mouse/Cursor interaction.

[3495] Uses

[3496] Reduce cognitive load

[3497] Reduce acquisition/grounding time

[3498] Create simplicity

[3499] Create effectiveness

[3500] Help create learnability

[3501] Implementation

[3502] Example: Conveying the location of a nearby object by producing a buzz or tone in 3D audio corresponding to the location of the object.

[3503] Background Awareness

[3504] A Sensory Analogy with low Prominence.

[3505] A non-focus output stimulus that allows the user to monitor information without devoting significant attention or cognition. The stimulus retreats to the subconscious, but the user is consciously aware of an abrupt change in the stimulus.

[3506] Uses

[3507] Reduce cognitive load

[3508] Reduce acquisition/grounding time

[3509] Create simplicity

[3510] Create effectiveness

[3511] Help create learnability

[3512] Implementation

[3513] Example: Using the sound of running water to communicate network activity. (Dribble to roaring waterfall)

[3514] Reasons to Scale

[3515] Platform Scaling

[3516] Power Supply

[3517] We might suggest the elimination of video presentations to extend weak battery life.

[3518] Input/Output Scaling

[3519] Presentation Real Estate

[3520] Different presentation technologies typically have different maximum usable information densities.

[3521] Visual—from desktop monitor, to dashboard, to hand-held, to head mounted

[3522] Audio—perhaps headphones support maximum number of distinct audio channels (many positions, large dynamic range of volume and pitch)

[3523] Haptic—the more transducers, the more skin covered, the more resolution for presentation of information.

[3524] User Adaptive Scaling Attention/Cognitive Scaling

[3525] Use Sensory Analogy

[3526] Use Background Awareness

[3527] Allow user option to “escape” from WPC interaction

[3528] Communicate task time, urgency, priority

[3529] Privacy Scaling

[3530] Use of Safety

[3531] H/W ‘Affinity’ for Privacy

[3532] Physical Emburdenment Scaling

[3533] I/O Device selection (hands free vs. hands)

[3534] Redundant controls

[3535] Allow user option to “escape” from WPC interaction

[3536] Communicate task time, urgency, priority

[3537] Expertise Scaling

[3538] Scaling on user expertise (novice to expert). Use of shortcuts/post processing.

[3539] Implementations

[3540] These are examples of specific UI implementations.

[3541] Acknowledgement

[3542] Constrain to a single phoneme (for binary input)

[3543] L/R eye close, hand pinch interactions

[3544] Confirmation

[3545] Constrain to a single phoneme (for binary input)

[3546] L/R eye close, hand pinch interactions

[3547] Lists

[3548] For choices in a list:

[3549] Many elements: characterize with examples

[3550] Few elements: enumerate

[3551] Windows Logon on a Wearable PC Technical Details

[3552] Winlogon is a component of Windows that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a Graphical Identification and Authentication dynamic-link library (DLL)—referred to as the GINA—and any number of network providers.

[3553] The GINA is a replaceable DLL component that is loaded by the Winlogon executable. The GINA implements the authentication policy of the interactive logon model (including the user interface), and is expected to perform all identification and authentication user interactions. For example, replacement GINA DLLs can implement smart card, retinal-scan, or other authentication mechanisms in place of the standard Windows user name and password authentication.

[3554] The Problem to be Solved

[3555] The problem falls into three parts:

[3556] Provide a paradigm Windows logon (logon mechanism consistent with our UI paradigm)

[3557] Allow for private entry of logon information

[3558] Allow for security concerns (ctrl-alt-del)

[3559] Biometrics

[3560] By scanning your fingerprint, hand geometry, face, voice, retinal or iris, biometrics software can quickly identify and authenticate a user logging on to the network. This technology is available today, but requires extra hardware, and thus may not be appropriate for an immediate solution.

[3561] Biometrics is a natural fit for Wearable PCs, as they are private, secure, and provide fast, efficient logins with minimal impact on the user's physical encumbrance, or cognitive load.

[3562] Note: this is meant to be merely illustrative. The blue highlight is run around the keyboard w/the scroll wheel.

[3563] Security Concerns

[3564] Separate from ability to input passwords without speaking them “in the clear”, it would be beneficial to provide a way for users to know that they are not entering their password into a “password harvester”, a program that pretends to be the windows logon, for the purpose of stealing passwords.

[3565] The windows logon mechanism for this is to require the user to press CTRL-ALT-DEL to get to the logon program. If there is a physical keyboard attached to the WPC, this mechanism can still be used. A virtual keyboard (including the Windows On-screen keyboard) cannot be trusted for this purpose. If there is not a physical keyboard, the only other reliable mechanism is for the user to power down the WPC and power it back up (cold boot).

[3566] Interface Modes

[3567] Output Modes

[3568] The example system supports the following interface output modes:

[3569] HMD

[3570] Touch screen

[3571] Audio (partial support)

[3572] The interface's primary output mode is video, i.e., HMD or touch screen. Although the touch screen interface is fully supported, the interface design is optimized for an HMD. For this release, audio is a secondary output mode. It is not intended as a standalone output mode.

[3573] Input Modes

[3574] The example system supports the following interface input modes:

[3575] Voice

[3576] 1D Pointing Device (scroll wheel and two buttons)

[3577] 2D Pointing Device (trackball with scroll wheel and two buttons)

[3578] Touch Screen (with left and right button support)

[3579] Physical Keyboard (standard PC keyboard)

[3580] Virtual keyboard (provided as part of the example system)

[3581] Although all input modes are fully supported, the interface design is optimized for voice and for 1D pointing devices.

[3582] Hybrid 1D/2D Pointing

[3583] Moving the trackball moves the pointer. List items (and other active screen objects) provide mouse-over feedback (focus) in the form of highlighting.

[3584] Rotating the scroll wheel moves the highlighting bar up and down in the list. The list itself does not move unless the user scrolls past the last visible item, which causes the next item to scroll into view. Rotating the scroll wheel also hides and disables the pointer. The pointer becomes visible and is reactivated as soon as the trackball is moved.

[3585] Single-clicking the left button causes one of the following:

[3586] If the pointer is visible and over a valid target (a list item, the System Menu icon, the Back button, Page Up, or Page Down), then the target is selected.

[3587] If the pointer is not visible or not over a valid target, then the currently highlighted list item is selected.

[3588] Single-clicking the right button opens the system menu.

[3589] The user can abort selection by moving the pointer off any valid target before releasing the left mouse button.

[3590] The user can disable 2D pointing entirely as a system preference setting.

[3591] Interface Design

[3592] Visual Design

[3593] Layout

[3594] The example system's visual user interface consists of five basic components in a standard layout:

1

[3595] Font

[3596] By default, all text in the example system is displayed using 18-point Akzidenz Grotesk Be Bold.

[3597] Colors

[3598] Prompts are white. Speakable screen objects (can be activated using a voice command) are gold. Disabled speakable objects are dark gray/dark gold. All other text is light gray. (Commands that are permanently disabled should be removed from the list.)

[3599] Frame Components

[3600] Applet Tag

[3601] Identifies the current applet. The Applet Tag exists in the visual interface only—it has no audio equivalent.

[3602] Prompt

[3603] The prompt indicates to the user what s/he should do next. The system speaks the prompt as soon as the screen appears and displays the prompt in the designated area along the top edge of the screen. Users can issue voice commands even while the system is speaking a prompt. As soon as the system recognizes a valid voice command, it stops speaking the prompt and confirms the voice command (unless the user has disabled audio feedback for prompt confirmations, in which case it speaks the next prompt).

[3604] As a rule, audio and video prompts should use identical wording. Exceptions should be made only if alternative wording has been demonstrated to enhance usability.

[3605] Interface Fields

[3606] Interface fields serve two functions:

[3607] They reveal to users the range of appropriate responses to the current system prompt.

[3608] They allow users to communicate their responses to the system.

[3609] Four types of interaction field are supported by the example system: single selection lists, multiple selection lists, data entry fields, and trees. By default, interface fields are spoken by the system only when the user invokes the “list” command.

[3610] Lists

[3611] A list is a set of appropriate user responses to the current prompt. Each response is presented as a numbered item in the list.

[3612] In lists, the input focus—which indicates where the user's input is being directed—is shown by highlighting the currently targeted list item. Only one screen object can have the input focus at any time. By default, the first item in a list has the input focus. Selection—which indicates the current value of each list item—is shown by checking the item. Depending on the input device used, input focus and selection may or may not always move in tandem. Depending on whether the list is single or multiple selection, one or more list items may be checked at once. Unless an application specifies otherwise, focus defaults to the first list item.

[3613] Several types of visual feedback are associated with selection. On mouse-down, the selected menu item becomes checked. On mouse-up, the highlighting blinks.

[3614] Lists can contain more items than can be shown simultaneously. In this case, a scrollbar provides a visual indicator to the user that only a portion of a list is visible on the screen. When the user moves the mouse wheel beyond the last currently visible item, the next item in the list scrolls into view and becomes highlighted. List items move into view in single increments.

[3615] The size of the scroll box represents the proportion of the list content that is currently visible. The position of the scroll box within the scrollbar represents the position of the visible items within the list.

[3616] List Interaction

[3617] The Example UI supports list interaction though 1D (scroll wheel) and 2D (trackball, touch screen) pointing devices, voice commands, and keyboard.

[3618] 1D Pointing Devices

[3619] When using a scroll wheel as a 1D pointing device, the user moves the input focus by rotated the scroll wheel and makes selections by clicking the left mouse button. With 1D pointing devices, focus and selection are independent: highlighting moves whenever the scroll wheel is rotated, but a checkmark doesn't appear until the left mouse button is clicked.

[3620] When the scroll wheel is rotated, the pointer is hidden and disabled; it remains so until the pointer is moved via the trackball or other 2D input device.

[3621] Trackball

[3622] When using a trackball as a 2D pointing device, the user moves the input focus by moving the pointer over the list items and makes selections by clicking the left mouse button. As with a scroll wheel, focus and selection are independent. The UI provides mouse-over highlighting for list items, but a checkmark doesn't appear until a selection is made. The user can abort a selection by moving the pointer off a valid target before mouse-up.

[3623] Touch Screen

[3624] When using a touch screen as a 2D pointing device, touching a list item moves both the input focus and the selection to the list item; the user cannot move highlighting independently from checking. The user can abort a selection by moving the pointer off a valid target before lifting her finger.

[3625] Voice Commands

[3626] When using voice commands, the user selects a list item by speaking it. (See also the section below on coded voice commands.) As with touch screen interaction, input focus and selection always move in tandem. Users can speak a list item that isn't currently visible. In this case, the selected list item is scrolled into view before checking it to give the user visual feedback for selection.

[3627] Keyboard

[3628] When using a keyboard to interact with lists, the user moves the input focus by pressing the up and down arrows and makes selections by pressing the enter key. In this case, focus and selection can be controlled independently.

[3629] Single Selection Lists

[3630] In single selection lists, selecting one item automatically unselects all other items. The user can invoke the “Next” system command to select the list item that currently has the focus.

[3631] Multiple Selection Lists

[3632] In multiple selection lists, selecting an item toggles it between the selected and unselected state. Selecting one item has no effect on the selection status of other list items. With certain input methods (e.g., scroll wheel, keyboard arrows), selection and focus may diverge as the user moves the focus without changing the selection. At the moment a selection is made, the focus shifts to the just-selected item. With other input methods (e.g., 2D pointer, voice), the focus and selection always move in tandem. The user should invoke the “Next” system command to indicate s/he is finished selecting items in a multiple selection list.

[3633] Data Entry Fields

[3634] A data entry field is a container for free-form alphanumeric data entry and editing. It can be defined to support a single line or multiple lines of text. Characters can be entered and edited in a data entry field using a physical or virtual keyboard, voice recognition, or handwriting recognition. Like the other interface fields, data entry fields appear in the central left portion of the frame, as shown below.

[3635] Focus

[3636] To enter or edit text, the keyboard should have the input focus, which is indicated by the presence of a blinking cursor (as shown above). When the keyboard does not currently have the input focus, the input area's outline box and text colors change from white to gray, and the cursor disappears.

[3637] Because interface fields are displayed one at a time, input focus shifts to the keyboard input area automatically (e.g., when a frame with a text entry field opens, or when the user closes the system commands menu). However, keyboard and voice commands can target the input focus to specific characters within the data entry field.

[3638] Entering and Editing Data

[3639] When entering data into an empty field, characters are inserted at the cursor. As each character is inserted, the cursor moves one space to the right; the cursor always appears immediately to the right of the last inserted character.

[3640] Editing a data entry field is limited to backspacing and retyping. Backspacing when the cursor is at the end of the data string moves the input focus to the preceding character. When input is focused on a character, the character appears in reverse color within the cursor, as shown below.

[3641] Backspacing when the input focus is already over a character deletes that character and again moves the cursor back to the preceding character. Once the incorrect characters have been removed, the user can type the correct characters.

[3642] By default, the system provides only visual feedback as each character is typed. As an option, however, the user can invoke an echo mode, in which the system speaks each character as it is typed. The user can toggle echo mode on and off by pressing the “Echo” key on the virtual keyboard or by enabling echo feedback in the system preference settings.

[3643] Maximum Length

[3644] A maximum length should be specified for every data entry field, although the maximum length may be greater than the field can display simultaneously. For example, a data entry field may have a maximum length of 30 characters, even if only 15 can be displayed at once. If the user types in text that is too long to display in a data entry field, then the text scrolls to allow the user to see each times in a row, then an error message appears, explaining the maximum length for the data entry field.

[3645] Submitting and Aborting

[3646] When data has been entered to the user's satisfaction, s/he issues a voice or keyboard “Enter” command to submit the data. The data is saved to the field and the next frame is presented to the user.

[3647] If the user wishes to abort data entry (i.e., discard any changes made to the data entry field), s/he issues a “Cancel” (voice or mouse) or “Escape” command (virtual or physical keyboard).

[3648] The table below summarizes data entry field interactions with the supported input methods.

[3649] Table X. Data Entry Field Interactions

[3650] Interaction Details for Specific Input Methods

[3651] Virtual Keyboard

[3652] Users can invoke the virtual keyboard using the “Keyboard” system command. This causes the virtual keyboard to appear on the screen, as shown below. The pointer changes from an arrow to a hand. As long as the virtual keyboard has the focus, user input is limited to keys on the keyboard. (Plus some non-virtual keyboard way of escaping from the virtual keyboard.) Other interface items and other modes of input are disabled.

[3653] Speech Recognition

[3654] Users can invoke speech recognition using the “Voice entry” system command. This causes a “speech keyboard” (not yet designed) to appear, providing a list of the voice commands that are available for data entry. The pointer changes to an ear. As long as the speech keyboard has the focus, user input is limited to voice commands on the speech keyboard and valid alphanumeric characters. (Plus some non-speech way of escaping from the speech keyboard.) Other interface items and other modes of input are disabled.

[3655] Speech Error Correction

[3656] As a supplement to the standard editing methods shown above, two additional methods are provided to help the user correct speech recognition errors.

[3657] The first correction method is to invoke a database of common misinterpretations by saying “Correction.” This command, which indicates to the computer that a correction is needed, causes the system to consult the database and suggest alternatives. The system continues to suggest alternatives until the correct character is displayed or the database alternatives have been exhausted.

[3658] For example, imagine that the user says, “three,” which the system misinterprets as “e.” The database might indicate that “e” is a common misinterpretation of “g” and “3.” When the user says, “correction,” the system replaces the “e” with “g.” Since this is still incorrect, the user says, “correction,” again. This time, the system correctly replaces the “g” with “3.” The error is resolved.

[3659] In the event that the database does not contain the correct character, the user can invoke the third correction method. In this case the system treats the characters as voice-scrollable list. The user can scroll backward and forward through this list using voice commands (“previous character” and “next character”) until the correct character is displayed.

[3660] For this example, imagine that the user says, “d,” which the system misinterprets repeatedly as “z.” The user says, “delete,” which causes the “z” to disappear. Then s/he says, “e,” and the system displays “e.” Finally, s/he says, “previous character,” and the system replaces the “e” with a “d.” Alternatively, s/he could have scrolled back forward from “c” by saying, “next character.”

[3661] Handwriting Recognition

[3662] Technical Recommendation

[3663] The product PenOffice by ParaGraph (http://www.paragraph.com) or the Calligrapher SDK by the same company, are possible technologies for implementation.

[3664] Interface

[3665] Users can invoke speech recognition by using the “Handwriting” system command. This causes a “handwriting palette” (not yet designed) to appear, providing a list of the gestures that are available for data entry. The pointer changes to a hand with a pen. As long as the handwriting palette has the focus, user input is limited to commands on the handwriting palette. (Plus some non-handwriting way of escaping from the palette.) Other interface items and other modes of input are disabled.

[3666] Recognition Style

[3667] Recognition will be on a character-by-character basis, utilizing the entire screen area. The recognition will be style independent, recognizing natural letter shapes, and not requiring any new letter writing patterns (in contrast to Palm's Graphitti method). The recognition will be writing style independent, recognizing characters that are drawn as cursive, or print, including variations that occur in modern handwriting, like “all caps”, or “small caps”.

[3668] Drawing the Character

[3669] The user will be able to “draw” a character on the entire screen surface, with any appropriate 2D input modality. Note that a GlidePoint® could permit finger spelling.

[3670] The “digital ink” of the characters drawn by the user will be displayed in real time, in a high contrast color, not otherwise reserved for the UI. The figure below shows how a character might appear while being drawn.

[3671] Entering and Exiting H/W Recognition Mode

[3672] To begin entering characters with handwriting recognition mode, the user will invoke the “handwriting” system command. To exit handwriting recognition mode, the user will either:

[3673] Enter the gesture for “Enter” to complete the entry

[3674] Cancel the input from the system command menu or equivalent.

[3675] Select the next field, from the system command menu or equivalent.

[3676] Physical Keyboard

[3677] Users can use a physical keyboard to enter characters into data entry fields simply by typing on the keyboard. Visual feedback is limited to the appearance of the typed characters in the data entry field.

[3678] Data Validation

[3679] The example system supports within-field and cross-field data validation for text entry fields. When a validation error occurs, an error message appears, explaining the problem and recommending a solution.

[3680] Masking

[3681] The example system will support masking in data entry fields. Some masks are associated with a unique presentation style to help users enter data in the required format. The following table lists the masks supported for data entry fields and shows the presentation style associated with each mask.

[3682] Table XXX. Masking and Presentation Styles

[3683] Trees

[3684] A command tree is a special type of single selection list that allows commands to be organized and displayed to the user hierarchically. Indentation is used to distinguish the different levels of the hierarchy, which can extend as many as four levels.

[3685] The primary purpose of the tree is to provide “table of contents” navigation for online documentation, but it can be used wherever the user would benefit from viewing commands in a hierarchical structure (e.g., users organized into groups).

[3686] A tree includes two object types: nodes and leaves. Nodes represent branches of the tree and act as containers for leaves, other nodes, or both. Nodes are never “empty.” Leaves represent the lowest level of a branch, and consist of commands or data entry fields. Leaves are never containers. When a tree is used to make a table of contents, the leaf commands are hypertext links to the documentation.

[3687] Selecting a closed node causes that branch to expand, revealing the next level of commands, which could include either nodes or leaves or both. Selecting an open node causes that branch to collapse, hiding all lower levels. Expanding and collapsing an individual node does not affect the state of any other node, so node state is “sticky.”

[3688] The user selects a node or leaf by clicking it or speaking it. When a mouse wheel (or other 1D pointing device) is used for navigating a tree, highlighting moves from one item to the next regardless of their relative levels in the hierarchy.

[3689] Each item in a tree consists of an icon and a text string. Three icons should be provided for each tree: collapsed node, expanded node, and leaf. Two icon sets will be included in the SDK: “generic tree” and “table of contents.”

[3690] As an optional feature, nodes and leaves in a tree can be color-coded (or an additional icon?) to reveal whether they contain incomplete data entry fields. (This feature is linked to data validation.)

[3691] Another optional feature is to color code leaves that have been visited. This feature is intended primarily for trees used as tables of contents.

[3692] Below is a tree showing only top-level items: 2

[3693] Clicking the highlighted node reveals the next level below that node. 3

[3694] Task Orientation (Bouncing Ball)

[3695] The task orientation area provides navigational context to assist in orientation. It is not interactive. The behavior of the task orientation area depends on the current navigational structure.

[3696] Linear

[3697] When the user is in a linear navigation structure (i.e., a fixed sequence of frames with no branching, AKA “island of linearity”), the task orientation area displays from left to right the following items:

[3698] The selection made in the previous frame of the linear sequence (if any—not available when the user is still in the first frame of a sequence)

[3699] The prompt for the current frame (highlighted)

[3700] Prompts for upcoming frames (as many as will fit on the screen)

[3701] Non-linear

[3702] When the user is in a non-linear navigation structure, the task orientation area displays from left to right the following items:

[3703] The selections made in previous frames (as many as will fit on the screen)

[3704] The prompt for the current frame (highlighted)

[3705] The user can hide/unhide as a preference setting. If hidden then the screen real estate is available for list and app area.

[3706] Note that the transition may be jarring to the user, and some sort of smooth scrolling transition may be preferable. Further feedback to the user to indicate that they are (or are not) now in a linear process may also be preferable.

[3707] Application Area

[3708] Hypertext Navigation

[3709] The example system supports hypertext navigation in the application area by 1) converting a hypertext document's links into the items of a list (i.e., a single selection list interface field) and 2) defining a highlight appearance for hypertext links in the application area. When the user scrolls through the list items, the highlighting updates in both the list and in the application area.

[3710] Full-Screen/Partial-Screen Display

[3711] By default, the application area occupies only a portion of the total available screen area. However, the user can toggle between partial-screen and full-screen display by using the “minimize” and “maximize” system commands, one or the other of which is always available. These commands are sticky. When the application area is in full-screen mode, all other interface components are hidden except the prompt, which appears in its usual location, superimposed on the content of the application area. To minimize visual obstruction of the underlying content, the prompt is displayed using a transparent or outline font.

[3712] System commands are available as usual when the application area is in full-screen view. The “system commands” command causes the list of system commands to appear in its usual area, superimposed on the application area, using a transparent or outline font. Although the frame's interface field is hidden when the application area is in full-screen view, users can still access it through voice or 1D mouse commands. Scrolling the mouse wheel causes the interface field to become visible, superimposed on the content of the application. The interface field disappears again when the user makes a selection or after a brief timeout. If the user makes a selection using a voice command, only the selected item appears.

[3713] When the system is in full-screen view, messages (notifications) will appear and behave as usual, except that they are superimposed over the application content.

[3714] Navigating the App Area

[3715] Users can control what's visible in the application area by invoking the following commands.

[3716] Page up/down (similar to list command)

[3717] Scroll up/down/left/right

[3718] Zoom in/out

[3719] Previous/Next (page)

[3720] System Components

[3721] System Commands

[3722] To reduce recognition errors, system commands are preceded by a universal keyword. By default, the keyword is “computer,” but users can change this keyword as part of the preference settings.

[3723] Menu

[3724] The “Menu” command causes a list of all system commands to appear in a popup menu. This list appears whenever the user says, “Menu,” clicks the right mouse button, or selects the Menu icon in the upper right corner of the frame. The menu closes as soon as the user issues any system command. (Repeating the “Menu” command closes the menu without performing any other action.)

[3725] Quit Listening/Start Listening

[3726] The “quit listening” and “start listening” commands suspend and resume speech recognition. The “quit listening” command is intended primarily for use when ambient noise is misinterpreted by the system as voice commands. Although “quit listening” can be issued as a voice command, “start listening” obviously cannot.

[3727] Previous/Next

[3728] The “Previous” command navigates to the most recently viewed frame and undoes any action performed as part of the forward frame transition. Data generated by the user in the preceding frame is preserved and displayed to the user. For example, in a tree or single-selection list, the item selected earlier is highlighted; in a multiple-selection list, items selected earlier are checked; in a data entry field, characters entered earlier are present.

[3729] The “Next” command is enabled only when the user has navigated back one or more frames. This command redoes the action(s) performed the last time the user proceeded through the current frame. The application is responsible for determining when the user can go forward and what data is persisted about the frames that have been backed through. As a guideline, data already entered should be preserved for as long as possible.

[3730] Cancel

[3731] The “cancel” command is passed back to the application, which decides how to respond. The intended functionality is to allow users to escape from some well-defined sub-task without saving any input, but it applies to an application-specific chunk of functionality. The command is enabled/disabled by the application on a frame-by-frame basis. When a cancel command is issued, the system displays a warning message, the text for which is supplied by the application, which also determines the button labels and behaviors. We recommend, minimally, allowing the user to proceed with or halt the cancellation. Once the cancellation has been confirmed, the application determines the next state and functionality.

[3732] Undo

[3733] The “undo” command reverses the last keystroke-level user action performed within the current frame. It is intended primarily for use with multiple selection lists and data entry fields. If there are no actions within the frame to be undone, this command will be disabled.

[3734] List

[3735] The “list” command causes the system to speak the items currently visible in a list or tree. If the system is currently in number mode, then the system will also speak the item number.

[3736] One, Two, Three . . .

[3737] The number commands allow the user to select list items privately by speaking a number rather than a word. For example, if the second list item happens to “Dan Newell,” the user can say “computer two” and select Dan Newell without revealing the content of the interaction to anyone.

[3738] Page Up/Page Down

[3739] If the list includes more items than can be displayed simultaneously, the “page up” and “page down” meta-commands can be used to scroll additional items into view.

[3740] Exit

[3741] This command returns the user to the startup frame. Application is notified so it can prompt the user to save data.

[3742] Namespace Collisions

[3743] The following features are intended to allow developers and users manage namespace collisions between system commands and application commands.

[3744] The system will expose a standard set of system commands in the UI in two tiers:

[3745] Tier1—require no escape sequence to be accessed: back, cancel, page up, page down.

[3746] Tier2—require an escape sequence to be accessed: system commands, quit listening, list, exit, voice coding.

[3747] All system commands can be aliased by the developer or the user as part of the system configuration or by the user at runtime.

[3748] The UIF will check at runtime to make sure that there are no namespace collisions between application specific input and the un-escaped system commands. If there is a collision, and the user selects the collided action, the system will prompt the user for disambiguation.

[3749] System Status

[3750] Potentially useful information includes: vu meter, battery, speech recognition status, network connectivity.

[3751] System status—these elements will be part of every frame

[3752] Battery and network signal strength will surface when outside norm (low)

[3753] Clock and VU meter will always be on unless user turns them off

[3754] Clock appearance is toggle-able through the configuration settings

[3755] Date/time format is also configurable.

[3756] System Configuration

[3757] User can adjust the following attributes:

[3758] Sound Output

[3759] Adjust the volume.

[3760] Clock

[3761] Specify whether it is visible and which date/time format to use.

[3762] Microphone

[3763] Launch the setup wizard.

[3764] Speech Profile

[3765] Switch users.

[3766] System Command Keyword

[3767] By default, the system command keyword is “computer,” but the user can specify a different keyword.

[3768] Speech Feedback

[3769] Several types of speech feedback are available on the example system. Users can enable or disable each type of speech feedback as part of their system preferences.

[3770] Echo Commands

[3771] When the user selects an item in a list or tree, the system speaks it.

[3772] Echo Characters

[3773] As the user enters each character in a data entry field, the system speaks it.

[3774] Speak Messages

[3775] The system speaks the contents of each system message (notification) that appears.

[3776] Pointing

[3777] The user can disable 2D pointing.

[3778] Messages

[3779] Source

[3780] The WPC system will manage messages from the following sources:

[3781] Current WPC applet

[3782] Other WPC applet

[3783] WPC system

[3784] OS

[3785] The WPC system will make no attempt to manage messages from the following sources:

[3786] Non-WPC applications

[3787] Message Types

[3788] The WPC system should distinguish the following types of message and manage each type appropriately:

		Possible Dismissal
Message Type	Description	Methods
Error	Reports system and	Automatic,
	application errors to users.	Acknowledgement, or
		Decision
Warning	Warns users about the	Decision (minimally,
	possible destructive	proceed or cancel)
	consequences of a user action
	and requires confirmation
	before proceeding.
Query	Requests task-related	Decision
	information from users before
	proceeding.
Notification	Provides information	Automatic,
	presumed to be of interest to	Acknowledgement
	the user but unrelated to the
	current task.
Context-	Provides information useful for	Automatic,
appropriate	completing the current task.	Acknowledgement
Help
A unique icon for each type of message will be displayed.

[3789] Presentation Timing Within the User's Task

[3790] Users should be allowed to complete certain tasks (e.g., free-form text entry) without being interrupted by messages unrelated to the current task.

[3791] Within the H/C Dialog

[3792] Messages should be presented by the WPC at a point in the human/computer dialog when the user expects the computer to have the conversational ‘token.’

[3793] Advance Warning

[3794] The WPC should be able to provide a cue (auditory and/or visual) before presenting any message unrelated to the user's current task.

[3795] Output Modes

[3796] The WPC will present all messages in both audio and video.

[3797] Modality

[3798] All messages presented by the WPC will be modal. Since the WPC application is itself modal, the effect is that all messages will be system modal.

[3799] If the message is modal, the sound continues until the user responds or (if it is application modal) switches to another application. If the user says something out of bounds or says nothing for a certain period of time, the system repeats the message and prompts explicitly for a response.

[3800] Dismissal

[3801] Automatic Dismissal

[3802] The WPC should allow appropriate messages (notification messages and error messages that require no decision from the user) to be dismissed automatically through a timeout.

[3803] User Actions

[3804] Preemptive Abort

[3805] The WPC should allow the user to preemptively abort presentation of a notification message unrelated to the current task. (Requires advance warning.)

[3806] Acknowledgement

[3807] Users should be able to acknowledge messages using an interaction that is fast and intuitive (e.g., say or click “OK”).

[3808] Decision

[3809] In general, users should be given the opportunity to make a decision any time it would allow them to return immediately to the current task.

[3810] Deferral

[3811] Users should be able to defer rather than dismiss messages when appropriate. Deferred messages should be re-presented automatically after a specified time. Developers should determine whether deferral is appropriate and specify the re-presentation time. (In other words, it is not a requirement that users be allowed to defer all messages or to specify the re-presentation time for each message.)

[3812] Input Modes

[3813] The user should be able to acknowledge, respond to, or defer messages using the following input modes:

[3814] Voice

[3815] Mouse

[3816] Keyboard

[3817] Touchscreen

[3818] Re-grounding

[3819] If a message's timing is appropriate (see discussion above), then the WPC will help the user re-ground by presenting the next prompt immediately after the user dismisses a message.

[3820] User Preferences

[3821] Users should be allowed to

[3822] Turn off the advance warning for messages (if any)

[3823] Specify whether any messages will timeout

[3824] Users should not be allowed to

[3825] Preemptively abort messages that require an acknowledgement or decision

[3826] Modeling Building Blocks of UIS

[3827] Scaling API

[3828] User/Computer Dialog Model

[3829] This describes a technique for abstracting the functionality of computers in general, and task software in particular, from the methods used to provide the presentation of and interaction with the UI. The functional abstraction is an important part of an ideal system to dynamically scale UI.

[3830] The abstraction begins with a description of a minimum set of functional components for at least one embodiment of a practical user/computer dialog. As shown in the following Illustration 1, information takes different forms when flowing between a user and their computing environment. The computer generates and collects information with local I/O devices, including many kinds of sensors. The devices provide or receive this information from the computing environment, which may be local or remote. The user perceives computer-generated information, and controls the computing environment with both explicit indications of intent or implicit commands via unconscious gesture or pattern of behavior over time. As long the information is generated by the user or their associated environment and can be detected by the system, it is part of the dialog.

[3831] The presentation of information to the user can use any of their senses. This is also true for the user's interaction with the computer's input devices. This is a significant consideration for the abstraction because it doesn't matter which sense or body activity is being used. In other words, the abstraction supports the presentation and collection of information without regard the form it is taking.

[3832] In Illustration 2, one embodiment of minimum functional elements are shown.

[3833] Computer to User Necessary

[3834] Prompts—provides user with information regarding an available choice. Types of choices range from unconstrained to constrained. Constrained choices may be enumerated or un-enumerated.

[3835] Choice—an option that the user can select which provides information that the computer can act on

[3836] Notifications—provides user with information, but does not provide a choice

[3837] Feedback—indicates to user what choice has been made

[3838] Desirable

[3839] Content—non-interactive

[3840] Status—shows progress of system or task related process

[3841] Focus

[3842] Grouping—relationships between choices

[3843] Mode—indication of how system will respond to a choice

[3844] User to Computer Necessary

[3845] Indications—these are generated by the user to show their intention. Intentions are conveyed by selecting choices. Indications do not require a prompt predicate.

[3846] Desirable

[3847] Content—this can be any information not designed to indicate a choice to the computer.

[3848] Context—Indications and Content that are modeled in the Context Module

[3849] Patterns—though not part of explicit user intention, the collection and analysis over time of a user's indications and context can be used to control a computer.

[3850] User/Computer/Task Dialog Model

[3851] Since most of the dialog between user and compute relates to the execution of a task, the preceding defining of the important elements of a user/computer dialog is insufficient to completely abstract the task functionality from the presentation and interaction. This is due in part to the desire for the computer system to provide prompts and choices that relate to system control, not to the task.

[3852] Therefore, as shown in Illustration 3, the abstraction can be broken into two pieces:

[3853] UI Functions

[3854] Input—How Choices are Indicated

[3855] Devices are manipulated by the user. A computer system could also convert analog signals from devices into digital O/S commands, and interprets them as one of the following:

[3856] BIOS or O/S escape sequences

[3857] UI Shell commands

[3858] Output—How Information is Presented

[3859] Devices, preferences

[3860] Task Functions

[3861] Input—What Choices are Indicated

[3862] Explicit choice indication

[3863] Implicit choice indication

[3864] Output—What Choices are Available

[3865] Prompted

[3866] Enumerated

[3867] Constrained

[3868] API: APP→UIPS

[3869] 1) Element of the Dialog

[3870] Schema of dialog

[3871] get from building blocks

[3872] prompts

[3873] feedback

[3874] Syntax of Dialog

[3875] <dialog element>

[3876] content

[3877] <content metadataX>

[3878] value

[3879] </content metadataX>

[3880] </dialog element>

[3881] 2) Content of Element

[3882] may not inform UI changes

[3883] text of a prompt

[3884] 3) Task Sequence/Grammar

[3885] How do I string the elements together, navigation path, chunking

[3886] The following illustration shows chunking on a granular level: 4

[3887] If this were a graphical user interface, there were be a separate dialog box or wizard page for each item in the flow chart. In a graphical user interface, chunking on a not-so-granular level is demonstrated by including all these bits of information about creating an appointment in one dialog box or wizard page.

[3888] “navigation state” specifics whether back/next/cancel are appropriate for this step

[3889] 4) User Requirements While In-task

[3890] This step uses both of the user's hands for the duration of the step, therefore physical burdening=no hands, . . .

[3891] 5) Content Metadata

[3892] This is explicit. This data is: sensitive, not urgent, free, from my Mom

[3893] Metadata can include the following attributes:

[3894] Sensory mode to user

[3895] Characterization of its impact on cognition

[3896] Security

[3897] To

[3898] From

[3899] Time

[3900] Date

[3901] API: Application←UIPS

[3902] 1) & 2) Choices within the Task

[3903] Value+application prompt

[3904] 3) Choices About the Task

[3905] Value+system prompt

[3906] Back, cancel, next, help, exit,

[3907] API: UIPS←→CA

[3908] API: UIPS←→UI Templates

[3909] API: UIPS←→Custom Run Time UI

[3910] API: UIPS←→I/O Devices 5

[3911] Overview

[3912] An arbitrary computer UI can be characterized in the following manner.

[3913] What are the UI Building Blocks?—What are the fundamental functions of a computer's UI? The fundamental functions are at a very elemental level, such as prompts, choices, and feedback. A UI element as simple as a command button is a combination of several of these elemental functions, in that it is a prompt (the text label), a command (that is executed when the button is “pressed”), and also provides feedback (the button appears to “depress”).

[3914] How are Building Blocks grouped?—What functional structures are created from the building blocks? In Windows these would include dialog boxes, applications, and operating environments, in addition to the basic controls in Windows themselves (scroll bars, command buttons, etc.).

[3915] What are General UI Attributes—Ignoring functionality, what are the Gestalt characteristics of a well-designed UI? Some of these attributes include Learnability, Simplicity, Flexibility, and so forth.

[3916] What are the UI Building Blocks?

[3917] Elemental Functionality (Building Blocks)

[3918] In this embodiment, there are only a limited number of types of user/computer interactions:

[3919] User Acknowledgement—User is given a single choice for communication with the computer. E.g. clicking okay to acknowledge and error.

[3920] User Choices—What is meant here is the expression of a choice (that occurs in the user's mind) to the computer. Moving a cursor, typing a letter, or speaking into a microphone are manifestations of this expression.

[3921] PC Notifications—Information presented to the user that is not associated with a choice, such as status reporting.

[3922] PC Prompts—The presentation of choice(s) to the user. A command button, by its use of metaphor to imply an obvious interaction, presents a choice to the user (you can click me), and is therefore a kind of prompt.

[3923] PC Feedback—presents indications on choices the user has made, or is currently making. When the user clicks on a command button, and the button appears to become “depressed”, the button is providing feedback to the user on their choice.

[3924] User Choices

[3925] Definition: The user indicates a preference from among a set of alternatives

[3926] WIMP Examples: Choice mechanisms can be ordered by how many choices are available. Low to High:

[3927] Confirmations

[3928] Lists

[3929] Commands

[3930] Hierarchies

[3931] Data Entry

[3932] Hidden elements can be revealed in various ways. Examples include:

[3933] Scroll bar

[3934] Text to speech

[3935] Acknowledgement

[3936] Definition: INFORMING: The PC is alerting the user that it cannot complete an action, and requiring the user to acknowledge that they have received the alert (in contrast to Confirmation below, user has no choices.)

[3937] WIMP Examples

Associated
Verbs	Deficits w/WIMP	Alternatives
Acknowledge	Requires either tactile	Single choice can be mapped to
	control or speech	any utterance. I.e., blowing on
	recognition of name of	the Example: Using the
	control (e.g. “OK”)	microphone could suffice
Ignore	Usually UI is stuck in	Time out w/ reviewable
	modality	history

[3938] Confirmation

[3939] Definition: SEEKING FEEDBAcK: The PC is seeking permission from the user to complete an action that can be accomplished in more than one way, and allows a choice between the alternatives.

[3940] WIMP Examples

[3941] The examples above illustrate different presentations of confirmations in the Windows environment. Note that in the example on the right, the confirmation Building Block has been combined with other Building Blocks to provide additional functionality.

[3942] A spin control, which presents elements of an ordered set one by one, is one example of a list.

Associated
Verbs	Description	Alternatives
Breath Focus	Moving the focus (on an
Manipulation	element in the list) in a
	procedural way
	First/Last/Next/Prev/,
	mouse pointer,
Exclusive	Identifying a single	List is read to user (this is
Selection	element of the list, to the	revealing hidden
	exclusion of all other	elements), listen for
	elements	choice, indicate “yes/now”
Highlight/		Speak choice
Marking		AutoFill by character
		Grid control
		Apparently clairvoyant
		suggestions
		Keyword navigation
		Labels (e.g. alias “A”, “B”)
Inclusive	Identifying multiple	This could be the same as
selection	elements of the list	the previous two until a
		certain keyword or action is
		initiated such as saying
		“Done.”
Reorder	Changing the sort
	sequence of the list
Create/	Modifies the set.
Delete	Add a new element to the
	list/
	Remove an element from
	the list
Copy
Invoke	Where there is a single or
selection(s) -	primary function to perform
default function	on elements of the list; the
	act of triggering that
	function
Perform Func-	Where there are multiple
tion on	functions to perform on
selection(s) -	elements of the list; the act
alternate	of triggering a specific
associated	function
function
invocation
COMMANDS
		Deficits
Description	WIMP Examples	w/WIMP
Using a command, the user initiates	Toolbar buttons,	Fine motor
a new thread of execution. Icons,	program icons	control, screen
when used as short-cuts or		real-estate
representations of files, are
commands. As are toolbar buttons.
Menus are hierarchical lists, with
the leafs as commands. <CNTL>
<I> is a command.
HIERARCHIES
Description	WIMP Examples	Deficits w/WIMP
A Hierarchy is a collection of	Tree control	Lack of consistency
elements and lists that has two	menus
relationships. That of breadth,
which lists have, and depth,
which relates multiple lists.
DATA ENTRY
Description
The choice of any alpha-numeric, or special characters.
PC NOTIFICATIONS
Description	WIMP Examples	Deficits w/WIMP
Notifications provide information	Progress bar (no	Cognitive load,
to the user that is not associated	ack)	screen real estate
with a choice.
PC PROMPTS
Description	WIMP Examples	Deficits w/WIMP
Prompts surface	Any onscreen control that can be	Reading requires
choices to the	manipulated by the user.	continuous
user.	The text part of a dialog box.	attention
	Earcon.	Audio is always
	Question Mark Icon	foreground
PC FEEDBACK
Description	WIMP
Description	Examples	Deficits w/WIMP
The PC presents indications on choices	Moving the
the user has made, or is currently	mouse
making.

[3943] How are Building Blocks Grouped?

[3944] Functions

[3945] The atomic functional elements of the User Interface, such as those defined in the previous section.

[3946] Task

[3947] A Task is a specific piece of work to be accomplished.

[3948] In some embodiments, tasks are characterized with the following.

[3949] Presence—This characterizes the quality of attention that the user should devote to the task. It may be Focus, routine, or awareness. See Divided User Attention.

[3950] Complexity—includes breadth and depth of orientation

[3951] Urgency/Safety—See . . .

[3952] Exclusivity—The property of being difficult to do more than one of this kind of task. Example is phone conversations. See “Modality”

[3953] Applications

[3954] Tasks grouped by convenience.

[3955] Threads

[3956] A Thread is a path of choices with a common user goal. The path can be tracked at a variety of levels, especially the Task or Application level.

[3957] Environment

[3958] The UI shell.

[3959] What are General UI Attributes?

[3960] General UI Attributes are abstractions belonging to, or characteristics of, a User Interface as a whole. Examples include the following:

[3961] LEARNABILITY

[3962] EXPLORABILITY

[3963] FREEDOM

[3964] SAFETY

[3965] GROUNDING

[3966] CONSISTENCY

[3967] INVITATION (PARKS)

[3968] FAMILIARITY

[3969] MEMORABLE

[3970] PREDICTABILITY

[3971] SURFACING INFORMATION/CONTROLS

[3972] MENTAL MODELS

[3973] METAPHOR: SYMBOL SUGGESTING A REAL WORLD

[3974] OBJECT, IMPLYING MEANING.

[3975] SIMILE: DIFFERENT SYMBOLS TREATED AS HAVING LIKE ATTRIBUTES OR INTERACTIONS.

[3976] DIRECT MANIPULATION

[3977] By treating certain classes of visual elements as “objects” that have common interactions, used to surface common properties, (simile) we create a mental model of being able to directly manipulate these “objects”, making interaction more learnable and memorable.

[3978] TRANSFERENCE

[3979] CONSISTENCY/PREDICTABILITY

[3980] CONSISTENCY W/UNDERLYING ARCHITECTURE

[3981] Surface reality of underlying architecture.

[3982] MALLEABILITY: HOW ADAPTABLE A MENTAL MODEL IS TO BEING INTERPRETED AS A DIFFERENT BUT VIABLE MENTAL MODEL.

[3983] SINGLE MODEL OF COMMAND

[3984] Not a modal User Interface based on I/O modality.

[3985] NATURAL/INTUITIVE

[3986] SIMPLICITY

[3987] AVOIDANCE OF MODES

[3988] DIRECTNESS

[3989] AVOIDANCE OF ABSTRACTION

[3990] AVOIDANCE OF IMPLYING INFORMATION

[3991] AVOIDANCE OF SUPERFLUOUS INFORMATION

[3992] FLEXIBILITY

[3993] ADAPTABILITY

[3994] ACCOMMODATION

[3995] DEFERABILITY

[3996] Back burner/front burner—defer/activate

[3997] EXTENDABILITY

[3998] EFFECTIVENESS

[3999] EFFICIENCY

[4000] EFFORT

[4001] SAFETY

[4002] ABILITY TO WITHDRAW FROM INTERACTION

[4003] ERROR PREVENTION/RECOVERY

[4004] FORGIVENESS

[4005] HELP

[4006] Synchronizing Computer Generated Images with Real World Images

[4007] In some situations, UIs are dynamically modified so as to display information in accordance with a real-world view without using real-world physical markers. In particular, the system displays virtual information on top of the user's view of the real world, and maintains that presentation while the user moves through the real world.

[4008] Some embodiments include a context-aware system that models the user, and uses this model to present virtual information on a display in a way that it corresponds to the user's view of the real world, and enhances that view.

[4009] In one embodiment, the system displays information to the user in visual layers. One example of this is a constellation layer that displays constellations in the sky, based on the portion of the real-world sky that the user is viewing. As the user's view of the night sky changes, the system shifts the displayed virtual constellation information with the visible stars. This embodiment is also able to calculate & display the constellation layer during the day, based on the user's location and view of the sky. This constellation information can be organized in a virtual layer that provides the user ease of use controls, including the ability to activate or deactivate the display of constellation information as a layer of information.

[4010] In a further embodiment, the system groups various categories of computer-presented information related to the commonality of the information. In some embodiments, the user chooses the groups. These groups are presented to the user as visual layers. These layers of grouped information can be visually controlled (e.g., turned off, or visually enhanced, reduced) by controlling the transparency of the layer.

[4011] Another embodiment presents information about nearby objects to the user, synchronized with the real world surroundings. This information can be displayed in a variety of ways using this layering technique of mapping virtual information with the real-world view. One example involves enhancing the display of ATMs to a user searching for ATMs. Such a layer could be displayed in a layer showing streets and ATM locations, or such a layer could display the ATM's location near the user. Once the user has found the ATM being desired, the system could turn off the layer automatically, or based on the user's configuration of the behavior, simply allow the user to turn off the layer.

[4012] Another embodiment displays a layer of information, on top of the real-world view, that shows information represents the path the user traveled between different points of interest. Possible visual clues (bread crumbs) could be any kind of visual image, like a dashed line, or dots, to represent the route, or path, the user traveled. One example involves a user searching a parking garage for a lost car. If the user cannot remember where the car is parked, and the user is searching the parking garage, the system can trace the search-route and help the user avoid searching the same locations by displaying that route. In a related situation, if the bread-crumb trail was activated when the user parked the car, the user could turn on that layer of information and follow the virtual trail as it displays to the user in real-time, adjusting to the user's view, thus leading the user directly back to the parked vehicle. This information could also be displayed as a bird's-eye view, showing the path of the user relative to a map of the garage.

[4013] Another embodiment displays route information as a bird's-eye view showing a path relative to a map. This information is presented in overlaid, transparent, layers of information and can include streets, hotels and other similar information related to a trip.

[4014] The labeling and selection of a particular layer can be provided to the user in a variety of methods. One example provides labeled tabs, like on hanging folders that can be selected by the user.

[4015] The system accomplishes the task of presenting virtual information on top of real-world information by various means. Three main embodiments are tracking head positions, tracking eye positions, and real world pattern recognition. The system can also use a combination of these aspects to obtain enough information.

[4016] The head positions can be tracked by a variety of means. Three of these are inertial sensors mounted on the user's head, strain gauges, and environmental tracking of the person. Inertial sensors worn by the user can provide information to the system and help it determine the real-world view of the user. An example of inertial sensors is some kind of jewelry to detect the turns of a user's head. Strain gauges, for example, embedded in a hat, or the neck of clothing, measure two axes: left and right, along with up and down. The environment can also provide information to the system regarding the user's head and focus. The environment can provide pattern-matching information of the user's head to help indicate the visual interest of the user. This can occur from a camera watching head movements, like in a kiosk or other such booth, or any camera that can provide information about the user. Environmental sensors can perform triangulation based on a single beacon, or multiple beacons, transmitting information about the user, and the user's head & eyes. The sensors of a room, or say a car, can triangulate information about the user and present that information to the system for further use by the system for determining the user's view of the real-world. Also, the reverse works, where the environment broadcasts information about location, or distance from one the sensors in the environment, such that the system can perform the calculations without needing to broadcast information about the user.

[4017] The user's system can track the eye positions of the user for use in determining the user's view of the real world, which can be used by the system to integrate the presentation of virtual information with the user's view of the real world.

[4018] Another embodiment involves the system performing pattern recognition of the real world. The system's software dynamically detects the user's view of the real world and incorporates that information when the system determines where to display the virtual objects such that they remain integrated while the user moves about the real world.

[4019] Those skilled in the art will also appreciate that in some embodiments the functionality provided by the routines discussed above may be provided in alternative ways, such as being split among more routines or consolidated into less routines. Similarly, in some embodiments illustrated routines may provide more or less functionality than is described, such as when other illustrated routines instead lack or include such functionality respectively, or when the amount of functionality that is provided is altered. In addition, those skilled in the art will appreciate that the data structures discussed above may be structured in different manners, such as by having a single data structure split into multiple data structures or by having multiple data structures consolidated into a single data structure. Similarly, in some embodiments illustrated data structures may store more or less information than is described, such as when other illustrated data structures instead lack or include such information respectively, or when the amount or types of information that is stored is altered.

[4020] From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims and the elements recited therein. In addition, while certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any available claim form. For example, while only some aspects of the invention may currently be recited as being embodied in a computer-readable medium, other aspects may likewise be so embodied. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.

[4021] What is claimed is:

Claims

1. A method for dynamically determining an appropriate user interface to be presented to a user of a computing device based on a current context, the method comprising: for each of multiple predefined user interfaces, characterizing multiple properties of the predefined user interface; dynamically determining one or more current needs for a user interface to be presented to the user; and selecting for presentation to the user one of the predefined user interfaces whose characterized properties correspond to the dynamically determined current needs.

2. The method of claim 1 including presenting the selected predefined user interface to the user.

3. The method of claim 1 wherein the computing device is a wearable personal computer.

4. The method of claim 1 wherein the current context is represented by a plurality of context attributes that each model an aspect of the context.

5. The method of claim 1 wherein the current context is a context of the user.

6. The method of claim 1 wherein the selecting is performed at execution time.

7. The method of claim 1 wherein the dynamic determining and the selecting are performed repeatedly so that the user interface that is presented to the user is appropriate to the current needs.

8. The method of claim 1 wherein the dynamic determining and the selecting are performed repeatedly so that the user interface that is presented to the user is optimal with respect to the current needs.

9. The method of claim 1 wherein the determining of the current needs includes at least one of characterizing UI needs corresponding to a current task being performed, characterizing UI needs corresponding to a current situation of the user, and characterizing UI needs corresponding to current I/O devices that are available.

10. The method of claim 1 wherein the determining of the current needs includes characterizing UI needs corresponding to a current task being performed, characterizing UI needs corresponding to a current situation of the user, and characterizing UI needs corresponding to current I/O devices that are available.

11. The method of claim 1 wherein the determining of the current needs includes characterizing a current cognitive availability of the user and identifying the current needs based at least in part on the characterized current cognitive availability.

12 The method of claim 1 wherein the determining and the selecting are performed without user intervention.

13. The method of claim 1 wherein the selected user interface includes information to be presented to the user and interaction controls that can be manipulated by the user.

14. The method of claim 1 including monitoring the user and/or a surrounding environment of the user in order to produce information about the current context.

15. The method of claim 1 wherein the determined current needs are based at least in part on the current context.

16. The method of claim 1 including customizing the selected user interface based on the user before presenting of the customized user interface to the user.

17. The method of claim 1 including adapting the selected user interface to a type of the computing device before presenting of the adapted user interface to the user.

18. The method of claim 1 including adapting the selected user interface to a current activity of the user before presenting of the adapted user interface to the user.

19. The method of claim 1 wherein the determining of the current needs is based at least in part on the user being mobile.

20. A computer-readable medium whose contents cause a computing device to dynamically determine an appropriate user interface to be presented to a user of a computing device, by performing a method comprising: for each of multiple predefined user interfaces, characterizing properties of the predefined user interface; dynamically determining one or more current needs for a user interface to be presented to the user; selecting for presentation to the user one of the predefined user interfaces whose characterized properties correspond to the dynamically determined current needs; and presenting the selected user interface to the user.

21. The computer-readable medium of claim 20 wherein the computer-readable medium is a memory of a computing device.

22. The computer-readable medium of claim 20 wherein the computer-readable medium is a data transmission medium transmitting a generated data signal containing the contents.

23. The computer-readable medium of claim 20 wherein the contents are instructions that when executed cause the computing device to perform the method.

24. A computing device for dynamically determining an appropriate user interface to be presented to a user of a computing device, comprising: a first component capable of, for each of multiple defined user interfaces, characterizing properties of the defined user interface; a second component capable of determining during execution one or more current needs for a user interface to be presented to the user; and a third component capable of selecting during execution one of the defined user interfaces whose characterized properties correspond to the dynamically determined current needs, the selected user interface for presentation to the user.

25. The computing device of claim 24 wherein the first, second and third components are executing in memory of the computing device.

26. A computer system for dynamically determining an appropriate user interface to be presented to a user of a computing device, comprising: means for, for each of multiple defined user interfaces, characterizing properties of the defined user interface; means for determining during execution one or more current needs for a user interface to be presented to the user; and means for selecting during execution one of the defined user interfaces whose characterized properties correspond to the dynamically determined current needs, the selected user interface for presentation to the user.

27. A method for dynamically determining an appropriate user interface to be presented to a user of a computing device based on a current context, the method comprising: determining multiple user interface elements that are available for presentation on the computing device; characterizing properties of the determined user interface elements; dynamically determining one or more current needs for a user interface to be presented to the user; and generating a user interface for presentation to the user, the generated user interface having user interface elements whose characterized properties correspond to the dynamically determined current needs.

28. The method of claim 27 including presenting the generated user interface to the user.

29. The method of claim 27 wherein the dynamic determining and the generating are performed repeatedly so that the user interface that is presented to the user is optimal with respect to the current needs.

30. The method of claim 27 wherein the determining and the generating are performed without user intervention.

31. The method of claim 27 including retrieving one or more definitions for combining available user interface elements in an appropriate manner so as to satisfy current needs, and wherein the generating of the user interface uses at least one of the retrieved definitions to combine the user interface elements of the generated user interface in a manner that is appropriate to the determined current needs.

32. The method of claim 27 including retrieving one or more definitions for adapting available user interface elements to a type of computing device, and wherein the generating of the user interface uses at least one of the retrieved definitions to combine the user interface elements of the generated user interface in a manner specific to the type of the computing device.

33. A method for dynamically presenting an appropriate user interface to a user of a computing device based on a current context, the method comprising: presenting a first user interface to the user; without user intervention, determining that the current context has changed in such a manner that the first user interface is not appropriate for the user; selecting a second user interface that is appropriate for the user based at least in part on the current context; and presenting the second user interface to the user.

34. The method of claim 33 wherein the determining that the current context has changed in such a manner that the first user interface is not appropriate for the user includes automatically detecting the changes.

35. The method of claim 33 wherein the selecting of the second user interface is performed without user intervention.

36. The method of claim 33 wherein the second user interface is one of multiple predefined user interfaces.

37. The method of claim 33 wherein the second user interface is dynamically generated after the determining of the changes in the current context.

38. The method of claim 33 wherein the second user interface is a modification of the first user interface.

39. The method of claim 38 wherein the modifying of the first user interface (“UI”) includes modifying prominence of one or more UI elements of the first user interface, modifying associations between the UI elements, modifying a metaphor associated with the first user interface, modifying a sensory analogy associated with the first user interface, modifying a degree of background awareness associated with the first user interface, modifying a degree of invitation associated with the first user interface, and/or modifying a degree of safety of the user based on one or more indications presented as part of the second user interface that were not part of the first user interface.

40. A method for characterizing predefined user interfaces to allow a user interface that is currently appropriate to be presented to a user of a computing device to be dynamically selected, the method comprising: for each of multiple predefined user interfaces, characterizing the user interface by, determining an intended use of the predefined user interface; determining one or more user tasks with which the predefined user interface is compatible; and determining one or more computing device configurations with which the predefined user interface is compatible, so that one of the predefined user interfaces can be dynamically selected for presentation to a user based on the selected user interface being currently appropriate.

41. The method of claim 40 including determining information about a current context and selecting one of the predefined user interfaces that is appropriate for the current context.

42. The method of claim 40 wherein the characterizing of each of the predefined user interfaces includes at least one of characterizing content of the user interface, characterizing a cost of using the user interface, characterizing a relevant date for the user interface, characterizing a design of elements of the user interface, characterizing functions of the elements of the user interface, characterizing hardware affinity of the user interface, characterizing an identification of the user interface, characterizing an importance of the user interface, characterizing input and output devices that are compatible with the user interface, characterizing languages to which the user interface corresponds, characterizing a learning profile of the user interface, characterizing task lengths for which the user interface is compatible, characterizing a name of the user interface, characterizing physical availability of the user interface, characterizing a power supply of the user interface, characterizing a priority of the user interface, characterizing privacy supported by the user interface, characterizing processing capabilities used for the user interface, characterizing safety capabilities of the user interface, characterizing security capabilities of the user interface, characterizing a source of the user interface, characterizing storage capabilities used for the user interface, characterizing audio capabilities of the user interface, characterizing task complexities compatible with the user interface, characterizing themes corresponding to the user interface, characterizing an urgency level for the user interface, characterizing a user attention level for the user interface, characterizing user characteristics compatible with the user interface, characterizing user expertise levels compatible with the user interface, characterizing user preference accommodation capabilities of the user interface, characterizing a version of the user interface, and characterizing video capabilities of the user interface.

43. The method of claim 40 wherein the characterizing of each of the predefined user interfaces is performed without user intervention.

44. A method for dynamically determining requirements for a user interface that is currently appropriate to be presented to a user of a computing device based on a current context, the method comprising: dynamically determining one or more current characteristics of a user interface that is currently appropriate to be presented to the user, the determining based at least in part on the current context; and identifying at least some of the determined characteristics as requirements for a user interface that is currently appropriate to be presented to the user.

45. The method of claim 44 including determining a user interface that satisfies the determined requirements and presenting the determined user interface to the user.

46. The method of claim 44 wherein the determining of the current characteristics includes determining characteristics corresponding to a current task being performed, determining characteristics corresponding to a current situation of the user, and/or determining characteristics corresponding to current I/O devices that are available.

47. The method of claim 44 wherein the determining of the current characteristics is performed without user intervention.

48. A method for dynamically determining requirements for a user interface that is currently appropriate to be presented to a user of a computing device, the method comprising: dynamically determining one or more current characteristics of a user interface that is currently appropriate to be presented to the user, the determining based at least in part on a current task being performed by the user; and identifying at least some of the determined characteristics as requirements for a user interface that is currently appropriate to be presented to the user.

49. The method of claim 48 including determining a user interface that satisfies the determined requirements and presenting the determined user interface to the user.

50. The method of claim 48 wherein the determining of the current characteristics is performed without user intervention.

51. A method for dynamically determining requirements for a user interface that is currently appropriate to be presented to a user of a computing device, the method comprising: dynamically determining one or more current characteristics of a user interface that is currently appropriate to be presented to the user, the determining based at least in part on a current I/O devices that are available to the computing device; and identifying at least some of the determined characteristics as requirements for a user interface that is currently appropriate to be presented to the user.

52. The method of claim 51 including determining a user interface that satisfies the determined requirements and presenting the determined user interface to the user.

53. The method of claim 51 wherein the determining of the current characteristics is performed without user intervention.

54. A method for dynamically determining requirements for a user interface that is currently appropriate to be presented to a user of a computing device, the method comprising: dynamically determining one or more current characteristics of a user interface that is currently appropriate to be presented to the user, the determining based at least in part on a current context of the user; and identifying at least some of the determined characteristics as requirements for a user interface that is currently appropriate to be presented to the user.

55. The method of claim 54 including determining a user interface that satisfies the determined requirements and presenting the determined user interface to the user.

56. The method of claim 54 wherein the determining of the current characteristics is performed without user intervention.

57. A method for dynamically determining characteristics of a user interface that is currently appropriate to be presented to a user of a computing device, the method comprising: dynamically determining a level of attention which the user can currently give to the user interface; and dynamically determining one or more current characteristics of a user interface that is currently appropriate to be presented to the user based at least in part on the determined level of attention.

58. The method of claim 57 including determining a user interface that includes the determined characteristics and presenting the determined user interface to the user.

59. The method of claim 57 wherein the determined level of attention is based on a determined current cognitive load of the user.

60. The method of claim 57 wherein the determining of the current characteristics is performed without user intervention.

61. The method of claim 57 wherein the determining of the level of attention is performed without user intervention.

62. A method for determining techniques for dynamically generating an appropriate user interface to be presented to a user of a computing device, the method comprising: retrieving one or more definitions for dynamically combining available user interface elements in an appropriate manner so as to satisfy current needs; and selecting one of the retrieved definitions based on current conditions so that available user interface elements can be combined in an appropriate manner to generate a user interface that is appropriate to be presented to the user.

63. The method of claim 62 including using the selected definition to generate a user interface that is appropriate to be presented to the user and presenting the generated user interface to the user.

64. The method of claim 62 wherein the selecting of the retrieved definition is performed without user intervention.

65. A method for determining techniques for dynamically generating an appropriate user interface to be presented to a user of a computing device, the method comprising: retrieving one or more definitions for dynamically adapting available user interface elements to a type of computing device; and selecting one of the retrieved definitions based on current conditions so that available user interface elements can be adapted to the type of the computing device so as to generate a user interface that is appropriate to be presented to the user.

66. The method of claim 65 including using the selected definition to generate a user interface that is appropriate to be presented to the user and presenting the generated user interface to the user.

67. The method of claim 65 wherein the selecting of the retrieved definition is performed without user intervention.

68. A method for dynamically determining an appropriate user interface to be presented to a user of a computing device based on a current context, the method comprising: determining multiple user interface elements that are available for presentation on the computing device; and characterizing properties of the determined user interface elements, so that available user interface elements whose characterized properties are appropriate for a current context can be selected and combined in an appropriate manner to generate a user interface that is appropriate to be presented to the user

69. The method of claim 68 including combining available user interface elements whose characterized properties are appropriate for a current context in order to generate a user interface that is appropriate to be presented to the user and presenting the generated user interface to the user.

70. The method of claim 68 wherein the characterizing of the properties is performed without user intervention.