Alfonso García Frey

Gaëlle Calvary
email: .calvary@imag.fr

Sophie Dupuy-Chessa
email: sophie.dupuy@imag.fr

Nadine Mandran
email: nadine.mandran@imag.fr

Model-Based Self-Explanatory UIs for free, but are they valuable?

Keywords: Self-Explanatory User Interfaces, Model-Driven Engineering, Models at runtime, Self-Explanation. 1 81

Model-Driven Engineering (MDE) has been extensively used for generating User Interfaces (UIs) from models. As long as these models are kept alive at runtime, the UIs are capable of adapting to variations of the context of use. This paper investigates a potentially powerful side effect: the possibility of enriching the UIs with explanations directly generated from these models. This paper first describes a software infrastructure that supports this generation of explanations. It then reports on a user study that evaluates the added value of such model based self-explanations.

Introduction

Many works ([9, 10, 14]) have reported on the benefits of supporting users through explanations in interactive systems. These explanations address specific questions that users ask about the User Interface (UI). For instance, how a task can be accomplished, why a feature is not enabled, or where an option is. Classical approaches [START_REF] Horton | Designing and Writing On-line Documentation[END_REF], which are based on predefined information such as static documentation, FAQs, and guides, specify this information at design time. Their scope is therefore limited because users can have questions about the UI that are not covered by these kinds of supports. Moreover, this static documentation is not only a time consuming task but, additionally, it requires manual updates when the program specification changes. To overcome this limitation, some researches [START_REF] García Frey | Users need your models! Exploiting Design Models for Explanations[END_REF] have recently proposed Model-Driven Engineering (MDE) as a means for supporting users at runtime. Model-Driven UIs use the models created at design time as their knowledge-base at runtime, exploiting the models and the relationships between them to find answers to the users' questions. These kinds of UIs with support facilities based on their own models are also known as Self-Explanatory UIs. Their main advantages are that answers are generated at runtime, and they evolve with the program specification automatically.

This paper firstly describes a self-explanatory system, explaining how to compute different types of explanations based on the underlying models. This system is representative of what explanations a model-based UI can provide. The paper then reports on an evaluation about the suitability of model-driven engineering for explanation purposes. We conducted a user study on such a self-explanatory UI. This UI reproduces an existent website, where all the necessary models have been generated by a reverse engineering process. The resultant model-driven UI has been extended with support facilities based on such models, to allow users to ask questions about the UI at runtime.

The paper is structured as follows. The next section provides related work on model-based explanations. Then, the paper describes the working hypothesis. Later, it presents the infrastructure of the self-explanation system that we used in our experiment. We also explain the algorithms that we used to, based on the models available at runtime, generate the questions and answers according to the model-driven approach. The paper then covers the user study, describing the experiment and the evaluation protocol. The final section analyzes and discusses the results of the qualitative analysis we did on the collected data. Finally, the paper ends with a conclusion and a brief discussion about the future perspectives.

Related Work

This section briefly explains the role of MDE in HCI and how its different types of models are used in different works for supporting users with specific types of explanations. A different type of explanation is provided regarding the nature of the question asked by the user. For instance, [START_REF] Sellen | Building user-centred on-line help[END_REF] describe five categories of questions: goaloriented (What can I do with this program?), descriptive (What is this? What does it do?), procedural (How do I do this?), interpretive (Why did this happen?) and navigational (Where am I? Where is it?).

Other authors describe similar categories but with different terms. For instance in [START_REF] Spieker | Natürlichsprachliche Erklärungen in technischen Expertensystemen[END_REF] we find conceptual explanations (What is this?, What is the meaning of this?), Why-explanations describing causes and justifications for facts, How-explanations for describing processes, Purpose-explanations (What is this for? or What is the purpose of this?), and cognitive explanations, which "explain or predict the behavior of 'intelligent systems' on the basis of known goals, beliefs, constraints, and rationality assumptions" [START_REF] Spieker | Natürlichsprachliche Erklärungen in technischen Expertensystemen[END_REF].

Some of these types of explanations have been provided through different models in model-based approaches. We firstly explain the model-driven approach of UIs before presenting such model-based explanations.

MDE for HCI

Model-Driven Engineering (MDE) has been recently applied to the engineering of UIs. It consists in describing different features of UIs (for instance, tasks, domain, context of use) in models from which a UI is produced according to a forward engi-neering process [START_REF] Vanderdonckt | Model-driven engineering of user interfaces: Promises, successes, failures, and challenges[END_REF]. An example of a MDE-compliant approach is the Cameleon Reference Framework [START_REF] Calvary | A unifying reference framework for multi-target user interfaces[END_REF], where a task model is transformed into an Abstract User Interface (AUI) model, which is in turn transformed into a Concrete User Interface (CUI) model representing the interactors or widgets, from which the Final User Interface (FUI), i.e., the code of the UI itself, is derived. The experimentation presented later is based on this approach. Some models of the Cameleon Reference Framework existed before MDE and they have been already used separately for explanation purposes in several works. For instance, task models have been extensively used for automatically generate procedural information in different forms.

Model-based explanations

