2002 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2002 Table of Contents


VELOCITY: RETHINKING THE ORGANIZATION OF UTTERANCE BASED DYNAMIC DISPLAY

Presenter: Christine Scally
Organization: Clark County School District
Address: 1330 Challenge Lane
City: Las Vegas
State/Province/Region: NV
Zip/Postal Code: 89110
Country: USA
Day Phone: (702) 799-2372
Fax: (702) 799-2379
Email: spin@lvcm.com

The initiative to rethink the design of dynamic display communication systems emerged from experience with the devices of several students. There were some successes, but for the most part, regardless of how the device was set up, it seemed that the content and organization were difficult for students and their support staff to learn. The task of communicating with the device was laborious. When speaking, the students' energies were directed toward operating the device and determining the location of vocabulary, not toward getting their point across. Device-mediated communication, even when that was the goal of all persons involved, was frustrating far more often than it was enjoyable or even effective. The goal of Velocity's development was to create a fast utterance based dynamic display communication system that was easy to learn and use.

In order to meet this goal, two parameters were established.
1. The configuration of pages needed to be visually informative and consistent, and
2. It needed to expand indefinitely without sacrificing the consistency and efficiency of navigation.

This presentation considers the second parameter. It provides a narrative of the development process and describes how certain, seemingly innocent decisions during that process impacted the final design. Outcomes of the process are demonstrated using the Velocity configuration as realized on the Enkidu Research Portable Impact Tablet.

There were two development tasks related to achieving efficiency, consistency, and expandability.
1. Identifying the functional components of the system, and
2. Organizing these components into a configuration.

These tasks did not occur in strictly linear fashion. Knowledge of the necessary functional components was a starting point for organizing the configuration. The process of organizing revealed the need for additional components. The majority of dynamic display devices utilize the same basic user interface, i.e. buttons, arranged in grids, on pages. Design considerations were, therefore, limited to components applicable to such an interface.

Task 1: Identifying the Functional Components of the Configuration.

Avoiding the State of the Art

Specific devices and software offer different options for establishing this user interface. Within a single product, some options are easier to use than others, and different commercially available products prioritize the options differently. The availability and ease of options sways the development of a configuration of pages in a given device. In order to open Velocity to the greatest number of possibilities, it was initially designed on paper, not in software. The initial development question was, "What actions must a dynamic display device be able to perform if an individual is going to use it to communicate?" In other words, "What is necessary?" The question, "What is available?" was not asked until the initial design concept was complete.

Task Analysis

Components were identified, organized and then constrained so that only necessary options were considered. This process was a necessary first step toward the task of visually marking components for the user. It also provided organizational options, and ensured that communication functions were accounted for in the overall configuration

Both single actions and action groups were considered as functional components. An action group was defined as a group of single actions that, taken together, serve a single purpose. For example, clear, backspace, and delete word, are each single actions, as a group they serve a single purpose: making changes to text in the editing window. Single actions and action groups both have physical corollaries or containers within a button grid interface. Single actions are contained in buttons; groups are contained in pages and panels. Panels are a somewhat artificial concept on a standard button grid. A panel is a group of on or more buttons grouped geographically on a page, e.g., a row, a column, or a quadrant. From a functional perspective, a panel contains an action group that serves a different purpose than the other buttons on the page. While artificial, panels are a necessary concept in dynamic display because every page needs at least one navigation button.

Outcomes

Seven specific actions were identified, and organized into three general classes: communication actions, control actions, and navigation actions. Each specific action was defined as an outcome of button selection. For example, the action complete utterance, received the definition, "Upon selection, the button speaks a complete utterance which may consist of a word, phrase or sentence." Functional groups of these actions were assembled, defined, and assigned to either a panel or a page depending on the size of the group and its specific function. Five communication pages, two control panels, two navigation pages, and one navigation panel were defined.

Task 2: Organizing the Components into a Configuration

Avoiding the State of the Art

Conceptually, most existing dynamic display page configurations have a main screen or front page with other pages attached behind it like chapters in a book or branches in a tree diagram. This organization makes sense. The basic metaphor for dynamic display is a communication book in the same way that the basic metaphor a personal computer is a filing cabinet. A dynamic display configuration is a book of symbol-pages, realized in software and given a voice. The editing interfaces of dynamic display devices are designed to help the programmer design these books. Developing the organization of Velocity began with dropping the metaphor. This meant examining the act of communication and building from there.

Task Analysis

The first step was to provide a level of baseline consistency and efficiency within the configuration, beginning with a communication page. A single nonspecific communicative situation was examined. Two questions were asked. "What kinds of talk occur frequently within the situation?" and "Do these "kinds of talk" flow one to the other in predictable fashion or is their order more or less random within in a situation?" The "kinds of talk" were defined in task one as the communication action groups or page types. Baseline efficiency and consistency were achieved by weighting the need to access each of the groups within a situation, and providing access to the groups consistently according to weight.

The second step was to provide for expandability within the system. Expandability was considered at the level of the communication page, and at the level of the configuration.

Outcomes: Consistency and Efficiency

Within a communicative situation, an augmentative device user may, at any time, need to use utterances that are predictable within that situation, perform conversational control tasks, bring up or respond to current topical comments, or generate novel utterances. These tasks related directly to four of the five communication groups identified in task one. The flow from one task to another within a situation was determined to be frequent and unpredictable, the flow from situation to situation was determined to be infrequent and somewhat more predictable. A weight was assigned to each of these groups with respect to each of the other groups according to frequency and predictability. Each page was then assigned a panel to provide single keystroke access to,
1. high priority groups,
2. a central hub (which provides navigation access to low priority groups), and
3. navigation history (back).

Outcomes: Expandability

The system described above works extremely consistently and efficiently as long as each communication group requires only one page. Velocity has 24 buttons per page. Taking up an entire column and row with navigation and control, places an extreme limit on the space available for communication buttons. This problem was resolved through the addition of virtual space to the communication pages. Virtual navigation buttons call up a token page for a single button selection, because of this; Token pages can be placed in the system without affecting overall organization or efficiency of the system. Use of this virtual space allows each communication page in Velocity to have between 15 and 345 one or two keystroke utterances.

A similar device was used to provide expansion within the overall system. The central hub, which in the final version of Velocity was called the Index, is a single page. Adding secondary navigation pages increased expandability. These pages attach only to the Index and contain only buttons that navigate to situation pages. Including the secondary navigation pages in the system made it one keystroke less efficient for transitions from one situation to another. In its final conceptualization, with 24 buttons per page, Velocity is expandable to 345 pages that are never more than three keystrokes from one another.


Go to previous article 
Go to next article 
Return to 2002 Table of Contents 
Return to Table of Proceedings


Reprinted with author(s) permission. Author(s) retain copyright.