Despite tremendous improvements in computer systems over the past several decades, designing and developing interaction techniques is still a difficult task, especially for highly interactive immersive 3D environments, such as Augmented Reality (AR), Mixed Reality (MR) and Virtual Reality (VR). Interaction in immersive environments involves many different types of user input and many devices with which that input is provided, such as position and orientation trackers, voice input, and haptic devices, in addition to conventional mice, trackballs, touch screens, and keyboards. While there is an increasing number of wellknown metaphors for immersive interaction, such as "the virtual hand" [3], "ray pointer" [3], and "flashlight pointer" [12], there is still much variation in how these metaphors are implemented.

Interaction techniques involve the mapping of data from input devices to application semantics. Therefore, we find it particularly attractive to use a dataflow approach to the design of interaction techniques, in which data is processed through a customizable network. We introduce the Unit framework [16], which allows users to specify 2D and 3D interaction techniques as dataflows and to modify them in running programs. We use our framework to abstract interaction techniques from applications that use them, as well as from input devices that control them. This allows users to flexibly configure and dynamically change interaction technique behavior, independent of both input devices and applications. Furthermore, in our framework, a dataflow can be easily distributed over multiple machines to create distributed interaction techniques, as well as distributed applications. As shown in Figure 1, we use a directmanipulation, visual-programming representation to specify the behavior of the dataflow in the Unit User Interface (Unit UI), which itself is implemented with Unit.

In the remainder of this paper, we first present related work in Section 2, followed by brief introductions to the Unit framework and the prototype Unit UI in Sections 3 and 4. To explain how Unit can be used, we describe some example interaction techniques that we have developed with it in Sections 5, 6 and 7: a novel flexible pointer for selecting objects in 3D environments (Figure 2) [15], an experimental setup for analyzing non-verbal features of speech [17], and a quickly prototyped rotationally sensitive mouse (Figure 3), created from a pair of conventional mice. We describe our implementation in Section 8, and present our conclusions and future work in Section 9.

Data flow programming and directed-graph-based visual programming languages have been used together by a number of researchers to design 2D UIs and interaction techniques. Projects that take this approach have included Smith's InterCONS [19], Borning's ThingLab [2], and Maloney and Smith's Morphic user interface framework [14] for Self [21]. A key issue here is the recognition that interaction techniques essentially map the outputs (and inputs) of interaction devices to the inputs (and outputs) of applications; this observation has long been an underlying theme of work on building formal models of abstract graphical input devices, which in turn can be composed together in graphs to create hierarchical input devices [1,4].

Most 3D interaction techniques can be conceptualized this way, and 3D toolkits that embody these techniques (e.g., [10,22,23,24]) typically use abstract input devices. We have chosen to abstract the interaction technique components in a similar fashion to BodyElectric [11], ICON [5] and InTml [6] (See Figure 4.) As in these systems, our components are dataflow graphs, which are assembled into customized interaction techniques. In contrast to InTml, whose developers emphasize their XML-based specification language, we have chosen to focus on an interactive design process in which interaction techniques can be modified at runtime. We have also been more concerned with design issues that are typical for highly interactive distributed environments, such as AR/MR/VR, which distinguishes our framework from systems targeted for a user on a single computer, such as ICON. While BodyElectric also addressed 3D virtual environments, its dataflow operated on only a single machine (a Macintosh that controlled one or more SGI workstations). In contrast, Unit's dataflow graph can be spread across multiple machines.

Our approach allows the development of flexible interaction techniques, portions of which can be distributed, as well as replaced and remapped at runtime, and we provide a user interface for visual dataflow programming of these behaviors, as well as a programming API. While the directmanipulation creation of 3D widgets is an appealing approach [25], we have chosen a dataflow language for its clear depiction of the mapping between device outputs and application inputs. While our work on Unit primarily applies this approach to the design of experimental 3D interaction techniques, we also believe it is of significant relevance to the design of new input devices (e.g., [7,8,20,13,18,9]).

The Unit framework uses the concept of units to represent the nodes in the data flow. Each unit has any number of properties and any number of connections to properties in other units, as shown in Figure 5. When a property is updated, a special method is called, which by default updates all connected properties. Customized units typically override this method with their own data processing, and when done, typically redirect to the default method. These connections can also be made over the network, allowing each unit in the dataflow to be able to share its properties and listen to property changes, anywhere on the network. These simple rules allow the design of flexible and customizable units that specify the desired behavior through their combination into Unit Graphs, much like electrical circuits.

As mentioned above, the key components of a unit are its properties and the ability to maintain and update connections to properties in other units.

Properties are attribute-value pairs, in which the value can be a pointer to any Java Object.

Connectivity is peer-to-peer, where only the involved units are aware of their connections and are solely responsible for administering their relationships. Connections between two units are typically accomplished by reference, with the data pointer of the source property initially copied to the target property. When an update is made, the target unit is notified that the data has changed. We also provide the ability to make connections by value, in which each update replicates the data in the source unit; however, connections by reference are typically preferred for efficiency. In addition, connections can be created through a chain of references to fields and methods in the property value, provided that the resulting source and target values are of the same data type. These references are more expensive since they require dereferencing, evaluation, and replication.

