Yann Laurillau

IOWAState: Models and Design Patterns for Identity-Aware User Interfaces Based on State Machines

Keywords: Identity-aware user interfaces, Interactive surfaces, Software design patterns, Architecture model, State machine model. ACM Classification H.5.2. User Interfaces: Graphical User Interfaces, Interaction styles, Prototyping, User-Centered design. H.5.3. Group and Organization Interfaces: Web-based interaction. D.2.2. Design Tools and Techniques: User interfaces

The emergence of interactive surfaces and technologies able to differentiate users allows the design and development of Identity-Aware (IA) interfaces, a new and richer set of user interfaces (UIs). Such user interfaces are able to adapt their behavior depending on who is interacting. However, existing implementations, mostly as software toolkits, are still ad-hoc and mostly based on existing GUI toolkits which are not designed to support user differentiation. The problem is that the development of IA interfaces is more complex than the development of traditional UIs and still requires extra programming efforts. To address these issues, we present a set of implementation models, named IOWAState models, to specify the behavior as state machines, the architecture and the components of IA interfaces. In addition, based on our IOWAState models and a classification of IA user interfaces, we detail a set of design patterns to implement the behavior of IA user interfaces.

INTRODUCTION

Research on multi-touch interactive surfaces, in particular interactive tabletops, is now well established in the fields of Human-Computer Interaction (HCI) and of Computer-Supported Cooperative Work (CSCW). The directness of interaction and the multiuser capabilities of tabletops may explain the growing interest for these systems. Currently, several technological solutions are available [START_REF] Han | Low-cost multi-touch sensing through frustrated total internal reflection[END_REF][START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF] including commercial ones [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF][START_REF]Microsoft Surface[END_REF]. Among these technologies, few are able to differentiate users touching the surface [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF][START_REF] Marquardt | Designing user-, hand-, and handpartaware tabletop interactions with the TouchID toolkit[END_REF][START_REF] Partridge | IdenTTop: a flexible platform for exploring identity-enabled surfaces[END_REF][START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF].

In conjunction with the growing number of technological solutions allowing user identification and differentiation (e.g., [START_REF] Annett | Medusa: a proximity-aware multi-touch tabletop[END_REF][START_REF] Marquardt | Designing user-, hand-, and handpartaware tabletop interactions with the TouchID toolkit[END_REF]), work is done on the development of identityaware (IA) user interfaces, taking advantage of user differentiation and showing the capabilities and benefits of such UIs (e.g. [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF][START_REF] Schmidt | IdLenses: dynamic personal areas on shared surfaces[END_REF]). For instance, SIDES [START_REF] Piper | SIDES: A cooperative tabletop computer game for social skills development[END_REF] is an IA multi-user tabletop-based interactive system designed to develop effective social skills. It shows that such category of technology is helpful for a therapeutic purpose considering teenagers with Asperger's syndrome. In particular, IA widgets requiring synchronous actions were key in its success.

As Identity-Aware User Interfaces (IAUIs) are more complex than traditional and single-user interfaces, their development is still challenging. We identify several issues:

Lack of implementation models and guidelines:

developing IAUIs requires extra programming efforts due to the lack of models and of capitalization of best practices (e.g. guidelines, design patterns). We observed that existing IA applications are mostly developed from scratch and, similarly to the development of multi-touch gesture-based interactive systems, developers must deal with low-level events.