An early example that employs a task model (in the form of user's actions) for explanation purposes is Cartoonist [START_REF] Sukaviriya | Coupling A UI framework with automatic generation of context-sensitive animated help[END_REF]. Cartoonist generates GUI animated tutorials to show a user how to accomplish a task, exploiting the model for providing run-time guidance.

Pangoli and Paterno [START_REF] Pangoli | Automatic generation of task-oriented help[END_REF] allow users to ask questions such as How can I perform this task? or What tasks can I perform now? by exploiting a task model described in CTT. Contrary to Cartoonist, answers are provided in [START_REF] Pangoli | Automatic generation of task-oriented help[END_REF] in natural language. Tasks modeled in the form of Petri Nets are used for similar purposes by Palanque et al. in [START_REF] Palanque | Contextual help for free with formal dialog design[END_REF], answering questions such as What can I do now? or How can I make that action available again?

Other works report on the usage of task models as a means for creating collaborative agents that help the user [START_REF] Eisenstein | Agents and GUIs from Task Models[END_REF].

Behavioral models, presented in different forms, have been also used to support Why and Why not questions in user interfaces. In [START_REF] Palanque | Contextual help for free with formal dialog design[END_REF] Why questions are answered using the same approach based on Petri Nets that is exploited for procedural questions. By analysing the net it is possible to answer questions such as Why is this interaction not available?

The Crystal application framework proposed by Myers et al. [START_REF] Myers | Answering why and why not questions in user interfaces[END_REF] uses a "Command Object model" that provides developers with an architecture and a set of interaction techniques for answering Why and Why not questions in UIs. Crystal improves users' understanding of the UI and help them in determining how to fix unwanted behavior.

Lim et al. [START_REF] Lim | Assessing demand for intelligibility in context-aware applications[END_REF][START_REF] Lim | Why and why not explanations improve the intelligibility of context-aware intelligent systems[END_REF] observed that why and why not questions improve users' understanding and confidence of context-aware systems.

Vermeulen et al. [START_REF] Vermeulen | PervasiveCrystal: Asking and answering why and why not questions about pervasive computing applications[END_REF] propose a behavior model based on the Event-Condition-Action (ECA) paradigm, extending it with inverse actions (ECAA -1 ) for asking and answering why and why not questions in pervasive computing environments.

These researches show explanations based on individual models. We aim to evaluate the suitability and added value of model-based approaches of UI, that can use one or more different models at the same time. In particular, we want to see whether these model-based approaches can generate more powerful explanations or have any extra added-value with regard to the previous isolated solutions. This is what our working hypothesis describes in the next section.

Working Hypothesis

In our previous work, we tried to combine different models for explanation purposes.

We explored [START_REF] García Frey | Xplain: an editor for building self-explanatory user interfaces by model-driven engineering[END_REF] how to let designers to describe the task model behind a UI, which is provided in the form of a Final UI (the model representing the UI itself), so procedural explanations could be provided based on this task model. We also explored how to support designers through design questions based on design rationale notations [START_REF] García Frey | Quimera: a quality metamodel to improve design rationale[END_REF], and an architecture for the unification of several help facilities in [START_REF] García Frey | Users need your models! Exploiting Design Models for Explanations[END_REF], showing how to employ CUI models for Where questions, or annotated task models for providing descriptions at runtime. These last works, that combine and integrate different models to compute several types of explanations, suggest that the model-driven approach of UIs, which is based on similar design models to those presented in the related works, should provide users with explanations that are at least of the same interest, usefulness and relevance than those provided by each model individually. Moreover, as model-based UIs can rely on a greater number of models or even include new ones, the power of explanation could be potentially better as well.

To verify the added-value of the model-driven approach of UIs for explanation purposes, we conducted an experimentation based on a model-driven prototype, which is described in the next section. The prototype was built according to the Cameleon Reference Framework, and it includes a self-explanatory facility in the form of a dialog to let users ask different types of questions about the UI. This system is representative of what explanations a model-based UI can provide.

Prototype Description and Supporting Infrastructure

This section firstly describes the prototype and the infrastructure of the help facility. Then it details the algorithms used for computing the questions and answers provided to the users, detailing how the models are used at runtime.

Prototype Description

The prototype consists in a cars shopping website called UsiCars. This website is inspired by a real site from a real car manufacturer. We reproduced only the part of the website that is devoted to the selection and configuration of the vehicles, keeping the options and the structure of the original website. This website was chosen for two main reasons. The first one is that we needed to use a system that contains knowledge that is understandable and accessible by all the participants, but complex enough for not being easy to use. A website for configuring cars covered this point as all the participants understand many of the car related con-cepts, but at the same time there are enough specific options with domain related concepts to create complex tasks that are non trivial to perform. The second reason is that we found the original website difficult to use by real users in different forums.

The reproduction of the website was done by a reverse engineering process. The first step was to explore all the different tasks that the user can perform to select and configure a vehicle. We created a task model according to this information. Secondly, we created a transformation to obtain an Abstract UI model that conforms to the structure of the original website. Thirdly, we wrote another transformation to generate the Concrete UI model from the Abstract UI model. This transformation produces all the widgets that we find in the original website. We also used the same images and we respected the same sizes for all the widgets from the original site, to ensure that we obtain the same usability properties. Finally, we wrote another transformation to generate the Java code and produce the resulting site.

In each one of the model to model transformations, we generated not only the target model but also mapping models that keep track of the successive transformations of an element from one model to another. For instance, in the transformation from the task model to the Abstract UI model we generated a Mapping-Task2AUI model that specifies what tasks are transformed into what Abstract UI elements. The same principle was applied to obtain a Mapping-AUI2CUI model. This allow us to go through the transformation chain and, for instance, retrieve the source task from which a button has been generated. Figure 1 shows an excerpt of the UI of the prototype. The UI is divided into two main parts. A big area in the middle and a thin area at the bottom. The central area of the UI has two different roles. On one hand it serves as a visual feedback for the user when he/she selects a car model or changes the color of the vehicle (figure 1). On the other hand, it can show dialogs containing all the possible options that the user can select to configure the car with. The thin area at the bottom allows users to navigate through several categories of options for accessing different features of the car such as the electronic equipment or the exterior color of the vehicle.

The prototype was build according to the approach described in [START_REF] García Frey | Users need your models! Exploiting Design Models for Explanations[END_REF], so the different types of questions previously discussed could be generated and fully integrated into the UI of the prototype. The infrastructure (figure 2) consists in two model-based UIs, the self-explanatory facility for providing the help and the application. For a discussion on how to mix both set of models see [START_REF] García Frey | Users need your models! Exploiting Design Models for Explanations[END_REF]. The functional core of the help UI is composed of 4 modules for generating the list of questions (QG), interpreting (I) a user's request, i.e., inferring the type of question and its parameters, the processor (P) that computes the answer based on such parameters, and the answer generator (AG) that presents the answer back to the user. Each of these four modules of the functional core of the self-explanatory facility has full access to the models of the underlying application at runtime. Fig. 2. Infrastructure for self-explanatory UIs. The possible questions are generated by the Question Generator (QG) from the Functional Core of the help facility (FC). For each user's request, the Interpreter (I) determines its type and parameters, used by the Processor (P) to compute the answer, which is presented in some form (textual in this prototype) to the user thanks to the Answer Generator (AG). These four modules use the application models at runtime.

Self-Explanation Infrastructure and Questions / Answers Computation

To check the added-value of model-driven UIs in terms of explanation purposes, we supported six different types of questions built all of them upon the main models of the Cameleon Reference Framework. Figure 3 summarizes the models that have been used to generate the questions and their respective answers. For each of the types, we explain the algorithm we followed to generate the questions, the algorithm for the answers, and the involved models used in each case (summarized in figure 3).

Procedural Questions -How

To generate How questions, we explore the task model recursively from the root task to the leaves. For each node representing a task, we create a question in a textual form according to the following grammar:

How to + Task.name + ? 1 were tasks are named starting with a verb following a standardized convention. An example of a How question is: How to choose Packs?

The computation of the answer is done as follows. First, we locate the task inside the task model. Second, we inspect the mapping model that maps tasks to AUI elements from the AUI model, so we can retrieve the abstract UI element that resulted from transforming such task. Once the AUI element has been found, we repeat the procedure to locate the CUI element derived from this AUI element. This is done by inspecting the mapping model that keeps track of the transformations from AUI ele-1 Original questions were asked in french. The shown grammar as well as the examples and their related answers are adaptations from the original questions presented in this research.

ments to CUI elements. Once the CUI element has been retrieved, we compose the answer with following grammar:

Use the + CUI-elem.name + CUI-elem.type

An example of a computed answer using this approach is:

Use the Packs button

Note that the answer can be completed with the information about the localization of the widget, which is computed later in the Where questions. In this way, a more elaborated answer for CUI elements that were not directly visible from the user's were composed as follows:

Use the + CUI-element.name + CUI-element.type + in the + CUI-element.parent + CUI-element.parent.type where an example is:

Use the 'Pack Connected Drive' checkbox button in the 'Optional Equipment' panel.

Purpose/Functional Questions -What is it for

The purpose questions generated in the prototype were of the form:

'What is the + CUI-element.name + CUI-element.type + for?'

An example of a purpose question is:

What is the 'Optional Equipment' button for?

To compute these questions, we iterate through the CUI model of the UI, adding a question for each new element. We added questions for all the CUI elements except for layouts, as they are the only CUI elements that are not directly visible by the user. Answers where computed as follows. First we inspect the mapping model between the AUI and the CUI models to retrieve the AUI element from which the CUI element has been generated. Once we have the AUI element, we retrieve the task originating this AUI element, i.e., the source of the transformation chain. Once the task has been retrieved, we directly provide the name of the task, answer is computed using the name of the task in the following grammar:

To + task.name As in the example:

To 'Select the optional equipment'

Even if this question is mostly useful for images or icons that have an unclear meaning, we also generated the questions and answers for the rest of the CUI elements, even if they presented textual information that made clear the purpose of the object.

Localization Questions -Where

The generated Where questions are of the form 'Where is the + CUI-element.name + ?' As in the example:

'Where is the Tuner DAB?'

The process of generating these types of question is quite similar to the previous purpose questions. We only considered CUI elements having textual information, i.e., labels, any kind of textual buttons such as normal buttons, checkboxes or radio buttons, menus, menu options, and window titles. The reason for avoiding other types of widgets like images is that we didn't want the user to describe such widgets and thus, asking open questions that the system couldn't understand. Answers were computed by finding the direct parent or container of the CUI element. This is, we first locate the CUI element in the CUI model and then we retrieve its parent, avoiding again layouts that are not visible for the user. For the Where question given in the previous example, the Tuner DAB refers to a checkbox button located on the 'Optional Equipments' panel. Thus, the grammar generating the answer is:

'The + CUI-element.name + is on the + CUI-element.parent + CUI-element.type' So the answer given by the system is:

The Tuner DAB is on the Optional Equipment Panel

What Can I Do Questions

The "What can I do now?" question provides information about what tasks are currently available to the user regarding its current situation in the UI, i.e., depending on the current task that the user is currently performing at the moment of asking the question. As not all the tasks are always available at the time, answers for the same question can vary in time. The presented question is then always of the form:

What can I do now?

The computation of the answer relies on the task model. We first retrieve the current task in the task model. We used the CTT notation to describe the task model so we find the available tasks as follows. From the current task in the task tree, we compute which sister tasks are available regarding the LOTOS operators used by CTT. We add the name of each available task to answer. We then recursively iterate from the current task to the root task of the tree, adding all the available tasks. We finally add the available sub-tasks. The final answer is then a list of tasks shown according to the next grammar: You can + task-1.name + … + task-N.name

For example, when the user accesses to the Optional Equipment panel, the answer to What can I do now? is:

You can select the external equipment, select the internal equipment, select the internal decorations, select the functional equipment, select the on-board electronics, select the wheel rims, select the maintenance contract.

Behavioral questions -Why

Behavioral questions were generated under the form:

Why I can't + task-N.name + ?

Where the task task-N is unreachable from the current task. For instance:

Why I can't Visualize the car?

To compute questions we proceed as for What can I do now?, locating the current task in the task tree first. We then locate all the unreachable tasks in a similar process, i.e., locating unreachable sister tasks (due to the CTT LOTOS operators) and traveling the task tree to the root and to the leaves. For instance, a task B enabled with information from a task A (A []» B ) is unreachable until the information is received. Questions are added for all the unreachable tasks following the previous grammar. Answers are computed by finding the path that enables the given task. If a task is not reachable it means that some task or tasks need to be done. We find these tasks by traveling the sister and mother tasks (up to the root), locating the LOTOS operators that enable the desired task. For instance, for the task 'Visualize the car', the task was reachable by selecting the model of the vehicle first, so the provided answer is: You need to Select the model which conforms to the grammar we used: You need to + task-1.name [+, task-N.name]*

Design Rational Questions

We also included a QOC and a quality model to compute questions and answers about the design rationale of the UI. A detailed description of the models and the procedure can be found in [START_REF] García Frey | Quimera: a quality metamodel to improve design rationale[END_REF]. The proposed questions were directly retrieved from the QOC model. This model is a simplified version of the one in [START_REF] García Frey | Quimera: a quality metamodel to improve design rationale[END_REF]. Answers were supported by one ergonomic criterion. The answers were computed according to the quality criteria supported by each option of the QOC model as shown in the following example:

Why the engines are ordered by price?

The provided answer, which follows the grammar "Because the ergonomic criterion is + criterion.description", is:

Because the ergonomic criterion 'Items of any select list must be displayed either in alphabetical order or in any meaningful order for the user in the context of the task'.

Self-explanatory dialogue

The questions were presented in a textual form inside a dialog box (figure 4). Textual answers shown up after clicking on the desired question. In the experiment, questions were presented one by one and only at the end all the questions were shown together. We didn't filter out any question in this dialog, i.e., all the possible questions that the system was able to answer were proposed to the user. The reason for this was to show the user all the questions, so he/she can better realize if the self-explanatory system could cover his/her expectations for the given type of question. For instance, if the user realizes that his/her question is missing in the list.

User Study

We conducted an experiment to evaluate the added value of model-based self-explanations. This section starts describing the participants involved in the experiment.

Then it describes each of the different phases that integrate the evaluation protocol.

Last section details the prototype that we have developed to carry out the study.

Participants

We selected 20 participants, all between 23 and 39 with an average age of 27.4. From the 20 participants, 12 were male and 8 female. We recruited individuals regardless their experience with interactive systems because the possible added value of modelbased explanations can vary regarding the experience of each profile.

Method

To carry out the study, we broken-down the evaluation protocol into three different phases.

In the first phase, we asked the participants to answer a questionnaire. This questionnaire allowed us to better know the background of participants, to understand their habits regarding how they use new technologies in general, what are their common uses, the kind of applications they use with a relevant frequency, the problems they use to find with these or other applications, as well as their habits for solving these problems. The questionnaire also included questions regarding how participants used the help provided by the applications they use, and how they used to proceed in case they have a problem with the application. A software recorder was used to record all the answers of all the participants.

In the second phase of the experiment, we asked the participants to use the prototype that we had developed to this aim. We asked them to complete 10 different tasks in an established order. All the participants received the identical 10 tasks. We randomized the order of the tasks for each participant to avoid side effects such as the influence between different tasks or memory effects that can help users to accomplish the tasks better in a certain order. This part of the experiment was conducted on a laptop and the audio was recorded. We asked the participants to verbalize their thoughts, specially the questions they would like to ask to the system and the problems that they find when accomplishing the tasks.

The third part of the experiment presented the prototype including a self-explanatory dialog that contained one type of question at a time. The six questions discussed previously were presented one after another again in a randomized order. For each type of question, the dialog box showed all the possible questions that the participants could ask. Every time we showed a new type of question, we asked the participants their opinion about it, including the possible advantages and disadvantages of asking that question to the UI. We asked as well if the given type of question could be useful in the previous phase of the experiment. At the end of the third phase, all the types of questions were shown together into the same self-explanatory dialog, and we asked some more general questions that are discussed in section 6.

Tasks

The motivation for the second phase of the experiment was to confront the users with different kinds of problems that are frequently found in UIs. To this end we designed 10 different tasks. The tasks were selected according to their complexity, ranging from easy tasks to more complex ones. We didn't force any specific problem in the tasks that could be easily solved by one of the previous questions. Instead, we tried to reproduce a realistic use case with a varied set of tasks so the answers of the participants in phase 3 were not influenced by the second phase. The 10 different tasks that we asked the participants to complete are shown in table 1. The accomplishment ratio indicates whether the participants were able to complete the tasks at all. A few users that got stuck and required hints were counted as unsuccessful. The accomplishment ratio gives an idea of how difficult each task was, regardless the expertise of the user. Some of the tasks involved selection with searches through small lists (1, 2, 4, 8) while others involved selection through lists having multiple options and categories [START_REF] García Frey | Xplain: an editor for building self-explanatory user interfaces by model-driven engineering[END_REF][START_REF] Horton | Designing and Writing On-line Documentation[END_REF][START_REF] Lim | Why and why not explanations improve the intelligibility of context-aware intelligent systems[END_REF] in different locations. Tasks 1, 2 and 4 involved selections through images while the rest of the selection tasks were through options in textual form. Other tasks involved verification [START_REF] García Frey | Quimera: a quality metamodel to improve design rationale[END_REF][START_REF] Horton | Designing and Writing On-line Documentation[END_REF][START_REF] Myers | Answering why and why not questions in user interfaces[END_REF], comparison [START_REF] Horton | Designing and Writing On-line Documentation[END_REF], or manipulate cars related terminology that was more or less easy to understand [START_REF] Dix | Human Computer Interaction[END_REF][START_REF] García Frey | Users need your models! Exploiting Design Models for Explanations[END_REF][START_REF] García Frey | Quimera: a quality metamodel to improve design rationale[END_REF][START_REF] Lim | Assessing demand for intelligibility in context-aware applications[END_REF]. Table 1. List of tasks and their accomplishment ratios. The tasks were randomized to avoid side effects such as the influence between tasks or memory related effects. The accomplishment ratio give an idea of the difficulty of the task.

Task description

Accomplishment 12/20

We used the accomplishment ratio in the last part of the experiment, specially when we asked the participants if they believed that the model-based explanations could help them to complete one of the problematic tasks, or doing it in a more efficient way. The next section discusses the results of the qualitative analysis that we carried out with all the collected data.

Qualitative analysis

A large amount of qualitative data was collected from the experiment. We extracted around three hundred comments from the records made during the second phase of the experiment, the one in which participants were asked to complete the list of tasks. The selected method of analysis was the thematic type [START_REF] Paillé | L'analyse qualitative en sciences humaines et sociales[END_REF]. This method is focused on the answers and comments recorded during the experiment, and classified into categories later on. The aim of the thematic analysis is to group together answers or parts of answers that have the same meaning. The thematic groups were then analyzed to identify the different categories of opinion. The objective is to gather and list all the themes covered by the answers to reflect the widest possible range of opinions, distinguishing the positive ones from the negative ones.

From the extracted comments, we identified around 250 verbatims that referenced types of questions either in an explicit or implicit way. Only those verbatims that clearly related a question type where considered. For instance, verbatims like "I don't where the contracts are" classified as an implicit question of type Where. The table 2 shows the results of this classification, as well as some illustrative verbatims. It is significant that most of the verbatims addressed navigational problems (Where + How) mainly due to usability issues and to the nature of the tasks (table 1). The high number of 'Other types' is mainly due to questions about semantic information relating concepts specific to the domain. These questions are described in section 6.2, while next section presents the findings for both positive and negative opinions, as well as some revealed limitations of the approach.

Findings

In the first phase of the study we collected the data described in the previous Participants section, and we also found that 16/20 liked new technologies, 17/20 use new technology everyday, and 20/20 have found problems in their use. To face these problems, 11/20 inspect the UI to try to solve them by themselves, 8/20 ask other people about the problem, 15/20 search for solutions in the Internet, and 7/20 use the help provided by the system.

The last phase of the study revealed that questions of types How and Where were identified by most of the users (15/20) as useful and helpful with statements such as "it can be very useful in certain situations" or "It could be very helpful for locating all options of the vehicle in a faster way". This last statement refers also to a gain of time, which was also identified as a positive value by a total of 10/20 users with statements such as "It is a gain of time" or "it makes me go faster without losing my time". The good acceptance of How questions contrasts however with the low number of verbatims. This suggests that users find the information useful but they are not thinking of asking it. The help UI could encourage/propose questions in these situations.

The What is it for and Why questions were also identified as useful by an important number of participants, but less useful than the previous ones. This was mainly due to the fact that subjects didn't find useful to ask for the purpose of some elements of the UI, such as check-boxes or labels, that already contain clear information about what they are currently doing. In the case of Why questions, the results didn't show a good acceptation by the participants as in the results found by [START_REF] Lim | Why and why not explanations improve the intelligibility of context-aware intelligent systems[END_REF][START_REF] Myers | Answering why and why not questions in user interfaces[END_REF]. This was due to the fact that the questions proposed by our algorithms didn't cover all the possible range of questions that the participants asked. For instance, as our algorithms entirely rely on the task model, our system couldn't answer why questions concerning the functional core of the application such as Why there is no diesel engines? (for specific kinds of Cabriolet cars). To overcome this limitation in our implementation, we propose to enrich the Cameleon models with other models more suitable for this purpose, as for instance those used in [START_REF] Myers | Answering why and why not questions in user interfaces[END_REF][START_REF] Vermeulen | PervasiveCrystal: Asking and answering why and why not questions about pervasive computing applications[END_REF]. Another possible solution is to enrich the mapping model to include the ECA rules used in [START_REF] Vermeulen | PervasiveCrystal: Asking and answering why and why not questions about pervasive computing applications[END_REF], so we can connect the methods of the widgets triggering the action directly to the functional core and vice versa.

Finally, the What can I do now and design rationale related questions were found to be useless by most of the participants (16/20), according to statements such as "I don't see where I would like to ask this question" (for what can I do now?) or "I am not interested in this information, all I want is to buy my car" (for design rationale questions).

At the end of the third phase, when we presented the help UI with all the types of questions together, the study revealed that in general, model-based self-explanatory facilities were identified as "useful" and "helpful" by most of the participants (16/20). The study also revealed question types that were not supported by our current implementation. The analysis of the collected data suggests that our model-based self-explanatory UI, with minor design enhancements for major usability improvements, could have the potential to easily help the users. Next section discusses the possible model-based implications for the types of questions that were not supported. Then, we discuss the usability suggestions extracted from the data for our particular implementation of self-explanatory UIs.

Unsupported types of questions

We identified other types of questions not explicitly supported by our system. A minor number of them referred to What if questions. Even if most of these verbatims come from users that showed a trial and error approach to understand the consequences of their actions in the UI (i.e., they don't know the consequences of an action but they perform such action on the UI anyway to see what happens), 2 users out of 20 didn't use options from the UI because they didn't know their possible side-effects. For instance, subject 9 didn't perform one of the tasks because "I have fear of losing all the options". Supporting What if questions can help this minority of users to feel more comfortable with the UI. These kinds of questions can probably be by analyzing the operators of the task model and how they are transformed to CUI elements, (what elements of the CUI model become active/inactive as we enable/disable new tasks. These answers will probably require some improvements for side effects related to the functional core of the application (external to the UI).

We also identified a high number of verbatims requesting confirmation and validation from the UI. For instance, "does the car already have a navigation system?", "are the options included in the price?", were recurrent expressions used by the participants. This observation suggests that the feedback provided by the site was not enough for the users. Supporting questions about confirming and validating the user actions can help to overcome this usability issue. This may require new models for handling user actions, specially those that have effects beyond the UI.

A third group of questions not supported by the self-explanatory dialog concerns definitions. Most of these questions were about specific car-related terminology and concepts such "What is the Tuner DAB?" or "What does Cabriolet stand for?". To support these questions, the proposed model-based approach needs to be extended with semantic information, either by adding new models or by connecting the UI with sources of semantic information (internet).

Semantic information may be also necessary for answering questions about differences that we identified in a minor number of verbatims, for instance, What is the difference between the packs? (or eventually similarities).

Usability Suggestions and Improvements

We were also interested in usability observations. During the third phase of the experiment, where participants were confronted to the self-explanatory dialog, 14 out of 20 suggested that they would like to type the whole question directly instead of clicking on a predefined answer inside a list. 13 out of 20 would like to access questions by typing keywords in a text area, and 4 proposed to use a vocal interface instead. These observations sustain some of the design principles for help systems of the literature, in particular, "Help should be accurate, complete and consistent" ( [START_REF] Dix | Human Computer Interaction[END_REF][START_REF] Shneiderman | Designing the User Interface[END_REF]), and "Help should not display irrelevant information" ( [START_REF] Horton | Designing and Writing On-line Documentation[END_REF]).

6 participants suggested to classify questions not only by question types but following the categories of the underlying site, for instance, grouping them by equipment or car models.

Regarding the answers, some participants argued that they don't like to read explanations, specially those that have a significant length. With the models used in this approach, the information given in the answers can be represented in non textual forms. For instance, as the CUI model can store the screen coordinates of the widget, Where questions can be answered by highlighting the region of interest (as currently done in mac systems), and procedural questions can be explained by means of animations of the cursor over the widget coordinates.

Finally, some participants proposed that it would be preferable to use the questions not as a means to know how to find a specific option, but to "get there". This suggests that self-explanatory UIs could be used as software agents to overcome the usability issues of a UI not only by explaining to the user how to solve the issue, but solving it directly if possible. For instance, navigating to the desired website instead of explaining what website the user should navigate to. This observation opens new research questions: can self-explanatory UIs benefit from agents? If so, what other models are needed and how this can be done?

7

Conclusions and Perspectives

Model-Driven Engineering of UIs has been extensively used for the automatic generation and adaptation of UIs. This paper studies a side effect of keeping these models at runtime. They can be used for supporting the users through explanations based on such models. These explanations have interesting advantages as the dynamic generation of answers and the automatic evolution along with the models, so no manual updates of the support are required when the program specification (the models) changes. But do users think that this model-based support is relevant and useful enough? The experiment that we conducted shows that most of the users identifies model-based explanations as potentially useful.

Our future work includes to test how scalable model-based explanations are, either with a huge number of models or with a huge number of users requesting answers. We will study how to support the new types of questions that we have identified, and better support the current questions that we are able to compute.

We also plan to investigate the use of design rationale questions to support the learning of HCI design methods.

Fig. 1 .

 1 Fig. 1. Screenshot of the prototype.

Fig. 3 .

 3 Fig. 3. Models used for generating questions (left) and answers (right).

Fig. 4 .

 4 Fig. 4. Self-Explanatory Dialog box showing the full list of available questions by type.

Table 2 .

 2 Relationship between question types and ocurrences extracted from the records during the second phase of the experiment. An exemple of verbatims illustrates each type.

	Question type	Example Verbatims	Occurrences
	How	I don't see how to do it	13
	Why	Why do I need to register?	21
	Where	And where do I find the maintenance contracts	119
	What is it for	I'm browsing the tabs to see what they do	7
	What can I do now I must find my way (inspecting all the UI with the mouse)	2
	Design rationale	Why they are not ordered by type?
	Other types	What does Cabriolet stand for? (Definition)
		What are the differences between the packs? (Differences)
		Is it included in the price I guess? (Confirmation)
		What happens if I click here? (What if)

Acknowledgments

This work has been funded by the UsiXML. We warmly thank all the participants that collaborated in this experiment. Note that all the content used in the prototype, extracted from the original website during the reverse engineering process, belongs to this website and has been used for research purposes only.


William Delamare
email: william.delamare@imag.fr

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

Laurence Nigay
email: laurence.nigay@imag.fr

Designing Disambiguation Techniques for Pointing in the Physical World

Keywords: Physical Interaction, Interactive Physical Objects, Design Space, Selection Techniques. ACM Classification D.2.2. Software Engineering: Design Tools and Techniques -User interfaces. H.5.2. Information interfaces and presentation (e.g., HCI): User Interfaces -Theory and methods, User-centered design

Several ways for selecting physical objects exist, including touching and pointing at them. Allowing the user to interact at a distance by pointing at physical objects can be challenging when the environment contains a large number of interactive physical objects, possibly occluded by other everyday items. Previous pointing techniques highlighted the need for disambiguation techniques. Addressing this challenge, this paper contributes a design space that organizes along groups and axes a set of options for designers to relevantly (1) describe, (2) classify, and (3) design disambiguation techniques. First, we have not found techniques in the literature yet that our design space could not describe. Second, all the techniques show a different path along the axes of our design space. Third, it allows defining of several new paths/solutions that have not yet been explored. We illustrate this generative power with the example of such a designed technique, Physical Pointing Roll (P2Roll).

INTRODUCTION

Ambient Intelligence involves a wide variety of smart objects. For instance, in a domestic context, there is a large range of physical objects that are digitally augmented: TV, light sources, coffee machine, washing machine, etc. These objects are not necessarily within reach of users in everyday situations. Thus, pointing techniques for distal selection of physical objects are important.

However, selecting a physical object by pointing raises several problems that are related to the objects' sizes, their density in the physical environment and the occlusion of the targeted object by other items. For defining an efficient pointing technique, designers can draw their inspiration from studies of the Graphical User Interfaces (GUI) and Virtual Environments (VEs) communities, two communities that extensively studied the pointing task. However, the physical environment defines additional constraints: (1) exocentric techniques [START_REF] Poupyrev | Manipulating objects in virtual worlds: categorization and empirical evaluation of interaction techniques[END_REF] that modify the user's point of view or techniques that modify the scene [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF] [START_REF] Kopper | Rapid and accurate 3D selection by progressive refinement[END_REF] are not possible, and (2) in the physical world, the system is not omniscient, whereas in virtual environments, the system creates the virtual world. As a consequence, designers cannot assume that the computer system has all the information about the physical surroundings [START_REF] Milgram | A taxonomy of mixed reality visual displays[END_REF].

Capturing these specificities induced by interaction in the physical environment, we present a design space for the disambiguation of the selection of physical objects by pointing at them. The design space adopts two points of view: the characteristics of the interaction techniques (Interaction Group) and the requirements for the disambiguation system to be developed (Disambiguation System Group). The identified axes in each group are useful for describing a significant range of existing techniques (descriptive power) as well as for helping designers to create new techniques for selecting physical objects (generative power).

In this paper, we first clarify the steps in a pointing task and highlight the disambiguation stage. After a review of related work, we present our design space. Its descriptive power is shown through concrete examples and its generative power through the design of a new disambiguation technique for the selection of a physical target.

POINTING TASK AND DISAMBIGUATION

When physical augmented objects are more than 1.1m away from the user, a distant interaction by pointing at physical objects is preferred [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]. Nevertheless, pointing tasks in the physical world are difficult for two main reasons: accuracy and occlusion.

Previous studies have reported natural hand tremor and limited human precision as drawbacks for absolute pointing [START_REF] König | Adaptive Pointing-Design and Evaluation of a Precision Enhancing Technique for Absolute Pointing Devices[END_REF]. As a consequence, laser pointer interaction has been proven to be inaccurate, error prone and slow [START_REF] Myers | Interacting at a distance: measuring the performance of laser pointers and other devices[END_REF]. Jitters appear when trying to maintain a steady position, and drifts of the beam are produced when pressing or releasing a trigger button. Thus, a volume selection (i.e., a cone) can make the selection of physical objects easier by facilitating the aiming action [START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF] (see Figure 1).

Selected'Volume'

Beam's'angle' ' Beam's'length' In addition to the accuracy problem, occlusion is another source of difficulty when multiple objects intersect the pointing direction [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF].

For the two above cases, volume selection and occlusion, the pointing task requires a disambiguation process.

The finite state machine in Figure 2 models the implementation of a pointing task, including the disambiguation stage. In Figure 2, the initial state corresponds to the state where no physical object is selected. From this initial state, three paths are identified:

• (t4) describes a direct pointing, e.g., with an absolute laser pointing system [START_REF] De La O Chávez | An independent and nonintrusive laser pointer environment control device system[END_REF][START_REF] Patel | A 2-way laser-assisted selection scheme for handhelds in a physical environment[END_REF][START_REF] Wilson | Pointing in intelligent environments with the worldcursor[END_REF][START_REF] Wilson | XWand: UI for Intelligent Spaces[END_REF]. Direct pointing is possible and efficient for the selection of large physical objects (e.g., a TV) in a non-dense environment.

• (t5.t6 = t5) corresponds to an automatic disambiguation mechanism, i.e. performed by the system. The user does not perform any further action in order to reach the final state, that is, the state where a physical object is selected. This is the case for a disambiguation mechanism based on heuristics. Some heuristics rely only on characteristics at the moment of the trigger event (e.g., selecting an object within the selection cone) [START_REF] Rahman | Spatial-geometric approach to physical mobile interaction based on accelerometer and IR sensory data fusion[END_REF]. Some enhanced approaches define heuristics that are also based on characteristics before the trigger event, e.g., computing scores taking into account the object's size and distance from the selection cone as well as the velocity of the pointing gesture during the entire interaction [START_REF] Steed | Towards a General Model for Selection in Virtual Environments[END_REF].

• (t1.t2*.t3) describes an interactive disambiguation mechanism. Two strategies exist for interactively selecting an object among n:

o Navigation: The user cycles through the previously selected set of targets (t2*) until reaching and selecting the desired one (t3).

For instance, after a pointing gesture in the physical world (t1), the names of the selected objects can be displayed on a handheld device and the user scrolls the list (t2*) in order to select the targeted object (t3) [START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF].

o Designation: The user performs another designation (t3) in the previously selected set of targets. For instance, the RFIG Lamps system [START_REF] Raskar | RFIG Lamps: Interacting with a Self-DescribingWorld via Photosensing Wireless Tags and Projectors[END_REF] includes such a two-step technique. After a first pointing gesture (t1), the RFIG Lamps system projects tags onto the selected physical objects. Then, the user selects with a laser the targeted object by pointing at its corresponding tag (t3). Since directly pointing at a physical object (t4) reaches its limits when many physical objects can be selected in a dense environment, the selection techniques of a physical object imply a disambiguation stage. An automatic disambiguation stage based on heuristics (t5.t6) may lead to the selection of a wrong physical object [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF][START_REF] Rahman | Spatial-geometric approach to physical mobile interaction based on accelerometer and IR sensory data fusion[END_REF]. Therefore in this paper we focus on techniques that include an initial coarse physical pointing gesture and then an interactive disambiguation stage (t1.t2*.t3). We define a design space for such two-step techniques for selection of a physical object by focusing on the disambiguation stage.

As presented in the following section, a literature review highlights that only five two-step techniques for the selection of a physical object have been developed. Our design space is therefore an analytical tool to empower the designers of interactive techniques in the physical environment, by organizing the design options and by highlighting gaps and under-researched areas.

RELATED WORK

There are two areas of research that are directly relevant to the present paper: (1) the existing two-step selection techniques of a physical object, and (2) the design spaces and taxonomies for the disambiguation stage.

Interactive Disambiguation Techniques for Physical Object Selection

As stated above, only five two-step techniques for the selection of a physical object have been designed. They all include an interactive disambiguation stage after a first pointing gesture. Bold names indicate how we will refer to the corresponding techniques in the remainder of the paper.

GesturePen [START_REF] Swindells | That one there! Pointing to establish device identity[END_REF] is a technique using a volume selection metaphor. It is based on an Infrared (IR) beam that is 1.5m long and with a conical angle of 30° (Figure 1). Users can select an IR tag by directing the beam towards a tag. This technique illustrates the problem of volume selection techniques: by easing the pointing task, GesturePen implies unwanted multiple selections. Indeed, GesturePen led to mistakenly selected tags neighboring the targeted object.

Nevertheless the limited range of the technique was designed in order to minimize errors due to a too large beam span, but users felt uncomfortable when they had to walk close to the tag. To overcome these difficulties, the authors proposed a disambiguation technique: a dial on the pointing device in order to adjust the beam's length and/or the beam's angle.

Another technique with a similar disambiguation mechanism is PICOntrol [START_REF] Schmidt | PICOntrol: using a handheld projector for direct control of physical devices through visible light[END_REF]. With this technique, the user points at a physical object with a visible light projection that activates light sensors attached to physical objects. If several objects are located within the light projection, an envisioned solution is to reduce the projection size.

The Radio Frequency Identity and Geometry Lamps system (RFIG Lamps) is a one-handed device that includes a laser, a radio frequency identification (RFID) reader, buttons and a projector [START_REF] Raskar | RFIG Lamps: Interacting with a Self-DescribingWorld via Photosensing Wireless Tags and Projectors[END_REF]. Physical objects are equipped with RFID tags. While the handheld RFID reader scans an area, the system automatically computes the locations of the tags and projects a stabilized interactive graphical presentation of the tags. A user can then more easily disambiguate the selection by pointing with a laser at the projected tags.

While the three above techniques keep the user's actions in the physical world during the disambiguation stage, the two following techniques include a disambiguation stage disconnected from the physical world.

A first solution is to display a list of selected objects on a handheld device [START_REF] Välkkynen | Evaluating touching and pointing with a mobile terminal for physical browsing[END_REF]. After a coarse pointing gesture in the physical world, if several objects are located within the beam, a List of the selected objects' names are displayed on screen and the user selects the targeted object based on its name.

Freeze-Set-Go (FSG) proposes an Augmented Reality (AR) technique on a smartphone [START_REF] Lee | Freeze-Set-Go interaction method for handheld mobile augmented reality environments[END_REF]. The user first places the device so that 2D markers attached to physical targets are visible on the screen through a real-time see-through video.

Since several markers can appear on the screen, a touch gesture on the screen is needed for the disambiguation of the selection. In order to ease this disambiguation, FSG provides a custom button that allows users to freeze the video. The real-time see-through video is resumed when the button is pressed again.

With respect to the above five techniques, the authors highlight the need for efficient and usable disambiguation techniques, motivating the need for a design space. We now present the related existing design dimensions.

Design dimensions for Disambiguation Techniques involving 3D Targets in Virtual and Physical worlds

Design dimensions for disambiguation have been studied only for the case of virtual environments. Amongst these studies, the design space [START_REF] Kopper | Rapid and accurate 3D selection by progressive refinement[END_REF] for disambiguation mechanisms (selection by progressive refinement) introduces three dimensions:

• The disambiguation criteria, characterizing if the disambiguation is spatial (e.g., choosing an object based on its location in the scene), by object attributes (e.g., choosing red and/or large objects), or out-ofcontext (e.g., choosing objects from a menu).

• The display of the selected objects, that can be in context (e.g., by freezing the viewpoint as in FSG or by relocating targets in order to ease selection) or out-ofcontext (e.g., by using a menu as in List). This axis is related to the perceptual continuity criterion as described for Augmented Reality [START_REF] Dubois | Assessing continuity and compatibility in augmented reality systems[END_REF].

• The type, characterizing if the disambiguation is:

o Discrete, e.g., if the disambiguation is done through several steps (e.g., (t1.t2*.t3) in Figure 2);

o Continuous, e.g., the disambiguation is done through a continuous process implying one continuous action (e.g. (t5.t6 = t5) in Figure 2).

A similar axis is found in [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF] for describing disambiguation techniques for the case of volumetric displays: the concurrent/sequential axis. A concurrent (or continuous) disambiguation mechanism means that both pointing and disambiguation tasks are performed at the same time. For instance, with the Depth Ray [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF], users control the ray direction and a depth marker along the ray at the same time. Contrastingly, a sequential (or discrete) disambiguation mechanism needs a temporal separation between the pointing and the disambiguation tasks. For instance, with the Lock Ray [START_REF] Grossman | The design and evaluation of selection techniques for 3D volumetric displays[END_REF], users control the ray direction before locking it so as to then control only the depth marker that appears on the ray.

These design spaces for virtual environments define relevant design dimensions that only partially contribute to our study, i.e. to disambiguation techniques for physical environments. Nevertheless they lay a foundation for characterizing the design and engineering of the interactive disambiguation stage in the selection of physical targets.

DESIGN SPACE

Our design space is made of 10 axes that are organized according to two groups, Interaction and Disambiguation System, as shown in Figure 4. The Interaction Group characterizes the interaction techniques for the disambiguation stage when selecting physical objects by pointing in the physical world. The Disambiguation System Group adopts an engineering point of view by identifying the implications of the Interaction Group for the disambiguation system. We first explain the axes of the Interaction and Disambiguation System groups before concluding on the links between them.

Interaction Group

From an interaction point of view, the designer can operate on two features of the disambiguation mechanism: the display of the targets (i.e. the display space) and the control from the user (i.e. the control space) [START_REF] Balakrishnan | Beating" Fitts' law: virtual enhancements for pointing facilitation[END_REF].

Display Space

For the disambiguation phase, the user can (a) focus on the physical targets, or (b) switch her/his focus to a virtual representation (both ends of axis 1 in Figure 4). Between both ends, modifications of the display space can occur in a mixed manner, augmenting the physical target with an additional virtual representation.

Towards the virtual end, augmenting or replacing the physical targets can make the selection easier if selecting the physical target is too difficult due to its size, distance or density of objects. For instance, the disambiguation stage of the RFIG Lamps system proposes to project a disc onto physical targets for pointing refinement. Indeed the bigger size of the projections as compared to the original tags facilitates the pointing task.

The augmented or virtual representation can be spatially decoupled from the primary physical targets (e.g., the List technique, that displays a list of objects' names on a handheld device). However, such a solution divides the users' attention between the physical environment and the virtual representation and creates an additional cost for changing the focus of attention (perceptual discontinuity as described in [START_REF] Dubois | Assessing continuity and compatibility in augmented reality systems[END_REF]). To overcome this limitation, the augmented or virtual representation can maintain a spatial link with the physical target (e.g., the RFIG Lamps system and an augmented reality technique using the magic lens metaphor such as FSG).

For the designer, another way to avoid changes of attention focus between the physical and virtual worlds is to propose a solution towards the physical end of the axis, and allow the user to operate directly in the physical world.

Towards the physical end of the axis, designers will be able in the future to physically modify the display space. For instance, a system such as ZeroN allows actual movements of physical objects in 3D space [START_REF] Lee | Mid-Air Tangible Interaction Enabled by Computer Controlled Magnetic Levitation[END_REF], e.g., to rearrange the targets so that they are easier to point at. Alternatively, Jamming User Interfaces can increase the size of physical objects in order to facilitate the pointing task, while keeping the focus on the bigger primary physical target [START_REF] Follmer | Jamming User Interfaces: Programmable Particle Stiffness and Sensing for Malleable and Shape-(a) (b) (c) (d) Figure 5: A pointing gesture turns on the lights of the current selected volume at medium brightness (a), and a rolling gesture (b, c, d) changes the current selected object (at maximum brightness) to the next one. Changing Devices[END_REF].

Control Space

Designers can help the disambiguation of preselected physical objects by modifying the control, i.e. the actions of the user and the interpretation of these actions by the system. The design approach is to modify the control space assuming that the display space (i.e., physical world) is not modifiable.

To do so, designers can decouple the control from the physical targets by modifying the reference frame (Figure 4, axis 2). Although initially introduced for describing physical pointing gesture [START_REF] Cockburn | Air pointing: Design and evaluation of spatial target acquisition with and without visual feedback[END_REF], the Reference Frame of spatial input can be relevantly applied to disambiguation techniques. The Control Space axis characterizes how the absolute mapping of the pointing step has been transformed for the disambiguation step.

First, if the action of the user is directed to the physical objects, the reference frame is absolute. In this case, a disambiguation technique should be based on a Display Space modification (axis 1) in order to ease the pointing task.

Second, if the actions of the user are performed around a user's body part, the reference frame is relative to the user's body. The physical objects are abstracted and reorganized according to an origin defined by a body part.

For instance the physical objects can be reorganized vertically from the hips to the head. In this example, the user selects a target by moving her/his arm along her/his trunk. The control space hence defines an input space that the user has to mentally map onto the physical world.

Third, if the actions of the user are performed according to the position of a device as a reference point, the reference frame is relative to the device. The physical objects are abstracted and reorganized with a neutral position of the device as origin. For instance the physical objects can be reorganized in a clock-manner disposition according to a neutral position of the device. In this example, the user selects a target by rotating the device. Again, the control space defines an input space that the user has to map onto the physical world.

The Control Space axis does not aim to describe in detail all the actions performed by the user: depending on the chosen disambiguation input (e.g., tangible, gesture, gaze, voice command, etc.), previous existing design spaces can further describe specific design characteristics that are not specifically related to disambiguation. Indeed it is an important attribute of our design space that it allows capitalizing on existing design spaces and that it facilitates interconnection between existing approaches.

Disambiguation System Group

We first refine the Extent of World Knowledge [START_REF] Milgram | A taxonomy of mixed reality visual displays[END_REF] of We first define two other types of knowledge, dynamic and static, then refines the what and where subgroups in our design space.

Knowledge Computation: Static vs. Dynamic

As represented by axes 3 and 8 of Figure 4, we distinguish two kinds of knowledge: the one produced during a setup step and the one produced at runtime. For instance FSG needs a registration process of 2D markers. This is an imperative step for further video analysis in order for the system to know what the user is selecting with a tap on the video. Contrastingly, the RFIG Lamps system first receives dynamic spatial knowledge for the first pointing step using RFID tags and then the spatial locations of the tags for the disambiguation step using light sensors and encoded projections.

On the one hand, knowledge defined during a setup process will constrain the user to configure and maintain the system, e.g., naming or locating objects and additionally updating the information if the user moves, adds or removes physical objects. On the other hand, knowledge computed at runtime is more flexible but less robust. For example, the RFIG Lamps system may know the spatial coordinates of pointed objects by projecting grey codes on light sensors attached to objects. However, these sensors might be visually occluded from the projector's viewpoint, whereas the user can actually see the physical objects (the user's viewpoint being different from the projector's viewpoint).

The What and Where axes can have different kinds of knowledge computation, considering each axis one by one. However, a promising design option is the dynamic computation of knowledge, avoiding a setup process from the user. Thus, the what and where axes are globally qualified to be static if at least one of the axes is statically computed by the system. Consequently the what and where corresponding axes (3 and 8 of Figure 4) are qualified to be dynamic if all the information is dynamically computed at runtime.

"What" Subgroup

If the designer chooses to provide a virtual representation as a Display Space (axis 1 of Figure 4), then What information can enhance the cognitive continuity between the physical object and its representation [START_REF] Dubois | Assessing continuity and compatibility in augmented reality systems[END_REF]. The continuity at the cognitive level refers to the user's interpretation of the virtual representation. This interpretation is influenced by the What information.

The disambiguation system may know different types of information about the interactive augmented physical objects:

(1) Identity of the object (axis 4 of Figure 4) that would allow the disambiguation system to present a label "bedside lamp" instead of "object 1" to the user for example.

(2) Functionalities of the object (axis 5 of Figure 4) that would allow the disambiguation system to present another information to the user. For instance, if the user is aiming at two light sources but intends to select the one that can turn blue.

(3) Appearance information (axis 6 of Figure 4) such as the aspect of the physical object including its form, its color, its texture. Thus, the disambiguation system could reduce the cognitive discontinuity by representing the target with its actual picture for example.

(4) State information about the physical object (axis 7 of Figure 4), including its current power consumption, its on/off state, its dimming level. For instance, if the user is aiming at two light sources -one turned on and another turned off -and intends to select the one that is turned on: the states of the objects are therefore a key characteristic during this disambiguation step.

Each axis can have several levels of knowledge: for instance Appearance includes the object's form, its color (either red-green-blue values or grey levels…), etc. However, in order to avoid too fine-grained descriptions that might be difficult to compare, we only consider two discrete values, namely yes/no, along the four axes [Identity, Functionalities, Appearance and State] of Figure 4. This representation allows a clear and simple visualization of What knowledge systems have, and is sufficient to compare existing techniques.

"Where" Subgroup

As in Milgram's initial axis, the system may have no spatial information about the physical surroundings (i.e., value none in the Where Subgroup of Figure 4). If the system maintains spatial information about the physical surroundings (statically or dynamically) we refine the Extent of World Knowledge axis [START_REF] Milgram | A taxonomy of mixed reality visual displays[END_REF] by defining two new axes:

(1) Relative vs. Absolute (axis 9 of Figure 4): In a relative situation, the system knows how objects are localized compared with each other (e.g., a target is below another). For example, the system could use a simplified map of the physical world (static knowledge) that only contains left/right relationships between objects. The relative situation is well adapted to the navigation strategy, when the user has to incrementally navigate through preselected objects, from an object to its neighbor. In an absolute situation, the system has absolute spatial coordinates in a common reference frame. For example, the RFIG Lamps system determine their spatial coordinates (x,y) in the video. The absolute situation is well adapted to the designation strategy, when the user has to directly designate the desired physical target amongst the preselected physical objects.

(2) Of the world vs. Of a subpart (axis 10 of Figure 4): In a World situation, the system knows spatial information about all the interactive physical objects. For example, a disambiguation technique using an OptiTrack 1 system, composed of IR tracking video cameras, would allow the system to dynamically know where all the interactive objects are (since they are augmented with reflexive markers). In a Subpart situation, the system knows only spatial information about a subset of objects. For example, the RFIG Lamps system uses dynamically computed spatial coordinates of the preselected objects only.

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

Links Between the Interaction and Disambiguation System Groups

While describing the 10 axes of our design space, we highlighted the links between the Interaction Group and the Disambiguation System Group. Indeed, interaction design choices will have an impact on the system to be developed and in particular on the knowledge that the system needs to maintain about the physical objects. But the design space clearly separates the two sets of axes, one set focusing on interaction characteristics and one set dedicated to the corresponding disambiguation system requirements. Furthermore the disambiguation system requirements will in turn have an impact on the technologies to be used for developing the whole system.

Moreover, it is worth noticing that the physical world knowledge may be a constraint for the user. Naming objects, or updating spatial coordinates may be a burden for the users. On the contrary, providing an autonomous system (i.e. value dynamic along the axes 3 and 8 of Figure 4 Knowledge Computation) might imply a heavy infrastructure and/or might be expensive or simply not feasible for real-world deployment.

Figure 4 illustrates how to use the design space. In order to be able to compare techniques based on the design space, we assume that a proper and complete description of each technique is available. A disambiguation technique for the selection of a physical object defines a path in this multidimensional space. The 10 axes of the design space enable us to precisely define an existing technique by a path in the design space or to design a new one by exploring an unexplored area of the design space. The number of design possibilities defined by the 10 axes is huge (2673 possible paths). In light of our design space, techniques are said to be similar if they have the same characteristics (i.e., the same path) and different if they have at least one difference on one axis. We do not provide any measure yet since we are not able to quantify the importance of the axes. Evaluation of the impact of the axes on usability is future work. The following section describes the existing techniques as paths in the design space (i.e., the descriptive power of our design space), while the next section presents a new technique for which the design is based on the 10 axes (i.e., the generative power of our design space).

DESCRIPTIVE POWER OF THE DESIGN SPACE

Both PICOntrol and GesturePen propose the same disambiguation mechanism: adjusting the selection volume. Thus, the display space is in the physical world, with an absolute reference frame since the interaction is the same as the one used for the pointing step, but with a different volume of selection. GesturePen proposes to dynamically get knowledge of the identity of selected objects using custom tags with an IR transceiver. PICOntrol does not have any knowledge about the spatial physical environment. The system uses light sensors attached to objects in order to directly control the objects, and thus does not need any knowledge about them.

The RFIG Lamps system provides a mixed display space for the disambiguation step (digital objects projected onto physical ones). The reference frame is absolute since the user has to aim these projections with a laser. The system receives dynamic knowledge (RFID tags for what information and encoded projection for where information) that provides identity and state information (for the warehouse scenario) and absolute tags' locations in the current pointed areasubpart of the world.

FSG provides a virtual display space for the disambiguation step, i.e. after pressing the button that creates a frozen image of the video, breaking the link with the physical world. The touching gesture for selecting the target is in a reference frame relative to the device since the user has to interact with the screen. In order to map the touch input and the content of the image, the system has static knowledge of 2D markers, using video-analysis techniques based on the appearance of the objects (markers, linked with objects' identity). This What knowledge about the physical world allows the disambiguation technique to dynamically obtain absolute coordinates of 2D markers in the videosubpart of the world.

The List of objects' names displayed on a handheld device defines a virtual representation as a display space. The user interacts on the screen of the handheld device, thus relatively to the device. The system receives dynamic knowledge of the identity of objects that are pointed at by the user with the IR beam. No more information is needed in order to disambiguate the selection.

GENERATIVE POWER OF THE DESIGN SPACE

Defining a new path in the design space allows designers to produce a new interaction technique. Based on the 10 axes, many design choices are possible. To illustrate this generative power of the design space, we now explain the design of a new technique, represented by a thick line in Figure 4.

We focus on the selection of light sources in the physical world. Indeed with Light Emitting Diode (LED) and Organic Light Emitting Diode (OLED) technologies, light sources will be in walls, ceiling, floors, furniture or fabric, so that the environment may have a very large number of interactive lights, possibly occluded by other everyday items. This context fits well with the topic addressed by the design space since it brings several problems that designers should address while designing selection techniques of light sources by pointing in the physical world. Moreover, this example could easily be transposed to other contexts since a classic way to augment physical objects for visual feedback is to attach LED to them [START_REF] Schmidt | PICOntrol: using a handheld projector for direct control of physical devices through visible light[END_REF][START_REF] Swindells | That one there! Pointing to establish device identity[END_REF].

A design approach based on the generative power of our design space has led to the following disambiguation technique: a navigation strategy called Physical Pointing Roll (P2Roll). The user first performs a pointing gesture towards the light sources. This defines an initial coarse physical pointing phase. The user then has to precisely select the targeted light source from within the set of selected light sources. To do so, the user navigates through the preselected light sources using a roll gesture of the wrist, as illustrated in Figure 5.

First we made the design choice to keep the focus of the user in the physical world (value Physical on axis 1 of Figure 4) so that the user can directly observe LED lights, and more importantly the effect on the ambient lighting.

Concerning the control space, the wrist rolling input covers an unexplored area, with the reference frame having the value Relative to Body along the axis 2 of Figure 4. We had to choose an adequate body part as the origin of the reference frame. Since the arm is already used for the rough pointing gesture, we decided to apply the physiologic chain of the arm [START_REF] Balakrishnan | Performance differences in the fingers, wrist, and forearm in computer input control[END_REF][START_REF] Card | A morphological analysis of the design space of input devices[END_REF]: Shoulder and elbow are used for the coarse physical pointing task, thus we chose a wrist input. Since the pronation/supination axis (roll) has been proven usable [START_REF] Rahman | Tilt techniques: Investigating the Dexterity of Wristbased Input[END_REF], our disambiguation technique is based on a relative to the wrist transformation.

Having defined the P2Roll Interaction Group, we focus on the Disambiguation System Group. We make the distinction between two different systems: the prototype system of Figure 5 that we developed in order to experimentally evaluate the interaction technique and the final system that we will develop for real-world deployment if P2Roll is validated by the in-lab experiments.

Our current lab equipment allowed us to rapidly build a prototype in order to evaluate the P2Roll technique. We used the OptiTrack2 with six IR cameras that track the instrumented user's hand as shown in Figure 5. Since our LED objects are very close to each other to simulate a very dense physical environment, the OptiTrack cannot be used for tracking LED objects. Thus, the developed system maintains a static (axes 3 and 8 of Figure 4) and absolute (axis 9 of Figure 4) knowledge of the entire physical world (i.e., the LED objects). Since LEDs are controlled by the system itself, the system keeps the identity (axis 4 of Figure 4), the functionalities (axis 5 of Figure 4), and the state on/off (axis 7 of Figure 4) of each LED object.

However, this lab configuration is not easily deployable in the real world: it has a heavy infrastructure for tracking purpose and a significant setup/maintenance process in a dynamic context in which objects can be moved. Thus, if the interaction technique is experimentally validated, we will design another system solution (Disambiguation System Group) for the engineering of the designed disambiguation technique.

As part of a collaborative project with a hotel chain, the final setting is a hotel room, designed with LED light sources in walls and furniture. For this particular real-world context, we can assume that the system can have a static what and where knowledge, the hotel rooms having the same fixed furniture and light sources. However, the key design issue related to the Disambiguation System Group is the tracking solution for the pointing and rolling gestures that compose P2Roll. Several design issues based on the axes of our design space are possible, we describe two technological design options: (1) RFID tags hidden in the physical environment for the pointing step that allow the system to dynamically receive objects' identities, and then obtain static knowledge (e.g., a list of objects ordered from right to left and defined during the setup) for relative spatial information amongst the set of preselected objects. ( 2) Finding a way to communicate with LEDs by switching them on and off at high frequencies not perceived by users but only by the system with a high-frequency video camera. This could lead to dynamic relative spatial knowledge of preselected objects (i.e. subpart of the world).

CONCLUSION

This paper has introduced and described a design space for pointing in the real world focusing on disambiguation. This novel conception of the design space is intended to support design and research in the field of physical interaction. In contrast to a technology-centered design approach, the design space has introduced a new way of thinking of interaction design for the selection of physical objects in terms of interaction characteristics and their implications for the system.

A first contribution of the paper has been to demonstrate the descriptive power of the design space by precisely classifying existing techniques. This is ongoing work since new techniques are continuously defined. Till now this was successful because the existing techniques show different paths in the taxonomy and we have not found techniques in the literature yet that our design space left out. Moreover the design space capitalizes from existing design spaces of different domains. In particular for characterizing interaction, the design space refines the two main approaches (based on the display and control spaces) that are studied for enhancing pointing tasks in GUI [START_REF] Balakrishnan | Beating" Fitts' law: virtual enhancements for pointing facilitation[END_REF] ; and for characterizing the system, it extends existing taxonomies dedicated to Augmented Reality [START_REF] Milgram | A taxonomy of mixed reality visual displays[END_REF]. This contributes to demonstrating the soundness of the underlying concepts of our design space.

A second contribution of the paper has been to demonstrate the generative power of the proposed design space: it allows defining of several new paths/solutions in the taxonomy that have not yet been explored. Although we presented here only one example of such a designed technique, namely the Physical Pointing Roll (P2Roll) technique, this is another form of validation of our design space. The P2Roll technique corresponds to an underresearched area of the design space.

As ongoing work, we are focusing on the design and the evaluation of other techniques in order to measure the benefits of the values along the axes of the design space. In particular we are currently designing techniques for selecting LED light sources, which will be deployed in a hotel room as part of a collaborative project involving a hotel chain. This will allow further testing of the design space.

Figure 1 :

 1 Figure 1: Volume selection: a rough aiming with a pointing gesture. A set of physical objects included in the volume selection (i.e. cone) are selected.

Figure 2 :

 2 Figure 2: Starting by pointing in the physical world, three paths for the selection of a physical object. (t1t2*t3): pointing gesture followed by an interactive disambiguation process. (t4): single pointing gesture for selecting an object. (t5t6): pointing gesture enhanced by an heuristic method for automatic disambiguation.

Figure 3 .

 3 It was introduced by Milgram to characterize how much the system knows about the physical environment. This design dimension defines a continuum from a world completely un-modeled to a world completely modeled. Between these two extremes is a world partially modeled with where and/or what data, i.e. localization and identification data. A system knowing only where data about an object of interest could precisely place a graphical superimposition onto the physical object. Contrastingly, a system knowing only what data could precisely define the augmentation of the physical object, but without correct location, scale or orientation.

Figure 3 :

 3 Figure 3: Extent of World Knowledge dimension from [13].

Figure 4 :

 4 Figure 4: Design Space with 10 axes organized according to two groups: Interaction and Disambiguation System. Classification of existing disambiguation techniques (thin lines). A technique (P2Roll) designed by drawing a new line (under-researched area) in the design space (thick line).

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

ACKNOWLEDGMENTS

This work has been supported by the DELight project (French government's FUI -Single Inter-Ministry Fundprogram, certified by the cluster Minalogic). The project is dedicated to the study of a new lighting system for Solid State Lighting (SSL) applications and is led by Schneider Electric.