Figure 6 shows a simple example in which two mice are used to provide six-degree-of-freedom control of an application.

Connections can be transparently distributed over Java Remote Method Invocation (RMI), with the addition of the hostname in the specification of the connection. Following the peer-to-peer approach, each unit is individually distributed through the RMI registry and directly accessible to other units.

This distribution approach allows parts of Unit Graphs to be distributed over an arbitrary number of applications running on an arbitrary number of machines. A common problem in immersive environments is the use of hardware, such as six-degree-of-freedom trackers, that have a permanent physical connection to a single machine. Unit not only allows cross-platform access to platform-specific devices, but also simplifies the sharing of machine-specific devices.

Our framework allows several Unit Graphs running on dif- ferent machines or within different programs on the same machine, to communicate as a single graph, providing transparent access to data and flow control from anywhere.

Unit, the core class, which is the superclass of all units, provides the general unit functionality, which most importantly is the handling of properties, connections, and distribution. Two units are connected by specifying the source unit, source property, target unit, and target property, and an optional host name (for remote connections).

We have also implemented a set of core units that provide additional functionality. These include units for flow control, such as switches and multiplexers, units for scalar and vector operations, and units for I/O (multiple mice, keyboards, six-degree-of-freedom sensors, speech recognition/synthesis).

The units are arranged in a class hierarchy under the Unit superclass. It is easy to implement new units, which typically involves overriding the changeProperty method that is called on every property update. Most core units have a set of reserved property names that are used for their specific input and output properties.

We created the Unit UI, shown in Figure 6, to allow users to design, manipulate, and visualize the dataflow in a Unit Graph.

The Unit UI lets the user add, modify and delete units, properties and connections, as well as load and save Unit Graphs. Besides visually displaying the dataflow as directed graphs with units, properties and connections, live data propagation is visualized by highlighting a property for a short time after it is updated. The user can also switch to live views of values of interest.

The Unit UI was implemented with units, using the same dataflow approach as the interaction techniques it manipulates-demonstrating that our framework does not restrict itself to interaction technique specification, but also applies to traditional application logic. Unit UI is a 3D application, and can thus coexist in the immersive environment, sideby-side with the interaction techniques whose behavior it controls. However, because of the limited field-of-view and low (800×600) resolution of our head-worn displays, we find it more productive to interact with the Unit UI in 2.5D on high-resolution (1920×1200) 24" desktop displays.

In the following sections, we describe our experience with Unit by presenting some of the experimental interaction techniques that we have developed with it.

Figure 7. The dataflow for the tweaking code that manipulates the parameters in the flexible pointer through a mouse with a thumb-controlled joystick. Clicking the second mouse button alternates the parameter to be modified, while the movement of the mouse changes the value. The result is accessible in the unit named "parameters" at the bottom, which is remotely con-

We have implemented a novel interaction technique, called the Flexible Pointer [15], which is an extension of existing ray-casting techniques for selection in immersive environments. The flexible pointer allows the user to point around objects, with a curved arrow, for selection of fully or partially obscured objects, as well as to more clearly point out objects of interest to other users in a collaborative environment. The flexible pointer, shown in Figure 8, reduces ambiguity by avoiding obscuring objects, which would have been selected with traditional ray-casting techniques.

The flexible pointer also has a visual advantage in situations in which it is easy to point out an object, without obstructing the object of interest, while still providing a continuous line from the user to the target.

The problems that we address with the Unit framework are how users can control the pointer, and how we can interactively modify and tweak this mapping, at runtime and during the design phase.

First, we have to decide on a representation for the geometry of the flexible pointer. We choose a Quadratic Bézier spline, where position, length, and curvature of the pointer are controlled by three points in space.

Secondly, we implement a corresponding, customized unit that listens to changes in its position, end point, and control point properties, and updates the geometry accordingly. We now have a mechanism for listening to, and updating the values of this unit, both locally and over the network. Any component in our framework is thus able to listen to changes or update the geometry of the pointer, by accessing these properties. For increased precision, our prototype flexible pointer utilizes a two-handed approach, where the hands are tracked with two six-degree-of-freedom trackers, the distance between the hands map to the length of the pointer, and the relative bending of the hands determines the curvature characteristics of the pointer. We implement this control behavior as a separate Unit Graph that updates the properties of the above-mentioned unit that is controlling the geometry.