User interfaces' behavioral model split across the code: traditional UI toolkits (e.g. Java's Swing), including UI toolkits that support user differentiation (e.g. DiamondSpin [START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF] toolkit is based on Java's Swing), massively rely on the well-known callback-based programming model: developers have to write a bunch of callbacks to handle each input event for each UI component. Thus, they must maintain the state of the UI component across these callbacks which usually leads to produce "spaghetti" of code [START_REF] Myers | Separating application code from toolkits: eliminating the spaghetti of callbacks[END_REF].

Dealing with concurrent inputs and differentiated outputs: although a traditional UI receives and deals with events generated by the same user, an IAUI has to manage input events generated by different users due to simultaneous actions, sometimes concurrent. Furthermore, such an UI must maintain a much more complex state model in order to produce consistent and customized outputs.

At implementation level, although most of the work done focuses on technical issues to allow user differentiation such as dedicated software toolkits, we investigate the building of software models that would help and drive the development of IAUI components. In particular, we investigate the use of state machines as a means to address the two last issues. This paper is structured as follows. First, we introduce an example to illustrate IAUIs. Then, we present the IOWAState models, our first contribution: a set of models to specify the behavior, the main components and the architecture of IAUI components. Based on our IOWAState models, we detail our second contribution, seven design patterns to implement the behavior of IAUI components, and our methodology. We conclude with a discussion and perspectives. Let us consider the following scenario: two users, Green and Blue, are interacting simultaneously on a userdifferentiating multitouch surface, manipulating digital artifacts (widgets, images, shapes, etc). Some are public while others are private. Thanks to user differentiation, supporting privacy, private artifacts are accessible by their owner only. However, user Green wants to give an image he/she owns to user Blue. Thanks to user differentiation, the users Green and Blue just have to accomplish a cooperative gesture [START_REF] Morris | Cooperative gestures: multi-user gestural interactions for co-located groupware[END_REF] to transfer ownership. As shown in Figure 1, having first activated ownership transfer mode, (a) user Green touches the image he/she wants to relinquish; (b) user Blue touches Green's image to indicate that he/she will be the next owner; (c) ownership is granted to user Blue when user Green releases his/her finger from the surface. This example is used further in the part about design patterns.

ILLUSTRATIVE EXAMPLE

(a) (b) (c)

BACKGROUND AND RELATED WORK

As underlined in introduction, multi-touch technologies, especially interactive surfaces, are intensively studied and are now well known in our research communities. Therefore, in this paper we concentrate on IA User Interfaces and on development tools supporting user differentiation.

Identity-aware user interfaces

In the 90's, researchers started to investigate the development of groupware using a single and shared display: Single Display Groupware systems (SDG) are ancestors of actual research on interactive surfaces such as tabletops: co-located users were able to interact simultaneously using multiple input devices [START_REF] Stewart | Single display groupware: a model for co-present collaboration[END_REF]. Therefore, assigning an input device per user allows user identification and thus the development of identity-aware applications. The most basic example is multi-pointers on a shared display: each user owns a pointer and is allowed to manipulate simultaneously the shared UI elements displayed on the screen. In particular, MMM [START_REF] Bier | MMM: A User Interface Architecture for Shared Editors on a Single Screen[END_REF], Pebbles [START_REF] Myers | Collaboration using multiple PDAs connected to a PC[END_REF], and Kidpad [START_REF] Druin | KidPad: a design collaboration between children, technologists, and educators[END_REF] are usually considered in the literature as the very first systems implementing and illustrating the concept of SDG. These systems are the first to take advantage of user identification to develop identityaware interfaces.

Proxy-Sketch [START_REF] Annett | Medusa: a proximity-aware multi-touch tabletop[END_REF] is another example of identity-aware interface dedicated to the creation of GUI prototypes. User identification is used to associate owners to content. It also supports casual observers (i.e. not logged in) that prevent from accidental changes.

Idlenses [START_REF] Schmidt | IdLenses: dynamic personal areas on shared surfaces[END_REF] is an identity-aware interaction technique that revisits magic lenses to provide a moveable personal area. Once identified, users benefit of personal tools that support access control to restricted and personal data, personalized actions such as automatic filling of web forms with personal data, a private clipboard, etc.

Tse et al. [START_REF] Tse | Exploring true multi-user multimodal interaction over a digital table[END_REF] have investigated multi-user and multimodal identity-aware interactive systems for gaming, based on DiamondTouch [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF]. The underlying mechanism for multimodal fusion uses user identification to link speech with gesture.

To capitalize the work done in this area, Ryall et al. [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF] propose the conceptual iDwidgets framework. The authors define identity-aware widgets (i.e. called iDwidgets for identity-differentiated widgets) as an extension of "the widget concept by including identity as an input parameter, which lets us customize interactions in a variety of ways".

For instance, an identity-aware paintbrush tool will adapt its color or stroke size according to the user.

Toolkits supporting user differentiation

In order to facilitate the development of identity-aware interfaces and widgets, several toolkits have been designed and developed to support user differentiation.

The very first toolkits used p e r i p h e r a l s a s a m e a n s t o differentiate users. The implicit user differentiation mechanism was "one input device, one user; one user, one input device". For instance, Multiple Input Devices (MID) [START_REF] Hourcade | Architecture and implementation of a java package for multiple input devices (MID)[END_REF] is a software library built on top of Java. In order to support multiple mice, MID revisits the underlying Java event mechanism. Therefore, it allows developers to implement identity-aware interfaces based on the mouse ID. Such a piece of information is implemented as an extra attribute of event objects.

SDGToolkit [START_REF] Tse | Rapidly prototyping Single Display Groupware through the SDGToolkit[END_REF] is an extension of MID as it supports multiple keyboards. At UI level, the toolkit provides mechanisms to support orientation in tabletop setups. This toolkit is built on top of the .NET framework and is written in C#. Similarly to MID, events generated by input devices are associated to devices based on a device ID. It allows the use of standard widgets provided by the .NET framework to develop identity-aware interfaces as well to develop its own identity-aware widgets from scratch. This toolkit gave rise to IdenTTop [START_REF] Partridge | IdenTTop: a flexible platform for exploring identity-enabled surfaces[END_REF], adding support for any multi-touch devices and support for a Polemus motion tracker. In addition, IdenTTop proposes a development framework for identity-aware applications based on a set of software components.

For touch surfaces, especially DiamondTouch [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF], DiamondSpin [START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF] is the most well-known toolkit. It is built on top of Java and extends Java's Swing GUI toolkit to support widget orientation. User identification is achieved using a similar mechanism as SDGToolkit: events generated by touches are associated to users by the way of a specific attribute: a user ID. In particular, the toolkit provides identity-aware frames (DSFrame component) allowing users to customize the appearance: a frame can be rotated, zoomed or resized. Similarly to SDGToolkit, it allows developers to reuse standard Java's Swing components in a DSFrame. Compared to DiamondSpin, the GIL Library (gil.imag.fr) is another toolkit based on DiamondTouch but built on top of Tcl/Tk While the java-based T3 toolkit focuses on high-resolution tabletop interfaces using wireless pens as devices for user identification [START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF], TouchID [START_REF] Marquardt | Designing user-, hand-, and handpartaware tabletop interactions with the TouchID toolkit[END_REF] goes beyond user identification as it investigates user-, hand-, and handpartaware tabletops. Similarly to SDGToolkit and IdenTTop, TouchID is build on top of the .NET framework and based on the Microsoft Surface touch table [START_REF]Microsoft Surface[END_REF].

IOWASTATE MODELS

As our model is intended for the design and the implementation of Identity-Aware UIs (IAUI), the IOWAState model encompasses three modeling primitives:

• A behavior model based on standard state machine models to describe the behavior of an IAUI. As detailed further, we used this modeling primitive to identify recurrent behavior patterns. In particular, we highlight how user differentiation is achieved in terms of state machine.

• A component model that identifies the main components of an IAUI and their relationships. In particular, this model highlights how we handle multiple state machines in order to allow parallel or concurrent user actions on an IAUI.

• An architecture model to describe the structure of an IAUI component. It illustrates how low-level events are processed to produce high-level events and are propagated to sub-components.

In the following, as the IOWA component model is based on the Model-View-Controller (MVC) design pattern, we will refer to it.

IOWA Behavior model

We chose to model and implement the Model part using hierarchical state machines (HSM), a derivative of finite state machines (FSM). Since Newman's work [START_REF] Newman | A system for interactive graphical programming[END_REF], user interfaces a r e o f t e n s p e c i f i e d u s i n g s t a t e m a c h i n e s [START_REF] Letondal | Usability requirements for interactionoriented development tools[END_REF][START_REF] Myers | Separating application code from toolkits: eliminating the spaghetti of callbacks[END_REF][START_REF] Wellner | Statemaster: A UIMS based on statechart for prototyping and target implementation[END_REF]. In addition, several works have demonstrated the feasibility and the benefits implementing state machinebased UIs [START_REF] Annett | Medusa: a proximity-aware multi-touch tabletop[END_REF][START_REF] Blanch | Programming rich interactions using the hierarchical state machine toolkit[END_REF][START_REF] Kin | Proton: multitouch gestures as regular expressions[END_REF].

As state machines are well suited to specify mode-driven interactions, we allow the Model to encompass several state machines, one per user, and support their parallel execution. Indeed, collaborative settings such as tabletops enable the interleaving modal actions.

In addition, using state machines facilitated the comparison of identity-aware widget's implementations and helped us to identify classes of identity-aware widgets based on their implementation model.

Figure 2: Example of state model of a button.

A state machine is a combination of states and transitions connecting states. Using UML statecharts, transitions are labeled according to the following syntax: trigger [guard] / effect. Trigger is an event name, guard is a set of conditions and effect i s a n a c t i o n e x e c u t e d w h e n t h e t r a n s i t i o n i s triggered. Figure 2 shows a classic state model of a button constituted of two states: disarmed: the button is raised; armed: the button is pushed. Such a state model responds to the press and release events. For instance, if the active state is "Armed" while a release event occurs, the do_action() is fired and the button goes in the "Disarmed" state.

Finally, the main advantage of Hierarchical State Machines is to facilitate the control of the state explosion problem as it allows the refinement of states as finite state machines. Indeed, specifying a state model using HSMs is a top-down approach like problem solving: an overall state model is decomposed into FSMs as problems are decomposed into smaller problems. For instance, HSMs are part of UML to specify state machines.

IOWA Component model

The IOWA component model slightly differs from the MVC design pattern as an IOWA Component inherits from an IOWA StateMachine (i.e. Model) and an IOWA UI (i.e. View). The main advantage is to present a component that looks externally as a whole, hiding the model and view

!"#$%&'( )%&'( !"#$$%&'$%'()* +#,#-$#%*%./0-12'/(34
parts, while preserving modularity and loose coupling between the View and the Model.

In order to support the design of IAUIs, user differentiation is first achieved at the Model level. As shown in Figure 3, the Model is an instance of an IOWA StateMachine that describes the behavior of an IAUI, as explained in the previous part, w i t h a n I A s t a t e m a c h i n e . S u c h a s t a t e machine is hierarchical as each state (i.e. IOWA State) may be described as a hierarchy of states. Transitions between states are triggered by events sent through a post() operation. Events are propagated in the state hierarchy. As events carry the identity of the user (i.e. user ID) who performs the associated action, this mechanism allows the design of IA state machines. that receives low-level events and produces high-level events sent to the IOWA Component t h r o u g h a post() operation. Such an IOWA Event Processor may be seen as a pipeline of event filters. As shown in Figure 4, the IOWA architecture model is layered according to the MVC design pattern. As explained previously, an IOWA UI and an IOWA Event Processor constitutes the View while an IOWA StateMachine constitutes the Model. They are assembled to constitute an event processing chain that processes user' input events and generates an output representation. As an IOWA Component may be a composition of sub-IOWA Component, in addition to the dispatch of events to the state machine, the IOWA Event Processor dispatches events to the sub-components. Furthermore, the state machine may generate events that are also dispatches to the sub-components.

IOWA Architecture model

IMPLEMENTING IOWASTATE MODELS

The IOWAState Models, in particular the IOWA behavior model, may be directly specified with an object-oriented programming language that allows a one-to-one correspondence between the IOWAState Models and the implementation. We chose such an approach because, as underlined in introduction, IAUIs are more complex to design and to implement than traditional single-user UIs. The implementation step is usually complex as existing toolkits that support user differentiation mostly rely on usual WIMP toolkits (e.g. Java's Swing). To address this issue, in particular about the implementation of state machines, existing works advocate a developer-centric approach claiming a tight integration of models with dynamic programming languages [START_REF] Appert | SwingStates: adding state machines to the Swing toolkit[END_REF][START_REF] Blanch | Programming rich interactions using the hierarchical state machine toolkit[END_REF][START_REF] De Haan | StateStream: a developercentric approach towards unifying interaction models and architecture[END_REF]. Indeed, a state machine leads to produce code easier to read and to maintain. In addition, it supports a better reusability and extensibility as we may easily add, remove or modify states and transitions thanks to the inheritance mechanism supported by object oriented programming languages.

In order to demonstrate the validity of our IOWAState models, without giving implementation details, we implemented eight very different IAUI components.

Although existing implementations focus on customization of appearance [START_REF] Marquardt | Designing user-, hand-, and handpartaware tabletop interactions with the TouchID toolkit[END_REF][START_REF] Partridge | IdenTTop: a flexible platform for exploring identity-enabled surfaces[END_REF][START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF][START_REF] Tse | Exploring true multi-user multimodal interaction over a digital table[END_REF][START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF]] (e.g. orientation to a particular user), we focus on component's behavior in terms of internal/external functionality and group input [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF].

Precisely, in order to cover the largest range of IAUI component classes as identified by Ryall et al. [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF], the components we implemented are taken and adapted from [START_REF] Morris | Cooperative gestures: multi-user gestural interactions for co-located groupware[END_REF][START_REF] Morris | exploring centralized versus replicated controls for co-located tabletop Groupware[END_REF][START_REF] Morris | Designing Tabletop Groupware[END_REF][START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF]. For instance, one of the eight components we implemented is a multi-user slider having a differentiated behavior, performing the same action (i.e. selecting a value) whoever the user is. However, it behaves with different styles depending on the user's identity. For instance, one user may slide the cursor from tick to tick and select a value on a discrete scale, another user would slide the cursor continuously.

Another example is a cumulative voting component allowing different users clicking on a s a m e b u t t o n t o perform an action. Achieving the action requires a minimum number of users performing the interaction.

The height IAUI components we implemented are developed in Python, to be used with a Diamondtouch device [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF]. In order to be independent from any GUI toolkit and their associated programming paradigm, we used basic graphic primitives to draw the components (i.e. OpenGL rendering engine). In order to support identity-awareness, we rely on the user-differentiation mechanism provided by the Diamondtouch device [START_REF] Dietz | DiamondTouch: A multi-user touch technology[END_REF], able to differentiate up to four users. The low-level events sent by the device are supplemented with a user ID represented as an integer value in a range of 0-3. It allowed us to implement an event loop that sends high-level events supplemented with a user ID to the user interface and thus to our IAUI components.

DESIGN PATTERNS

Methodology

In order to identify recurring design patterns for IAUIs, we defined and followed a twofold method. The first part of this method consists in analyzing and in reverseengineering the source code of existing identity-aware widgets to detect recurring implementation patterns. The second part of this method consists in developing identityaware widgets using state machines to model and implement widget's behavior. We chose to reuse and adapt existing identity-aware widgets that are the ones described in the previous section. Obviously, these developments are on our IOWA state models.

Code-based analysis of existing IA widgets

Concomitantly with the development of the eight widgets detailed in the previous section, we analyzed the code of a set of existing prototypes that includes IA widgets. We focused on prototypes developed with toolkits allowing user identification: SDG [START_REF] Tse | Rapidly prototyping Single Display Groupware through the SDGToolkit[END_REF], DiamondSpin [START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF], T3 [START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF], TouchID [START_REF] Marquardt | Designing user-, hand-, and handpartaware tabletop interactions with the TouchID toolkit[END_REF] and GIL [START_REF] Bérard | Single User Multitouch on the DiamondTouch: From 2x1D to 2D[END_REF]. We did not consider the IdenTTop toolkit [START_REF] Partridge | IdenTTop: a flexible platform for exploring identity-enabled surfaces[END_REF] because the code is not publicly available. Although several IA widgets and the related source code are available online, we also requested additional examples from the authors of the DiamondSpin and GIL toolkits.

We analyzed seven IA widgets taken from SDG, DiamondSpin, and GIL. We found no relevant widget for the T3 and TouchID toolkits. The source code was reversed engineered to identify implementation patterns of identity-aware widgets. First, we carefully examined the code as follows: (1) identification of callbacks or related methods managing user input events supplemented with a user ID;

(2) identification of attributes used to store the component state;

(3) identification of control structures that use the user ID to update the attributes related to the component state. Then, we modeled IA widgets using state machine representations. In order to verify our models, we compared the models at runtime. In order to classify state machines and to derive patterns, based both on our developments and on the analysis of existing components, we focused on similarities and differences in terms of states (e.g. associated states) and transitions (i.e. conditions).

The IA widgets and IA interaction techniques we analyzed are:

• From SDG toolkit, a multi-user button (SDGButton) allowing two interaction modes: (1) restricted interaction to the first user pushing the button (oneuser-at-a-time); (2) cumulative effect; a multi-user check button (SDGCheckButton) that paints parts of its border with the color related to the users that checked it; a multi-user slider with multiple cursors (SDGTrackBar), one per user.

• From DiamondSpin toolkit: an identity-aware and moveable menubar (DSMenuBar); a multi-user chess board [START_REF] Chaboissier | RealTimeChess: lessons from a participatory design process for a collaborative multi-touch, multi-user game[END_REF] (RealTimeChess); a RingMenu.

• From GIL toolkit: a cooperative design application to assemble shapes in order to design a building. As shown in Figure 5, our method leads us to identify three categories of patterns related to:

Design patterns

• Individual actions: these patterns deal with ownership, i.e. how a UI component is owned by one or multiple users. We identify three kinds of ownership: (a) public UI components that are free and not owned; (b) private UI components that are owned by one or multiple users and that can exclusively be used by the owners; (c)

!"#$"%&' &! !"#$"%&' &! (!&()""$&(* (!&()""$&(*

349%(%9")$2)&*%048 :'0"/2)&*%048
temporarily UI components that are free UI components owned for a limited amount of time.

• Group actions to achieve a sequence of actions: these patterns identify UI components that require multiple users to achieve a group action: (a) cumulative UI components that take into account the number of users whatever the sequence of action is; (b) cooperative UI components that imply a well-defined and ordered sequence of actions.

• Group actions allowing parallel execution of actions: we identify two situations: (a) the interleaving of actions with no concurrency; (b) mutually exclusive UI components to deal with concurrency.

In the following, we detail each design pattern using Borchers' pattern language [START_REF] Borchers | A pattern approach to interaction design[END_REF]. In addition, illustrations of state machines are given using UML statecharts. Context: in order to achieve an individual task, different users simultaneously interact with a same UI element (e.g. a button) of the shared workspace to issue a command that acts on an artifact associated with her/him.

Problem: First, traditional widgets are single-user and do not support simultaneous actions. Secondly, the display may offer a limited amount of space: replicated UI elements would clutter the interacting space and would waste pixels. Thirdly, simultaneous but opposite actions on a same UI element would produce an inconsistent visual representation or have no effects: for instance, a user is pressing his/her finger on a button that should look armed while another user releases his/her finger on the same button that should look disarmed.

Solution: a single instance of an identity-unaware state machine composed of a single state would support simultaneous actions: transitions are labeled without uidbased conditions. Thus, user differentiation is achieved by an external function triggered when an action is performed on the UI (i.e. associated to the triggered state transition such as the function do_action(uid) s h o w n i n Figure 6 (a)). Such a function takes the user id associated to a user event as an argument: different actions are executed according to the user id.

To support presentation consistency for simultaneous actions, a unique output representation is coupled with the state machine because the state machine is composed of a single state.

Examples: TeamTag's IA controls [START_REF] Morris | exploring centralized versus replicated controls for co-located tabletop Groupware[END_REF] (Figure 6 (b)).

Private IAUI

Context: an interactive surface is partitioned into shared and private territories, allowing users to interact with private artifacts located in their private territory and to perform individual tasks. Problem: an interactive surface is naturally a public shared resource as everything is visible and potentially free, including private territories. Tacit social rules are the most common mechanism that preserves private territories.

Solution: an IAUI exclusively associated to an owner, based on his/her user id, prevents other users to interact with such private UI elements. All transitions of the state machine associated with the private IAUI must be labeled with uid-based conditions: when an event is received, a transition is triggered if the user ID carried by the event matches the owner ID (e.g. condition [uid == owner] as shown in red in Figure 7 (a)). We may consider that an owner is associated to such an IAUI element at instantiation time.

Examples: Swing widget in a DSFrame [START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF] (Figure 7 (b)), IdLenses [START_REF] Schmidt | IdLenses: dynamic personal areas on shared surfaces[END_REF].

Temporarily Private IAUI

Context: different users simultaneously access to a shared and free UI element such as a widget or an artifact (e.g. digital photo).

Problem: although some UI elements are public and freely available, some UI elements may only support interactions for one user at a time.

Solution: an IAUI element temporarily owned by the current user interacting with the IAUI: ownership is granted Problem: the UI element must consider how many users (i.e. critical mass) are interacting to achieve a group action (e.g. majority). Furthermore, this UI element must remember who is interacting to take into account each user only once: for instance, a user touching a button with two different fingers must be counted as a single touch.

Solution: an IAUI element that maintains a list of users already interacting with it. This list is updated when transitions of the associated state machine are triggered. Three categories of conditions are observed:

• Conditions verifying if a user is not already in the list to avoid duplicate entries (e.g. condition [uid ∉ P] as shown in Figure 9 (a)). Consequently, for transitions that verify such a condition, the associated action consists in adding the new interacting user to the list (e.g. condition [P := P ∪ {uid}] a s s h o w n i n Figure 9 (a)).

• Conditions verifying if a user is already on the list (e.g. condition [uid ∈ P] as shown in Figure 9 (a)) when the user interaction is completed. Consequently, for transitions that verify such a condition, the associated action consists in removing the associated user from the list (e.g. condition [P := P \ {uid}] as shown in Figure 9 (a)).

• Conditions verifying if no more users are interacting with the IAUI element to maintain state consistency (e.g. condition [|P| > 1] where |P| denotes the cardinality of set P as shown in Figure 9 (a)). Such a condition can be seen as threshold to reach in order to select a state transition in case of alternatives.

Although a Public IAUI element responds to individual actions, a Cumulative IAUI element responds to group actions. Similarly, there is no owner associated with it.

Examples: SDGButton [START_REF] Tse | Rapidly prototyping Single Display Groupware through the SDGToolkit[END_REF] (Figure 9 (b)), Voting button [START_REF] Morris | Designing Tabletop Groupware[END_REF], SIDES [START_REF] Piper | SIDES: A cooperative tabletop computer game for social skills development[END_REF], SDGTrackBar [START_REF] Tse | Rapidly prototyping Single Display Groupware through the SDGToolkit[END_REF].

References: PUBLIC IAUI.

Cooperative IAUI

Context: different users are interacting with the same UI element to perform a synchronized group action, involving a limited number of users. Achieving the group action requires to execute actions in a certain order (i.e. ordered sequence of actions). Depending on the number of users or depending on who is interacting, the UI element behaves in different ways (modes). Problem: the UI element must consider how many users are interacting to achieve a group action. Furthermore, this UI element must remember who is interacting to take into account each user only once. As the UI element behaves differently depending on who is interacting, several states must be considered to represent the sequence of actions.

Solution: an IAUI element's state machine composed of an ordered set of states. This set corresponds to the ordered sequence of actions that the users must execute to achieve the group action. Each state is associated to different behaviors of the IAUI element. User differentiation is performed to (1) limit the number of users interacting with the IAUI element using a list similarly to a Cumulative IAUI element; (2) to associate a user for different modes of interaction using uid-based conditions (e.g. condition [uid == P [START_REF] Annett | Medusa: a proximity-aware multi-touch tabletop[END_REF]] as shown in red in Figure 10 (a)). As the number of users allowed to interact with a Cooperative IAUI element is limited, such a component may be seen as Temporarily private IAUI element.

Examples: Cooperative gesture [START_REF] Morris | Cooperative gestures: multi-user gestural interactions for co-located groupware[END_REF] (Figure 10 (b)), Rotating shape (Figure 1).

References:

TEMPORARILY PRIVATE IAUI, CUMULATIVE IAUI.

Interleaving IAUI

Context: different users are simultaneously interacting in a shared workspace on different artifacts. Some of the users may execute destructive actions (e.g. delete).

Problem: using a global mode (i.e. the same mode for all) in a shared workspace does not support parallel moded interactions. For instance, if one person is in an erasing mode, other persons cannot be in a different mode such as drawing: once the erase mode is activated, the next selected stroke would be erased. Solution: an IAUI component's state machine managing a set of multiple instances of the same sub-state machine that are running in parallel (Figure 11 (a)). The master state machine intercepts the events and, as a proxy, dispatches events to each instance. Each instance is owned (i. Problem: a user must wait for the first user already interacting to end up taking his/her turn and then accomplish his/her own action.

Solution: similarly to an Interleaving IAUI component, a Mutually exclusive IAUI component is based on a master state machine that manages several sub-state machines running in parallel. In addition, each sub-state machine implements an Idle/Active mechanism: the idle state is reached when a user is not interacting; the active state is reached when a user is interacting. For the latter, two substates are considered in order to support mutual exclusion and the fact that a user must wait his/her turn: two sub-substates are considered as show in Figure 12 (a): an operative state that locks the IAUI component (i.e. ownership taken) until the interaction is ended up (i.e. ownership released); a non-operative state that corresponds to a stand-by period.

Examples: Waiter's Diamondspin mechanism [START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF], RingMenu [START_REF] Chaboissier | RealTimeChess: lessons from a participatory design process for a collaborative multi-touch, multi-user game[END_REF] (Figure 12

DISCUSSION

IOWA models

As a first evaluation, we instantiated the IOWAState models to develop eight very different IAUI components. As a second evaluation, we used our models as a framework to analyze existing implementations and to identify recurring patterns. Of course, a long-term evaluation would be clearly appropriate for a good understanding of the strengths and weaknesses of our models. In particular, we currently use our models to implement a serious game, based on a DiamoundTouch device, for the learning of cooperative practices for engineering tasks.

As the IOWA models are based on HSMs to specify the behavior of IAUIs, our approach is similar to SwingState [START_REF] Appert | SwingStates: adding state machines to the Swing toolkit[END_REF], StateStream [START_REF] De Haan | StateStream: a developercentric approach towards unifying interaction models and architecture[END_REF] or HsmTk [START_REF] Blanch | Programming rich interactions using the hierarchical state machine toolkit[END_REF] models and implementations. Although these works target single-user interfaces, our models are designed to support IA user interfaces. In particular, an IOWA component supports simultaneous user inputs and an ownership mechanism in order to allow the development of Private and Temporarily private IAUIs. In addition, our models are designed to support the parallel execution of HSMs within a MVC-like architecture in order to allow the development of Interleaving and Mutually exclusive IAUIs. The IOWA architecture model is designed to allow compositions of state machines. However this point is out of the scope of this article.

Compared to existing IA toolkits [START_REF] Letondal | Usability requirements for interactionoriented development tools[END_REF][START_REF] Newman | A system for interactive graphical programming[END_REF][START_REF] Shen | DiamondSpin: an extensible toolkit for around-the-table interaction[END_REF][START_REF] Tuddenham | T3: A toolkit for highresolution tabletop interfaces[END_REF][START_REF] Wellner | Statemaster: A UIMS based on statechart for prototyping and target implementation[END_REF] widely based on a callback-based programming model inherited from traditional GUI toolkits, since our models are based on HSMs to specify the behavior of IAUIs, our several developments show it can be easily translated into code in order to produce code easier to read and to maintain, avoiding the use of a specialized and additional language. Furthermore, as we adopted an object-oriented programming approach for the implementation of the IOWAState models, we observed that the inheritance mechanism facilitates the reuse of existing HSMs. It also facilitates the creation of n e w b e h a v i o r s with minor modifications of existing HSMs. It seems an interesting property to investigate further in order to address state explosion.

Currently, as explained previously, a first limit of our approach is the lack of long-term evaluation. Particularly, we consider another long-term evaluation with Master students following computer engineering courses, asked to implement IAUIs based on our models. Focusing only on IAUI's behavior constitutes another limit. Investigating how our models are extensible to support userdifferentiation at presentation level must be considered further. Finally, we do not address the combination of two IAUI components, in particular two IAUI components having conflictual behaviors.

Design patterns

In terms of evaluation, according to [START_REF] Brown | The Software Patterns Criteria[END_REF], a pattern follows a lifecycle model composed of several steps. Currently, our patterns have reached step #5 "Pattern Gestalt" for which readers review the patterns. This article contributes to this step. The next step must be "Popular acceptance". Contributing to the evaluation as well as demonstrating the completeness of our patterns, our pattern classification covers the classification of the IDWidgets framework [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF] related to behavior, and coherently integrates cooperative gestures [START_REF] Morris | Cooperative gestures: multi-user gestural interactions for co-located groupware[END_REF]. In addition, we go one step further towards software implementation of IAUIs as we provide and detail seven design patterns. Furthermore, although CSCW literature considers UI elements' ownership as private or public, we identify a new and intermediate situation of ownership: temporary ownership.

Complementary to the conceptual IDWidgets framework [START_REF] Ryall | Identitydifferentiating widgets for multiuser interactive surfaces[END_REF] providing classes of IAUI widgets, our pattern classification is at implementation level and identifies classes of identity-aware user interactions.

Except the fact that our patterns should reach step "Popular acceptance" ( s t e p # 7 ) , an unanswered issue is the completeness of our design patterns and the related classification. Particularly, our patterns focus on behavior only and patterns for user-differentiated presentations should be investigated further. As a perspective, we need to investigate rules to combine several IAUI components. Indeed, combining two IAUI components may lead to the combination of conflictual HSMs such as a Private IAUI component embedding a Public IAUI component. In terms of implementation, we need to investigate alternative programming languages to Python to demonstrate the generative power of the IOWAState models. Finally, we plan to extend our patterns and the state machine approach to single-user multi-touch user interfaces.

CONCLUSION

Figure 1 :

 1 Figure 1: Cooperative gesture to transfer ownership [18].

Figure 3 :

 3 Figure 3: IOWAState's component model.

Figure 4 :

 4 Figure 4: IOWAState's architecture model.

  $%&'(&)&*+,45).'!"#$%&'(*+',%-!9:$"3%;<&'(*+',%-

Figure 5 :

 5 Figure 5: Design pattern graph.

Figure 6 :

 6 Figure 6: (a) SM model for Public IAUI; (b) TeamTag centralized control [19].

Figure 7 :

 7 Figure 7: (a) SM model for Private IAUI; (b) Swing widgets in a DSFrame [28].

! 3 !

 3 Figure 8: (a) SM model for Temporarily Private IAUI; (b) Single-user lock SDGButton [31].

Figure 9 : 2 0Figure 10 :

 9210 Figure 9: (a) SM model for Cumulative IAUI; (b) Cumulative SDGCheckButton [31].

Figure 11 :

 11 Figure 11: (a) SM model for Interleaving IAUI; (b) DTMap. Mutually exclusive IAUI Context: Two users are interacting simultaneously with the same UI component.

!!Figure 12 :

 12 Figure 12: (a) SM model for Mutually exclusive IAUI; (b) RingMenu [7].

Focusing

  on the design and development of Identity-Aware User Interfaces, this article presents two main findings. First, the IOWAState models revisit the MVC architecture model to rely on hierarchical state machines in order to support identity awareness, simultaneous user inputs, and to help d e v e l o p e r s t o p r o d u c e c o d e e a s i e r t o r e a d a n d t o maintain. Another significant contribution is a classification of IAUIs based on a set of seven design patterns to specify the behavior of IAUIs using state machines.

ACKNOWLEDGMENTS

To Renaud Blanch for advice and hints he gave about HSMs and the permission to use his HSM-based SWIT toolkit.


William Delamare
email: william.delamare@imag.fr

Céline Coutrix
email: celine.coutrix@imag.fr

Laurence Nigay
email: laurence.nigay@imag.fr

Mobile Pointing Task in the Physical World: Balancing Focus and Performance while Disambiguating

Keywords: Mobile interaction, Physical interaction, Pointing, Disambiguation, Focus, Performance. ACM Classification H.5.2. Information interfaces and presentation (e.g. HCI): User Interfaces -Interaction styles Human Factors, Design, Experimentation, Performance

We address the problem of mobile distal selection of physical objects when pointing at them in augmented environments. We focus on the disambiguation step needed when several objects are selected with a rough pointing gesture. A usual disambiguation technique forces the users to switch their focus from the physical world to a list displayed on a handheld device's screen. In this paper, we explore the balance between change of users' focus and performance. We present two novel interaction techniques allowing the users to maintain their focus in the physical world. Both use a cycling mechanism, respectively performed with a wrist rolling gesture for P2Roll or with a finger sliding gesture for P2Slide. A user experiment showed that keeping users' focus in the physical world outperforms techniques that require the users to switch their focus to a digital representation distant from the physical objects, when disambiguating up to 8 objects.

INTRODUCTION

Mobility gives users the opportunity to interact with the physical world around them, anywhere and anytime. A mobile user carrying a handheld device within smart environments can initiate interaction with many objects. In order to avoid unnecessary travel for selecting one of these objects, a usual solution is to point at them from a distance [START_REF] Ailisto | Bridging the physical and virtual worlds by local connectivity-based physical selection[END_REF][START_REF] Swindells | That one there! Pointing to establish device identity[END_REF][START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF].

Two metaphors exist for physical pointing: ray casting (e.g. laser-based systems) and volume selection (e.g., Infrared-based systems). While studied in Virtual Environment (VE), the physical world has specificities that make existing techniques difficult to transpose:

• The location of physical targets is not easily modifiable by the system, making difficult the spatial reconfiguration of targets as the Flower Ray does [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF].

• The location of the pointer representation (e.g., the laser dot) is mapped to the pointing device location (e.g., the laser device) with a fixed scale, making difficult the use of improved Control-Display Gain [START_REF] König | Adaptive Pointing-Design and Evaluation of a Precision Enhancing Technique for Absolute Pointing Devices[END_REF].

• There is no visual representation of the pointing tool. For instance, when pointing with a laser, there is no representation of the ray. Thus, techniques like the Flexible Pointer are difficult to transpose [START_REF] Feiner | The flexible pointer: An interaction technique for selection in augmented and virtual reality[END_REF].

Yet, ray casting and volume pointing metaphors have been transposed to mobile physical interaction. However, as expected, pointing with a bare laser has accuracy limitations due to limited precision [START_REF] König | Adaptive Pointing-Design and Evaluation of a Precision Enhancing Technique for Absolute Pointing Devices[END_REF][START_REF] Myers | Interacting at a distance: measuring the performance of laser pointers and other devices[END_REF]. Jitters cause ±5˚ deviation [START_REF] Forsberg | Aperture based selection for immersive virtual environments[END_REF], i.e., 17cm when interacting at a distance of 2m, possibly causing an error. The existing techniques that address these problems have other limitations: [START_REF] Ailisto | Bridging the physical and virtual worlds by local connectivity-based physical selection[END_REF] the management by the system of a model of the physical world [START_REF] De La O Chávez | An independent and non-intrusive laser pointer environment control device system[END_REF][START_REF] Wilson | Pointing in intelligent environments with the worldcursor[END_REF], restricting the dynamicity of the physical world (e.g. moving a lamp has to be reported in the system by the user), and (2) invasive devices, such as large sensors [START_REF] Patel | A 2-way laser-assisted selection scheme for handhelds in a physical environment[END_REF] or a platform attached to the ceiling [START_REF] Wilson | Pointing in intelligent environments with the worldcursor[END_REF].

Instead of using a ray, techniques based on the selection volume metaphor are good alternatives to avoid accuracy problems. However, several objects may fall in the volume selection. Thus, a disambiguation step is needed in order to refine the selection.

Some existing disambiguation techniques use heuristics in order to automatically disambiguate which target in the volume the user intended to select: In a spatial-geometric approach [START_REF] Rahman | Spatial-geometric approach to physical mobile interaction based on accelerometer and IR sensory data fusion[END_REF], a metric is used to automatically select the target closest to the volume axis. While avoiding additional action from the user for the disambiguation step and clearly letting the users focus on the primary physical target, heuristics can fail in some particular situations. For instance, if the scoring mechanism is based on the size of the intersection between objects and the selection volume, users would not be able to select a small object located right in front of a large one. In addition, the automatic predictive -2 -mechanism can prevent the users from understanding why they perform incorrect selections, and thus adjust their manipulation. As a consequence, in this paper we address explicit disambiguation mechanisms.

The explicit disambiguation step can be performed either by keeping users' focus on the physical target, or by forcing them to switch their focus to a digital representation distant from the physical objects, such as a list of objects' names displayed on the screen of a handheld device. In this paper, we investigate techniques that allow maintaining of the focus on the physical world.

Fitts law [START_REF] Balakrishnan | Beating" Fitts' law: virtual enhancements for pointing facilitation[END_REF] usually helps understanding of the perceptualmotor factors of pointing tasks and therefore is used to enhance pointing techniques. Such modeling would be useful for focus-keeping physical disambiguation techniques. The law has been transposed to pointing at distant on-screen targets [START_REF] Kopper | A human motor behavior model for distal pointing tasks[END_REF]. This work models a direct, ray-casting pointing technique with no disambiguation. As a consequence, it does not always apply to a volume selection technique where a disambiguation step might be needed when several targets are preselected. The law has also been transposed to pointing at distant physical targets through a phone used as a Magic Lens [START_REF] Rohs | Interaction with magic lenses: real-world validation of a fitts' law model[END_REF][START_REF] Rohs | Target acquisition with camera phones when used as magic lenses[END_REF]. On the contrary, we aim for our users not to look at the screen but to maintain their focus on the physical target itself. As a consequence, we aim at a different perceptual-motor task and its Fitts modeling needs to be further studied. We first review existing explicit disambiguation techniques for mobile selection of physical objects. Next, we present design dimensions for disambiguation techniques in the physical world before describing our two mobile disambiguation techniques P2Roll and P2Slide. We then report an in-lab experiment focusing on the balance between change of the user's focus and performance. We conclude with a discussion of our results and directions for future work.

RELATED WORK

We build on previous work on volume pointing techniques for mobile interaction that include an explicit disambiguation step. We distinguish techniques that maintain the users' focus in the physical world from techniques that imply a switch of the user's focus from the physical world to the mobile device.

The GesturePen proposes a way to point at physical objects using an IR beam [START_REF] Swindells | That one there! Pointing to establish device identity[END_REF]. It combines custom tags attached to physical objects and a custom handheld stylus for pointing. Even if the prototype did not propose any disambiguation mechanism if several tags respond to the IR broadcast, authors reported that a user suggested a dial on the device as an explicit control of the beam angle and/or length. However, an IR beam is not visible and thus difficult to control without visual feedback [START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF]. Interestingly, the authors evaluated the GesturePen (selection in the physical world) against a selection in a graphical list displayed on a handheld device's screen, forcing the user to change her/his focus of attention. However, the users had to get close enough to the physical object in order to read its tag. On the contrary, we want to allow the user to interact from a distance. Moreover only the pointing step has been evaluated versus the list, but not the disambiguation step, as the latter was not implemented.

Other solutions use both physical and digital representations, the digital representation being co-localized with, or closely located to, physical objects.

First, PICOntrol combines light sensors attached to physical objects and an encoded projection in order to select and control smart objects [START_REF] Schmidt | PICOntrol: using a handheld projector for direct control of physical devices through visible light[END_REF]. Since several sensors may fall in the projected image, authors proposed introduction of a way to optically or digitally control the size of the projection, thus keeping the users' focus on physical objects. However, this solution has not been implemented or tested.

Second, the "Radio Frequency Identity and Geometry Lamps" system (RFIG Lamps) also proposes an explicit disambiguation technique with co-localized physical and digital representations [START_REF] Raskar | RFIG Lamps: Interacting with a Self-Describing World via Photosensing Wireless Tags and Projectors[END_REF]. The system uses two sequential pointing gestures: a rough one for volume selection, followed by a precise disambiguating one. First, to allow a coarse first pointing gesture, the pointing device embeds an RFID reader. An encoded projection allows the system to know the positions of all the objects awoken in the volume by the RFID broadcast. The selected objects are highlighted by projecting tag areas (digital part) onto the physical objects (physical part). Then, users can manipulate a laser embedded in the pointing device for selecting the desired tag by clicking in the projected tag area that is bigger than the original tag. The key aspect of the technique is that it maintains the users' focus on the physical targets. Unfortunately, the system was designed for a warehouse scenario, in which augmented objects are cardboard boxes that suit well for projection. We cannot assume that a mobile user can always find such projection-compliant surfaces in any augmented environment. Moreover, the experiment revealed that both the projection and the disambiguation step using the laser-based input, suffer from hand-jitters.

Other solutions use mixed representations through handheld Augmented Reality (AR) techniques: users perform a rough pointing gesture, positioning the handheld device until physical objects appear on the screen via a live video. In this case, the selection volume is the field-of-view of the embedded camera. A first solution for disambiguating the selection is to provide an on-screen cursor, to select the virtual representation of objects through the video [START_REF] Rohs | Interaction with magic lenses: real-world validation of a fitts' law model[END_REF]. A second solution is to break the spatial mapping between the digital representation on the screen and the actual physical target. Techniques such as Shift&Freeze [START_REF] Vincent | Precise pointing techniques for handheld Augmented Reality[END_REF] propose to freeze the video in order to ease the disambiguating touch gesture. AR techniques include a first pointing step that does not provide a set of selected objects, but rather a view of a subpart of the physical surroundings. Thus, they force users to go through the disambiguation step (e.g., selecting the target on the screen), even if there is a single target in the selected subpart of the physical surroundings (i.e. in the video).

Finally, two techniques proposed a digital representation of the selected objects for the disambiguation step [START_REF] Ailisto | Bridging the physical and virtual worlds by local connectivity-based physical selection[END_REF][START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF]: a list of targets' names or images displayed on a handheld device's screen when they are in the selected volume. Only one technique has been evaluated [START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF], but authors only reported users' satisfaction when selecting objects in the list. On the contrary, we want to explore in detail this disambiguation step and compare the technique based on a list on screen with focus-maintaining techniques.

To our knowledge, there are no experimental studies of the benefits and drawbacks of focus switching on performance while disambiguating a selection in the physical world. In addition and as highlighted in this section, the few disambiguation techniques maintaining the users' focus on the physical world (GesturePen, PICOntrol) chose to loose the benefits of volume selection when disambiguating by returning to a ray casting technique and its potential drawbacks. This is the challenge we addressed by designing our two techniques P2Roll and P2Slide: instead, our design rationale is based on maintaining the easy volume pointing gesture while exploring navigation techniques in this volume for disambiguation.

Before describing our two techniques, we present two of the design dimensions for disambiguation techniques [START_REF] Delamare | Designing Disambiguation Techniques for Pointing in the Physical World[END_REF] that are determinant of the users' focus of attention and performance.

DESIGN RATIONALE: DIMENSIONS FOR DISAMBIGUATION TECHNIQUES

Two aspects determine the design of explicit disambiguation techniques: (1) the representation of the selected objects determining the focus switching or not, and (2) the input method impacting on the users' performance. As the pointing step already uses a gesture, we focus on consistent gestures as input methods.

Representation of Selected Objects

As illustrated in the previous section, the representation of objects is organized along a physical-digital continuum. Between these two extremes are mixed representations, where both physical and digital elements are used to represent objects of interest. When a digital representation is involved, users may need to change their focus of attention. In this case, spatial relationships between objects' representations can be studied [START_REF] Vernier | A framework for the combination and characterization of output modalities[END_REF]. Five spatial relationships are defined. Among these, for instance the RFIG Lamp technique provides a digital representation of tags that overlay the primary physical objects. On the contrary, the list provides digital representations that are separated from the physical objects. In the latter case, users have to switch their focus between these representations.

We consider this design aspect of representation as important, since it has an impact on the usability of the technique and implies a change of focus of attention.

Physical Gesture Properties

The limb chosen for inputs influence the overall performance of the interaction techniques. Indeed, there is a tradeoff between speed and accuracy that a limb is able to perform, depending on:

• The limb's bandwidth [START_REF] Card | A morphological analysis of the design space of input devices[END_REF], i.e. the rate of information that can be transmitted by the limb,

• The jitters users may have during the interaction with this limb [START_REF] Davis | Elbow and Wrist Components of Physiologic Tremor Amplitudeas Measured Using a Laser Penlight[END_REF].

But, as stated in a previous study [START_REF] Balakrishnan | Performance differences in the fingers, wrist, and forearm in computer input control[END_REF], because of many differences in tasks, protocols, border effects such as learning effect between conditions, or muscles group involved in the experiment, it is difficult to clearly state which limb is best suited for a particular task. However, since the pointing step already involves an arm gesture, we focus on the next options following the kinematic chain of the upper limb: wrist and fingers. It appears that even with non-comparable results, wrist [START_REF] Balakrishnan | Performance differences in the fingers, wrist, and forearm in computer input control[END_REF] and fingers [START_REF] Zhai | The influence of muscle groups on performance of multiple degree-of-freedom input[END_REF] have been reported as good input candidates.

In the next section, we present our two disambiguation techniques designed to keep users' focus on physical targets with wrist and finger inputs, previously identified as good candidates.

P2ROLL AND P2SLIDE

We present two mobile disambiguation techniques designed for the selection of physical objects. We assume that augmented physical objects provide visual feedback to the users, for instance with Light-Emitting Diodes (LEDs) commonly attached to the physical augmented objects [START_REF] Swindells | That one there! Pointing to establish device identity[END_REF].

One technique uses a wrist rolling gesture (Physical Pointing Roll -P2Roll), and one technique uses a finger sliding gesture (Physical Pointing Slide -P2Slide). Without exiting comparative results on the two input methods, we decided to explore both options.

Quasi-Mode

Both techniques use sequential actions performed while holding a handheld device: pointing and disambiguating. The disambiguation step can be seen as a quasi-mode: the user enters this mode by touching and holding her/his finger on the handheld device's screen, and exits the mode (i.e. validate her/his selection) by releasing her/his finger from the screen.

If the desired target is not in the pointed volume when entering the disambiguation mode (i.e. error during the pointing step), the user can exit the disambiguation mode without validating the selection by sliding her/his finger to the bottom of the touch screen. In doing so, on finger lift, the selection is not triggered and the pointing direction is unlocked.

Physical Pointing Roll: P2Roll

This disambiguation technique uses a wrist rolling gesture for browsing the set of pre-selected objects (Figure 1). After the pointing gesture (Figure 1, A), users can lock the pointing volume by touching the device's screen (Figure 1, B). At this point, objects are associated with a range of rolling angles, so that when the wrist angle is in a particular range, the corresponding current object provides feedback to the user. Nothing is displayed on the handheld device's screen, the user focuses only on the physical objects and their feedback. Once on the desired target, the user can validate the selection by removing the thumb from the touch screen.

A previous study [START_REF] Qin | Structured laser pointer: enabling wrist-rolling movements as a new interactive dimension[END_REF] reported a comfortable rolling range of 130˚ while holding a laser, in [-70˚, 50˚]. But holding a laser can be different from holding a smartphone. So we conducted a pilot study (7 participants) showing that righthanded participants were comfortable holding the smartphone in the motion range [-80˚, 50˚]. We used mirrored values for left-handed people. The discretization of the rolling range was quadratic (Figure 1, B C D), since it has been demonstrated to allow more precision than a linear one [START_REF] Rahman | Tilt techniques: Investigating the Dexterity of Wrist-based Input[END_REF]. We empirically optimized this discretization and then validated it through pilot experiments. Discretized parts were then linked with physical objects, linearly ordered on the horizontal axis (Figure 1, B C D).

We expect that expert users could anticipate the rolling angle for a given physical target, so that when locking the pointing direction, the desired target would be the current element (i.e. selected if the selection is validated). This would increase performance since only a fast 'touch and release' gesture on screen would be needed for the selection of the desired target. In a real-world scenario, we expect this expert behavior for recurrent situations e.g., selecting the TV from the couch.

Physical Pointing Slide: P2Slide

This disambiguation technique uses a horizontal sliding gesture with the thumb on the device's touch screen (Figure 2). It has been shown that horizontal thumb gestures on a one-handed device have an equivalent or better throughput 3"

2" 1"

A) Poin+ng:"" selec+on"volume"" Light"on" Light"off" 4" Sliding" Range"

2" 3" 1" 4" B)"Touching:"" selec4on"volume"locked" Current" 1" 3" 2"
Sliding" Posi4on" 3"

1"

C)"Sliding"Le.:"the"element"on" the"le."becomes"the"current"one" 2" 4" 1" 2" 3"

1" D)"Sliding"Right:"the"element"on"the" right"becomes"the"current"one" Rolling" Range"

A) Poin0ng:" selec0on"volume"" Rolling" Angle" Light"on" Light"off" 4"

2"

3" 1" 4" B)"Touching:"" selec4on"volume"locked" 1 " 3" Current" 2 "

3" 1" C)"Rolling"Le.:"the"element"on" the"le."becomes"the"current"one" 1 " 3" 2 " 2" 4"

1" D)"Rolling"Right:"the"element"on" the"right"becomes"the"current"one" than vertical ones [START_REF] Wobbrock | The performance of hand postures in front-and back-of-device interaction for mobile computing[END_REF]. As P2Roll, no feedback was provided on the device: browsing was performed with an input on the smartphone and an output on physical augmented objects. After the pointing gesture (Figure 2, A), users can lock the pointing volume by touching the device's screen (Figure 2,B). At this point, objects are associated with a vertical area of the screen. All vertical areas are equally distributed along the horizontal axis of the touch screen. Each area is associated with a pre-selected physical object, linearly ordered on the horizontal axis, so that when the finger is detected in an area, the corresponding object provides feedback to the user (Figure 2, B, C andD).

As for P2Roll, we expect the same anticipation for expert users: validating the selection with a fast 'touch and release' on the remembered area of the screen.

EXPERIMENT

The aim of this experiment was to explore the relationship between change of users' focus and selection performance.

We therefore studied the differences in performance of two classes of disambiguation techniques:

• Techniques that imply a switch of users' focus from the physical targets to a digital representation of targets: in the experiment we evaluated a commonly used technique: a list of objects' names displayed on a handheld screen (baseline technique).

• Techniques that keep users' focus on the physical targets: in the experiment we evaluated our two techniques P2Roll and P2Slide.

We chose to evaluate two techniques that keep users' focus on physical objects in order to control the effect of the input method. Having two focus-maintaining techniques also allowed us to explore the benefits and drawbacks of both wrist rolling and finger sliding inputs.

Performance of the selection techniques was evaluated by selection time and error rate. This evaluation took place along several difficulty levels: an increase of the density of physical objects is expected to augment the selection task's difficulty, as it was expected to augmented the search task's difficulty using AR techniques [START_REF] Rohs | Impact of item density on the utility of visual context in magic lens interactions[END_REF]. However, as the tasks are different, the two experiments cannot be compared.

Baseline: List

As reported in the related work section, a list displaying the names of pre-selected objects on a handheld device's screen is a commonly used technique for disambiguating the pointing selection. Thus, we chose this technique for the baseline of our experimental study.

First, the user points at a target (Figure 3,A). Once the selection volume is locked by tapping on screen (Figure 3, B), the user is able to look at the screen without the need to maintain the position of her/his arm. All pre-selected objects are displayed on the handheld device's screen (Figure 3,C). Then, the user can either directly select the desired target's name by tapping on it, or scroll the list until the name appears on screen and then tap on the desired target's name. If the first pointing gesture needs to be canceled (i.e. the desired target is not in the selection volume), users can touch the default 'return' button of the phone and retry the pointing selection.

We chose to represent physical objects by their names, since (1) images may be misinterpreted if several objects are similar, and (2) textual names can easily be ordered to help with the selection task. This choice therefore favors the list technique. We used the standard vertical list widget and the standard size of Android items: the user therefore needs to scroll when the list contains more than 8 items.

Hypotheses

For the experiment, we formulated the three following hypotheses. Two hypotheses concern the comparison of performance between focus-maintaining vs. focusswitching techniques and the third one concerns the comparison of performance of our two techniques:

• H1a: The disambiguation techniques that keep users' focus on the physical targets have better performance than the disambiguation techniques that switch users' focus to a digital representation of the physical targets.

• H1b: Users prefer focusing on the physical objects while disambiguating the pointing selection.

• H2: In the class of disambiguation techniques that keep users' focus on physical targets, the disambiguation technique using a smaller finger sliding gesture (P2Slide) outperforms the disambiguation technique using a larger wrist rolling gesture (P2Roll). Numbers were used so that names could be read from afar and quickly found in the ordered list on screen. Targets were randomly assigned a number, as in the real world objects are not necessarily placed in the alphabetical order. There was also no pattern in the disposition of targets.

Only the density of targets influences the performance of all three disambiguation techniques, thus the size of Ping-Pong balls or the distance from Ping-Pong balls are not relevant once in the disambiguation step. In order to provide different densities, sets of 2, 4, 8 and 16 light balls were fixed on 4 different 31 cm × 22 cm frames (Figure 4, right).

The same densities were used to evaluate AR search techniques [START_REF] Rohs | Impact of item density on the utility of visual context in magic lens interactions[END_REF]. We chose 16 objects as a maximum since previous work found that it is upper bound of the wrist rolling inputs [START_REF] Rahman | Tilt techniques: Investigating the Dexterity of Wrist-based Input[END_REF]. This limit also suits the P2Slide technique: accuracy with the index finger on a surface could rise up to 150dpi, i.e. targets of 0.17mm [START_REF] Bérard | Measuring the linear and rotational user precision in touch pointing[END_REF]. However, these results are for the index and not for the thumb. The maximum of 16 targets requires sectioning of the screen into areas of width of about 3.5mm, thus 20 times larger than the index limit. This is sufficient for the thumb. We also assessed that 16 objects in a selection volume represent a realistic scenario, e.g. when pointing in a smart home. Previous studies used 4 [START_REF] Rukzio | Mobile interaction with the real world: An evaluation and comparison of physical mobile interaction techniques[END_REF][START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF] or 5 [START_REF] Swindells | That one there! Pointing to establish device identity[END_REF] objects. Interviewing 13 subjects, it appears that up to 6±2 (mean ± standard deviation) objects are likely to be disambiguated in their home.

For tracking the position and orientation of the smartphone in our experiment, we used the OptiTrack2 system using 5 V100:R2 cameras and the Arena3 software. The system provided 100Hz, 6 degrees of freedom (DoF) tracking of markers attached to the device and ran on a 3.06Ghz Core 2 duo workstation.

In order to avoid a form factor and to have consistency between techniques, all three techniques used the same smartphone as an input device. The device was a Galaxy Nexus I9250 smartphone, used to capture touch inputs on the screen and to display the list of targets' numbers.

The three techniques were implemented in python and ran on a 2.2 GHz Intel Core i7 computer.

Procedure

The task in the experiment was to select a physical object, namely a Ping-Pong ball with an embedded LED. Users were sitting in front of the 4 frames exactly in the middle, at a distance of 2.1m (Figure 4, left). Although the techniques are mobile, the users were sitting in order to minimize the fatigue since the experiment was very long in time and to fully control the distance to the targets. A special frame, with only one object corresponding to the 'start target', was placed on the utmost right of the four other frames. Frames were positioned at 35 cm distance from each other.

The trial begins by pointing at a red 'start target'. For subjects to be as fast as possible, there was no constraint about the initial angle of the wrist or the initial finger position on the screen. Once pointed at, the 'start target' turned green, meaning that its selection could be validated.

After the subject validated the 'start target', another target turned red, randomly chosen among the 30 other targets. When pointing at a frame or a subpart of the frame, all targets of the frame were switched on in white, meaning that they were in the selection volume. Our pilot study showed that users tended to only aim at a subset of the frame when the target was on the border, thus creating new uncontrolled densities and scattering data. In order to avoid this uncontrolled parameter in our experiment, frames were completely selected even if they were not completely inside the selection volume. This design choice allowed us to ignore the size of the selection volume and to control the number of selected items in the experiment.

When beginning the disambiguation step, feedback was provided:

• In the physical world for the P2Roll and P2Slide conditions, a target turned blue in the pre-selected volume of white targets in order to indicate what the current element was. When the current element was on the desired red target, the target turned from red to green. • On the device's screen for the List condition. A sound feedback was additionally provided by the smartphone to notify the user about the appearance of the list of targets' number on screen. This was done in order to guide visual attention to the screen of the mobile phone [START_REF] Talsma | The multifaceted interplay between attention and multisensory integration[END_REF].

Once the disambiguation was validated (either right or wrong), a sound indicated that the trial was complete and the 'start target' turned red again for the subject to launch the next trial.

Design

We used a repeated measure within-participant design. The independent variables were the disambiguation technique T (List, P2Roll, P2Slide) and the density D [START_REF] Balakrishnan | Performance differences in the fingers, wrist, and forearm in computer input control[END_REF][START_REF] Bérard | Measuring the linear and rotational user precision in touch pointing[END_REF][START_REF] Delamare | Designing Disambiguation Techniques for Pointing in the Physical World[END_REF][START_REF] Patel | A 2-way laser-assisted selection scheme for handhelds in a physical environment[END_REF].

The experiment lasted approximately 90 minutes per participant, and was divided into 3 sections corresponding to the three techniques. The order of the disambiguation techniques was counterbalanced between subjects. A Latin square design was used for balancing the different positions of the target frames between subjects, so that all 4 frames happened to be at the 4 different distances from the 'start target'. Between each section, users were asked to fill a qualitative questionnaire about the technique they just used. Each section consisted of 6 blocks: 3 training blocks and 3 blocks for measuring performance. The 3 blocks of training aimed at (1) avoiding the "wow effect" that occurs during our pilot study when users first manipulate new interaction techniques, (2) recording data from "equally expert" users, since some participants were already used to select an item in a list, and (3) allowing users to learn the new techniques, in particular the horizontal/angular mapping between physical objects and Roll and Slide inputs as it may be difficult, e.g., for objects 10 and 13 figure 4, right. Each block consisted of 40 random selections (10 for each density condition). This design resulted in 3 techniques × 3 blocks × 40 selection tasks, i.e. 360 trials per participant and 4320 trials in total.

RESULTS

The main dependent measures for the task were trial completion time and error rate (for H1a and H2). In order to obtain a deeper insight into the differences between the techniques, we also considered their footprint. The footprint of a device is the length of the path the device went through during a trial. This is a commonly used measure for evaluating fatigue while manipulating a device [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF].

A total of 1.58% of the trials were removed as outliers (data off by at least three standard deviation from the mean).

There was no need to test for learning or order effect since the techniques and the target frames were counterbalanced.

We performed non-parametric tests on our data, instead of ANOVA, since (1) a Shapiro-Wilk normality test showed that there was a violation of the normality assumed for parametric tests (p < 0.0001), and (2) a Bartlett's test showed a violation of homogeneity of variances for all factors (p < 0.0001).

Keeping users' focus on the physical target is efficient (H1a)

The experiment confirmed H1a: using Friedman's nonparametric tests, we found significant main global effects for T [χ 2 (2) = 129.9, p < 0.0001] and D [χ 2 (3) = 1166.1, p < 0.0001] on completion time (Table 1 However, when taking into account error rates, Chi-square tests revealed that the density D had significant effects on P2Roll [χ 2 (3) = 39.1, p < 0.0001] and P2Slide [χ 2 (3) = 55.7, p < 0.0001] only (Table 1). P2Roll and P2Slide show an important increase of incorrect selections (from ~3% for density 2 to ~20% for density 16). On the contrary, the density does not impact the error rate for List (between 2% and 5%).

We further refine the error analysis by considering the error types. First, errors can happen when the desired target is not in the pointing selection (see Table 2, "Out" values). 16% of P2Roll incorrect selections were such errors and 22% for P2Slide (against 14% for List). Two observations during the experiment indicate a possible explanation:

• Some users tended to lock the selection volume faster when keeping their focus in the physical world, thus they were selecting the wrong frame. This is confirmed with the rate of cancel action per technique: 6.3% for P2Roll, 2.7% for P2Slide and 0.5% for List. • The cancel action was more difficult for P2Roll and P2Slide (sliding the thumb to the bottom of the screen) than for List (touching the default cancel button).

Thus, both the rush for locking the volume selection and the cancel difficulty led to more incorrect selections for P2Roll and P2Slide than for List.

Second, and more importantly, when errors happen at the disambiguation step (i.e., within the right selection volume), two kinds of errors happen: before or after reaching the desired target (see Finally another explanation for the error performance is the arm fatigue over extended usage. List has a smaller footprint (18.58±9.44 cm) than P2Roll (26.73±13.24 and P2Slide (24.82±13.39 cm). Friedman's tests revealed significant global effect of T [χ 2 (2) = 217.9, p < 0.0001]: users did smaller arm movements while selecting in the list than while gesturing with the wrist or even with the finger. This could explain that subjects became more tired and made more errors with P2Roll and P2Slide than with List.

Avenues for improving the P2Roll and P2Slide techniques are threefold. First, different cancel actions of the pointing step must be studied. Second, accuracy in high densities using P2Roll could be improved adapting RapMenu [START_REF] Ryan | Tech-note: rapMenu: Remote Menu Selection Using Freehand Gestural Input[END_REF]: a rolling range would be then linked to more than one physical object, and pinch gestures would be mapped to the selected objects of a given rolling range. This solution could address the wrist accuracy limit factor. Third, decoupling the trigger from the disambiguation selection might be proposed for high densities. For instance, the trigger of P2Slide could be done using a 'tilt-forward' as for TouchOver [START_REF] Scoditti | TouchOver: decoupling positioning from selection on touch-based handheld devices[END_REF]: indeed, the decoupling of the trigger action from the selection action facilitates avoidance of last minute unwanted movements.

To conclude on time and error performance related to H1a, keeping users' focus in the physical world while disambiguating a pointed volume is more time efficient.

Yet, in order to decrease the error rate in high densities of the focus-maintaining techniques, P2Roll and P2Slide, we plan to explore different cancel actions of the pointing step as well as to study a validating mechanism decoupled from the selection mechanism as described above. Such a validating mechanism as well as a correct cancel action of the pointing step could prevent ~70% of errors of P2Roll and P2Slide.

Users prefer keeping their focus on the physical target (H1b)

The second hypothesis was that users would prefer to maintain focus on the physical targets when disambiguating a pointed volume. This is validated since 10 out of 12 participants reported a preference for either P2Roll (5 participants) or P2Slide (5 participants) and ranked List last (only 2 preferred List). A more detailed analysis shows that even if users found many benefits to List (e.g., they felt confident, they found it easy to learn and use), they also found it the least enjoyable technique to use.

It also appears from the analysis of the interviews that 7 participants mentioned negatively the switching of focus, saying, e.g., "It is not cool to look at the screen and loose eye-contact with the balls" and 4 participants mentioned negatively the feeling of having extra-actions to perform (such as reading or scrolling), saying, e.g. "It is tiresome to have to read". Yet, some participants were aware of the accuracy benefit of having the list representation (5 participants), saying for instance "I do not have to do precise movements".

To conclude on H1b, users prefer techniques that keep their focus of attention on physical objects, even though they are aware of drawbacks such as the lake of precision for the highest density. This confirms that it is worth studying focus-maintaining techniques such as P2Roll and P2Slide.

Smaller gestures are not always more efficient (H2)

Our hypothesis H2 was that the smaller gestures of P2Slide would outperform larger gestures of P2Roll. Indeed, a Post-Hoc test using Mann-Whitney tests with Bonferroni correction revealed that completion time of P2Slide was better only for density 2 (p < 0.0001, r = .048), and equivalent to P2Roll for all the other densities. We explain this result by the fact that smaller movements are more efficient only if the task is easy. But when the difficulty increases, the smaller movements need to be performed with care and the time difference between small and large movements disappears.

Regarding error rates, Chi-square tests revealed no significant differences between P2Roll and P2Slide, whatever the density is [χ 2 (1) = 0.8491, p > 0.1]. Yet, the wrist movements of P2Roll seem to be more tiring: when analyzing the interviews, we found that physical fatigue has been reported mostly for P2Roll (7 times for P2Roll, 3 times for P2Slide and 4 times for List). However, as previously reported, P2Roll and P2Slide have been ranked as the first preferred technique by 5 participants each.

To conclude on H2, P2Slide has better performance only for density 2. Based on both quantitative and qualitative data analysis, P2Roll and P2Slide can be considered as equivalent for the higher densities (4, 8 and 16 targets).

TOWARD DISAMBIGUATING IN THE REAL WORLD

In contrast to our experiment, objects in the real world can occlude each other in two ways. First, we voluntarily omit total occlusion since the resulting lack of feedback for the occluded object is out of the scope of this study involving a motor-perceptual task. Second, partial occlusion still enables left/right relationships to be defined. E.g. if a large object is behind a smaller one and the former is visible all around the latter, the former can be arbitrarily defined "on the left". This arbitrary mapping has to be learned during training, as users do in real settings.

In contrast to our experiment, the implementation of the techniques would have to be adapted for a real-world setting, e.g., with an RFID reader embedded in the device and hidden sensors attached to physical objects.

CONCLUSION AND FUTURE WORK

Mobility gives users the opportunity to select and interact with physical objects around them, anywhere and anytime, thanks to handheld devices. In this context, our contributions are two-fold. First we have presented two new selection techniques -P2Roll and P2Slide -that keep users' focus directly on physical objects, unlike GUI or AR techniques. Second we conducted an in-lab experiment mainly showing that keeping users' focus on the physical target is efficient and preferred by users when disambiguating a selection. We showed that the gain in performance is valid when up to 8 objects are included in the pointed selection volume. For the higher density of objects (16 objects in the selection volume), the focusmaintaining and focus-switching techniques are equivalent. We were able to identify a convergence at the density of 16 objects as our experiment considers a higher maximum density than previous studies (4 physical objects were used in [START_REF] Rukzio | Mobile interaction with the real world: An evaluation and comparison of physical mobile interaction techniques[END_REF][START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF] and 5 objects in [START_REF] Swindells | That one there! Pointing to establish device identity[END_REF]).

In future work, in order to go beyond this experiment validating two new focus-maintaining techniques, three paths are now to be explored.

First, we plan to improve the performance of our techniques. To do so, we will explore discrete gestures instead of continuous ones (e.g. swipe instead of slide for P2Slide) and 2D gestures instead of 1D ones. In a pilot experiment we conducted, users gave positive feedback on an early prototype of the extended P2Slide technique with 2D (horizontal and vertical) finger movements.

Second, we plan to provide a better understanding of movement time by extending Fitts law to focus-maintaining techniques. This will allow our knowledge of these techniques to catch up with current knowledge of GUI or AR techniques for pointing in the physical world. Doing so will require a subsequent study, controlling the use of the techniques in order to be able to model them, e.g. the initial rolling angle for P2Roll. Contrastingly, the study presented here to validate focus-maintaining techniques allowed users to be as efficient as possible, e.g. by rotating the wrist in advance as users can do in real settings. Indeed, such 2-step interaction techniques can benefit from parallelization as for the GUI Rake-Cursor technique [START_REF] Blanch | Rake Cursor : Improving Pointing Performance with Concurrent Input Channels[END_REF]. Fitts modeling of our techniques through a dedicated experiment will allow a better understanding of their benefits.

Third, we plan to extend our work by getting closer to reallife scenarios.

• We will investigate how users adapt themselves to high densities in real life. For instance, from which density users would rather walk closer to their target to decrease the density in the selected volume? • We will investigate targets without visual feedback, for instance providing an audio list of pointed objects. • We will investigate techniques for control, which usually follows the selection of an object. An interesting direction is to adapt Control Menus [START_REF] Pook | Control menus: excecution and control in a single interactor[END_REF] to mid-air gesture. Doing so, users will be able to perform both the selection and the command (e.g. dimming a light) in a single, quick gesture while maintaining their focus on the physical target. • After conducting in-lab experiments, we will conduct an in-vivo experiment of the P2Roll and P2Slide techniques. Indeed, it is common to first perform in-lab evaluation [START_REF] Rohs | Target acquisition with camera phones when used as magic lenses[END_REF], and then validate results in the real world [START_REF] Rohs | Interaction with magic lenses: real-world validation of a fitts' law model[END_REF]. The concrete task will be a lighting source selection in the context of a restaurant and of a hotel suit.

Figure 2 :

 2 Figure 2: P2Slide walkthrough. A) The pointing step. B) The beginning of the disambiguation step with a touch gesture. The current element is '2' since the thumb is in its area. C) The user performs a sliding gesture to the left, so that '3' becomes the current element. D) The user performs a sliding gesture to the right extremity, so that the current element goes from '3' to '1' by traversing '2'.