One of the hardest tasks in interaction technique design is the assignment of appropriate values to constants, and as with most interaction techniques, there are several such constants for the flexible pointer (e.g., the scale factor for the mapping of the distance between the user's hands to the length of the pointer).

Thanks to Unit's modularity, separate Unit Graphs can be used for interactive tweaking and debugging of the running interactive technique. We constructed a new graph that takes input from a small handheld presentation mouse with a thumb-controlled joystick. A button click alternates between the constants that are modified and pushing the joystick up/down increases/decreases the value of the current constant, as shown in Figure 7. Although we could place the graph in the same program as the flexible pointer, avoiding the mix of interaction technique and tweaking code seemed reasonable, and we found it more advantageous to run it in a separate program. In fact, the ease of distribution made us place it on a separate machine, which gave us an exclusive environment for developing the tweaking code, as shown in Figure 9. The behavior of our interaction technique can be modified in real time as soon as the graph is connected to the flexible pointer. More importantly, we can have the flexible pointer running constantly, while modifying, recompiling, and restarting the tweaking code. When satisfied with the behavior of the interaction technique, the tweaking code is removed, simply by not running it. This example shows how we can use Unit to abstract the interaction techniques from the input devices and the application, and also how two interaction techniques (the flexible pointer and the tweaking code) can be abstracted from each other.

We found Unit very useful in a recent experimental setup for a user interface based on speech analysis and audio localization [17]. We intended to explore the use of nonverbal features of the user's speech for implicit or explicit program control. Additionally, we planned to use multiple microphones to approximate the user's head position, by comparing the audio from the different microphones.

First, we needed a mechanism for getting input from multiple microphones, so we considered the following approaches:

1) Using multiple general-purpose sound cards on one computer. One would have to be careful to not run into hardware conflicts, since an ordinary PC is not designed to have many simultaneously active sound cards.

2) Using a special-purpose sound card with multiple audio inputs. One of these cards would be too expensive for our low-budget experimental setup.

3) Using a special-purpose array microphone for audio localization, where the signal processing is done in hardware. The few such inexpensive consumer-level microphones we found did not provide programming API access to inferred positional data. These microphones also put restrictions on the setup, limited by the characteristics of the microphone, and we found it neither feasible nor cost effective to build our own microphone.

Second, speech recognition is CPU intensive, and running several instances of speech recognition software on the same machine used for the visualization would significantly affect the frame rate.

Realizing that we had many available machines in our lab, equipped with standard sound cards, we decided to take advantage of Unit's distribution mechanism to offload the CPU-intensive speech recognition to other machines on the network. Each of these machines could then support one microphone, without the need for any special-purpose hardware or alteration of the hardware configuration.

We designed our Unit graph such that the speech is analyzed locally on each speech server, with the recognized speech and the extracted speech features communicated over Ethernet to the application server. The Unit dataflow in the application server fuses the input and adjusts the behavior of the application accordingly. Our experimental setup is shown in Figure 10.

It might sound contradictory that we find it more costefficient and convenient to use a separate computer, instead of a special-purpose sound card, to host a microphone. However, the important point here is that Unit allowed us to use our currently available general-purpose hardware for rapid prototyping of an experimental user interface, without having to deal with the hardware-related issues that would play a central role in designing a practical product. While Unit made it possible to easily develop a distributed dataflow for our purposes, its transparent distribution mechanism also makes it straightforward and simple to reconfigure the application to run on a single machine (e.g., with multiple sound-cards or a multi-input sound card).

The Unit framework has made it easy for us to develop rudimentary prototype input devices, assembled from arrangements of two or more input devices. Figure 3 shows one of the simplest examples of a composite input device: a three-degree-of-freedom mouse created from two off-theshelf wireless optical mice that are rigidly attached to provide an additional degree of freedom (rotational acceleration in the plane of the surface on which they are used). Unit provides simple means for specifying the relations between the two mouse sensors, and thus allows the behavior of this composite input device to be visually programmed, completely in software, as shown in Figure 1.

Unit makes it possible to build composite input devices that consist of hierarchies of different input devices and interaction techniques, while providing unified application-level APIs to these devices.

The Unit framework is implemented with Java and Java3D, and thus runs across multiple platforms. Unit's current im-plementation supports conventional pointing devices (e.g., mice, trackballs, touchpads, trackpoints, and touchscreens) and keyboards, as well as several six-degree-of-freedom sensors (Ascension Flock of Birds, InterSense IS600 Mark 2 Plus, and InterSense IS900) and speech recognition and speech synthesis (through the Java Speech API and IBM ViaVoice). RMI is used for distribution over TCP/IP. We have used a heterogeneous machine pool during the development, with machines ranging from a Celeron 400 MHz, with 192 MB RAM, running Windows 98, to a Dual Xeon 2.8 GHz, with 1 GB RAM, running Windows XP. The lowend machines can be used for running Unit Graphs and input device handling, while the more powerful machines with 3D acceleration hardware are needed for 3D graphics.

We have presented Unit, a system that uses a visual dataflow programming language to support designing and experimenting with 2D and 3D interaction techniques. We are actively using Unit to develop interaction techniques, and have demonstrated its utility through a set of examples created with the system.

As we have showed, Unit allows the flexible specification of interaction techniques, while effectively avoiding problems related to specific hardware setups in experimental systems through a peer-to-peer distribution mechanism. Besides abstracting interaction techniques from input devices and applications, Unit's modularity has also proven convenient, since it allows debugging components to be developed in a stand-alone fashion outside the interaction technique of interest.