Figure 1 :

 1 Figure 1: P2Roll walkthrough. A) The pointing step. B) The beginning of the disambiguation step with a touch gesture. The current element is '2' since the rolling angle is in its area. C) The user performs a rolling gesture to the left, so that '3' becomes the current element. D) The user performs a rolling gesture to the right extremity, so that the current element goes from '3' to '1' by traversing '2'.

Figure 3 :

 3 Figure 3: Illustration of List. A) The pointing step. B) The beginning of the disambiguation step with a touch gesture. C) The list of objects' names displayed on screen.

Figure 4 :

 4 Figure 4: Left: setup of the experiment. Right: a frame with 16 Ping-Pong balls embedding RGB LEDs. All (white) balls are in the selection volume; #21 (red) is the target of the current trial; #8 (blue) is the current element. Participants Six male and six female unpaid volunteers, ranging in age from 22 to 33 years old (26.75±2.70), participated in the experiment. One participant was left-handed, and 8 used tactile smartphone on a daily basis. All participants controlled the input device with their dominant hand.

Table 1 : Movement Time (MT in seconds, m ± sd gives the mean m and the standard deviation sd) and Error Rate (ER in %) by technique for each density.

 1

	). A Post-Hoc test

Table 2

 2

				, "Before" and
	"After" values). Both P2Roll and P2Slide have ~60% of
	their errors happening right after reaching the target. The
	validating release of the finger happened on average 0.51s
	after the loss of the desired target for P2Roll, and 0.75s for
	P2Slide. One possible explanation is that the validating
	mechanism (i.e., release the finger from screen) is tightly
	coupled with the disambiguation selection (i.e., rolling or
	sliding) for P2Roll and P2Slide.
		Out	Before	After
	P2Roll	16%	18.4%	65.6%
	P2Slide	22.86%	18.57%	58.57%

Table 2 : Percentage of type of error for P2Roll and P2Slide. Most errors happen after that the desired target became the current element.

 2

http://www.arduino.cc/

http://www.naturalpoint.com/optitrack/ 2 http://www.naturalpoint.com/optitrack/

http://www.naturalpoint.com/optitrack/products/arena/

ACKNOWLEDGMENTS

This work has been supported by the DELight project (French government's FUI -Single Inter-Ministry Fundprogram) led by Schneider Electric.