Keywords: Virtual Reality, Building Information Modelling, User-centred design methodology, Task-centred design methodology, Practical guide repeated-measures ANOVA with the interaction technique, case Virtual Reality, Building Information Modelling, User-centred design methodology, Task-centred design methodology, Practical guide

The field of virtual reality (VR) has undergone significant development these last years due to the growing maturity of this technology. This has allowed for its diffusion in many domains, notably in the building construction one. In this domain, the efforts of different trades must converge towards the creation of a unitary object. The Building Information Modelling (BIM) methodology and the BIM tools, which enable the centralisation of all the construction project data, have made these data accessible and modifiable by all, allowing thus for more collaboration. Using these data, VR can enhance this collaboration thanks to a shared virtual immersion; nonetheless, VR can also improve the individual performances in non-collaborative situations. Indeed, many problems in the building construction sector, such as construction planning or project review, are due to spatio-temporal aspects, which are better understood and evaluated when interacting in immersive environments. However, a problem resulting from such use of VR is that the VR interactions provided to the users are often not sufficiently adapted to their needs. It is indeed difficult to make a synthesis between the building trades' expertise and the VR expertise.

In this context, we identified in this research two scientific issues. The first concerns the formalisation of domain-specific tasks for their use in the VR design process. The second is related to the determination of proposals of VR interaction techniques in adequacy with the tasks. Finally, a global issue is how to offer the possibility to the domain-specific experts, who do not have VR expertise, to manage autonomously these two aspects while achieving the desired results.

To address these issues, we propose in this research a new task-centred methodology for the design of VR interactions, in three steps. The first step guides the domain-specific experts in the building of a model of their domain-specific tasks that decomposes such tasks into subtasks, thanks to a semiautomated system, for their integration in VR. The second step gathers VR design guidelines and rules in an expert system to allow for the semi-automated obtaining of proposals of VR interaction 5 ABSTRACT techniques according to the task. Besides these expert rules, this step is also based on existing taxonomies of VR interaction techniques that have been adapted for an optimal processing of the data information flow. Finally, the third step consists of VR prototyping by a VR expert and of conducting user evaluations on these prototypes. This methodology has been tested and evaluated on an experiment with two experts from the building industry, on two study cases from this sector. The first case focuses on the safety planning of a building worksite, whereas the second one concerns the evaluation of spatial inconsistencies between building components during the design phase.

Our methodology has the following advantages: i) none of the a priori possible solutions is omitted during the design process, ii) the number of solutions to be prototyped and evaluated is determined, iii) the domain-specific experts are actors of the design process because they are the ones who define entirely and autonomously the specifications about the design of the interactions, iv) the need of task analysis expertise and VR expertise is limited because the domain-specific experts are guided for the construction of the VR model of their domain-specific tasks and for the determination of proposals of VR interaction techniques. The limitation of our methodology is that VR prototyping and user evaluations still require VR experts because this cannot be automated. To conclude, this work provides the contribution of a methodological guide for the design and implementation of interaction techniques in VR applications, here applied to a particular domain.

First, I would like to thank all the external jury members -M. James Herman Oliver, M. Guillaume Moreau, M. Frederic Noel, and M. Fernando De La Rosa, that read this PhD thesis document, gave me their feedback about it and listened to me during my defence. I hope that we could collaborate once again on future research work.

Then, I would like to thank all my advisors -Frédéric Merienne, José Tiberio Hernandez, Ruding Lou, Florence Danglade and Pablo Figueroa, for their support during my PhD. Your differences have been very complementary during these three years.

I would like to thank all the engineers, teachers and PhD students of the two laboratories where I pursued my PhD -Institut Image in Chalon-sur-Saone at Arts-et-Métiers and Colivri in Bogota at Universidad de los Andes. Some helped me for some courses, whereas others involved themselves in my research and its relative tasks such as the development of VR applications.

Thank you also to the Arts-et-Métiers Master students who collaborated directly to my research, and to the INGECO students from Universidad de los Andes, Civil Engineering Department, for the same reason.

I also want to thank the local administrative workers from Institut Image and from Universidad de los Andes, Computer Science Department, who did really make my life easier sometimes ! It would not have been the same without you.

Thank you to all the people that I met during these three years and that gave me advice, support, or simply good vibes ! It has been a pleasure to make new friends, from different countries and cultures. Merci les amis, gracias amigos !

Résumé

Le domaine de la réalité virtuelle (RV) a connu un développement important ces dernières années en raison de la maturité croissante de cette technologie. Cela a permis sa diffusion dans de nombreux domaines, notamment dans celui du bâtiment. Dans ce domaine, les efforts des différents corps de métiers doivent converger vers la création d'un objet unitaire. La méthodologie BIM (Building Information Modelling) et les outils BIM, qui permettent la centralisation de toutes les données des projets de construction, ont rendu ces données accessibles et modifiables par tous, permettant ainsi une plus grande collaboration. En utilisant ces données, la RV peut améliorer cette collaboration grâce à une immersion virtuelle partagée ; néanmoins, la RV peut également améliorer les performances individuelles dans des situations non collaboratives. En effet, de nombreux problèmes dans le secteur du bâtiment, tels que la planification de la construction ou la revue de projets, sont dus à des aspects spatio-temporels, qui sont mieux compris et évalués lorsqu'on interagit dans des environnements immersifs. Cependant, un problème résultant de cette utilisation de la RV est que les interactions de RV fournies aux utilisateurs ne sont souvent pas suffisamment adaptées à leurs besoins. Il est en effet difficile de faire une synthèse entre l'expertise des métiers du bâtiment et l'expertise de la RV.

Dans ce contexte, nous avons identifié dans cette recherche deux problèmes scientifiques. Le premier concerne la formalisation des tâches spécifiques au domaine pour leur utilisation dans le processus de conception de la RV. Le second est liée à la détermination des propositions de techniques d'interaction en RV en adéquation avec les tâches. Finalement, une question globale est de savoir comment offrir la possibilité aux experts d'un domaine spécifique, qui n'ont pas d'expertise en RV, de gérer ces deux aspects de manière autonome tout en obtenant les résultats espérés.

Pour répondre à ces questions, nous proposons dans cette recherche une nouvelle méthodologie centrée sur les tâches, pour la conception des interactions de RV, en trois étapes. La première étape guide les experts d'un domaine spécifique dans la construction d'un modèle de leurs tâches spéci-RESUME fiques à leur domaine qui les décompose en sous-tâches, grâce à un système semi-automatique, pour l'intégration de ces tâches dans la RV. La deuxième étape rassemble les recommandations et les règles de conception de la RV dans un système expert pour permettre l'obtention semi-automatisée de propositions de techniques d'interaction en RV en fonction de la tâche. Outre ces règles expertes, cette étape est également basée sur des taxonomies existantes de techniques d'interaction en RV qui ont été adaptées pour un traitement optimal du flux d'informations des données. Enfin, la troisième étape consiste à faire réaliser des prototypes de RV par un expert en RV et à mener des évaluations utilisateurs sur ces prototypes.

Cette méthodologie a été testée et évaluée lors d'une expérience avec deux experts du bâtiment sur deux cas d'étude de ce secteur. Le premier cas se concentre sur la planification de la sécurité d'un chantier de construction, tandis que le second concerne l'évaluation des incohérences spatiales entre les éléments de construction pendant la phase de conception.

Notre méthodologie présente les avantages suivants : i) aucune des solutions possibles a priori n'est omise pendant le processus de conception, ii) le nombre de solutions à prototyper et à évaluer est déterminé, iii) les experts d'un domaine spécifiques sont acteurs du processus de conception car ce sont ceux qui définissent entièrement et en autonomie les spécifications de conception des interactions, iv) le besoin d'expertise en analyse de tâches et en RV est limité car les experts d'un domaine spécifique sont guidés pour la construction du modèle de RV des tâches spécifiques à leur domaine et pour la détermination des propositions de techniques d'interaction de RV. La limitation de notre méthodologie est que le prototypage en RV et les évaluations utilisateurs nécessitent toujours des experts de RV car cela ne peut être automatisé. Pour conclure, ce travail apporte la contribution d'un guide méthodologique pour la conception et la mise en oeuvre de techniques d'interaction dans les applications de RV, ici appliqué à un domaine en particulier.

Mots-clés: Réalité virtuelle, Building Information Modelling, Méthodologie de design centrée sur l'utilisateur, Méthodologie de design centrée sur les tâches, Guide pratique

Resumen

El campo de la realidad virtual (RV) ha experimentado un desarrollo significativo en los últimos años debido a la creciente madurez de esta tecnología. Esto ha permitido su difusión en muchos ámbitos, especialmente en el de la construcción de edificios. En este ámbito, los esfuerzos de los diferentes oficios deben converger hacia la creación de un objeto unitario. La metodología del Building Information Modelling (BIM) y las herramientas BIM, que permiten centralizar todos los datos de los proyectos de construcción, han hecho que estos datos sean accesibles y modificables por todos, permitiendo así una mayor colaboración. Utilizando estos datos, la RV puede mejorar esta colaboración gracias a una inmersión virtual compartida; no obstante, la RV también puede mejorar el rendimiento individual en situaciones no colaborativas. En efecto, muchos problemas del sector de la construcción, como la planificación de la construcción o la revisión de proyectos, están relacionados con aspectos espacio-temporales, que se comprenden y evalúan mejor cuando se interactúa en entornos de inmersión.

Sin embargo, un problema resultante de esa utilización de la RV es que las interacciones de RV que se proporcionan a los usuarios no suelen estar suficientemente adaptadas a sus necesidades. En efecto, es difícil hacer una síntesis entre los conocimientos técnicos de los oficios de la construcción y los de la RV.

En este contexto, hemos identificado en esta investigación dos cuestiones científicas. La primera se refiere a la formalización de las tareas específicas de cada ámbito para su utilización en el proceso de diseño de la RV. La segunda está relacionada con la determinación de las propuestas de técnicas de interacción de la RV en adecuación con las tareas. Por último, una cuestión de carácter global es cómo ofrecer la posibilidad a los expertos en ámbitos específicos, que no tienen conocimientos de RV, de gestionar de manera autónoma esos dos aspectos y lograr al mismo tiempo los resultados deseados.

Para tratar estas cuestiones, proponemos en esta investigación una nueva metodología centrada en las tareas para el diseño de las interacciones de la RV, en tres etapas. La primera etapa guía a los RESUMEN expertos en cada ámbito en la construcción de un modelo de sus tareas específicas que descompone dichas tareas en subtareas, gracias a un sistema semiautomático, para su integración en la RV. La segunda etapa reúne las directrices y reglas de diseño de la RV en un sistema experto para permitir la obtención semiautomática de propuestas de técnicas de interacción de la RV en función de la tarea.

Además de estas reglas expertas, esta etapa también se basa en las taxonomías existentes de las técnicas de interacción de la RV que se han adaptado para un procesamiento óptimo del flujo de información de los datos. Por último, la tercera etapa consiste en la creación de prototipos de RV por un experto en RV y en la realización de evaluaciones con usuarios sobre esos prototipos.

Esta metodología se ha ensayado y evaluado en un experimento con dos expertos de la industria de la construcción sobre dos casos de estudio de este sector. El primer caso se centra en la planificación de la seguridad de una obra de construcción, mientras que el segundo se refiere a la evaluación de las incoherencias espaciales entre los componentes de un edificio durante la fase de diseño.

Nuestra metodología tiene las siguientes ventajas: i) no se omite ninguna de las soluciones posibles a priori durante el proceso de diseño, ii) un número de soluciones que se deben prototipar y evaluar es determinado durante las etapas de especificación, iii) los expertos en ámbitos específicos son agentes del proceso de diseño porque son los que definen de forma completa y autónoma las especificaciones sobre el diseño de las interacciones, iv) la necesidad de conocimientos especializados en materia de análisis de tareas y de conocimientos sobre la RV es limitada porque los expertos en ámbitos específicos están guiados durante la construcción del modelo de RV de sus tareas específicas y para la determinación de propuestas de técnicas de interacción de la RV. La limitación de nuestra metodología es que la creación de prototipos de RV y las evaluaciones de los usuarios siguen requiriendo expertos en RV porque actualmente se no puede automatizar este proceso. Para concluir, este trabajo aporta la contribución de una guía metodológica para el diseño y la aplicación de las técnicas de interacción en las aplicaciones de la RV, aquí aplicadas a un ámbito concreto.

Palabras-claves : Realidad Virtual, Building Information Modelling, Metodología centrada en el usuario, Metodología centrada en la tarea, Guía práctica

List of Figures

2.4

The three i's of virtual reality, adapted from Fuchs et al. [56] and Mutterlein [START_REF] Mütterlein | The three pillars of virtual reality? investigating the roles of immersion, presence, and interactivity[END_REF] . . 2.5 3D mock-ups used in BIM tools -Johansson et al. courtesy [84] . . . . . . . . . . . . . 2.6 2D models to create the building design -Costa et al. courtesy [37] . . . . . . . . . . . 2.7 A point cloud and a 3D model of an existing building -Mill et al. courtesy [START_REF] Mill | Combined 3d building surveying techniques -terrestrial laser scanning (tls) and total station surveying for bim data management purposes[END_REF] . . . 2.8 Diverse senses of BIM, in narrower or larger scopes -Volk et al. courtesy [START_REF] Volk | Building information modeling (bim) for existing buildings -literature review and future needs[END_REF] . . . . 2.9 Phases in a building life cycle -O'Sullivan et al. courtesy [START_REF] O'sullivan | Improving building operation by tracking performance metrics throughout the building lifecycle (blc)[END_REF] . . . . . . . . . . . . . 2.10 A clash automatically detected in a design review life cycle -Hu et al. courtesy [79] .

2.21

A taxonomy of the navigation interaction techniques in a VE -Bowman et al. courtesy [23] 2.22 A taxonomy of the selection interaction techniques in a VE -Bowman et al. courtesy [26] 2.23 A taxonomy of the manipulation interaction techniques -Bowman et al. courtesy [26] 2.24 A user-centred design methodology to create VE -Gabbard et al. courtesy [57] . . . . 2.25 A generic methodology to design 3D interaction techniques -Chen et al. courtesy [35]

6.8

The VR interaction techniques characteristics for the interaction "move -short moves" 6.9 The VR interaction techniques characteristics for the interaction "activate the functionality to signal workers" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.10

The VR interaction techniques characteristics for the interaction "target workers in hazardous situations" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 The VR interaction techniques characteristics for the interaction "activate the functionality to send the report" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12 The VR interaction techniques characteristics for the interaction "place/orient the machines present on the worksite" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. 13 The VR interaction techniques characteristics for the interaction "move in the plant room"181 6. 14 The VR interaction techniques characteristics for the interaction "activate the function-

ARCHITECTURE, CONSTRUCTION AND ENGINEERING AND BUILDING INFORMATION MODELLING

1.1 Architecture, Construction and Engineering and Building Information Modelling

The Architecture, Construction and Engineering (AEC) industry is a sector whose concrete realisations have a high visibility for all the citizens of the world and may easily have an impact on their daily life. Over the last centuries, the progresses issued from the different industrial revolutions have permitted serious improvements in the AEC industry. Nonetheless, probably because of its tendency to create "products" in unstable and changing environments [1], the AEC industry has started later its 3.0 revolution -the third industrial revolution, which was due to the automation of the production thanks to robotics and to the first automated systems -and has evolved more slowly than other industries such as the aviation [53] and the automobile industries [START_REF] Park | Augmented reality based on driving situation awareness in vehicle[END_REF]. This may be explained by the fact that this sector is mainly composed by small and medium enterprises that usually face more difficulties to assume the financial cost of automation [START_REF] Wong | Use of ict for e-procurement in the uk construction industry: A survey of smes readiness[END_REF]. Additionally, it may also be due to the low repeatability of the AEC "products", since many constructions are unique, oppositely to cars for example. However, it should be highlighted that these differences with the other industries have been more likely due to a partial combination of those factors and of other ones. Moreover, this combination of factors may vary depending on the companies and the countries.

However, during the last decades, the evolution of the AEC industry processes has continued, and this has been particularly due to the progressive use of a methodology called Building Information Modelling (BIM) [61]. This methodology relies on centralising all the construction project data, on updating these data during the building life cycle and on sharing them between all the different stakeholders of an AEC project. Thus, the BIM methodology mainly relies on the use of a common database for all the data, and requires collaboration, interoperability and coordination approaches for the professionals involved in BIM projects, and within the tools they use.

Typical BIM data are interdisciplinary 2D plans and 3D models of a building or another structure -e.g. a bridge, but BIM data can also be cost tables, supplier contracts or construction planning. All the BIM data must be updated during the whole building life cycle, which is composed of five main phases [START_REF] Xu | A framework for bim-enabled life-cycle information management of construction project[END_REF]. These phases are the preconception phase (field studies, costs, budget etc.), the design phase (conception of the future building), the construction phase (concrete realisation on the worksite), the operation phase (when people are using the building for its initial use) and the maintenance phase

ARCHITECTURE, CONSTRUCTION AND ENGINEERING AND BUILDING INFORMATION MODELLING

(follow-up of the building for replacements). For all these phases, the BIM methodology allows for the improvement of their organisation, their planning and their monitoring. Many BIM tools can be used for this purpose, each one with its own objective, from time scheduling to cost management, and including health and safety management [START_REF] Rokooei | Building information modeling in project management: necessities, challenges and outcomes[END_REF]. These tools have improved the AEC processes and should contribute to make this sector become a part of the industry 4.0 [42].

The use of BIM tools and the application of the principles of the BIM methodology provide BIM benefits to AEC projects, according to several studies and reviews in the literature [START_REF] Rokooei | Building information modeling in project management: necessities, challenges and outcomes[END_REF] [61]. Azhar et al.r [13] showed in their review the BIM benefits in terms of cost avoidance for several case studiesnotably for clash detection or construction scheduling tasks, but BIM benefits are not only on financial costs [60]. In this sense, Enshassi et al. [47] classified these benefits as issued from four main factors: life cycle cost control and environmental issues, effective construction processes, design and quality improvement, and decision-making support/better customer service.

To provide such benefits, BIM contributes to improve the AEC stakeholders' task performance.

Nonetheless, this amount of improvement varies depending on the tasks. For some tasks, the BIM benefits are high and may allow for the complete resolution of their related issues -e.g. clash detection, or cost management -whereas for other tasks the BIM benefits may not be sufficient to solve their related issues completely -e.g. safety and health management. For these last kinds of tasks, other improvements could be done on their decision-making part, where the human expertise is valuable, required and cannot be replaced easily by a machine. In this sense, some BIM tools currently try to facilitate decision-making by providing to the AEC experts some automated follow-ups and data, particularly for management tasks.

Finally, BIM benefits can be measured in many different ways, notably in terms of costs, in terms of the quality of the decision-making, and in terms of the amount of time saved, which can be measured through the date when decisions have been taken -earlier -thanks to BIM [START_REF] Najjar | Integration of bim and lca: Evaluating the environmental impacts of building materials at an early stage of designing a typical office building[END_REF]. About the costs, a measure called return of investment (ROI) is usually used, which can be defined as the savings, i.e. the difference between the investments and the costs, divided by costs [START_REF] Stowe | Capturing the return on investment of all-in building information modeling: Structured approach[END_REF]. This measure has interested many researchers since showing that BIM has a positive ROI would encourage the use of BIM despite of the initial cost of BIM, such as employees' training. For this purpose, Qian et al. intended to provide a formula to estimate the ROI depending on the projects and on the companies [START_REF] Qian | Benefits and roi of bim for multi-disciplinary project management[END_REF], but such predictions are hard to make for any cases [START_REF] Stowe | Capturing the return on investment of all-in building information modeling: Structured approach[END_REF]. Nonetheless, there is a global trend: Latiffi et

COMPUTER SCIENCE TECHNOLOGIES AND VIRTUAL REALITY IN THE AEC INDUSTRY

al. [91] concluded that the ROI of BIM was usually negative during the first year of BIM use, but then can become positive during the next years. In a shorter time scale, Walasek et al. found the ROI of BIM was usually lower at the beginning of a project, but can be very positive afterwards, and they linked this result with the fact that using BIM implies investment particularly for the first phases of the building life cycle and less for the last phases [START_REF] Walasek | Analysis of the adoption rate of building information modeling [bim] and its return on investment[END_REF].

To summarise, the AEC industry has improved its processes thanks to the arrival and the use of the BIM methodology and BIM tools. This has been notably shown by studies that evaluated and proved that BIM can improve the task performance of different stakeholders of AEC projects.

Computer science technologies and virtual reality in the AEC industry

A current challenge in the AEC industry is to succeed in linking the benefits obtained from BIM with the expertise of the AEC professionals when they are performing their tasks, instead of after or before doing it, particularly for decision-making. For this purpose, computer science technologies are more and more used, to address such decision-making issues [78]. These technologies can improve the AEC processes by enhancing the human expertise, particularly when they are linked to BIM data and tools: for example, when BIM data are integrated to a Geographic Information System, this can facilitate the environment impact assessment made by the BIM managers [START_REF] Liu | A state-of-the-art review on the integration of building information modeling (bim) and geographic information system (gis)[END_REF]. About this link between BIM and computer science technologies, these last can be used either separately or as a complement to BIM technologies [95] [78]. This means that BIM can be either an input, by providing BIM data to the computer science technologies, or, on the contrary, a target for the output data collected by these technologies. Machine learning tools [28], or the Internet of Things tools, which are notably based on sensors [START_REF] Tang | A review of building information modeling (bim) and the internet of things (iot) devices integration: Present status and future trends[END_REF], are some examples of such technologies.

In this thesis, we focused our research on the use of virtual environment (VE) technologies, meaning the mixed reality (MR) technologies, and particularly on the virtual reality (VR) technology. Virtual environments can be created either from data coming from the reality, or from virtual modelling, or from both. This spectrum of data is usually called the virtuality-reality continuum; in the same sense, the mixed reality term has been created to encompass both the augmented reality (AR) -closer the reality -and virtual reality -closer to the virtuality [START_REF] Milgram | Augmented reality: a class of displays on the reality-virtuality continuum[END_REF]. For the case of the AEC field, the data used in a VE can be for example 3D models from BIM virtual modelling, and 3D data captured on the

ISSUES FOR DESIGNING AND EVALUATING A VIRTUAL ENVIRONMENT AND ITS USER INTERACTIONS

real worksite. The 3D BIM models are usually edited in BIM authoring software, which allow for the creation of such models of the building design [START_REF] Preidel | Seamless integration of common data environment access into bim authoring applications: the bim integration framework[END_REF]. And about the data captured on the worksite, these can be videos taken with a drone [136], or point clouds obtained using laser tools [74].

In the AEC industry context, the benefits of virtual environments have been studied through the evaluation of VR or AR applications designed for specific AEC purposes. Chalhoub et al. showed the benefits of an AR application to build electrical designs for a building [34]. Perlman et al. evaluated the identification of hazards in a CAVE -a CAVE Automatic Virtual Environment [38], and showed the benefits of this VR immersive system for performing this task, for some kinds of users [START_REF] Perlman | Hazard recognition and risk perception in construction[END_REF]. These two studies evaluated the benefits for individual user performances; however, Ammari et al. studied the benefits of VR for remote collaboration [5]. In the evaluations conducted in all these studies, the different authors measured the user task performance in the VE and compared it to the performance in the real world. Then, if the performance measured in the VE was higher than in the real world, it meant for them that they had succeeded in showing the added value of the VE. Nonetheless, other considerations could also show the added value of a VE, such as direct cost saving due to the virtuality, e.g. for marketing purpose, no need to create a real model of a flat thanks to a VR application. In these studies, the authors measured the task completion times, the rate of correct answers, and the error rates [34] [START_REF] Perlman | Hazard recognition and risk perception in construction[END_REF], or the users' satisfaction through subjective questionnaires, about collaboration effectiveness [5]. The results of their evaluations showed the benefits of the use of BIM-based VE applications, improving the user task performance or the user satisfaction.

To conclude, BIM can help for solving decision-making related issues, nonetheless, computer sciences technologies can be used in complement to BIM to improve such decision-making, particularly for human expertise related tasks. Among these technologies, virtual reality can be used in particular, which allows for the creation of virtual environments. Indeed, several studies have shown the benefits on the user task performance when using VR in combination with BIM in VR applications.

Issues for designing and evaluating a virtual environment and its user interactions

According to the state of the art about the use of VR for AEC needs, we noticed that the use of VR applications could improve the task performance of AEC project stakeholders. We also noted that this use of VR could be for many different trends and purposes, and even more in BIM projects since the use of BIM reinforces the involvement of all the trends and their collaboration. Moreover, even if conceived for a unique purpose, it should be highlighted that a VE can be designed in many different ways. Indeed, in terms of data visualisation, there are bountiful design choices that are available [64], and this is the same about the techniques that are available for designing the user interactions [71] [START_REF] Sutcliffe | Multimedia and virtual reality: designing multisensory user interfaces[END_REF]. It is important to note that this design issue is not limited to the context of the AEC industry, but on the contrary, to almost all the fields where VR can be used.

To address this issue about the design of the VEs, many studies have been conducted to propose and evaluate some methodologies that can be used to guide this design. Some of these studies gave approaches for some specific fields of application [35], while others intended to provide generic methodologies [25] [130] [57]: in any cases, they provided user-centred design methodologies to guide the design of VEs. As defined by the ISO 1503:2008 -available at www.iso.org, a user-centred design approach is "characterised by the active involvement of users, a clear understanding of user and task requirements, an appropriate allocation of function between users and technology, iterations of design solutions, and multi-disciplinary design". Thus, this kind of methodology usually focuses on two main aspects [START_REF] Tanriverdi | Vrid: a design model and methodology for developing virtual reality interfaces[END_REF] [25] [57]: the way of designing a virtual environment based on the users' needs, and the way of evaluating such design based on users' criteria.

About this evaluation aspect, the existing user-centred methodologies proposed to conduct usability evaluation on the VEs, particularly on the techniques used by the users for interacting. Such usability evaluations rely on an iterative process of user experiments, where different measures are taken, notably about the user task performance, such as task completion time, or user preference, such as through subjective questionnaires. Many studies focused on this usability evaluation aspect [24] [166], leading to the creation of models for organising such user experiments [START_REF] Tromp | Systematic usability evaluation and design issues for collaborative virtual environments[END_REF] [76]. These evaluation approaches and models seem to have given significant progresses on this evaluation aspect; nonetheless, several studies still have a focus on the evaluation of the design of the VEs [88].

Then, for the aspect about the way for designing VEs to address the users' needs, as induced by the definition of a user-centred design approach, the existing methodologies proposed some design processes that were based on two main components: the analysis of the user task -in the ISO definition:

"a clear understanding of user and task requirements", and the transmission and application of expert guidelines for choosing the interaction techniques that are appropriate in terms of usability -in the ISO definition: "an appropriate allocation of function between users and technology". These processes do

DESCRIPTION OF OUR CONTRIBUTION ABOUT THE DESIGNING OF VES

allow for designing VEs that address the users' needs [25] [57]; however, they rely on expert knowledge, notably VE knowledge, contained in the required expert guidelines, and on the VR experts themselves that apply these methodologies. This is why, in this thesis, we focused on this design aspect, i.e. about the way of designing the virtual environments based on the users' needs, and more precisely on how to guide this design process.

Description of our contribution about the designing of VEs

The design of the interaction techniques used in virtual environments and their evaluation appear in the literature as a research problem. To address this problem, several user-centred design methodologies have been proposed in the literature [25] [57] [130]. An analysis of these existing methodologies reveals that they did focus on these two main aspects, the design and the evaluation of the VE interactions, according to the users' needs. Moreover, it can be noticed that, based on that, three main components are usually present: for the design, the analysis of the user task, and a study of the existing interaction techniques through expert guidelines and evaluations of which techniques may be appropriate to the users' needs in terms of usability, and for the evaluations, processes for conducting user evaluations on the usability of the interaction techniques.

First, based on this analysis of the existing user-centred design methodologies, we experimented in this thesis these methodologies on several AEC case studies. During these experiments, in the same way that we noted it previously with an analytical reading of these methodologies, but this time empirically with the AEC professionals, we noticed some issues about the way for designing the interactions following these methodologies. These issues were linked to the need of having task analysis and VE expertise for designing the VE interactions, and, as a result, we noted two main possible axes of improvements, on the first two components mentioned above for the design -the user task analysis and the expert guidelines and evaluations. First, the user task analysis could be improved to allow people that do not have task analysis knowledge to do it, and the expert study, guidelines and evaluations of the appropriate interaction technique in terms of usability could be modified to allow the AEC experts -or other kinds of domain-specific experts -to determine proposals of appropriate interaction techniques without having VE expertise. These possible improvements can be interpreted as the following scientific issues: how to improve the task analysis to make it accessible to the AEC/domain-specific experts, and how to modify the current VE design approach to involve 1.5. DOCUMENT OUTLINE more the AEC/domain-specific experts and less the VE experts.

Then, to address these research issues, we proposed in this thesis a task-centred design methodology. Our methodology aims to guide the AEC/domain-specific experts in going from their original domain-specific task, i.e. a task from their own field, such as construction supervision for an AEC expert, to VE interaction techniques that are appropriate to this task in terms of usability, before requiring a VE expert to prototype VE applications and conduct user evaluations on usability. To ensure such aid, our methodology is composed by three main steps: first, the construction of a model of the domain-specific task through a guided analysis and decomposition of it, then the determination of VE interaction techniques for each subtask issued from this decomposition, and finally the creation and the evaluation of prototypes of VE applications with the user interactions previously determined.

It should be highlighted that our methodology has the ambition to be generic, but here we only applied it and tested it in the AEC context.

Document outline

This document has the following structure: after this chapter 1 of introduction, we present in the chapter 2 state-of-the-art studies about the use of BIM, the use of diverse virtual environment technologies and notably VR, and the existing user-centred design methodologies for the design of VEs.

Then, in the chapter 3, we show our first approaches and experiments on the design of BIM-based VE applications, based on the existing user-centred design methodologies. Next, in the chapter 4, we explain the scientific issues that remain to be solved, based on our analysis of the existing methodologies and our experiments presented in the previous chapter, accompanied by our hypotheses. After that, in the chapter 5, we describe our methodology for designing VE interactions and its steps. Next, in the chapter 6, we explain how we have evaluated our methodology through an experiment with two AEC professionals on two different AEC case studies, in which they have obtained the specifications of the interaction techniques for the VE application of each case study, once following our methodology and once following a traditional user-centred design methodology. Finally, in the chapter 7, we conclude about our research and give perspectives of use for our methodology.

In the appendices of this thesis document, we provide two documents. First, in the appendix A, we provide a practical guide that explains how to follow our methodology that has been presented in 39 1.5. DOCUMENT OUTLINE the chapter 5, in an adapted way for the domain-specific experts. It should be highlighted that this guide has been used by the AEC professionals in the experiment presented in the chapter 6. Then, in the appendix B, we present an example of the application of our step of prototyping VE applications and of conducting user evaluations on an AEC case study about hazard identification, based on the proposals of VE interaction techniques that have been obtained during the experiment done in the chapter 6 for this case.

To summarise, Figure 1.1 shows an overview of the thesis document structure and its appendices.

VIRTUAL ENVIRONMENTS, MIXED REALITY, VIRTUAL REALITY

Virtual environments, mixed reality, virtual reality

In the literature, many terms are used to describe and define the different virtual environment technologies. All these technologies aim to provide to their users a virtual environment where they can visualise and interact with some content, which can be either virtual and/or real. To describe such VE technologies in a generic way, the term mixed reality can be used since it encompasses the definitions of all the kinds of environments that provide to their users a "reality", which is in fact an alternative to our physical world. It means that this term includes the concept of virtual realitywhich is close to full virtuality, the one of augmented reality -which is closer to the reality, and all the other intermediate possibilities, such as augmented virtuality [START_REF] Regenbrecht | Using augmented virtuality for remote collaboration[END_REF]. To sum up, MR technologies allow for the creation of environments that combine both real elements from our physical world with fictive elements from virtual worlds, regardless of the relative proportion of each of these two kinds of elements in the environment [105] [104]. Figure 2.1 shows this concept called virtuality continuum. MR technologies aim to put in relationship a virtual environment and our real world, through some input and output systems that are provided to the users. These systems allow for the establishment of communications and of actions between the two kinds of environments and the users. In one of their study, Burdea et al. [31] represented explicitly this fact, as shown in Figure 2.2. Indeed, in this figure the arrows represent both these relationships and the interactive workflow of communication between the users and the virtual reality technology, notably when they need to perform a task within this VR environment. In this regard, Rubio-Tamayo et al. highlighted an essential aspect about this relationship: this communication between the users and the virtual and real environments, through input and output systems, is mostly based on our senses [START_REF] Rubio-Tamayo | Immersive environments and virtual reality: Systematic review and advances in communication, interaction and simulation[END_REF]. This explains why our visual perception is particularly important and essential for us in VR experiences; nonetheless, other human senses can be used in VR, such as our touch or motion sense through haptic devices, as shown in Figure 2 Virtual environments are characterised by the choices made about the content they display and its associated visualisations, and the interactions they offered to their users [29]. To clarify what these two main elements of a virtual environment are, these definitions can be used:

• The VE content is the content that composes the VE itself: this is usually some 3D visual content such as 3D models, but it can also be some audio content for example. This content can be created by designers or be issued from domain-specific field data.

• The VE interactions are the interactions that the users have with and within the VE. They are possible thanks to VR interaction techniques, which are the ways or the interaction techniques built by the VR developers to provide to the users these capacities to interact.

Bryson et al. called these visualisations choices "the overall environment and the information presentation metaphors" choices, and called them for the interaction "the interaction metaphors choices" [29]. They also noticed that these two main characteristics -visualisations and interactions -that are employed to describe a virtual environment could also be used when thinking about the device requirements or the device performance constraints since they are usually visual display constraints and interactivity constraints. About the design of the virtual environments, both human and device characteristics may have some influence on it. This can be explained since VEs are in fact advanced human-computer interfaces. Thus, as Hettinger et al. noticed, virtual environments should be designed thinking on the future users and their aims -e.g. following a user-centred design -since VE main purpose is to improve and extend human abilities [72].

Virtual reality can offer a lot to its users, notably through an improvement of their imagination, due to a virtual environment that improves their interaction capabilities, and provides a deeper sense of immersion. Indeed, Fuchs et al. described the interaction and the immersion as "the two keywords of virtual reality" [56], and, more recently, Mutterlein added a third "i", with the concept of the imagination of the VR users, and called these three "i's" the three pillars of virtual reality [START_REF] Mütterlein | The three pillars of virtual reality? investigating the roles of immersion, presence, and interactivity[END_REF].

Figure 2.4 shows this principle about virtual reality. Moreover, as these "i's" are what make VR much more than a simulation according to Zyda et al. [START_REF] Zyda | From visual simulation to virtual reality to games[END_REF], the use of VE technologies should also improve the users' performance on their expert tasks. Alshaer et al. showed that the virtual environments can improve the spatial abilities of their users, and more precisely in their study the spatial memory and navigation abilities during an exploratory walkthrough task [3]. It has been shown that these kinds of abilities may be essential for performing some tasks, and that VR allows the users to perform these tasks better, inclusively in many different contexts such the aeronautic [97] or the aircraft industries [START_REF] Peinecke | VR and AR environments for virtual cockpit enhancements[END_REF].

Figure 2.4: The three i's of virtual reality, adapted from Fuchs et al. [56] and Mutterlein [START_REF] Mütterlein | The three pillars of virtual reality? investigating the roles of immersion, presence, and interactivity[END_REF] For these reasons, mixed reality technologies are currently widely used in different kinds of industries. They have also been used for many different purposes, such as for example in the mining industry for training as Wyk and De Villiers noted it [START_REF] Van Wyk | Virtual reality training applications for the mining industry[END_REF]. Virtual reality can also be used to perform training sessions for complex tasks such as assembly tasks and industrial maintenance [58] [118]. Nonetheless, it would be reductive to think that VR can only be used for training. Indeed, in such environments, users' behaviours can be evaluated for other purposes and tasks. For example, user experiments can be conducted when VR users must validate the design of industrial workstations, to evaluate their collaboration on a designing task [63] [126]. In that sense, design or planning tasks are usually good candidates for virtual reality since they may require coordination and collaboration between several experts, which are two concepts that are enhanced in VR [103] [92]. In particular, some VR techniques enhance this collaboration by providing multiple representations of objects, and by showing a different one to each user according to their own expertise, notably in CAVE devices [93]. To conclude, mixed reality technologies can be used for diverse purpose in different kinds of industries, and in particular for performing design tasks, either individually or in collaboration.

Finally, about the design tasks performed in VR, one major challenge is to reflect the decisionmaking choices taken during the VR sessions on the design model that is used by the experts on their domain-specific tools. To address this issue, in the context of the AEC industry, Du et al. presented a zero-latency environment, based on AEC software and a VR application, to assist design decision-

BUILDING INFORMATION MODELLING USAGES AND BENEFITS

making about a building [43]. Their virtual environment improved both the collaboration and the individual user task performance of the AEC stakeholders involved in this design task, by allowing for earlier decision-making, thanks to the VR technology, and thanks to AEC software, which are presented in the next section.

Building Information Modelling usages and benefits

In the AEC industry, the Building Information Modelling is a methodology that has been more and more used since the last decades [START_REF] Sacks | BIM handbook: a guide to building information modeling for owners, designers, engineers, contractors, and facility managers[END_REF]. This methodology and its related software, specific to the AEC industry, have helped the different stakeholders of building projects for completing some of their tasks. One of the main purposes of BIM is to centralise all the data about a building from its conception to its renovation or its recycling. For this purpose, BIM allows all the different stakeholders to share and to participate in a common digital model. Thus, to enhance the collaboration, BIM tools allow for the consultation and modification of the building models, the costs supervision documents, and the planning of the construction. Nonetheless, BIM is more than a simple database and also relies on software that allow for the design of building models thanks to 2D plans and 3D virtual mock-ups.

These models can be for example structural, architectural or mechanical, electrical and plumbing models, and are usually designed in BIM authoring tools such as Autodesk Revit or Graphisoft Archicad.

All these models and also the data from other sources -e.g. simulations, text documents, videos or point clouds from the field -contribute to the global digital model. By extension, this BIM global model, which centralises all the building data, may be considered as a digital twin of the real structure. A digital twin may be defined as "a digital asset [i.e. a data set that describe an asset that is not necessarily physical] on which services [i.e. repeatable business activities that have a specified outcome] can be performed that provide value to an organization" -ISO norm ISO/TS 18101-1:2019. This point is actually debated in the literature, and accepted or not depending on the studies. As for Khajavi et al. [87], a BIM model is not a digital twin and would only become it if the data collected thanks to the Internet of Things technologies (IoT) and the information coming from machine learning computation could be considered as included in the BIM methodology -and as for them, they cannot be considered as such. They specified that, as for them, a digital twin model is

BUILDING INFORMATION MODELLING USAGES AND BENEFITS

a BIM model enriched with these kinds of data -IoT data [87]. Volk et al. also expressed this possible ambiguity about the understanding of BIM scope, which can variate [START_REF] Volk | Building information modeling (bim) for existing buildings -literature review and future needs[END_REF], as shown in Figure 2.8.

In any cases, the different studies in the literature about BIM agreed that its use does allow for a better follow-up of the construction steps and has actually improved the work of the building projects stakeholders, spreading the idea that BIM has benefits and that these benefits can be evaluated, to

show how it can help the AEC professionals. BIM benefits have been indeed shown and evaluated in the literature in many studies, in different situations and with the involvement of different AEC trends and roles. Thus, it means that it has been observed that BIM can improve the performance of the AEC projects stakeholders for their tasks. It should be highlighted that this is valid during all the different phases of a building life cycle. Figure 2.9 illustrates a way to represent the building life cycle phases, adapted from the research of O'Sullivan et al [START_REF] O'sullivan | Improving building operation by tracking performance metrics throughout the building lifecycle (blc)[END_REF]. It can be noticed that many studies have shown in particular the use of BIM in the design and the construction phase, to prevent issues before starting more concrete actions [START_REF] Parn | Origins and probabilities of mep and structural design clashes within a federated bim model[END_REF] [162], nonetheless others have evaluated on the contrary the BIM benefits during the maintenance phase to anticipate buying and repairs [110] [178]. To understand and observe the BIM benefits for completing a task on determined situations, we present afterwards some examples of such tasks performed using BIM. One of these tasks is the design review of clashes, a mandatory task that belongs to the design phase and more precisely to the coordination sub phase. Mehrbod et al. showed that BIM helped to improve significantly the reviews of these clashes thanks to the use of 3D models shown on 2D

screens, compared to the use of paper plans [START_REF] Mehrbod | Characterizing interactions with bim tools and artifacts in building design coordination meetings[END_REF]. To be more precise about these design reviews, it is important to notice that there are usually composed of two subtasks: the clash detection and the clash analysis. About clash detection, BIM software such as Autodesk Navisworks Manage allow for the automatic detection of clashes, based on rules defined by the user. Such BIM tools that detect automatically clashes helped the AEC stakeholders to coordinate different 3D models of one building during the design phase.

However, the understanding of the design clashes can still be improved. In this sense, Parn et al.

have been able to evaluate the typical size of the clashes, to know better their characteristics and to determine the most probable origins of clashes between structural models and mechanical, electrical and plumbing models [START_REF] Parn | Origins and probabilities of mep and structural design clashes within a federated bim model[END_REF]. For the same purpose, Hu et al. built a BIM component-dependency network based on semantic rules. This allowed them to understand the relationships between building elements and to improve the results of automatic detection approach by avoiding false positives during clash detection [79]. Another task for which the quality of the work done by an AEC project stakeholder has been improved thanks to the BIM methodology and BIM tools is the construction safety planning task.

It is important to explain that this improvement is mostly due to the fact that the construction planning and scheduling has also been improved thanks to BIM [START_REF] Sulankivi | 4d-bim for construction safety planning[END_REF]. BIM indeed allowed for a stepby-step scheduling for a better preparation of the worksite, and current BIM tools offer such planning possibilities usually thanks to a Lean construction management approach, like in Plexos Project for example [62]. Other tools have been specifically designed to allow the creation of construction simulations of the worksite over time. Thus, as the construction steps are planned and defined in terms of time, quantity of people and materials, a construction safety planning can be done more easily.

Based on these considerations about construction planning, Zhang et al. proposed a way to perform a BIM-based fall hazard identification, to improve the prevention of hazards within the construction safety planning [194] [195]. These kinds of approaches are based on two different aspects: first, the detection of the potential hazards and then the proposals of mitigation for these hazards. courtesy [START_REF] Zhang | Bim-based fall hazard identification and prevention in construction safety planning[END_REF] To summarise, in these studies and experiments, several purposes and usages of BIM have been shown: design review, construction scheduling, and health and safety design and planning. Moreover, these studies have shown how BIM allows the AEC projects stakeholders to improve their task performance. It should be highlighted that this is also the case for other usages, which are also presented in the literature. In the next section, we want to present how virtual environments and BIM technologies can be used together, as mentioned with the study by Du et al. [43], and the benefits of using these two technologies together for completing AEC tasks.

Benefits of using BIM-based virtual environments for AEC tasks

We have seen that VE applications can have many benefits for their users, and that using BIM can improve the AEC users' task performance. For example, user evaluations have shown that 3D BIM data and particularly 3D building models may be better than 2D data to support user's participation, in a study for the architectural design process by Saleh et al. [START_REF] Saleh | Evaluation of three-dimensional computer visual materials to support user's participation in architectural design process[END_REF]. And, as the VEs aim to display virtual and real content to their users, BIM data could as a result be used in such environments. Thus, it seems that VE technologies could be combined with BIM to create innovative solutions. If so, the use of VE would thus increase the benefits already obtained with BIM, or could produce new ones.

BENEFITS OF USING BIM-BASED VIRTUAL ENVIRONMENTS FOR AEC TASKS

Nonetheless, such benefits need to be evaluated; Heidari et al. faced this issue in their study, which considered an AEC project in its entirety and not some specific tasks or cases [70]. They proposed a BIM-based VR prototype that aimed to be more useful than traditional BIM tools. As for them, one objective that VR researchers should try to reach is to propose a smart-BIM that is dynamic and with free-interactions. According to them, their prototype was between an ordinary BIM tool and a smart VR one: in their prototype, a virtual environment was provided to the users with predefined interactions on some scene objects. Finally, about the design of their VE, they noted that when predefined interactions where available to the users; this improved the quality of the users' work, even though an issue for them was to choose which interactions provide and to decide about the design of these interactions.

In opposition with Heidari et al., most of the studies in the literature evaluated VEs for a specific AEC context and for specific users' tasks, in order to determine and evaluate precisely the benefits of a BIM-based VE. In this sense, Heydarian et al. studied the choices made by the users about lights, in a design decision-making task, through an experiment in a virtual environment [73]. In this specific case, the multiples choices about the design of the VE -choices for the design of the lights -dovetailed with the multiple design choices of the building, evaluated and tested as a result by the users of the VE.

Similarly, in the literature many authors studied how to use VR to provide collaborative environments that could improve collaborative decision-making. For example, Yan et al. proposed a BIM-Game prototype where they involved the users in the design of a building using the VR interactions, which facilitated collaborative decision-making [START_REF] Yan | Integrating bim and gaming for real-time interactive architectural visualization[END_REF]. Figure 2.12 shows two views available in their BIM-game prototype during a user navigation task: on the left, the users benefit from a firstperson view, and on the right, from a third-person point of view. They proposed here to use these visualization and interaction choices to test them in this case study for accessibility testing. Finally, other studies focused on comparing VR applications to traditional mock-ups in 2D [96]. Additionally, Shi et al. presented a methodology for creating this kind of collaborative environment in VR from BIM data [START_REF] Shi | A multiuser shared virtual environment for facility management[END_REF], and Boton chose to study how to improve this kind of collaboration for design by using 4D simulations (3D over time) [22]. These studies showed that BIM can provide benefits on collaboration between stakeholders, and, additionally, they showed that multiple design representations could be used in these VEs, notably since they are based on different kinds of contents. TASKS Figure 2.12: BIM-Game engine prototype for collaborative design, using two different points of views, first-person on the left and third-person on the right -Yan et al. courtesy [START_REF] Yan | Integrating bim and gaming for real-time interactive architectural visualization[END_REF] However, it would be reductive to say that virtual reality or mixed reality combined with BIM can only improve collaboration. For example, a BIM-based augmented reality application has been built and tested by Chalhoub et al. for individual training [34]. In their study, they compared the traditional technique with 2D plans to the one with the use of an AR application in the context of the task of assembling an electrical design on a worksite. They aimed to observe the difference in task completion time between two groups, each one using two different approaches on two different cases. Their results showed that both groups of people built the electrical circuits faster in AR than by following the traditional technique, without making more errors, showing thus here that augmented reality improved the task performance of the users for this task. Figure 2.13 presents the results of their evaluation, and shows the benefits of augmented reality in terms of number of mistakes and quality of the final assemblies.

BENEFITS OF USING BIM-BASED VIRTUAL ENVIRONMENTS FOR AEC TASKS

It can be noticed in that most of the studies in the literature about BIM-based MR tools are related to design decision-making. This can be explained by the fact that design-related decisions that occur earlier in the design phase do have a significant impact in terms of time and costs of the AEC projects, making them the priority of the use of mixed reality. More globally, considering the entire building life cycle, the earlier the decisions are made the better. It means that the final objective of using BIM, or BIM combined with MR, is the reduction of the final costs, even though it implies more effort at the beginning [START_REF] Lu | Cost-benefit analysis of building information modeling implementation in building projects through demystification of time-effort distribution curves[END_REF]. Nonetheless, there are other cases where BIM data are used in virtual environments. A common case in the literature is the use of VR for sales demonstrations, in order to make a user evaluation of the designs of a future building by potential customers. In this sense, Wang et al. studied how an AR application built for interactive architectural visualisation could help people to make decisions, and their results showed that augmented reality helped to perform this task better [START_REF] Rahimian | Integrating bim and augmented reality for interactive architectural visualisation[END_REF].

Furthermore, it can be noticed that most of the studies previously cited here did not use other data than the ones coming from the 3D BIM models. Nonetheless, some others studies used other sources of data, and particularly from the real world from the worksite itself or from the future place of the worksite. In this sense, Sun et al. built a VR application where they combined the 3D BIM models of a building with oblique photogrammetry data of the building environment [START_REF] Sun | Virtual experiencing and pricing of room views based on bim and oblique photogrammetry[END_REF]. They noted that this visualisation design choice of juxtaposing the two kinds of data in their VR application helped the final customers to be immersed in their virtual environment, and thus allowed them to evaluate whether the price was correct or not for an apartment, navigating between different points of view.

Figure 2.14 shows on the left an view from the exterior, and on right a view from the interior. However, photogrammetry is not the only source of information from the real world that could be coupled to 3D

BIM data, such as videos from drones or data from sensors. Entrop et al. used infrared drones as data source from the real world about building thermography [48]. As for them, the classic approaches of the building industry were considering separately the drone video data and the infrared data, thus they presented an approach mixing both. They proposed a new protocol to design building thermography using drone procedures. Other studies have used drones to scan existing buildings to rebuild 3D models [36][90] [94][172] [START_REF] Zheng | A multi-uav cooperative route planning methodology for 3d fine-resolution building model reconstruction[END_REF]. In this kind of case, this is common that the data only come from real environment sources and that the result is a VR application with the 3D model newly rebuilt from the data [89]. TASKS Figure 2.14: Juxtaposition of photogrammetry and 3D BIM model in a MR application for building sales, from two points of view -Sun et al. courtesy [START_REF] Sun | Virtual experiencing and pricing of room views based on bim and oblique photogrammetry[END_REF] Nonetheless, other studies did combine data from both real and virtual sources in a mixed reality environment. In this regard, Iwai et al. built an augmented reality environment where infrared thermography pictures were superimposed on some objects present in the real environment [82]. Their AR prototype allowed the users to get the resulting combination of both kinds of data for assisting decision-making. Finally, MR applications can also improve the comparison task between a real building and a virtual building. Indeed, for this purpose Riexinger et al. built a MR application that allowed for a visual comparison of the as-planned plumbing and the as-built plumbing [START_REF] Riexinger | Mixed reality for on-site self-instruction and self-inspection with building information models[END_REF].

Additionally, in the case of both applications, we can noted that the authors had to make design choices to allow for the visualization of their two sources of data, as visible in Figure 2.15. Additionally, about these applications, user evaluations have been conducted to evaluate and to show the VE benefits for the users to perform in such environments. Such evaluations are based on measuring user task performance or user preference. Nonetheless, usually these user evaluations have not only been used for the evaluation of the benefits of the application itself, but also for the evaluation of the design of the virtual environment. Indeed, for certain cases explained above -

[70] [73] [152] [22] [82] [141]
-the authors noted that, for building a VE application, multiples design choices about the visualisations and interactions were available. They noticed that making these design choices may be complex from them, notably when they were people that are non-expert in VE.

In some of these cases, it can be noted that design evaluations have been conducted thus: we explain in the next section what this consists of.

Ambiguity about the "design evaluations" noun group in the AEC literature

We observed that the AEC industry improved its solutions for many processes thanks to the BIM methodology and BIM tools. Moreover, we noted also the benefits of using virtual environment technologies for several AEC situations and for different stakeholders. Particularly, the use of VE contributes to improve the user task performance for many AEC expert tasks. Nonetheless, the creation of these VEs, and particularly to choose the design of the user interactions, might be complex, and, as a result, user experiments with design evaluations are usually conducted. In the scientific literature of diverse fields, in many studies that involve virtual environments, design evaluation experiments have been conducted. However, in the AEC literature the meaning of design evaluations may be ambiguous.

Indeed, in the AEC field in studies related to virtual environments, "design evaluations" can be interpreted in two different ways: a design evaluation can focus either on the design of the content within the VE, or on the design of the VE itself -this last kind of evaluation is the one that are required on our research scope, oppositely to the other ones that belong to AEC research on the design of buildings.

Most of the studies in this field focused on the first aspect, about the design of the future building displayed in the environment. In such studies, user-centred design experiments are conducted and

AMBIGUITY ABOUT THE "DESIGN EVALUATIONS" NOUN GROUP IN THE AEC LITERATURE

these users usually evaluate and propose or make corrections on the building design during the design phase of its life cycle. Then, the authors usually evaluate in such studies how much better, faster, or easier, the decision-making process was in the virtual environment, resulting in the improvement and the validation of building designs. In this respect, Bullinger et al. proposed a VR environment for participatory design where the users evaluate the design and make decisions about it [30]. Thanks to a user evaluation and a comparison to the traditional techniques, they concluded that their virtual environment did improve the quality of the users' decisions in their study.

Nonetheless, a few studies in the AEC field related to BIM-based virtual environments focused on design evaluations about the VEs themselves instead of the design of the building content. In this regard, about the use of virtual reality, Ventura et al. proposed a design review protocol to guide the AEC professionals in their internal processes of implementation of VR applications [START_REF] Ventura | A design review session protocol for the implementation of immersive virtual reality in usability-focused analysis[END_REF]. They aimed to reinforce an effective and smart use of the VR technology thanks to this user-centred design protocol, visible on Figure 2.16. It seems that their protocol could be very useful to encourage and organise the use of the VR technology to lead AEC meetings. However, it can be noticed that the step 5 of their protocol for user evaluations is only oriented on improving the user experience by preparing and organising the VR sessions better. Moreover, they did not propose to make eventual changes or adaptations of the interaction techniques used in the virtual environment, according to the AEC situations presented within it.

USABILITY EVALUATION ON THE DESIGN OF A VIRTUAL ENVIRONMENT

These evaluations of the design of a virtual environment, in this case dedicated to AEC tasks, could be particularly done on the interaction techniques that are provided to the users. Wu et al. built a BIM-based educational gaming prototype where several user profiles were stored and they proposed to evaluate the design of this virtual environment [START_REF] Wu | A bim-based educational gaming prototype for undergraduate research and education in design for sustainable aging[END_REF]. For this purpose, the users participated several times within the environment and data were collected to improve it iteratively. Thus, the authors showed that the design of a BIM-based virtual environment could be improved conducting user evaluations, by applying an iterative approach.

Nonetheless, this last study from the AEC literature did not follow a specific protocol to involve their users in the virtual environment design process, meaning the design choices made about the VE visualisations and interactions. Fortunately, in the computer science literature, several studies proposed design methodologies to both create and evaluate the design of virtual environments, and more particularly about for the user interactions available in such environments.

Usability evaluation on the design of a virtual environment

Looking at the studies in the computer science literature about the design of VEs and their evaluation [130] [25], it is proper to use the noun group usability evaluation on the design of a VE, instead of design evaluations. Indeed, in these studies, the term usability or the term task performance are used. These two terms may appear in our mind as reflecting two different objectives for a VE designer, but we probably do this confusion because of the definition of the usability concept that we might have in mind. Indeed, the usability term usually makes us thinking about either subjective opinions on the ease-of-use of the evaluated item, or about the user satisfaction when performing a task with this item or system. However, if we took a precise definition of usability from the field of humansystem interaction, the definition from the ISO 9241-11 norm [86] explains that usability is not only satisfaction, but instead takes into account the three following aspects: the efficiency, the effectiveness and the satisfaction [55].

The ISO 9241-11 norm allows for the understanding of what usability is, however, we still wonder which place the task performance has in the definition given in this norm, and which link with usability the task performance has. To understand that, we can take another definition of usability given by Nielsen et al. [START_REF] Nielsen | Measuring usability: Preference vs. performance[END_REF]. Following the same idea that in the ISO 9241-11 norm, they explained that 58

USABILITY EVALUATION ON THE DESIGN OF A VIRTUAL ENVIRONMENT

usability has two wider components: the user preference and the user performance. They explained then that, in that sense, the user preference represents the satisfaction aspect of the ISO 9241-11 norm and the user (task) performance represents the efficiency aspect -"resources used in relation to the results achieved" (definition from the same ISO norm) -and the effectiveness aspect -"accuracy and completeness with which users achieved specified goals" (definition from the same ISO norm). This explains thus the use of the two terms usability and task performance, in the studies previously cited, since usability in its wider meaning -and in the ISO norm definition -encompass the notion of task performance.

To perform these usability or user task performance evaluations, different measurement techniques can be used, particularly qualitative and quantitative measures. Qualitative measures are usually taken during or after user experiments, and are characterised by the fact that they allow for the collection of non-numerical data such as words: some examples of qualitative measures are think aloud comments, or unstructured interviews [21]. Quantitative measures allow for the collection of numerical data: some examples of quantitative measures are task completion time, error rates, or even reaction time [START_REF] Longo | Experienced mental workload, perception of usability, their interaction and impact on task performance[END_REF]. Quantitative measures offer the benefit of allowing more direct comparison between the results obtained from different experiences or different applications or interfaces [77].

Additionally, still about the measures, it is important to note that both kinds of measuresqualitative and quantitative -can be either objective or subjective: for example, to evaluate the efficiency, task completion time is an objective measure that can be used, whereas using a postexperiment questionnaire with questions about the speed of the experiment -e.g. some questions of the Computer System Usability Questionnaire -is a subjective measure [12]. Finally, Nebeling et al.

noted the fact that it could also be relevant to perform other kinds of evaluations than usability or task performance ones, since it would allow to answer other questions about the design of a VE and the task performed within it [START_REF] Nebeling | Mrat: The mixed reality analytics toolkit[END_REF]. They explained that in some cases, it could be interesting to answer "larger research questions, such as whether a user's experience changed between AR and VR, or how to promote and assess problem solving strategies and creativity" [START_REF] Nebeling | Mrat: The mixed reality analytics toolkit[END_REF]. For such purposes, other measures would be necessary, such as an advanced tracking of the users or movements recognition [19].

2.6 Required analyses and studies to design appropriately VE interactions 2.6.1 Explanations on the importance of the design of VE interactions VE have been defined in the section 2.1 as composed of VE content and user interactions. Indeed, on one hand, virtual environments display some content, which can be virtual and/or real content [START_REF] Milgram | Augmented reality: a class of displays on the reality-virtuality continuum[END_REF].

This content must be chosen according to the purpose of the VE application, and, in that sense, in most of the cases, the domain-specific experts or the end-users of the application are the ones in charge of deciding about this content [START_REF] Smith | User centred design and implementation of virtual environments[END_REF]. This can be explained since they are the ones who have the required domain-specific expert knowledge to decide what should be displayed [174] [30]. Oppositely, visualisations choices such as colours or objects' positions might be discussed between the domainspecific experts and the VE experts [67]. On the other hand, VR environments are a space where their users can act, and are thus characterised by the possibilities of interactions they offer to their users [41]. As a result, when designing this kind of environment, a main facet of the VE design is the design of the users' interactions [69]. These interactions are usually performed through interaction techniques provided in the virtual environment, which either mimic a real interaction from the physical world or on the contrary allow a user to act in a non-realistic way such as flying or teleportation [50].

Several interaction techniques exist for a unique kind of interaction, thus this lets to the designers of a VE application multiple choices. It can be difficult to make these design choices since some interaction techniques can be more appropriate -in terms of usability -than other ones, for the specific purpose of the application [59]. Thus, this is why the domain-specific end-users and the VE designer must seek for an interaction technique that would enhance the VE benefits. One way to choose an interaction technique accurately consists of selecting interaction techniques that are close and appropriate to the users' needs according to their tasks. For this purpose, two kinds of analyses are usually performed: user task analysis and interaction techniques analysis [START_REF] Monk | User-centred design[END_REF]. User tasks analyses are conducted to understand the tasks and to guide the choice of their associated interaction techniques [START_REF] Shepherd | Hta as a framework for task analysis[END_REF]. About the interaction techniques, it is possible to analyse the characteristics of all the interaction techniques available for one kind of task. To facilitate this analysis, taxonomies of VE interactions are usually used [25].

User task analysis

An analysis of the user tasks is required for an appropriate design of the VE interactions. Indeed, this analysis helps to understand the needs of the end-users in their future virtual environment, where they would realise their tasks. To perform such analysis, a possible approach presented in the literature is to develop and use taxonomies about human behaviours and human tasks. In this sense, Proctor et al. proposed a classification of the human information processing into three stages: the perception stage, the cognition stage and the action stage [START_REF] Proctor | Human factors in simple and complex systems[END_REF], as shown in Figure 2.17. This means that the humans perform complex tasks in response to external stimulus that initiate the following sequence:

they perceive information through their senses, then they analyse it in their brain, and finally they deliver a response via an action on the external world.

Figure 2.17: Three-stages human information processing when completing a task -Proctor et al. courtesy [START_REF] Proctor | Human factors in simple and complex systems[END_REF] Nonetheless, to analyse more deeply a task, it is necessary to classify not only the human behaviours but also all the possible human actions at the last stage of Proctor and et al. model. These actions can take multiple forms, and actually human actions are usually complex and composed by several sub-actions that address subtasks. To address this issue, for the specific field of the AEC industry, Dunston et al. proposed a hierarchical taxonomy of the AEC tasks [45] shown in Figure 2.18. This taxonomy proposes a characterisation of the tasks by main domain -level 1: construction, inspection, maintenance, training etc., then by operation -level 2: safety and disaster response situation, maintenance, build, inspection etc. and by activity -level 3: architecture planning, monitoring, assembly etc. Then, they proposed to another decomposition of the tasks, even finer, by splitting the activities into "low-level tasks" -low-level in terms of domain-specificity. This decomposition is done in two steps: first the tasks are decomposed into composite tasks (level 4), and then these composite tasks INTERACTIONS are divided into primitive tasks (level 5).

VE interaction techniques study

To design VE interactions, the existing VE interaction techniques must be understood and studied.

For this purpose, in the same way that the human tasks can be decomposed and placed into several categories, the VE interaction techniques can be classified. Addressing this issue, several studies in the literature proposed some taxonomies of VE interactions [23] [26] [129] [10]. Other studies, such as the one by Muhanna [START_REF] Muhanna | Virtual reality and the cave: Taxonomy, interaction challenges and research directions[END_REF], proposed some taxonomies about the VE systems, but it is important to note that these two kinds of taxonomies are totally different, since the later focuses on the technology that can be used to implement and use the interaction techniques rather than on the interactions techniques themselves. The interaction techniques taxonomies usually consider three main categories of interaction: the interactions of object selection, the ones of object manipulation and the ones of navigation in a space. This division into these categories is notably shared by Poupyrev et al. [START_REF] Poupyrev | Manipulating objects in virtual worlds: Categorization and empirical evaluation of interaction techniques[END_REF] with their taxonomies about selection and manipulation, or by Bowman et al. [23] [26] who considered all these three categories. In the same way, Argelaguet et al. [10] The other techniques are mainly some variants of these ones, for example using a bubble at the end of a pointer, as described in the review by Argelaguet et al [10]. About the exocentric metaphors, they particularly authorise a user to perform an action on an iconic, "fictive" or "smaller" (or bigger)

representation of an element present in the virtual environment or of the complete virtual world -like in the World In Miniature technique for example. anisomorphic [10]. The CD ratio is the ratio between the action done by the user in the "real world" and the action performed as a result in the "virtual world". If this ratio has 1 for its value, the technique is isomorphic and thus the action performed in the real world is the same -in terms of scale -that the action performed within the virtual environment. Otherwise, if the CD ratio has a value smaller or higher than 1, the technique is considered as anisomorphic, such as the go-go technique for INTERACTIONS example, thus in this case, the virtual movements are not equal to the movements done by the user and it allows the user to reach elements out of the range of its arm. manipulation VE interaction techniques respectively. It can be noticed that these three different taxonomies share common ways for classifying the interaction techniques. Indeed, the three taxonomies consider the user input/the input conditions are a main characteristic. They also consider the manner for choosing a target: "target selection" in the navigation taxonomy / "indication of object" in the selection and manipulation ones. It can be noted that the object position and the object orientation for the manipulation tend to be criteria that are similar to the selection of the velocity and/or the acceleration for the navigation. Indeed, this last navigation characteristic is the control that a user has on their movement, thus like the way to "manipulate ourselves", ourselves being the manipulated object. In this next chapter, we give our interpretation of these taxonomies, looking particularly to the sub-categories proposed here such as pointing versus touching etc. INTERACTIONS 2.7 User-centred design methodologies for VE interactions

We want to present here several studies issued from the literature that proposed user-centred methodologies to help for the design of the user interactions that are used within virtual environments.

Indeed, the issue of the process to follow to design VE user interactions has been studied in the literature, either from a generic point of view [25] [130], or in some cases from a specific-field point of view [35].

The research conducted by Gabbard et al. about the design of these interactions in virtual reality applications is of the greatest importance. They proposed a methodology for the user-centred design and evaluation of these virtual environments [57], visible in Figure 2.24. It should be highlighted that they aimed to give a generic technique, not specific to a field in particular.

Their methodology contains four main steps: 1) a user task analysis 2) an expert guidelines-based evaluation 3) a formative user-centred evaluation and 4) a summative comparative evaluation. It is important to specify that this methodology is iterative, thus each step is usually repeated several times, meaning that we could talk about a global process of several user task analyses, several expert evaluations, several formative evaluations and several summative comparative evaluations. Nonetheless, a key point is that this sequence aims to be followed in this order and not another one, for several reasons. The first reason is due to the fact that each step ensures that the following one can be done on a correct base. Indeed, for example the data obtained from user task analyses such as the kind of the task, its difficulty etc. are required before applying expert guidelines-based evaluations on a task -otherwise, we would not know which guidelines to follow. Then the second reason is that, about the three "evaluation steps" -here the steps 2, 3 and 4, Gabbard et al. specified that the order that they proposed has been thought to ensure a croissant order in terms of cost, time, specificity of the decision and precision of the choices. It means that the last step would appear as the one with the highest cost and time, and indeed this is the case this step requires the creation of prototypes and many users for testing. Thus, as this step has the highest level of specificity, the authors insisted that summative comparative evaluations need the results of the previous evaluation steps to ensure a useful comparison, in their terms "[to] compare good apples to good oranges rather than comparing possibly rotten apples to good oranges".

USER-CENTRED DESIGN METHODOLOGIES FOR VE INTERACTIONS

From a point of view specific to one field, Chen and Bowman proposed a user-centred design methodology to be used in the AEC context, still for the design of virtual environments [35]. In their study, before proposing their own approach, they explained what a conventional approach for a usercentred design of VE was as for them, as shown in Figure 2.25. They noted that the main of idea of these approaches was to first reduce the complexity and the specificity of a task from its application level to a generic level -calling it the top-down decomposition, and then to specify the design of the corresponding interactions at the same level of complexity and specificity -bottom-up specification.

Figure 2.25: A generic methodology to design 3D interaction techniques -Chen et al. courtesy [35] Even though they explained the benefits of these approaches, they nonetheless explained that these might be limited since such approaches could break users' workflow. This means that as for them this kind of methodology may lead to grant too much importance to the VR interactions instead of granting importance to the users' tasks themselves. As a result, they presented their own approach in contrast with these conventional generic approaches. Their methodology aimed to keep some generic elements, but also to take into account some domain-specific characteristics -in their terms "taking a middle ground" i.e. a place between generic aspects from VE and specific aspects from the application domain -to prevent the issue noticed about the lack of importance given to the tasks themselves. To summarise, the fact they considered domain-specific characteristics in their methodology is the main difference in their model, shown in Figure 2.26, in comparison to the model proposed in Figure 2.25.

The "domain-specificity" component of their methodology is notably reflected by the addition of an intermediary level called "domain-specific design" or domain level in the figure. This level allows the end-users to inject some domain-specific knowledge into the design process. This helps for the specifications of the VE interaction techniques in compliance with the requirements that are proper to

Conclusions

It has been shown that the use of BIM and the use of virtual environments can be beneficial during AEC projects. When BIM and mixed reality are combined, BIM-based virtual environment applications help the AEC professionals by improving their task performance. This has been shown for several kinds of AEC tasks and stakeholders. Nonetheless, these environments must be built according to the needs of the AEC end-users, and thus the design process of such VE must follow a specific design process.

This design process, and in particular the one for the interactions provided within a VE, may be complex; to address this issue, some methodologies have been proposed in the literature. These methodologies are user-centred design methodologies, and it can be noticed that these mainly rely 2.8. CONCLUSIONS on three components: 1) the analysis of the user tasks, 2) the expert evaluation and study of the possible interaction techniques, and 3) the user evaluations of the interaction techniques that have been prototyped. In the next chapter, we present some preliminary experiments that we ran on AEC case studies following the existing methodologies that are based on these three components for designing VE interaction techniques and applications.

Chapter 3

Experiments on user-centred design methodologies with AEC case studies

Objectives

We conducted here some experiments on several AEC case studies: we aimed to design VE applications by following the existing user-centred methodologies that contain these three main components:

1) the user task analysis, 2) the expert evaluation/study about the design of interaction techniques and of the application and the creation of VE prototypes, and 3) the user evaluations of the prototypes. Our objective here was to test these methodologies with the aim to understand how they could be improved, the main objective of our thesis being to study and propose ways to improve such methodologies for the design of VE interactions.

As a result, in this chapter, we present first the experiments that we made for two case studies, the first one about the supervision of a building construction of a real worksite, and the second one about the resolution of spatial inconsistencies in the design of a building. Then, based the results that we obtained, we explain the first approaches that we proposed in this research to improve the existing user-centred design methodologies, and we present how we applied it on another case study about architectural walkthroughs. To summarise, by experimenting on these case studies, we aimed to test these methodologies, and to find and present some possibilities of improvements about the design process that they propose.

Worksite construction supervision case study

Description of the case study

This case study focused on improving the supervision of a building construction of a real worksite [136]. Here, the main goal is to have a follow-up of the worksite, during the construction phase. This goal is usually pursued by the construction supervisor. It is possible to achieve this goal by comparing the state of the construction on the worksite with the expected progress in the scheduled planning, which can be available as BIM data in such AEC projects. This means that the main task associated to this goal is to compare these two different states, the real and the expected. To do that, a mixed reality application could be used by a construction supervisor to identify and report differences between the real state of the building in the worksite and the planned design, which can be represented through a 4D virtual mock-up (3D with time) [22] [START_REF] Sulankivi | 4d-bim for construction safety planning[END_REF]. Finally, it should be highlighted 3.2. WORKSITE CONSTRUCTION SUPERVISION CASE STUDY that finding such differences can have two different consequences: either it allows for the detection of errors present on the worksite and thus for the modification of the real building, or it allows for the detection of errors on the digital mock-up and thus for the update of this digital model, to be equivalent to the construction real state. A possibility for building such MR application would be to rely on the production of annotations in a MR environment composed of 3D digital models and videos from the worksite, and then to send the content of these annotations to the BIM model of the building, as shown in the Figure 3

Participants

Following the existing user-centred design methodologies, AEC professionals' participants were necessary both for designing the MR application and for evaluating it. According to the task performed here, participants who have a role of construction supervisor were necessary for this case study. First, about the designing, a sample of construction supervisors -for example, we asked to a pair of supervisors in this case study -was notably required for the user task analysis, and for collaborating in the decision-making about the interaction design choices. Then, a larger sample of supervisors was required in order to conduct a user evaluation on the usability of the MR application. In our user experiment, 32 civil engineers and civil engineering students participated, with an average age of 22.7.

User task analysis

A user task analysis can be conducted on the main task of this construction supervision case study, which is to compare the as-planned and the as-built states of the building. According to user-centred design methodologies [57] [35], such analysis implicates doing a hierarchical decomposition of this task into subtasks, until decomposing is unnecessary. We did this decomposition in collaboration with the two construction supervisors who participated in this phase.

We built the following decomposition: the main task could be divided into two subtasks, to detect differences between the videos issued from the drone and the BIM 3D model, and to report these differences for future corrections. Then, we proposed to divide the detection subtask into "to search zones with differences" and "to identify zones with differences", and to divide the reporting subtask into "to annotate the issues identified" and "to transmit the issues for correction". Finally, we proposed to divide the action of searching into moving in the virtual worksite and observing the zones, the action of identifying into observing differences in a zone and deciding if errors are present, the action of annotating into choosing an annotation tool and using it, and the action of transmitting the issues into checking mentally if complete and pressing the validation tool. Figure 3.2 shows this proposal of hierarchical decomposition, which is the result of the user task analysis.

WORKSITE CONSTRUCTION SUPERVISION CASE STUDY

About the user task analysis, the two construction supervisors noted that, without having task analysis expertise, it was difficult to estimate when decomposing would become unnecessary and thus when the decomposition could be stopped. Moreover, they had difficulties in dividing its task progressively, following different levels of decomposition, and in finding adequate words to express the subtasks. They concluded that having expertise on task analysis was required to follow this user task analysis process, in these conditions -for this decomposition, our participation to the decomposition contributed to "provide" such expertise, allowing thus for obtaining this result.

Expert study, guidelines, and prototyping

First, data about the real state of the building on the worksite and data about its planned state were necessary to be able to build this MR application. For our prototype, the following data were available: about the first kind of data -real state, we had videos of the building on the worksite, collected by a drone in several zones of interest, at a specific time of the construction planning. About the second kind of data -planned state, we had some 3D models, extracted from the 4D BIM scheduling of the building, taken at the same time in the construction planning than the real time.

Based on that, in the prototype that we developed, we used these two data sources, and to be able to observe differences between the two states, the videos issued from the drone were available in some zones of the 3D model, and, in these videos, some virtual elements were superimposed at some frames. This prototype was built for performing an off-site supervision; nonetheless, here the videos were recorded with the drone first, and then used in the application, instead of using a live stream. Figure 3.3 shows a global view from the MR prototype, which displays the external view of the building, which was used to navigate like the drone.

WORKSITE CONSTRUCTION SUPERVISION CASE STUDY

Then, about the user interactions, it must be highlighted that our MR application has been prototyped as a desktop application here. This was due to the fact that the requirement about the prototype with the highest priority for the constructor supervisor was to be able to test how the content of the annotations could be sent to the BIM software they used. It was thus easier to transfer this content in a unique device with the BIM software and the MR prototype installed in. As a result, the virtual environment of this MR prototype was not immersive, and the available props were the mouse and the keyboard.

Nonetheless, the expert evaluation and study about the user interaction techniques was still necessary. Based on the user task analysis, two main interactions were required here: moving in the virtual worksite, and using an annotation tool. For the last one, the fact that the MR prototype was a desktop application induced the use of the mouse for selecting a zone, and activating the annotation mode, and the keyboard for writing the content of the annotations. Based on our VR expertise, we proposed to use a flying interaction technique, where the user had the control of the target, among a restricted amount of available points, but did not have the control

WORKSITE CONSTRUCTION SUPERVISION CASE STUDY

of its velocity. This choice was motivated by several facts: in the external view of the building, it was not possible to display real data from the videos, thus the velocity control seemed to be not necessary; the videos had been taken only on some zones of interest, thus it was possible to offer a restricted zone of movements, and to let the users choosing the next direction between these different points. Figure 3.5 shows two points (cubes here) between which a user could navigate using the flying interaction technique. We ran here a user experiment with our 32 participants to evaluate the usability of our MR prototype. They had to perform the following actions: first, to move around the 3D model of the building using the navigation with the cubes, then to watch a video on a point of interest, to observe the superimposition of some 3D model elements and the video, and finally to use the annotation tool to write annotations, which were then exported to a BIM software that contains the 3D model of the building. In this experiment, we did not measure the usability aspect of the user task performance, but we measure the usability aspect of the user preference or user satisfaction. To do that, we collected subjective data thanks to a post-experiment questionnaire, allowing thus for an evaluation of the usability, but also of the benefits of the MR application. The results of this questionnaire are available in Figure 3.6 and the questions asked were the following ones:

WORKSITE CONSTRUCTION SUPERVISION CASE STUDY

• Q1: Is the application useful for supervision of construction?

• Q2: Is the application easy to use?

• Q3: Is the application clear enough to interact with it?

• Q4: Could other experts than you easily use this application too?

• Q5: Was it clear how to realise and follow the instructions?

• Q6: Did the app allow me to get a good overview of the building?

• Q7: Was it easy to move around the building in the application?

• Q8: Was it easy to watch videos about some building zones?

• Q9: Was it easy to detect worksite differences/defects in the application?

• Q10: Was it easy to annotate defects/errors in the application?

• Q11: Was it easy to transfer and see the annotations made in MR, into your BIM software? Regarding the results, it should be highlighted first that for all the questions, 80% or more of the participants gave a neutral or positive grade -4 (neutral) and above on this Likert scale. Thus, this means that globally this MR application satisfied the users for performing an off-site construction supervision task, based on the use of BIM data and drone videos.

Then, we must analyse in particular the results obtained for the question Q7, since this is the question about the navigation interaction. 18% of participants rated it with a neutral or negative grade, which makes it belonging to the questions with "most" negative grades between the elements.

In the comments given by the users, they noticed the flying technique was useful and allowed for a correct immersion "as a drone" on the "mixed worksite", but the fact that the area available to be selected for moving was restricted to some points could be frustrating. These results and comments could show a potential limitation of the design process, which is based on expert evaluation and expert study in the existing user-centred design methodologies. This suggest that a determination of the interaction techniques truly guided or eventually made by the end-users themselves rather than by the VE experts could avoid such feedback given by the end-users.

Clash resolution during design coordination case study

Description of the case study

This case study focused on one particular aspect of the design reviews: the design clashes. Typically, a design clash between several elements occur when an element is misplaced, and enters in collision with another one [170]. They are called design clashes since they happen during the design phase of the building life cycle. During this phase, each AEC professional virtually creates the future building elements, such as walls or plumbing, according to their specialisation. A common method consists of modelling the elements independently, per discipline, and then in coordinating everything in a unique model. This method has been validated by Grytting et al. and they explained some of its advantages [65]. However, a major drawback and challenge is that following this approach requires a step of design coordination, which implies substantial work in the detection and the solving of spatial inconsistencies, called above design clashes. Figure 3.7 shows two examples of clashes that can appear during this step of design coordination.

CLASH RESOLUTION DURING DESIGN COORDINATION CASE STUDY

About the design clashes issues, two main tasks exist for the BIM coordinator: the detection of clashes, and the analysis and resolution of the clashes previously detected. It is important to notice that, on one hand, the detection of clashes has been improved a lot on the last years, thanks to BIM software, which automatically finds clashes, based on rules defined by the coordinators [49] [150].

However, on the other hand, clash analysis and clash resolution still remain on full human decisionmaking [16]. These tasks are currently done on software such as Autodesk Navisworks Manage on computers on desktop screens, by adding notes on 2D pictures of the 3D models. Thus, the clash resolution task is a main task related to the design clashes, not currently fully improved thanks to BIM software, and which could be perform better in a virtual environment. Thus, it was a foregone conclusion to choose as the task to be studied in this case study the clash resolution task for design coordination [START_REF] Raimbaud | A virtual reality and bim approach for clash resolution[END_REF].

Participants

Following the existing user-centred design methodologies, AEC professionals participants were necessary in this case study for both designing the VR application that allows for the design coordination task identified here and for evaluating this application. According to the nature of this task, participants who have a role of BIM coordinator were necessary for this case study. First, about the designing, the two BIM coordinators in charge of the coordination of the construction studied here participated to the user task analysis, and collaborated in the decision-making about the interaction design choices. Then, a larger sample of BIM coordinators participated in a user evaluation on the usability of our VR application. In this user experiment, eight users solved design clashes, with an average age of 22.6 (+/-1.06).

User task analysis

A user task analysis can be conducted on the clash resolution task of this design clash case study.

Doing this analysis consists of performing a hierarchical decomposition of this task into subtasks, until dividing becomes unnecessary [35] [57]. This decomposition has been made with the two BIM coordinators who participated in this phase.

Our discussion resulted in the following decomposition: the main task could be divided into two subtasks, to understand the clash -already automatically detected via a BIM software, and to provide a solution to this clash. Then, we proposed to divide the "understanding subtask" into "to check the issues between the elements involved in the clashes", and "to imagine a solution to this clash", and to divide the subtask about providing a solution into "to annotate the solution on the clash zone" and "to transmit the solution proposed for correction in BIM software". Finally, we proposed to divide the action of checking the issues into moving close and around the clash, observing the clash, and studying the elements involved, the action of imagining a solution into observing the clash and analysing it, the action of annotating into choosing an annotation tool and using it, and the action of transmitting the issues into doing a last mental check and pressing the validation tool. Figure 3.8 shows this proposal of hierarchical decomposition, which is the result of the user task analysis. for us to guide this decomposition, and to propose verbs that were adequate for each subtask.

Expert study, guidelines, and prototyping

First, to build a VR application for this case study, 3D models, coming from BIM design software, were necessary. Moreover, it was necessary to launch an automatic detection of clashes on these models, to detect and choose relevant design clashes to highlight in the application. These data represented the VR content required to build the VR application. The user interactions could be designed then.

Based on the user task analysis, two main interactions were required here: moving close to the clashes, and using an annotation tool. About the navigation interaction, to come close to the clashes, natural walking interaction technique has been chosen for two reasons: 1) the amount of movements were limited for the building and the clashes chosen -only the scale of a small room was necessary, and 2) as the clashes were already detected and highlighted in the environment, the users did not have to explore and search for the clashes. However, for the annotation action, it was possible study and evaluate all the possible interaction techniques. Following the taxonomy by Poupyrev et al. [START_REF] Poupyrev | Manipulating objects in virtual worlds: Categorization and empirical evaluation of interaction techniques[END_REF],

different ways could be used to select and manipulate a target. Based on VR expertise knowledge, the virtual pointer metaphor has been chosen. This choice was mainly motivated by the following facts: due to the nature of the annotation task, the exocentric metaphors, such as automatic scaling or world-in-miniature, had been rejected, and the hand metaphor seemed to offer less flexibility for switching between annotations on elements close and far to the user. Figure 3.9 shows a user using an annotation tool with a raycast-based pointing interaction technique. Once our application was ready to be used, following the user-centred design methodologies, it was necessary to evaluate its usability, and, for this purpose, we ran a user experiment. Thus, this user evaluation aimed for the usability evaluation of the application, for the task in its entirety -and not for a particular subtask such as the manipulation of the annotation tools for example, as suggested in the user-centred design methodologies. Additionally, this user evaluation also aimed to evaluate the benefits of using this kind of immersive environment, compared to the use of a 2D desktop software, for performing the same clash resolution task.

Both aspects of the usability were evaluated here: the user task performance aspect of usability, considering the global task performance of clash resolution here, and the user preference / user satisfaction. For the user task performance, we collected data from two measures, the task completion time, and the quality of the solutions to the clashes through a grade given by an expert of design coordination. For the user preference, subjective opinions were collected thanks to a post-experiment questionnaire.

We conducted here a user evaluation with our eight participants. About the experimental protocol, the participants had to observe two clashes in this experiment -clash A and clash B, then to understand them, to conceive mentally a solution, and to annotate such solution. They had to perform this task once in our VE application -named 3D VR afterwards, and once in the traditional 2D desktop screen software -named 2D screen afterwards. Both applications relied on the same 3D BIM models, but provided by their nature two different kinds of environments. Finally, thanks to the within-subjects design applied here, we obtained sixteen results in total, allowing thus for a greater analysis.

Results

About the measures for the task performance, task completion time was measured directly within the applications, whereas the quality of the solution was evaluated after the experiment, through a grade from zero to ten given by an expert of design coordination. Task completion time results are available in Figure 3.10 and in Table 3.1, whereas quality of the solutions results are shown in About the user satisfaction, the data about the VR application opinions were collected through eleven questions, whose answers were based on a Likert scale from 1 to 7. The results of this postexperiment questionnaire are shown in Figure 3.12, and here is the list of questions:

• Q1: The application is useful for reviewing clashes.

• Q2: The application is globally easy to use.

• Q3: The application is particularly useful for getting an idea of the volumes. 86

CLASH RESOLUTION DURING DESIGN COORDINATION CASE STUDY

• Q4: The application is particularly useful for changing my point of view in 3D.

• Q5: The application is useful for thinking about a solution for a clash.

• Q6: The application is useful for designing and representing my solution in 3D.

• Q7: The application allows me to do the task quickly.

• Q8: The application allows me to do the task correctly.

• Q9: I think I could do the task better with more training with VR headsets.

• Q10: I think that the use of such devices for doing longer reviews would NOT cause fatigue.

• Q11: The grade I give to my VR experience of today compared to the one in Navisworks is:

Discussion

About the task performance results, it can be noted first in Table 3.1 that a trend appears when comparing the task completion time results in the traditional 2D screen tool to the 3D VR application. 87

CLASH RESOLUTION DURING DESIGN COORDINATION CASE STUDY

For both clashes, the users spent on average less time in the VR application than in the traditional tool.

For case A, the time spent is 61% lower in the 3D VR application than in the 2D screen software, for case B it is 31% lower, and considering both cases, the average time spent is 47% lower with our 3D VR application. About the quality of the solutions results, as visible in Table 3.2, no clear trend appears since for the case A the average grade is 53% lower with our application than with the traditional tool, but 29% higher for case B.

Moreover, a statistical analysis can be done on these results, organised into two datasets of both sixteen rows, on for the task completion time data and one for the quality of the solution data. It should be highlighted that the data followed a normal distribution in each dataset. This has been ensured by applying the Shapiro-Wilk's test on them, which returned 0.85 and 0.56 as p-values for the task completion time dataset and the quality dataset respectively, thus both higher than a level of significance of α=0.05. Additionally, the Levene's test was applied on each dataset, and returned pvalues of 0.88 and 0.70, for the task completion time dataset and the quality dataset respectively. This showed the homogeneity of the variance between the scenarios on a level of significance of α=0.05.

Moreover, since the observed factors were the nature of the tool used (VR application or desktop software) and the clash case (A or B), both were independent. According to the validation of these required assumptions, we ran a two-way repeated measures ANOVA on each dataset with the factors "Nature of the tool" and "Clash case".

The ANOVA on the task completion time dataset confirmed the results observed graphically, since it revealed that the factor "Nature of the tool" does have a significant effect on the completion time with a p-value of 0.045 on a level of significance of α=0.05. The other ANOVA on the quality of solution dataset also confirmed the results observed graphically, since it revealed that the factor "Nature of the tool" does not have a significant effect on the quality of solution with a p-value of 0.69 on a level of significance of α=0.05. However, this last result from this preliminary experiment should not be considered as definitive about the quality of the solution results, since the statistical analysis revealed a significant effect of the clash case for this measure with a p-value of 0.019 on a level of significance of α=0.05. This means that the clash cases used here had a non-expected effect on the results for this measure, whereas this was not the case for the task completion time measure with a p-value of 0.25 on a level of significance of α=0.05.

About the results from the post-experiment questionnaire, the VR application globally received METHODOLOGIES very positive opinions from the users. The "worst" rated questions mostly received less than 20% of negative or neutral grades as answers, except for the questions Q10 about the potential fatigue issues in further experiments with longer design reviews, thus not directly about this experiment in particular. About the question Q6, which was about the manipulation of the annotation tools, all the grades received were neutral or positive, thus it seems that the interaction technique chosen was appropriate here.

To conclude, this user evaluation showed that virtual environments do allow for an improvement of the user task performance, compared to 2D desktop environments, at least in terms of time -in terms of quality, it could not have been shown here. It seems thus that, about the performance aspect of usability, the application has been designed appropriately, and about the preference aspect, the application also received positive results. Nonetheless, other user evaluations could be conducted to evaluate different interaction techniques for annotating in VR, to confirm such results.

3.4 First approaches to improve the user-centred design methodologies

Observations from the preceding case studies and proposals

The studies and experiments conducted on the two preceding case studies confirmed the benefits of VE for performing AEC tasks, as expected. However, about the use of user-centred design methodologies for designing the virtual environments for these cases, they revealed some issues present in the existing methodologies, which we followed here. We noted two main issues: 1) the difficulty that the AEC experts had in analysing and decomposing their task, and 2) the lack of accessibility for the AEC experts to contribute to the determination of the design of the virtual environments and its interactions. These issues could be traduced into two possible points of improvements: 1) to improve the formalisation of the AEC users' needs, by assisting them for the user task analysis, and 2) to improve their participation in the determination of the design of the VE application, to make them become the main guide and actor of this decision-making and study.

In this sense, we proposed a first approach for a new user-centred methodology for the design of virtual environments that address AEC needs, with a focus on the two points of improvements mentioned above, related to both the users and the needs associated to their tasks. This approach [START_REF] Raimbaud | Smart adaptation of bim for virtual reality, depending on building project actors' needs: The nursery case[END_REF] 3.4. FIRST APPROACHES TO IMPROVE THE USER-CENTRED DESIGN METHODOLOGIES is represented in Figure 3.13. Based on this approach, the existing user-centred design methodologies could be modified, and be improved on their aspect related to the user task, and the possibilities for the domain-specific experts to be implicated into the study of more components of the design process of a VE application, particularly on choosing the visualisations and the user interactions.

Figure 3.13: Our first approach to improve the methodology for the design of virtual environments that use BIM data [START_REF] Raimbaud | Smart adaptation of bim for virtual reality, depending on building project actors' needs: The nursery case[END_REF]

Application to the architectural walkthrough case study

This case study took place in a project of renovation and transformation of an old covered market into a nursery construction [START_REF] Raimbaud | Smart adaptation of bim for virtual reality, depending on building project actors' needs: The nursery case[END_REF]. A division of the council, dedicated to the town planning of the city, was responsible of reviewing the architecture of the building that had been proposed in the project.

Thus, the architect in charge of this construction had to perform an architectural walkthrough task:

this task is the one studied in this case study.

To build a VR prototype, we proposed here to follow the two improvements that we mentioned above: first, to assist the architect for the user task analysis thanks to a more-systematic approach, and then to improve the participation of the architect in the determination of the design of the VE interactions.

First, for the task analysis, we provided to the architect a list of verbs that define the possible tasks and interactions that someone may have to do to achieve AEC or generic goals -explore, check, annotate etc. The architectural walkthrough main task has been divided by the architect, without our help, into two subtasks: to seek for issues in the design, and to signal them. The subtask "seek for issues" has been divided into "to explore the different rooms of the building", and "to identify issues

FIRST APPROACHES TO IMPROVE THE USER-CENTRED DESIGN METHODOLOGIES

in the design". The exploring task has been divided then into deciding of moving and moving from a room to another, and the identifying task into observing the design of each room, analysing this design, and deciding when an issue is present. And the subtask "signal the issues" has been divided into "mark a design issue" and "notify the issue", which have been divided then respectively into "choosing a marker tool" and "place a marker", and in "decide if the issue is relevant" and "send the issue for future correction". We noticed that providing such content did help the architect, notably for formalising their ideas; nonetheless, we noted that we could improve this help to improve the logical hierarchical link between the different levels of decomposition. techniques to use, we asked several questions to the architect, about the kinds of distances that would be necessary to travel during the architectural walkthrough, and its objectives during this travel. Then, we explained them which navigation techniques exist and their benefits or drawbacks according the answers to the previous questions, e.g. that a steering technique would be slower than a teleportation technique, whereas a teleportation technique would made them "skip" some parts of the building etc. 91

CONCLUSIONS

Based on these explanations, the architect has been able to link its needs with some navigation interaction techniques: they proposed to use a teleportation technique, with restricted areas for moving.

This choice was justified since the architect wanted to perform an architectural walkthrough between some predetermined rooms, going from a point of interest to another one. Figure 3.15 shows how this navigation interaction technique could be prototyped. Finally, we aim here to conclude about the benefits of applying our first approaches on this architectural walkthrough case study. We noted that by asking the questions that we asked to the architect, about the aims and the characteristics of each task, such as the kind of distances to travel, and by giving then the information that we gave to the architect according to the answers given about these characteristics, the architect was able to make decision autonomously about the VE interaction techniques that would be appropriate to use, in terms of usability, for the navigation interaction here.

These results encouraged us to improve our first approaches, applied in this case study through a different kind of discussion between a VR expert and an AEC expert, with the aim of making possible for the architect to make decisions in autonomy.

Conclusions

These first experiments on AEC case studies have revealed some potential issues when designing VE applications and particularly VE interaction techniques. It seemed that the existing user-centred methodologies could be improved, notably for allowing and helping the AEC experts to perform their user task analysis and to study the possibilities for the VE interaction techniques to use in their application. One main objective would be to modify the existing approaches to make them become 92 3.5. CONCLUSIONS possible to be used by the AEC experts -and other domain-specific experts, without the need of having VE expertise.

Nonetheless, these empirical results and users' feedback must be completed with an analytical reading of these existing user-centred design methodologies, and if the issues are confirmed and formalised, to be also followed by a concrete proposal of improvements. BIM and mixed reality technologies can be combined and result in virtual environments that are provided to the stakeholders of AEC projects. In many studies, it has been shown that these VE, whose content is issued from BIM data like 3D models, can improve some construction processes, following in that sense the same objective that the BIM methodology does [66]. In most of the studies, it can be noticed that these VE applications have been designed to address specific issues and to allow specific kinds of AEC stakeholders to complete one or several tasks that they must perform [22] [89] [START_REF] Rahimian | Integrating bim and augmented reality for interactive architectural visualisation[END_REF].

Moreover, it can be noticed that these applications are usually designed with the objective of improving the user task performance -i.e. to make the users performing the task either faster, or better by doing it earlier in the building life cycle or by doing it in a more collaborative way -thanks to the benefits that provide the designed VEs [START_REF] Shi | A multiuser shared virtual environment for facility management[END_REF]. Appropriate designs of the user interactions in terms of usability are necessary to provide such benefits; nonetheless, it may be complex to make these design choices.

Additionally, the measures must have been selected according to the task [34] for the evaluations also, in order to be able to show VE benefits in terms of task performance.

For this purpose, several studies [57] [25] [35] recommend to perform two kinds of analyses, one on the user tasks and one on the interaction techniques. In other terms, these studies insist on the fact that having knowledge about these two concepts is required for designing appropriately some VE interactions. User task analysis [START_REF] Proctor | Human factors in simple and complex systems[END_REF] and interaction techniques taxonomies [26] [23] contribute to understand the users' needs and the different categories of tasks and interaction techniques.

Relying on these taxonomies, user-centred design methodologies to create virtual environmentsand more precisely about the design of VE interactions -have been developed in the literature. Tasks analysis, interaction techniques classification, VE expertise and end-users evaluations are components that appear in all these methodologies [57] [25] [35]. Some of them aimed to be generic [57] [25], whereas others aimed to have a "domain-specific" component in their approach [35]. This can lead to some differences between the existing methodologies, but their main concern is always the understanding of both the original domain-specific user tasks and the possible VE interaction techniques. Moreover, another main concern is to find a way to succeed in linking these two kinds of knowledge, to select an appropriate interaction technique in terms of usability, and the reliability of such association. About the first component (A), the user task analysis in step 1, in this methodology, it can be observed that this implies the description of the sequences of tasks, the decomposition of the task, and the description of eventual dependencies between subtasks. Nonetheless, as explained in their study, Gabbard et al. propose to the users of this methodology to do these actions through a hierarchical task analysis (HTA), since it has been shown that this approach allows for the decomposition and abstraction of a main task into subtasks by Annett et al. [9]. Task analysis is defined as an "analytical process employed to determine the specific behaviours required of people when operating equipment or doing work" by the norm ISO 11064-3:1999; as a result, a hierarchical task analysis consists of 4.1. RESEARCH PROBLEM performing this analytical process by following or establishing a hierarchy during this analysis. Nonetheless, to be able to do a traditional hierarchical task analysis [9] , this requires abilities for task decomposition and for writing detailed specifications [8]. Indeed, Ormerod et al. noted this issue for being able to perform this kind of analysis [START_REF] Ormerod | Using task analysis for information requirements specification: the sub-goal template (sgt) method[END_REF]. To address this issue, we think that the HTA process could be improved by providing some help during the HTA, by guiding the decomposition and the establishment of different levels in a hierarchy.

Then, about the expert guidelines-based evaluations in the step 2, we agree that this VR expertise is required for choosing the appropriate interaction techniques to be prototyped (component B) and evaluated afterwards. Nonetheless, in Gabbard et al. methodology, this implies the presence of VR experts: we think this could be improved with the aim of retiring this need in this first phase of decision-making about the VR interaction techniques. Some guidelines, given in this methodology by the experts, could be provided through a semi-automated system, and thus the VR experts would be required later in the design process.

Finally, about the user evaluations (component C), divided here into formative user evaluations -step 3 -and comparative summative evaluation -step 4, Gabbard et al. explain that in their methodology the formative evaluations allow for preliminary or coarse decisions whereas summative comparative evaluations allow for the evaluations of specific design possibilities for one interaction.

One possible improvement would be to reduce the number of required evaluations. This would be possible as a consequence of the reduction of the number of iterations during the design process. about this domain level and the use of the domain-specific knowledge provided in this level. First, this knowledge has improved the top-down decomposition (A) a lot; however, this is much less the case for the bottom-up specification process (B). We think that the component B "interaction techniques study" could be improved and benefit more from this domain-specific information, for example by guiding the choices about the interaction techniques depending on both the intrinsic characteristics and the domain-specific context of the subtask that is related to this interaction.

Statements about existing user-centred design methodologies for VEs

Based on these analyses, we think that two main aspects could be improved in these methodologies:

1) the user task analysis could be transformed to be accessible to people that are non-expert in writing specifications and task decomposition in particular, and 2) the interaction technique study could be modified to become possible even to people non-expert in VR, to obtain proposals of appropriate interaction techniques in terms of usability, before asking to a VE expert to propose some prototypes of VE applications. As a summary of the research problem and as an introduction to the research issues developed in the next subsection, Figure 4.4 shows these two possible improvements, found thanks to our analyses and which were also marked in orange in the previous Figures 4. 2

Conclusions about the research problem and research issues

As previous studies have shown it, virtual environments are beneficial for the stakeholders of AEC projects, and in particular, they can contribute to improve the user task performance. Nonetheless, these environments are usually built to allow their users to address specific issues, and, as a result, they must be designed according to these issues. This means that they must be designed according to the tasks performed by the users and the context of these tasks. Thus, the design of the user interactions in these virtual environments is a research issue and, to address it, some user-centred design methodologies have been developed in the literature. Here we want to summarise the different observations and deductions that we made thanks to our analysis of the existing user-centred design methodologies. We made two main observations, which lead to two main research issues that we want to explain afterwards.

First, we observed that user task analyses are required in this kind of methodology, and have given interesting results by allowing a separation of the required functionalities from the initial task and by allowing drawing up a list of the required interactions. Nonetheless, in the existing methodologies, the user task analyses, which are done through the use of hierarchical task analysis [9] [8], appear as hard to be completed by a non-expert in writing specifications and decomposing task. Indeed, in these methodologies, they must be done without be guided or helped, and thus they must be done by people that have task analysis expertise. We think that, on the contrary, it would be interesting if the domain-specific experts could do this analysis autonomously and obtain results that are similar to the ones got by people with such analysis expertise. The fact that this analysis cannot be done by domain-specific experts who do not have task analysis expertise, is the first issue we noted.

Then, after having obtained the specifications from a domain-specific point of view -i.e. the 4.2. RESEARCH QUESTIONS domain-specific required functionalities, and the specifications that link the domain-specific to the VR -i.e. the list of the required interactions -thanks to the user task analysis, it is necessary to obtain the VR specifications -i.e. the appropriate VR interaction techniques. For this purpose, the current approach is to perform a step of "expert guidelines, expert evaluations" as it is called in Gabbard's methodology [57]. This kind of step allows for the determination of appropriate VR interaction techniques, reinforced then two other steps of user evaluations here. Nonetheless, we noticed an issue here: the dependency to the VR expertise during the first step of interaction techniques study, since this step is based on expert choices given by a VR expert. Indeed, it could be interesting to increase the importance of the domain-specific experts, and to reduce the need of VR experts during this step.

It could also be interesting to follow a methodological guide for the design of the VR interactions. As a result, a study of the possible interaction techniques, even as a draft study, should be possible by the domain-specific experts before asking to a VR expert. This current lack of accessibility of ways to perform a study of the available interaction techniques by the domain-specific experts, for determining the interaction techniques that can be used, similar to the ones proposed by a VR expert, is the second issue we noticed.

Research questions

Based on the analysis of the existing user-centred design methodologies, we stated two (sub) research issues about the research topic of the design of VE interactions : 1) the need of having task analysis expertise to obtain the domain-specific specifications that are required for the design of the VE, 2) a lack of accessibility of the study of VE interaction techniques by the domain-specific experts, due to the need of having VE expertise to determine VE interaction techniques that are appropriate in terms of usability. These research issues may lead to the following research questions:

• Q1: How to allow the domain-specific experts to obtain the specifications that are related to the domain-specific tasks performed in the VE and that are required for the design of the VE interactions?

• Q2: How to allow the domain-specific experts, who do not have VE expertise, to determine the VE interaction techniques that are appropriate to use in their VE, in terms of usability and according to their task? 4.3. HYPOTHESES

Hypotheses

Based on these two research questions, we propose the three following hypotheses:

• Global hypothesis H0: A task-centred design methodology can be used by domain-specific (AEC here) experts, in autonomy and without having VR expertise, and would allow for the obtaining of results that are similar to the ones obtained with a traditional user-centred design methodology Criteria of evaluation: the methodology and its associated system are 1) usable by domain-specific (AEC here) experts, 2) autonomously, and 3) allow for the obtaining of results that are similar than with a traditional user-centred design methodology (boolean values for all these criteria)

• Hypothesis H1: A semi-automated system for decomposing a user domain-specific task can help a domain-specific (AEC here) expert to obtain task specifications that are similar to the ones obtained through a traditional meeting with a VR expert Criterion of evaluation: the results obtained with this semi-automated system used for the task decomposition are similar to the ones obtained with a traditional methodology (boolean values)

• Hypothesis H2: A semi-automated system can help a domain-specific (AEC here) expert to determinate VR interaction techniques that are similar to the ones defined through a traditional meeting with a VR expert Criterion of evaluation: the results obtained with this semi-automated system used for the determination of proposals of VR interaction techniques are similar to the ones obtained with a traditional methodology (boolean values)

About the possible values for the criteria, we propose the following values (boolean values):

• for the criterion usable by domain-specific experts: usable / not usable

• for the criterion of autonomy: in autonomy / not in autonomy

• for the criterion of similarity: similar / not similar Additionally, two other criteria could be considered about the evaluation of our methodology:

RESEARCH SCOPE

• The exhaustiveness of the methodology: results can be obtained with the methodology for any case study, considering all the possibilities for both the task decomposition and the determination of proposals of VR interaction techniques

• The robustness of the methodology over the time and the future VE technologies: the results obtained with the methodology could be used and would be valid even for future technologies

Research scope

Our research, presented in this document, aims to explain the current issues about the design of VE interactions and to present our new task-centred design methodology to address these issues, based on the research questions and the hypotheses we explained. It should be highlighted that this methodology could be used in a generic way, but all our examples and all the user tasks analysed during this research concern the AEC industry. In this way, all our case studies have also been selected according to gaps present in the AEC literature, and our research aimed to propose and evaluate innovative solutions for these case studies. Additionally, most of our VE solutions for these case studies aimed to be developed with the virtual reality technology here, more much than in augmented reality for example. In the next chapters, we present our methodology and our experiments on different AEC case studies.

Chapter 5

Methodology Contenu

OVERVIEW OF OUR METHODOLOGY AND OF ITS STEPS

5.1 Overview of our methodology and of its steps

Origins of our methodology

A user-centred or a (user) task-centred methodology for designing virtual environments aims to help for making design choices about a virtual environment according to the users' needs [35] [57], as shown in the section 2.7. This means thus that, in both kinds of methodologies, the user has a key role for making the design choices and for conducting the evaluation of this design. A task-centred design methodology could improve the fact of considering the user tasks to make design choices. In other terms, this kind of methodology could particularly reinforce the link between the characteristics of the user tasks and the design of the user interactions. Indeed, it is expected that this kind of methodology could help for the choice of the VE interaction techniques that are provided to the users, and thus they should help for finding appropriate -in terms of usability -interaction techniques, which thus notably increase the user task performance.

Based on our analysis of the existing methodologies and their potential lacks in the section 4.1.2, we determined some research questions about these issues, and, to address them, we built several hypotheses, available in the same chapter in the section 4.3. These hypotheses lead us to think about some axes of improvement that could be applied in a new task-centred design methodology.

First, our hypothesis H1 suggests that the user hierarchical task analysis could be modified and become possible to be done using a semi-automated system, and done in autonomy by people that are not expert in task analysis. As a result, we propose in our task-centred design methodology a stepour step 1 -for building a model of the domain-specific user task, through a semi-automated system that has been designed for people that are non-expert in task analysis and in writing specifications.

This step is based on the semantic of the human actions and task classification. According to H1, this semi-automated system for task decomposition must be usable by the domain-specific experts, in autonomy, and must allow for the obtaining of results that are similar to the ones obtained with a traditional user-centred methodology: this would be evaluated in an experiment presented in the chapter 6.

Then, the hypothesis H2 suggests that proposals of VR interaction techniques could be determined by domain-specific experts using a semi-automated system, in autonomy, without having VR expertise.

Thus, we propose here a step -our step 2 -of determination of such proposals thanks to a semi-

OVERVIEW OF OUR METHODOLOGY AND OF ITS STEPS

automated system that contains VR knowledge and guidelines from previous scientific studies and reviews, recollected and compiled as deduction rules. According to H2, this semi-automated system for determining these proposals must be usable by the domain-specific experts, in autonomy, and must allow for the obtaining of results that are similar to the ones obtained with a traditional user-centred methodology: this would be evaluated in an experiment presented in the chapter 6.

To conclude, these two hypotheses H1 and H2, summarised by our global hypothesis H0, led us to propose in this research our task-centred methodology with its semi-automated systems, which must respect three criteria: to be usable by the domain-specific users, to be usable in autonomy and to provide results that are similar to the ones obtained with a traditional user-centred methodology.

This would be evaluated and shown in the chapter 6 by an experiment on two AEC case studies.

Steps of our methodology

To address the research questions raised in the previous chapter and based on our hypotheses, we built a new task-centred design methodology for designing the interactions provided to the users in a VE application. Based on the processes that have been proposed and used in the literature for the design of VE interactions [35] [57] [25], we created our methodology with the aim of respecting our evaluation criteria and of proposing a methodology that offers the benefits of being performed by the domain-specific experts, without having VR expertise nor requiring VR experts, except for the development and testing of the VE applications. Figure 5.1 presents our methodology in its entirety, and shows the steps that compose it:

• Step 1 -build a model of the domain-specific task

• Step 2 -

determine proposals of VR interaction techniques

• Step 3 -create VR applications prototypes and run user evaluations

OVERVIEW OF OUR METHODOLOGY AND OF ITS STEPS

The step 1 allows for the construction of a model of the domain-specific task -a task that belongs to the field of the users e.g. construction supervision for AEC users -that the users want to perform in the virtual environment. This step relies on the objective of obtaining from this original domainspecific task some primitive subtasks, a primitive task being here a task that cannot be divided into subtasks when performing this step 1.This can be done through the decomposition and the abstraction of the original domain-specific main task. Human information processing knowledge, from Proctor et al. [START_REF] Proctor | Human factors in simple and complex systems[END_REF], and a taxonomy of AEC tasks, from Dunston et al. [45], have been inspiring to build our own approach. Indeed, it was important to understand how a human proceeds with a task, and how the AEC tasks may be classified, before building our own approach that focuses on a decomposition through the semantic of the words used for describing a task and its subtask. We propose here a new approach to perform a user task analysis, an approach based on guiding and helping for the task decomposition, through a guided and semi-automated system. Thanks to these two characteristics in our system, our approach allows for the completion of a user task analysis, which is necessary for designing the VR interactions related to the task, by the domain-specific users, without having neither task analysis expertise nor VR expertise -having domain-specific expertise only is sufficient. Finally, by looking at the result obtained with the task decomposition, i.e. all the divisions into subtasks from the main task to the primitive tasks including all the intermediate ones, it is possible to get two kinds of specifications: a list of the domain-specific required functionalities, which are directly linked to the users' need, and a list of the primitive tasks that compose the original main task, which are directly related to the required interactions in VR. These specifications are keys to build a link between the users' specific domain and the VR domain. Our step 1 is detailed in the section 5.2.

The step 2 allows for the determination of proposals of VR interaction techniques, for all the required interactions that are associated to the primitive tasks listed in the step 1, according to these tasks and to the required domain-specific functionalities also identified in this previous step.

We proposed to proceed to this step 2 in a semi-automated way, thanks to an expert system that contains VR expert knowledge, which allows thus people that are non-expert in VR to obtain the expected results: some proposals of VR interaction techniques. To build such expert system, it has been necessary for us to understand and classify both the human primitive tasks/actions, and the VR interaction techniques. For this purpose, in this step, we built, based on previous taxonomies present in the literature [START_REF] Muhanna | Virtual reality and the cave: Taxonomy, interaction challenges and research directions[END_REF] [23] [26] [129], our own VE interaction taxonomies, adapted for an usage in our 108 5.2. STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK expert system. Our step 2 is detailed in the section 5.3.

Finally, in the step 3, we propose to proceed to a step of prototyping VR applications and of conducting user evaluations. In opposition with the previous steps, a VR developer is this time required to be able to complete this step in its entirety. Indeed, in the first part of the step 3, a VR developer must develop VR prototypes of applications, based on the proposals that the domain-specific users have obtained in the step 2. Then, this developer must conduct user evaluations with end-users subjects: for this purpose, we provide here some guidelines for evaluating and comparing the different interaction techniques that have been prototyped. Our step 3 is detailed in the section 5.4.

Thus, these user evaluations aim to evaluate the usability of these interaction techniques, i.e. in terms of user task performance, user preference or both. To evaluate the usability, we recommend here to orient and guide these evaluations by selecting and taking into account some specific quality factors for each interaction evaluated, as Bowman et al. and Arns et al. suggested it [23] [11]. Moreover, we also recommend to apply weighting to the quality factors, depending on their relative importance, which can either be attributed by the users [145] [146] or by some VR experts, leading finally to a weighted global score of the usability. By following these recommendations, the VR interaction techniques can be compared in such evaluations, as Gabbard et al. explained it in their study about usability and user evaluations [57].

To summarise, we propose a new task-centred design methodology for the design of virtual environments that are dedicated to a specific purpose, focusing in particular on the design choices made for the VR interaction techniques. This methodology is composed of three main steps: first, to build a model of the domain-specific task, then, to determine some proposals of VR interaction techniques, and, finally, to create and evaluate prototypes of VR applications with these VR interaction techniques.

5.2

Step 1: build a model of the domain-specific task

Overview

The first step of our methodology consists of building a model of the domain-specific task that the users want to perform in the VE. The two objectives beyond building this model are 1) to determine the specifications that are required for the VR application from a domain-specific point of view, and 2) to create a link/a bridge between the specific domain and the VR domain. Following our step 1, a model

STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK

of the domain-specific task is obtained: this model contains a decomposition of this task into sub tasks.

By reading such decomposition, the domain-specific functionalities that are required can be deduced, contributing thus to achieve the first objective. Moreover, at the last level of this decomposition, there is the main output of this step: a list of the primitive tasks that compose the original main task.

Indeed, having these primitive tasks allows for achieving the two objectives mentioned above: 1) to be able to complete these tasks is a concrete domain-specific requirement, and 2) each primitive task obtained thanks to our step 1 is directly related to a required interaction in the VR application.

To build this model, a hierarchical task analysis of the main domain-specific task must be done.

This HTA consists of a hierarchical decomposition of the main user task, by splitting it into subtasks.

This results in reducing the complexity and the specificity of the tasks at each level of decomposition, until reaching a level where the subtasks are primitive tasks that cannot be divided anymore. By obtaining such decomposition, it would facilitate the comprehension of the original domain-specific task and as a result of the required functionalities too. Finally, the primitive tasks obtained here could be used afterwards as a bridge between the specific domain of the users and the domain of VR, by deducing their associated interaction in VR.

To facilitate the construction of this model, we provide here some guidelines and a semi-automated system to perform the HTA. We propose a hierarchical model to use for the task decomposition, based on the intrinsic meaning of the verbs used, verbs that are obligatory in our grammatical pattern.

Moreover, we provide a list of verbs for each level of decomposition and rules that give suggestions of decomposition. Figure 5.2 shows how these elements are used in the step 1. Thanks to that, this step does not require neither task analysis expertise nor VR expertise, and thus the HTA can be done by the domain-specific users without having task analysis expertise nor requiring the aid of VR experts.

Human information processing and classification in kinds of primitive tasks

First, it can be observed that proceeding to task abstraction and decomposition can be facilitated using task classification. Yet, task classification can be related with the way the humans process the information that they received from their environment, regardless of its nature -virtual or real. Thus, it is interesting to understand human information processing. Proctor et al. distinguished three stages in human information processing: the perception, the cognition, and the action stage [START_REF] Proctor | Human factors in simple and complex systems[END_REF].

We think that the Proctor et al. analysis [START_REF] Proctor | Human factors in simple and complex systems[END_REF] about the information processing can be extended to a classification of the human tasks. Indeed, at each of the stages identified in this information processing, a human performs "an action", which is done in order to complete a task, even if this "action" is not motor. Thus, it can be considered that, to complete a composite task, a human must perform a sequence of several perceptual, cognitive and motor -this term can be used instead of action Then, it means that the human tasks, when they are "simple" tasks issued from the decomposition of a more complex task, can be classified into three main categories: the perceptual, the cognitive and the motor tasks. About this kind of task classification and decomposition, Dunston et al. used different task levels in their hierarchical taxonomy for AEC tasks [45]. Their hierarchical taxonomy allows for the decomposition of a task, until reaching a level of composite tasks, and finally a primitive task level, the last one of their model. As for them, the composite tasks are the ones that are directly related to the interactions in VE, and they are split into perceptual, cognitive and motor tasks.

Nonetheless, some critiques can be raised about the Dunston et al. hierarchical taxonomy. To understand it better, we can look at their hierarchical model, and at the examples of tasks that they gave for each level of their model. Figure 5.4 shows this model, on the left, and some examples, on the right. We noted three main issues in their model, observing the hierarchy proposed and the corresponding examples: 1) the naming convention of all the tasks is not constant, 2) the authors claim that clear differences exist between their levels in their hierarchy, but there is some incoherence in their examples, and 3) this taxonomy does not state a difference between composite and primitive tasks, and thus do not take advantage of the differences that exist. These issues have these consequences on the result: first, task decomposition and abstraction result in having unexpected variability depending on the users, and thus this may be more complex for them to decompose (no fixed naming, difference between some levels not clear), and, second, the interpretations and uses for VE purposes of these decompositions result in being unstable (a composite task can hardly rely on a unique VE interaction). others by the use of both a verb and a noun. This means that the different grammatical pattern, or naming structures, are used here, as underlined in purple in the figure . Here, the absence of usage of a constant and unique way to describe a task could be an issue for creating a list of the required interactions in VR, and for using this list as a bridge to the VR domain, since the interactions could not be interpreted easily from the names of the tasks.

Then, about the issue 2), we can notice the use of different task levels: level 1 "domain", level 2

"operations", level 3 "activities", but, at the same time, it can be noted that diverse examples of tasks, which are similar in terms of their nature, seem to belong to different levels, and this impression is due to the repetition of words in these examples. Some of these similar examples that are placed at different task levels are marked in orange in Figure 5.4: at the levels 1 and 2, the words inspection, maintenance, are repeated, and at the levels 2 and 3, construction planning and architecture planning are repeated. Such repetitions create unclear differences between levels, disturbing thus the users and preventing them from having a good comprehension of the hierarchical model proposed by Dunston et al.

Next, about the issue 3), the definitions and the examples given in this study for the composite and primitive tasks do not state a clear difference between both levels. We may wonder why grasp or move are primitive task, whereas select or navigate are composite ones. Nonetheless, an answer can be found in the literature, notably about navigate. Navigate is a composite task, because it contains two primitive components: a "wayfinding" primitive task, and a "travel" primitive task, where the term move corresponds to the "travel" primitive task [27]. But, this means thus that navigate cannot be a full cognitive or full motor task, whereas the primitive tasks move/travel and wayfinding are a motor task and a cognitive task, respectively. This means that the categories cognitive, perceptual and motor cannot be used at the composite task level -as it is done in Dunston et al. model, but could be for the primitive task level.

To address the issue 1), we propose to use the following naming convention, or grammatical pattern, to define a task: a task must be described using one verb and one complement -e.g. a noun group.

Indeed, according to Munzner [START_REF] Munzner | Visualization analysis and design[END_REF], this is an efficient technique to describe a task, since the verb allows for the definition of the action, and the noun for the representation of the target of this action. Finally, to address the issue 3), we propose to use the cognitive, perceptual and motor categories of tasks at the primitive tasks level, instead of using it at the composite task level. This allows us to take advantage of the difference between a composite and a primitive task: the composite tasks are, as their name indicate it, composed of different components, which rely on our mind, our senses, or our physical actions. This means that these composite tasks can be directly split into primitive tasks, which are either cognitive, perceptual or motor, resulting in facilitating the decomposition of a task. Additionally, by having this classification at the last level of our decomposition, it would help for making the bridge between the primitive tasks and the interactions required in the virtual environment.

It should be highlighted that, due to their nature, the cognitive tasks would not be considered as concrete VE interactions; however, the perceptual tasks could be considered as visualisation, auditory etc. interactions, and the motor tasks as motor/physical interactions.

Our hierarchical decomposition model and hierarchical task analysis system

A hierarchical decomposition for a main input task

Based on the suggestions we made for the three issues that we had detected, we propose here a new model of hierarchical decomposition to be used to conduct the hierarchical task analysis for the step 1 of our methodology. Moreover, this model has been thought for being used in a semi-automated system, which contributes thus to guide this hierarchical task analysis, so the domain-specific users, without having task analysis expertise, can conduct it and finally obtain the model of their domain-specific task. We want to present this model and our system in the next paragraphs.

Indeed, before explaining our model, it is important to give a precision about the input domainspecific tasks that can be considered here and used as the main input task to be analysed. This task should be given here with the point of view of a unique kind of stakeholder, and this must belong to a unique phase of the building life cycle. Indeed, the final aim of this analysis is to obtain the primitive tasks that compose the original main task, which are linked to interactions in the virtual environment.

Yet, different kinds of stakeholders, who participate the same original main task, would have different primitive tasks at the end of the decomposition, and thus have dedicated interactions, i.e. interactions that depend on their trade and role. This is why it is necessary to consider one kind of stakeholder at a time, to be able to obtain their associated interactions. To obtain the results for multiple kinds of stakeholders, the hierarchical task analysis would have to be done several times. It would follow the

STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK

same principle for a main task that belongs to several building life cycle phases, since the primitive tasks would be different in each phase, and thus a HTA should be done for each phase.

Our hierarchical model

First, as suggested above, to address the different issues that we noted, we propose to use the naming convention "verb + complement" in all our model; then, the approach used in this model is based on the decomposition through the semantic meaning of the verbs used at each level, and this has induced the use of levels that are different to the ones of Dunston et al. Moreover, the modification mentioned previously about the primitive tasks and their classification -perceptual, cognitive or motor differentiation must be used for the primitive tasks -is effective in our model. Primitive tasks are keys in this model, since one of our most important guidelines that help for the HTA is to specify that the end of the decomposition has been reached when primitive tasks are obtained. Indeed, Annett et al. [8] noted that knowing when to stop the HTA is the main difficulty for the people that perform an HTA. Additionally, for a concrete aid, a list of the verbs that can be used for a primitive task, and for all the other intermediate levels, are provided in our semi-automated system.

Then, we propose to follow the main principle that Annett et al. [8] [9] gave: the original main task is directly linked to a main goal that the domain-specific users have, and thus, to proceed to the decomposition, this original task must be divided into subtasks in the same way that the original goal can be divided into sub goals. Nonetheless, to guide the domain-specific users that perform the HTA, they need more guided and concrete steps, which apply this principle. Thus, we propose to use the following hierarchical model -each level being a new decomposition, and with the main task level called level 0 because no decomposition has been done yet:

• Level 0: the original main task (and its associated main goal)

• Level 1: major subtasks of this task (associated to the main sub goals)

• Level 2: activities that compose a subtask thus giving rise to our levels 0 and 1, with the terms tasks and subtasks used for these levels [8] [157].

•
Then, these subtasks can be divided into activities, and these activities into operations, as Bedny and

Meister [18], and Crystal and Ellington [39] proposed it through their activity theory. Finally, Annett et al. defined an operation as "the fundamental unit of analysis" [8], and explained that an operation is specified by three components: an input -i.e. its goal, actions and feedback. This explains why "actions" are the next level after "operations" in our model. Moreover, Stanton et al., who shared this same definition of an operation, insisted on the fact that the operations must always be on the last levels of decomposition in a hierarchy [START_REF] Stanton | Human factors methods: a practical guide for engineering and design[END_REF]. This explains thus why our model ends with the operation level, followed by the action level, whose elements compose the operation level, as explained by Annett et al [8]. to be able to decompose following this principle and this hierarchical model, it is necessary to list the verbs are available at each level of decomposition, and to explain in which verbs a verb could be divided. For this purpose, we propose here a list of verbs for each level, and suggestions of decomposition of a verb into its "child verbs". Finally, to make easier the use of such lists and "rules" of suggestions, we provide in our methodology a semi-automated system, which acts as a pattern that the user can follow, and allows for the centralisation of all our guidelines and aid for completing this hierarchical task analysis, as shown in Figure 5.8. Additionally, all the rules of suggestions of division of tasks into subtasks are shown in Figure 5.9.

Figure 5.8: Our semi-automated system to perform the HTA with our model and guidelines for step 1

Conclusions

To summarise, we presented here the step 1 of our methodology, which aims for the construction of a model of the domain-specific user task, by performing a hierarchical task analysis. This HTA allows for the decomposition and abstraction of this user main task into primitive (sub) tasks. For this purpose, we proposed a new hierarchical model and provided a semi-automated system to allow the users to perform the HTA with more help and guidelines. We proposed to use a grammatical pattern "verb + complement", and to perform a decomposition based on the intrinsic meaning of the

STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK

verbs used. To do that, we provided a list of verbs for each level of decomposition and rules that give suggestions of decomposition.

To conclude, in this step, our semi-automated system would allow the users, even for those who do not have task analysis experience, to perform the required task analysis on their domain-specific task, autonomously. This would be evaluated in the experiment shown in the chapter 6, taking in account three criteria: 1) this step and its semi-automated system are usable by the domain-specific users, 2) they can perform this step autonomously, and 3) they obtained results that are similar to the ones that would be obtained following a traditional user-centred design methodology.

Finally, for each primitive task obtained here in this step 1, an interaction would be required for the VE, making thus a bridge between the users' specific domain and the VR domain, and leading to our step 2.

STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES

5.3

Step 2: determine proposals of VR interaction techniques

Overview

In this step, the main objective is to determine proposals of VR interaction techniques for each required interaction, from the set of primitive tasks obtained with the step 1. We propose in this step to follow our guided process, split into several sub steps, which has been designed to allow the domainspecific experts to obtain these proposals, without having VR expertise. This also means that this step can be entirely done without needing a VR expert. At the end of this step, for each interaction, one, or more likely several proposals of VR interaction techniques would be obtained. These proposals are determined based on VR knowledge, and are selected in order to be appropriate to the primitive task associated to each interaction, in terms of usability. Thus, for each primitive task, we propose to follow these sub-steps: first, the identification of the type of VR interaction associated to the task and the identification of the characteristics of this task (2.1), then the characterisation of the VR interaction The step 2.1 allows for the extraction of two elements from a primitive task previously obtained in the step 1: the interaction associated to this task, and the characteristics about this task and its context. Moreover, in this step, the interaction is classified, i.e. the VR type of this interaction is obtained, and it depends on the primitive task. An interaction can be classified into one of the three following main types: the motor one, the perceptual one, and the cognitive one. Additionally, motor interactions are classified into sub-types: navigation interactions, manipulation interactions and selection interactions.

Thanks to our hierarchical model and our guided and semi-automated system in the step 1, all the primitive tasks follow the same naming convention, i.e. grammatical pattern, composed of two elements: to describe the action, a verb, which belongs to a determined list, and a complement to describe the target. Based on that, we propose to use here an automatic system to split the primitive task into two parts, one with the verb and one with the complement. Then, this automatic system associates the isolated verb to a type of VR interaction, and eventually to a sub-type, if motor, thanks to a correlation table between the verbs that describe the tasks and the VR interaction types and motor sub-types, shown in Table 5.1. Finally, the characteristics of the task are attributed by using directly the content of the complement previously separated from the verb. Thus, this system allows for the obtaining of the two expected outputs for this step 2.1, as shown in Figure 5.11. In this document, starting from this step 2.2, and for all the next steps of our methodology, only the motor interactions will be considered and studied. This means that the perceptual and cognitive interactions are not included for these steps in this current research; nonetheless, they may be considered in future work, notably the perceptual ones, as the VE technologies offer sensorimotor experiences to their users.

In this step 2.2, we propose to characterise with more details the (motor) VR interactions classified in the step 2.1. Indeed, thanks to this step 2.1, the VR interactions have already been differentiated by their kind of actions and their sub kinds of motor actions, between navigation, selection and manipulation interactions. Then, we propose in the step 2.2 to characterise these motor interactions, depending on their associated primitive task and its context. This consists, for the domain-specific users, of assigning values, usually between binary or ternary choices, for each characteristic of a list.

The characteristics that belong to this list vary depending on the kind of motor interaction, and these are presented in the next paragraphs for the three kinds considered here. Figure 5.12 shows the step 2.2 mechanism. These choices made by the domain-specific users can be done based on the knowledge that they have about the primitive tasks: thus, our approach does relies on obtaining the characteristics of the VR interactions from their associated primitive tasks, as few studies did in the literature. Indeed, Arns et al. mentioned this lack of existing methodologies that take into account this kind of task-centred approach for the design of VEs [11]. Nonetheless, this concept has been studied in other fields, notably in the 2D visualisation design in Munzner's research [START_REF] Munzner | Visualization analysis and design[END_REF]. As mentioned above, about the list of characteristics to be used to characterise each VR interaction, we provide here a different list for the navigation, selection, and manipulation interactions. In fact, even though diverse motor interactions shared common characteristics, some information are for example more relevant for the selection interactions than for the navigation ones, e.g. the distance between the user and the objects in the VE. We have been able to build these lists of characteristics by gathering the factors studied in interaction technique evaluations, and thanks to some reviews that listed those factors, notably one by Poupyrev et al. [130]. Below we present for each kind of motor interactions the list of characteristics that we provide to the domain-specific users here, with their possible values.

About the navigation interactions, we propose the following list of characteristics, based on studies about this kind of interaction in the literature [25] [112]:

• the distance between the VR user and the spatial zone(s) where the objectives of the travel are

• the kind of spatial objective of the travel

• the kind of "target-finding" objective of the travel First, about the distance user-zone(s), we propose two values: A) distances within the personal space and B) distances within the public or action spaces. These two values represent the "short"

and "long" distances, and the terms personal and public are used to represent less subjectively what

STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES

"short/close" and "long/far" distances are. Indeed, in the depth perception literature, Cutting et al. [40] defined the personal space as our space from 0m of distance around us and up to 2m, the public space from 2m to 30m, and the action space beyond this last distance. Here, it was relevant to use such space divisions, from the literature about perception, since a VE user needs to perceive its environment for navigating, and thus this may affect them when they move.

Then, about the kind of spatial objective and the kind of target-finding objective characteristics, these are inspired from the 2D visualisation design literature. Indeed, Munzner [START_REF] Munzner | Visualization analysis and design[END_REF] proposed, for 2D search tasks, to distinguish four cases based on two criteria with two values: the target criterion, with the values known or unknown, and the location criterion with the values known or unknown. Then, Munzner explained that these values led to four kinds of search tasks: the locate, lookup, explore, and browse tasks. These search tasks can be assimilated to eye-navigation tasks, thus these values could also be used for a VE navigation task.

In a travel, a subject may have a final destination as their spatial objective to reach, or on the contrary they may do not have a final destination and their objective is to follow a path and to observe everything in this way during the travel. This is why we propose two distinct values for the spatial objective: A) the destination (location known) versus B) the path/way of the travel (location unknown). Then, as a subject has usually another objective than the navigation itself, in particular to find some targets within the environment, we can assimilate here the "target known" as the value A)

"pre-determined target-finding objective", and the "target unknown" as the value B) "undetermined target-finding objective". • the kind of selection -taking (concrete) versus activating (abstract)

• the distance between the VR user and the objects to be targeted for selection (if concrete)

• the size of the targets/objects (if concrete)

• the state of the environment (if concrete)

About the manipulation interactions, we propose the following list of characteristics, based on studies about this kind of interaction [25] [51], and notably the one by Poupyrev et al.

[130]:

• the distance between the VR user and the objects to be handled

• the size of the targets/objects

• the kinds of movements that are required

• the range required for positioning (only if positioning movement is required)

First, it can be noticed that there are two common characteristics in the lists for the selection and manipulation interactions: the distance between the VR user and the objects and the size of the targets/objects. This can be explained by the fact that both characteristics come from the Fitts's law [51]. This law states that the farther and the smaller a target is to the subject the more difficult the task -of selection in the original Fitts's study -is. Initially, this law has been stated in the Human Computer Interaction field for 2D selection tasks only, but then more experiments have been conducted

in the literature after the original one by Fitts, and notably for 3D tasks in 3D environments, including both selection and manipulation tasks. This explains the presence of these two characteristics in both lists. As the natural limit of a human subject is the range of movements of their arm, thus for the two values about the distance user-object, we propose A) within the arm-reach workspace and B) out of the arm workspace. Indeed, some would notice that we could not naturally select or manipulate objects out of the arm-workspace; nonetheless, this is possible in a virtual environment by using remote interaction techniques. This means thus that choosing between these two values may influence the Then, about the selection tasks, we added two characteristics to the list: the state of the environment [33], and the kind of selection. For the state of the environment, two values are possible A) sparse, and B) dense, in terms of the quantity of objects that are present in a same zone. Indeed, if many objects are present in a same zone, this adds more difficulty for selecting a target, and thus this can influence the choice of a VR interaction technique. Finally, the kind of selection is the last characteristic presented here, but this is the one for which a value must be assigned first. It was necessary to add this characteristic, not stated as clearly as that in the literature, to distinguish two major cases of selection, before going farther: the concrete selection of a target/an object versus the abstract selection of a feature, or a functionality/a mode. Indeed, in the last case, the three characteristics given above are as a result not relevant, and this would influence the choice of the VR interaction technique.

Next, about the manipulation tasks, we also added two characteristics: the kinds of movements In the step 2.2, each VR interaction has been characterised according its associated primitive task, and depending on its kind of motor interaction. Here, in this step 2.3, we propose, for each interaction, to analyse the values that have been assigned by the domain-specific users to all these characteristics, in order to determine the characteristics of the VR interaction technique that would be appropriate for this interaction. This analysis is performed here by an automatic system, based on an expert system that contains rules of deductions between a characteristic of the interaction and a characteristic for an appropriate interaction technique. Thanks to this expert system, a domain-specific user can also execute this step 2.3, and without having VR expertise. Figure 5.16 shows the step 2.3 mechanism. Nonetheless, as visible in the Figure 5.16, to do that, it was necessary to build the rules of the expert system according to VR expert knowledge. Thus, for the step 2.3, it has been necessary to:

1. create a classification of the characteristics of the interaction techniques that exist for each kind of motor interaction.

2. build the deduction rules that link a value assigned to a characteristic of an interaction to a value assigned to a characteristic of a VR interaction technique that is appropriate for this interaction.

For 1), we used some existing VE interaction techniques taxonomies that we re-interpreted and modified for our usage in this step of our methodology. It was notably important for our usage

STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES

to group together the VR interaction techniques into less categories when possible, to reduce the number of characteristics that we use here to define an interaction technique. We particularly studied the taxonomies proposed by Poupyrev et al. and Bowman et al. [START_REF] Poupyrev | Manipulating objects in virtual worlds: Categorization and empirical evaluation of interaction techniques[END_REF] [23] [26], and the review by Argelaguet et al. [10]. And for 2), we proposed some rules based on the results obtained in the literature in various studies that compared different interaction techniques under different task conditions.

Taxonomies of characteristics of VR interaction techniques

First, we can analyse the navigation interaction techniques. For this kind of motor interactions, we built our taxonomy of characteristics based on Bowman et al. taxonomy [23]. To do that, we extracted the characteristics contained in this existing taxonomy, by splitting elements that were contained in some groups initially, and by forming new groups of techniques or features, which finally define a characteristic in our taxonomy. Figure 5.17 human speed (or less), and high speed (more than the human speed, including infinite speed).

To summarise, Figure 5.18 shows the final result of this process, i.e. the characteristics that we propose to consider in our methodology for the VE navigation interaction techniques, with their different possible values. Finally, it is possible to analyse the manipulation interaction techniques. Here again, we proceeded to the same technique than for the other kinds of interaction techniques, and our analysis relied here on the taxonomy by Bowman et al. [26]. Figure 5.21 shows how we created this taxonomy of characteristics, with, on the left, our taxonomy, and, on the right, the Bowman et al. taxonomy.

The colours are used in the same way than for the process of creation of the navigation and selection interaction techniques taxonomies shown previously.

Deduction rules between interaction characteristics and interaction technique characteristics

Once our taxonomies about the characteristics that define the interaction techniques have been defined, for each kind of motor interaction technique, we can produce some deduction rules between the interaction characteristics -defined previously in the step 2.2, and the interaction technique characteristics defined in the taxonomies here in the step 2.3. This means that a deduction rule in our methodology follows this pattern:

Input data f rom step 2.2 ⇒ Output data in step 2.3 i.e.
V alue f or an interaction characteristic ⇒ V alue f or an interaction technique characteristic (5.1)

These rules have been built from the results obtained in studies in the literature that evaluated and compared different interaction techniques under varying conditions. Yet, in these studies, these conditions reflected values of the characteristics of VR interactions that we use in our methodology, and their user evaluation results showed, depending on the cases, significant differences, or not, according to the interaction techniques used, in terms of usability. This allowed us to build deduction rules about the appropriate -in terms of usability -characteristics for VR interaction techniques.

As a result, these deduction rules can be used in this step 2.3 in an expert system, to provide automatically to the domain-specific users some proposals of appropriate characteristics -in terms of usability -for the interaction techniques that are required in the application. Figure 5.23 shows this mechanism of using deduction rules as an expert system for determining characteristics of VR interaction techniques without having VR expertise. The following tables -Tables 5.2, 5.3, and 5.4, one table for each kind of motor interaction technique -show all the deduction rules used here in our methodology, with the references of the expert guidelines or experiments done in the literature, if they exist; otherwise, the term "suggestion" may be written if we proposed this rule based on the conditions, or "by definition" if this is the case by nature, i.e.

based on the nature of some values of characteristics (e.g. objects are already close to the user, so there is no need of automated movements to make the objects come close).

STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES

Input

Recommended value

Ref.

Hand-size (or less) object manipulation mode (tr) direct or indirect via interface [START_REF] Ware | Rotating virtual objects with real handles[END_REF] Hand-size (or less) object manipulation mode (rot) direct or indirect via interface [START_REF] Ware | Rotating virtual objects with real handles[END_REF] Hand-size (or less) object manipulation tool (rot) hand [START_REF] Mine | Moving objects in space: Exploiting proprioception in virtual-environment interaction[END_REF] Hand-size (or less) object kind of tool control (rot) both (isomorphic/ anisomorphic), aniso. for precision [START_REF] Mine | Moving objects in space: Exploiting proprioception in virtual-environment interaction[END_REF] Out of arm reach range for positioning manipulation mode (tr) direct or indirect via interface [START_REF] Pierce | Voodoo dolls: Seamless interaction at multiple scales in virtual environments[END_REF] Object size more than hand manipulation mode (rot) indirect (interface/ resized objects)

[108] [START_REF] Pierce | Voodoo dolls: Seamless interaction at multiple scales in virtual environments[END_REF] Object within the arm reach + within arm reach range for positioning manipulation mode (tr) direct [START_REF] Pierce | Voodoo dolls: Seamless interaction at multiple scales in virtual environments[END_REF] Object within the arm reach + within arm reach range for positioning manipulation tool (tr) hand [START_REF] Steed | Evaluating effectiveness of interaction techniques across immersive virtual environmental systems[END_REF] Object The taxonomies and the expert system developed in this step 2.3 allow for the automated obtaining of appropriate -in terms of usability -VR interaction techniques characteristics for each interaction that had been characterised in the step 2.2. This means that, for example, for a selection interaction, the step 2.3 returns the appropriate values of the characteristics for a VR selection interaction technique, i.e. in this case, for the selection mode: direct or indirect, for the selection tool: hand or raycast, for the kind of tool control: isomorphic or anisomorphic, and for the disambiguation mechanism: yes/no. For the navigation and manipulation interaction, this is the same, with their own list of characteristics. Finally, it is important to note that for some characteristics the appropriate value in terms of usability may not be defined here, because of a lack of rules on these conditions. Moreover, in the case where a study in the literature has shown it for some conditions, the appropriate value in terms of usability can also be "both values, without any difference" -for example, "both: hand or raycast, the two are equally appropriate". All these recommended characteristics can be given to the VR developer that will develop the VR application with the required interaction techniques.

Conclusions

To summarise, we presented here the step 2 of our methodology, which aims for the determination of proposals of VR interaction techniques, for all the kinds of motor interactions -navigation, selection and manipulation, and, to do that, we proposed to follow four sub steps. First, in the step 2.1, the interactions must be extracted from the primitive tasks obtained in the step 1. Then, these interactions must be characterised by the domain-specific experts, in the step 2.2, based on the information contained in the primitive tasks. Next, in the step 2.3, we analysed the existing taxonomies about the interaction techniques in VR, to build our own taxonomies of interaction technique characteristics.

Thus, based on the results from previous studies and VR knowledge from the literature, deduction rules between these characteristics and the characteristics attributed in the step 2.2 have been built.

Using these rules, we provided in this step an expert system that can provide to the domain-specific experts some recommendations about appropriate -in terms of usability -characteristics for their VR interaction techniques. And in the step 2.4, we explained how these recommendations could be translated into proposals of VR interaction techniques.

To conclude, in this step, our semi-automated system would allow the domain-specific users, without having VR expertise, to determine proposals of VR interaction techniques for all the VR interactions required for their task. This would be evaluated in the experiment shown in the chapter 6, taking in account three criteria: 1) this step and its semi-automated system are usable by the domainspecific users, 2) they can perform this step autonomously, and 3) they obtained results that are similar to the ones that would be obtained following a traditional user-centred design methodology.

Finally, the results obtained by the domain-specific users in this step 2 would lead to our step 3, in which these users would have to give these results to a VR developer, who is required in this last step.

5.4

Step 3: create VR prototypes and run user evaluations

Overview

The main objective here is to create VR applications prototypes and to run user evaluations, from the set of proposals of VR interaction techniques obtained thanks to the step 2. We propose here to follow our guided process, taking in account that this step must be completed with a developer who In this step 3.2, the VR developer must create some prototypes of VR applications that contain both the VR interaction techniques chosen in the step 3.1 and the VR content of the application, for example the 3D BIM models in a case from the AEC industry. This is in this step that this developer realises the concrete implementation of the VR interaction techniques, for each interaction. Usually, it is possible to develop several prototypes, since, in the step 3.1, several appropriate candidates of VR interaction technique may have been chosen for one interaction. Indeed, in the steps 2.3 and 2.4, in 5.4. STEP 3: CREATE VR PROTOTYPES AND RUN USER EVALUATIONS some cases, our system may provide a unique proposal of interaction technique, but in other cases, two or more proposals. This means thus that, depending on the number of interactions and the number of proposals accepted to be prototyped for each interaction, the number of prototypes can increase quickly, notably if several interactions have influence on the performance of the other ones and thus more prototypes must be "split". Thus, the VR developer and the domain-specific users must define, depending on the budget, the available time and possibly other constraints, the amount of prototypes to be developed, to avoid a potential exponential explosion of prototypes to build. Figure 5.27 shows the step 3.2 mechanism. About the user evaluations, we propose to run usability evaluations, in the usability sense of efficiency, effectiveness and satisfaction [55], or, in other terms, in the sense of the user performance and the user preference [START_REF] Nielsen | Measuring usability: Preference vs. performance[END_REF]. Such evaluations must be prepared according to the task that will be performed by the users, and to the interactions that they will be able to have. In our methodology, to perform these user evaluations on interaction techniques, the following components are required, explained in detail afterwards: 1) the quality factors taken into account for evaluating an interaction technique, 2) the associated measures and scores, and 3) the quality factors scores weighting.

We propose thus to choose first the quality factors that must be taken into account to evaluate an interaction technique, depending on the task performed and the interaction technique itself. For each kind of motor interaction, recommended lists of quality factors can be found in the literature. Then, a subset of quality factors must be chosen based on their relative necessity of being ensured for the execution of the user task using the VR interaction technique.

STEP 3: CREATE VR PROTOTYPES AND RUN USER EVALUATIONS

Then, each quality factor must be evaluated by a score that can be obtained through some measures, which are chosen according to this quality factor and the possibilities that are inherent to the user task and to the virtual environment used during the user evaluation. Each measure allows for the determination of the score obtained with the VR interaction technique used during the user evaluation, for one aspect of the usability, the one represented by the quality factor. or not on the usability of an interaction technique when performing a task in particular. However, they noted that, usually, only a subset of the quality factors present on the lists is relevant for the evaluation of an interaction technique used for one particular task. They explained that making the choice of the quality factors that must be included in this subset, according to the task performed, might be complex. Thus, we may wonder how to make such selection of quality factors. According to Bowman et al., an option for the selection of these quality factors is to let the future users of the VE application do it, in collaboration with the VR developer.

Measures and scores for evaluating the usability of VR interaction techniques

Each of the quality factors taken into account in a user evaluation in our methodology must be associated to one or several measures. As these quality factors vary depending on the kinds of tasks and interactions that are evaluated, thus these measures also vary. Moreover, for some quality factors, different measures are possible: for example, for the quality factor "ease of use", taken into account for the user evaluation of a manipulation task, it is possible to count the number of required movements to place correctly an object -an objective measure, or to use a post-experiment questionnaire -a subjective measure. It would be hard to say, for a quality factor, that there is a rule for choosing a measure instead of another. We propose thus to let the VR developer, in collaboration with the domain-specific users, make this choice.

Then, once all the measures associated to the quality factors have been selected, a score for each quality factor score can be calculated here, from the data collected during the user evaluation through the different measures. Next, a global usability score could be calculated, from the scores obtained for each quality factor. However, to be able to do that, all these scores must be expressed on the same scale, e.g. from 0 to 1, or from 0 to 100. The "difficulty" of this change of scale varies depending on the measures. Indeed, on one hand, some measures, such as the ones obtained with SUS questionnaires [154] [173], can be changed easily, by adjusting the existing ratio on the chosen common scale, e.g. by transforming a score /100 into a score /1. On the other hand, for some measures, such as task completion time or the number of clicks, it may be necessary to re-scale entirely the data 5.4. STEP 3: CREATE VR PROTOTYPES AND RUN USER EVALUATIONS obtained. In this case, a possible approach is to attribute a score of zero out of the max grade to the worse measure, and a score of max grade out of the max grade to the best measure, and to use a linear function to calculate the scores issued from the remaining data. It can be noticed that this operation might require a previously analysis of the data distribution to avoid considering some outlying data.

Finally, once all the scores share a common scale, a global usability score can be calculated.

Nonetheless, we may wonder how this calculation can be done. The first approach to calculate this global score for a user is to gather all the different scores obtained for the diverse quality factors and to take the average. Nonetheless, this approach does not take into account the relative importance of each quality factor. Indeed, even if the quality factors that are considered in an evaluation have been chosen according to the task, to its context, and to the kind of interaction, each quality factor may have a different importance on the usability. To address this issue, we propose to apply weighting to the quality factors before calculating the scores average, to obtain a global balanced score of usability.

Scores weighting to obtain global balanced scores of usability

We aimed in this step of our methodology to explore and propose here different approaches to define and use the relative importance of the quality factors, which is necessary for the calculation of global balanced scores of usability.

First, we can notice that the relative importance between quality factors can be defined either mathematically or linguistically. From the users' point of view, both techniques seem to be correct, even though some would prefer to use numbers, and others to use words. From the developer's point of view, numbers may be easier to use since they can directly express weights, which are necessary for calculating a weighted average. This explains thus why we used numbers in the case studies presented here, nonetheless, using words would also be correct since they can also be transformed as number values, with a simple table of weight associations, or using Fuzzy logic rules [START_REF] Zadeh | Fuzzy logic[END_REF].

Then, we may wonder how to determine and set the relative importance of the quality factors. As explained by Bowman et al. [23], we propose in this step to let the participants of the user evaluations that are conducted here assign the relative importance of each quality factor. Indeed, the domainspecific users are the ones who really know the needs associated to the task performed in the VE.

Nonetheless, another approach that we propose is to let an expert perform an "expert distribution" of the relative importance of the quality factors. In the future, this expert distribution could also be done

STEP 3: CREATE VR PROTOTYPES AND RUN USER EVALUATIONS

automatically, through artificial intelligence using the results previously obtained in other experiments that followed our methodology, for VE applications where the same kind of task is performed and where the same kind of interaction technique is evaluated.

In both cases, i.e. either through the users of the application or the VR expert, there are several ways for establishing the relative importance of different factors. We present and propose here two options: A) the "simple weighting" technique, which may appear as the simplest and the more "natural" technique, and consists of comparing all the factors at the same time and of assigning directly all the weights, or B) the "cross-weighting" technique, which consists of comparing each factor to the others, pair by pair, then of assigning "sub-relative" importance between two factors, and finally of obtaining the importance of each criteria by summing its "sub-relative" importance [START_REF] Saaty | What is the analytic hierarchy process?[END_REF]. This technique may appear as more complex, but could be more comfortable when many factors are considered, since it reduces the number of factors that are compared at the same time at a maximum of two.

Our process for preparing the usability user evaluations of interaction techniques

To conclude, in this step 3.3, we propose to organise and prepare user evaluations to compare the usability of different VR interaction techniques, developed by the VR expert in the step 3.2 into different prototypes of VR applications. We summarise here our proposals about the three points mentioned in the overview -1) quality factors, 2) measures and scores, and 3) quality factors weighting.

About 1), the selection of the quality factors that are relevant for the user evaluations can be done by the domain-specific users of the VE, in collaboration with the VR developer. Then, about

2), measures must be associated to the quality factors, and this must be done by the VR developer.

We may recommend to use quantitative measures -either objective or subjective, since they offer the benefit of allowing more direct comparison between the results obtained from different experiences or different applications/interfaces [77] -thus these measures can be better for comparing VR interaction techniques. Finally, about 3) in our case studies, we asked the users to use the two techniques presented above, to obtain data about the way for establishing the relative importance of the quality factors itself.

We suggest for future studies to use also the two techniques, until reliable results have persistently shown that one of the two techniques is better. These techniques can be presented through different forms: for example, for the simple weighting, several sliders can be used, one for each factor, with an imposed total weight to reach, and for the cross weighting, a cross table with two drop-down lists may be used, with one list to select which factor is more important between the two factors 'row x column', and the other to assign the value of this "sub-relative" importance between the "row factor" and the "column factor". Figures 5.29 We propose in the step 3.4 to run the user evaluations prepared in the step 3.3. First, the VR developer must organise the user evaluations with some participants that are domain-specific experts, and must define an experimental protocol to follow for these user evaluations on the usability of interaction techniques. During the experiment, they must take the measures defined in the step 3.3, one, or several if necessary, for each quality factor selected in the same step.

Next, the VR developer must calculate the global score of usability, taking into account the relative importance of each quality factor through the weighting scores, previously defined either by the participants of the experiment or by a VR expert -eventually themselves.

Then, the scores obtained using different interaction techniques with the different prototypes must be compared. From the results of this comparison, it is possible to decide about the final appropriate interaction techniques in terms of usability to be used in the final VR application that addresses the original domain-specific task. This VR application is the final output obtained following our methodology. Figure 5.31 summarises the step 3.4 mechanism.

Conclusions

To summarise, we presented here the step 3 of our methodology, which aims for the creation of VR prototypes and for running user evaluations on the usability of the VR interaction techniques developed here. In this step, we proposed to follow four sub steps: in the step 3.1, the choice of the VR interaction techniques to be prototyped must be done by a VR developer, based on the proposals obtained in the step 2 and on the other constraints mentioned by the end-users such as the devices to use; then, in the step 3.2, the developer must create some VR prototypes; next, in the step 3.3, the developer must prepare the user evaluations about usability, and finally, in the step 3.4, the user experiments must be run and the comparison of the scores obtained gave the VR interaction techniques to use in the final VR application.

To conclude, in this step, we provided a process to follow for the user evaluations. This step 3 allows for the closure of our task-centred methodology. An example of application of this process, accompanied with all its results, is given in the appendix B of this thesis document.

Conclusions on our methodology

We provided here a new task-centred design methodology for the design of VR interaction techniques. We proposed a methodology in three main steps: it consists of, in the first step, building a model of the domain-specific task, then, in the second step of determining some proposals of VR interaction techniques, and, in the final step, of creating and evaluating prototypes of VR applications with the interaction techniques proposed in the previous step.

The step 1 has been designed to allow for the decomposition of a main user task into primitive tasks by domain-specific experts who do not have neither task analysis expertise nor VR expertise.

Similarly, the step 2 has been designed to allow domain-specific experts to determine proposals of VR interaction techniques for a task, without having VR expertise. These two steps have been built

with semi-automated systems that aim to address our research questions, and thus to allow for the verification of our hypotheses.

Additionally, about the step 3 of our methodology, which allows for the obtaining of concrete VR applications through the development and the evaluation of VR prototypes with a VR developer, the content of the appendix B of this thesis document shows how it can be followed and executed for an 5.5. CONCLUSIONS ON OUR METHODOLOGY AEC case study.

Finally, once we have built this methodology and its associated semi-automated systems, we must verify our hypotheses, which are, as mentioned above, directly linked to the steps 1 and 2 of our methodology. To do that, these two steps must be executed by some domain-specific experts in an experiment, to evaluate our methodology and thus our hypotheses, based on the criteria that we gave in the chapter 4. This experiment is shown in the next chapter 6, on two AEC case studies with AEC experts. To participate to this experiment, these AEC experts had to consult a practical guide that was provided to them, which had been built for explaining to domain-specific users how to use and follow our methodology. This practical guide is available in the appendix A of this thesis document.

Chapter 6

Evaluation of our methodology: an experiment with AEC experts

Objectives

Once we had built our task-centred methodology for the design of VE interactions, it was necessary to evaluate it. A required step for this evaluation was to write a practical guide of our methodology -available in the appendix A of this thesis document, and this guide had to be intended for domainspecific experts. Then, using this practical guide, these domain-specific experts were thus able to participate to the experiment that we conducted here to test and evaluate our methodology.

The objective of this experiment presented in this chapter was to proceed to the evaluation of our methodology, based on the three criteria that have been given in the chapter 4: 1) the methodology is usable by the domain-specific professionals, 2) in autonomy, and 3) the methodology allows for the obtaining of results similar to the ones obtained with a traditional user-centred design methodology. Thus, in this experiment with domain-specific professionals -AEC professionals here in the scope of our thesis, we aimed to observe how the steps 1 and 2 of our task-centred design methodology could be followed and executed by them. Thanks to such observations, we could verify or reject thus our first two criteria of evaluations, of being usable, and of being usable in autonomy. Moreover, we also aimed to evaluate and compare the results that they obtained using our methodology, versus their results obtained with a traditional user-centred design one, to evaluate thus our third criterion of evaluation, about the similarity of results.

For this purpose, we organised an experiment with two AEC case studies, in which two AEC professionals had to follow a design process for obtaining a VR application for each case study, once following our methodology using our guide for one case, and once by following a traditional user-centred design methodology for the other case.

Finally, as mentioned above, it is important to note that this experiment focused on the evaluation of the results obtained in the steps 1 and 2 of our methodology rather on the step 3 of prototyping, since our hypotheses about our methodology have a focus on these two steps. Nonetheless, in the appendix B of this thesis document, we present how our step 3 could be followed and executed, by building VR applications for one of the two case studies that we used here in this experiment, by prototyping the VR interaction techniques according to the proposals obtained here in this chapter 6 with the AEC professionals, and by conducting user evaluations about the usability of these interaction techniques.

EVALUATION, CRITERIA, AND NUMERICAL LEVELS LINKED TO THE VALUES OF THE CRITERIA

Evaluation, criteria, and numerical levels linked to the values of the criteria

In this evaluation of our methodology done in this experiment, first, about the criterion of "being usable by domain-specific users", a first way of evaluating it here will be to check if the users have succeeded in following and executing entirely the steps 1 and 2 of our methodology, accompanied by their subjective feedback about our methodology collected during the experiment thanks to the recording of the work sessions. Moreover, we will compare here the time spent by the users with our methodology and the traditional one with a VR expert. In both cases, the amount of time measured here will not take into account the preparation time, i.e. using our methodology, the reading time of our guide, and using a traditional methodology, the time spent by the VR expert to explain how the meeting would take place and with which objectives. This can be explained by the fact that, with both methodologies, this preparation time would only be necessary the first time(s) that a domainspecific expert would use it, and not for its next uses. Finally, about our usability criterion, in this experiment, an amount of time lower than 133% of the time spent -i.e. the time spent + 1/3 of this time, with the traditional methodology, which is guided and led by the VR expert, would indicate that our methodology is usable, otherwise it would indicate that this is not usable (boolean values).

Next, about the autonomy, we will take into account the number of times when the users asked for help during the experiment when they used our methodology. In this experiment, a number equal or lower than 3 questions for each step -our steps 1 and 2 -would indicate that our methodology would have been used in autonomy by the domain-specific users, otherwise not in autonomy (boolean values).

Finally, about the criterion of the similarity of the results, this experiment would aim to compare here the results for the design choices made for the interactions, i.e. the specifications about the interactions, which are defined in these first two steps of methodology. With both methodologies, the following elements could be obtained and then compared:

• a description of the functionalities of the VR solution

• a list of the VR interactions that are required in the VR solution

• a set of appropriate -in terms of usability -characteristics for each VR interaction technique,

A WEBSITE AS A CONCRETE SUPPORT FOR THE EXPERIMENT according to the task

• a set of concrete proposals of VR interaction techniques, for each required VR interaction, according to the task In this experiment, 75% -or more -of similarity on the content obtained for these four components between the results obtained with the two methodologies would indicate the similarity of the results -value: similar, otherwise it would indicate that the criterion must take the value not similar (boolean values).

6.3 A website as a concrete support for the experiment

Overview of the website

For this experiment, a website has been createdhttps://pierreraimbaud.github.io/guideVR -to allow for the execution of the steps 1 and 2 of our methodology. This means that the two AEC professionals had to follow our guide -available in the appendix A of this thesis document, and to execute the required actions for each step and sub-step on this website. This website, as a support for this experiment, had two main advantages: it was easily accessible to our users, and it was possible to implement directly our semi-automated systems within this website.

We want to present here how our website works and how to use it, as an example of a concrete support for our practical guide. This website allows for building the model of a domain-specific taskour step 1, and for determining proposals of VR interaction techniques -our step 2. To summarise, it allows for the obtaining of the specifications of the VR interaction techniques according to a task to be performed in VR, and this, without having VR expertise.

Step 1 on the website

To allow the domain-specific users to perform the step 1 as it is described and explained in our guide, the website contains a form must be filled in. Figure 6.1 and Figure 6.2 show this form.

The users must fill in first the main task of their case study, and then they must proceed to its decomposition by expressing the subtasks, the activities, the operations and finally the primitive tasks that compose this main task. Following the guide, some fields are reserved for the verbs, which

A WEBSITE AS A CONCRETE SUPPORT FOR THE EXPERIMENT

represent the action, and others for the complements, which represent the target of the action. A list of verbs that can be used to express a subtask, an activity, an operation, or a primitive task, is provided for each field, to guide the decomposition. Moreover, suggestions of verbs are automatically done, from a level to its next one, following the semantic rules given in the appendices of the guide. Finally, it can be noted that a feedback of the decomposition is given simultaneously using the representation of a hierarchical tree, to facilitate to the users the understanding and the verification of the decomposition they are making. The results of completing this whole form for the step 1 are the model of the domainspecific task, represented by the hierarchical trees, and the set of primitive tasks that compose this main task.

Step 2 on the website

Once the user has completed the step 1 and validated its results, the step 2 begins automatically on the website. Indeed, about the step 2.1, described as automatic in our guide, the split between verbs and complements has already been done de facto, as the user has filled in them separately in the step 1. Then, each verb chosen for a primitive task is automatically associated to a type of VR interaction, e.g. take = selection, or travel = navigation. Finally, this information is shown to the user, for each motor primitive task, as well as the primitive task characteristics, directly issued from the complement written by the user. Figure 6.3 shows the step 2.1 results for some examples of primitive tasks.

A WEBSITE AS A CONCRETE SUPPORT FOR THE EXPERIMENT

Next, once everything has been filled for the step 2.2 and has been validated by the user, the step 2.3 is automatically done. For each VR interaction, the recommended characteristics for an appropriate VR interaction technique in terms of usability are generated and shown in a table, thanks to an expert system integrated in our website. This expert system contains all the VR expert rules given in the appendices of the guide. Finally, in the same way, the step 2.4 is automatically done, immediately after the step 2.3 has been completed. Thus, based on the data shown in the table obtained thanks to the step 2.3, proposals of VR interaction techniques that are appropriate to the task -in terms of usability -are given and shown in the website. Figure 6.6 shows an example of results obtained in the step 2.4 using the website.

Conclusion on the website

This kind of support allows for the completion of the steps 1 and 2 by some domain-specific professionals, in autonomy and without requiring to have VR expertise. Thanks to it, from their original task, they can obtain a model of their domain-specific task, and the specifications about the VR interactions, i.e. the list of required VR interactions, the recommended characteristics of the VR interaction techniques, and proposals of VR interaction techniques that are appropriate in terms of usability. Finally, after that, they may perform the step 3 of development and evaluation with a VR developer, as shown in the next chapter, for one of our two case studies. In the civil engineering literature, many studies and reviews identified the AEC industry as one of the most dangerous industry for the workers, and considered that to improve the safety on the worksites is a current main gap [194] [195] [83]. For the safety of the workers, it is crucial to reduce the number of accidents and their gravity, since the accident rate is higher in the AEC industry than in other industries in many countries, and a non-negligible part of those accidents are highly severe or fatal [4] [44] [85]. To prevent such accidents, this is necessary to improve the understanding of the AEC hazards [START_REF] Yilmaz | Analysis of occupational accidents in construction sector in turkey[END_REF], to increase the hazards' knowledge that all the stakeholders of a building project have, and to improve the safety processes [101] [164].

Concretely, to prevent the accidents, the hazards that are related to the construction of a building must be detected, identified, and mitigated. This can be done by safety inspectors on the worksite during the construction phase. Nonetheless, it would be better to act during the earliest stages of the construction process: indeed, it could be done preventively during the design phase, for example by 6.4. CASE STUDY 1: PREVENTIVE HAZARD IDENTIFICATION applying a design technique called design for safety [START_REF] Xiaer | Design for safety (dfs) and building information modeling (bim): A review[END_REF]. Preventive hazard identification allows for the adoption and the implementation of safety measures, by applying correctives within the design planning of the construction and the design itself. For that, the use of BIM methodology and tools can help by improving the understanding of the hazards and of their potential solutions. This has been particularly studied using BIM authoring tool to prevent falls by corrective designs [START_REF] Zhang | Bim-based fall hazard identification and prevention in construction safety planning[END_REF]. This can be explained since falls are the most important hazard for the workers in terms of number of accidents that occur and in terms of number of people exposed [START_REF] Zhang | Building information modeling (bim) and safety: Automatic safety checking of construction models and schedules[END_REF].

Other kinds of hazards can also be frequent and grave, such as electrocution or caught-in/caughtbetween hazards, but notably struck-by hazards [75]. Struck-by hazards mostly happen in dynamic environments where workers and vehicles are in movements, and then a collision between them occurs and results in severe injuries. Even if objects falling were a subcategory of struck-by hazards, the related accidents would be hard to predict since they would be caused by unexpected movements on a worksite. Nonetheless, they can be prevented by avoiding disorder in the worksite, and can be mitigated by using personal protective equipment [7]. Oppositely, the accidents related to collisions with vehicles could be predicted and avoided, since the vehicles and machines should follow movements that have been planned in the construction planning. Thus, the hazards related to them could be corrected thanks to the establishment of safer planning. Currently, the BIM 4D simulations, which

show the spatial organisation of the worksite over the time, usually built by the construction manager for specific critical periods of time, have improved the quality of the safety planning.

Task of the case study: preventive hazard identification

The use of BIM, and notably of 4D simulations, can contribute to improve the preventive actions done before the construction, for the safety of the future worksite. Nonetheless, to prevent the hazards, notably the falls and struck-by hazards, this kind of simulation could also take place into immersive VE. Indeed, we think that such environment could help the safety inspectors to detect and understand these hazards, which are related to dynamic events that come from the workers and from some machines and vehicles. VR applications could be used by safety inspectors for reviewing a construction planning before starting the construction. This kind of application would be beneficial to the safety inspectors for performing this task of hazard identification, in a preventive virtual review of the worksite.

Based on these elements, a main objective in the AEC industry about the hazards and the acci-

CASE STUDY 2: DESIGN REVIEW OF A PLANT ROOM -SPACE REQUIREMENTS ASPECT

dents that they cause is to avoid accidents not only on the worksite, but also since the phase of the construction planning. To reach this objective, a main task for the safety inspectors is to inspect a virtual worksite to detect preventively the hazards. This task is thus the one studied here during this test experiment on our methodology, in the first case study.

6.5 Case study 2: design review of a plant room -space requirements aspect

Description of the case study

Design reviews are essentials in AEC projects since they allow for the verification of norms and the conformity of the desired design [START_REF] Ventura | A design review session protocol for the implementation of immersive virtual reality in usability-focused analysis[END_REF]. As expressed in their name, they are necessary before starting the construction phase of the project, to make decisions preventively. Design reviews can have different focus, for example, it is possible to make modifications on incompatible, unexpected or incorrect designs [START_REF] Seo | Collaborative process to facilitate bim-based clash detection tasks for enhancing constructability[END_REF]. This is because they can different purposes, such as clash detection [170] or health and safety purpose [START_REF] Xiaer | Design for safety (dfs) and building information modeling (bim): A review[END_REF]. Additionally, it has been shown in the literature that the use of BIM gives benefits for performing these reviews, notably since it allows for the centralization of the data and their continuous update [66]. Nonetheless, as noted by Zaker et al. [START_REF] Zaker | Virtual reality-integrated workflow in bim-enabled projects collaboration and design review: a case study[END_REF], design reviews can be improved if they are performed in virtual reality. Indeed, it has been shown that, notably thanks to the immersion provided by such environments, VR can be beneficial for design reviews in the AEC industry [17] [182].

Based on these considerations, this case study is about design review, with the specific angle of the assessment of space requirements on plant rooms [46], also called mechanical rooms, or even electrical room, since they mainly contain mechanical, electrical, and plumbing elements. This case study addresses issues from several aspects of the design of a construction, notably the correctness of the design [START_REF] Zadeh | Review of bim quality assessment approaches for facility management[END_REF], the physical requirements [46], the maintenance requirements [80], and safety requirements [START_REF] Zhou | Construction safety and digital design: A review[END_REF].

Task of the case study: design review of a plant room -space requirements

Since VR can be beneficial for this case study, a virtual reality application could be designed to perform this kind of design review [START_REF] Yang | Requirements of integrated design teams while evaluating advanced energy retrofit design options in immersive virtual environments[END_REF]. One main objective in a design review for space requirements 6.6. EXPERIMENTAL PROTOCOL aspects is to ensure the conformity of the design, in the meaning of respecting the norms, which are mainly on safety considerations. This induces for the civil engineering in charge of the review -a design coordinator in most cases -to control the distances between the elements present in the plant room, for checking if the norms are respected. This is the task studied during our experiment with our methodology, in this second case study.

Experimental protocol

In this experiment, we aimed to evaluate our methodology when it is followed and executed by AEC professionals, to observe how they use it -usability criterion, and to evaluate if they are comfortable with it in autonomy -autonomy criterion. We also aimed to compare the results that they would obtain using it with the results that they would get when they follow and apply a traditional user-centred design methodology for designing VR interaction techniques, to evaluate our similarity criterion. Thus, to conduct such experiment, we followed this experimental protocol, which involves two AEC professionals and a VR developer.

First, during this experiment, the two case studies presented above were explained in details to the two AEC professionals. This was necessary in order to prepare them for playing the role of a domain-specific professional that needs a VR application for these cases during the experiment.

Then, it was told to each AEC professional that their objective was to succeed in having the specifications/the design of the VR interactions required in the VR application for the two case studies.

We explained to them what these specifications had to include: the description of the functionalities of the VR application, a list of the VR interactions and a set of appropriate characteristics for each required VR interaction technique and concrete proposals of appropriate VR interaction techniques, in terms of usability.

Next, we explained to each AEC professional that they would have to follow our methodology for one case, and that they would have to follow a traditional user-centred design methodology for the other case. They were told that each of them would the same process, but with the case studies and the methodologies swapped. This means that this experiment followed a within-subject design. About that, it should be highlighted that the order between the methodologies was counterbalanced.

Finally, to follow and execute the steps 1 and 2 of our methodology, the AEC professionals had

RESULTS FOR THE CASE STUDY 1 -PREVENTIVE HAZARD IDENTIFICATION

two elements: our practical guide -available in the appendix A of this thesis document, to understand and follow the procedure, and our website to complete each step. Thanks to these elements, they were able to obtain the expected outputs. For the traditional user-centred design methodology, we asked them to follow a methodology, based on the ones present in the literature [57] [25], which contained the following traditional steps: 1) user task analysis, and 2) VR expert recommendations/guidelines. In this case, according to the traditional approaches, these two steps had to be done through discussions and interviews between the AEC professionals and a VR developer. For this purpose, we organised some work sessions between the two AEC professionals and a VR developer, external to our research, who had accepted to participate to this experiment. Thanks to these sessions with the VR developer, the AEC professionals were able to obtain the expected results, this time following a traditional usercentred design methodology.

During the two sessions of design of the VR interaction techniques, either done by following our methodology or the traditional one, the AEC professionals were recorded in order to keep all the data about how they followed these methodologies -remarks, doubts, time spent, questions asked etc.

Additionally, in the case of the use of our methodology, the AEC professionals were able to export their results from the website as a text file, which contained all the output specifications. In the case of the traditional methodology, an online document was shared to all the stakeholders of this experiment, and was used during the meetings with the VR developer to keep all the specifications. In the next section, we present the data obtained by each AEC professional with the two methodologies on each case study.

Results

for the case study 1 -preventive hazard identification

Completion of the steps of the methodologies and time spent

For this case study 1, the two AEC professionals used, followed and performed entirely the steps 1 and 2 of our methodology, and of the traditional methodology too. Then, about the time spent by the professionals, the AEC professional who used our methodology spent 100 minutes in total, and the AEC professional who used the traditional methodology spent 75 minutes.

Autonomy and questions for completing the steps

For this first case study, using our methodology, the AEC professional asked 3 questions in the step 1: one about the number of subtasks at the first level of task decomposition, one about the available subtask of closing/finalising, and one about the complement that must be added to the verb chosen to describe each task. In the step 2, the AEC professional asked 2 questions: one about the navigation interaction characteristic of "target-finding objective", and one about the manipulation interaction characteristic of "kind of required movements".

Functionalities

With our methodology, the following functionalities have been obtained, directly issued from the subtasks given in the hierarchical model built by the AEC professional in the step 1:

• to be able to locate hazardous elements in the worksite

• to be able to understand the relationships between these hazardous elements and the workers

• to be able to conduct an accurate hazard assessment according to the state of the virtual worksite by signalling the hazards in the application With the traditional methodology, the AEC professional has obtained the following functionalities:

• to be able to detect hazardous zones in order to identify/locate them

• to have a global view of the worksite to be able to understand the hazards according to its state and to find my way around once the real construction would start (in particular where the hazards had been identified in the virtual inspection)

• to be able to signal these hazardous zones within the application in order to leave a trace of their location

• to be able to report my work in order to have a final assessment of the exploration

List of required interactions

With our methodology, the AEC professional has obtained the following list of required interactions (motor only here):

• move in the whole worksite

• move -short moves, to refine decision-making about a worker

• activate the functionality to signal workers in hazardous situations

• target workers in hazardous situations

• place/orient the machines present on the worksite With the traditional methodology, the following list of required interactions (motor only here) has been obtained:

• move in the whole worksite

• move -short moves, to refine decision-making about a worker

• activate the functionality to signal workers in hazardous situations

• target workers in hazardous situations

• activate the functionality to send the report at the end the inspection

VR interaction techniques recommended characteristics

The following Figures 6.7, 6.8, 6.9, 6.10, 6.11, and 6.12 show the values of the characteristics of the VR interaction techniques that have been recommended with each methodology, in terms of being appropriate for the usability of the interaction. The results obtained with the traditional methodology, initially stored in a text report document of the meetings with the VR developer, have been put to the same format than the one of the website, to allow for a visual comparison of the results.

In the first four figures, the same interactions had been obtained in both methodologies, thus in all these figures, the result obtained with our methodology is on the top, whereas the result obtained

RESULTS FOR THE CASE STUDY 1 -PREVENTIVE HAZARD IDENTIFICATION

with the traditional methodology is on the bottom. The last two figures show the results for interactions present in only one of the two methodologies. The figures are presented in the order than the interactions were listed above, for the required interactions.

The use of green colour indicates that the values recommended using both methodologies is the same, whereas the use of orange or red indicates a difference -orange when the difference is "compatible", and red when "incompatible". This distinction between these two kinds of differences is detailed in the discussion section 7.9.

Figure 6.7: The VR interaction techniques characteristics for the interaction "move in the whole worksite" Figure 6.8: The VR interaction techniques characteristics for the interaction "move -short moves" IDENTIFICATION Figure 6.9: The VR interaction techniques characteristics for the interaction "activate the functionality to signal workers" Figure 6.10: The VR interaction techniques characteristics for the interaction "target workers in hazardous situations"

RESULTS FOR THE CASE STUDY 1 -PREVENTIVE HAZARD IDENTIFICATION

Figure 6.11: The VR interaction techniques characteristics for the interaction "activate the functionality to send the report" Figure 6.12: The VR interaction techniques characteristics for the interaction "place/orient the machines present on the worksite" 6.7. RESULTS FOR THE CASE STUDY 1 -PREVENTIVE HAZARD IDENTIFICATION

Proposals of VR interaction techniques

With our methodology, the AEC professional has obtained the following proposals of VR interactions techniques:

• move in the whole worksite: free pointing steering technique (human speed transition) on the 3D environment, or on a 2D map or a list

• move -short moves, to refine decision-making about a worker: natural walking, omni-directional treadmill, joystick

• activate the functionality to signal workers in hazardous situations: physical button, button in interface

• target workers in hazardous situations: raycast or other virtual pointer, or go-go (virtual hand with anisomorphic movement)

• place/orient the machines present on the worksite: world-in-miniature for rotations, and for translations experiments are necessary to compare direct and indirect interaction techniques (raycast, virtual hand, world-in-miniature)

With the traditional methodology, the other AEC professional has obtained the following proposals of VR interactions techniques:

• move in the whole worksite: teleportation using a 2D map

• move -short moves, to refine decision-making about a worker: natural walking or joystick, or teleportation -a recommendation made by the developer is to test the two interaction techniques

• activate the functionality to signal workers in hazardous situations: physical button

• target workers in hazardous situations: raycast

• activate the functionality to send the report at the end the inspection: physical button 6.8 Results for the case study 2 -design review of a plant room 6.8.1 Completion of the steps of the methodologies and time spent

For this case study 2, the two AEC professionals used, followed and performed entirely the steps 1 and 2 of our methodology, and of the traditional methodology too. Then, about the time spent by the professionals, the AEC professional who used our methodology spent 80 minutes in total, and the AEC professional who used the traditional methodology spent 95 minutes.

Autonomy and questions for completing the steps

For this second case study, using our methodology, the AEC professional asked 3 questions in the step 1: one about the subtask of acting/performing, one about the use of "other" for the verb of a task, and one about the place of the tasks with the use of real tools. In the step 2, the AEC professional asked 3 questions: one about the navigation interaction characteristic of "target-finding objective", one about the navigation interaction characteristic of "spatial objective", and one about the selection interaction characteristic of "environment state".

Functionalities

With our methodology, the following functionalities have been obtained, directly issued from the subtasks given in the hierarchical model built by the AEC professional:

• to be able to locate elements a priori close to each other in the plant room

• to be able to measure the distance between two elements

• to be able to report non-regulatory distances

• to be able to end the review by sending the assessment of the review With the traditional methodology, the AEC professional has obtained the following functionalities:

• to be able to identify potential areas of design error in order to avoid future issues during the next phases

RESULTS FOR THE CASE STUDY 2 -DESIGN REVIEW OF A PLANT ROOM

• to be able to measure the distance between two elements in order to check whether this distance is regulatory or not

• to be able to report non-regulatory distances in order to draw up a list of errors that need to be corrected

• to be able to capture an image of the areas that are reported as non-regulatory in order to provide a report and make it easier to understand

• to be able to end the review by sending the assessment of the review

List of required interactions

With our methodology, the AEC professional has obtained the following list of required interactions (motor only here):

• move in the plant room

• activate the functionality of taking a measure

• target two points on the objects where the measure must be taken (only objects close to the user)

• target two points on the objects where the measure must be taken (objects close and far to the user)

• activate the functionality of annotating a measure

• target the measure to add the annotation "to modify"

• activate the functionality of sending the report of the review With the traditional methodology, the other AEC professional has obtained the following list of required interactions (motor only here):

• move in the plant room

• activate the functionality of taking a measure

RESULTS FOR THE CASE STUDY 2 -DESIGN REVIEW OF A PLANT ROOM

• target two points on the objects where the measure must be taken (only objects close to the user)

• target two points on the objects where the measure must be taken (objects close and far to the user)

• activate the functionality of annotating a measure

• target the measure to add the annotation "to modify"

• activate the functionality of capturing a screenshot of the elements at non-regulatory distances

• activate the functionality to send the report of the review

VR interaction techniques recommended characteristics

The following Figures 6.13, 6.14, 6.15, 6.16, 6.17 The first seven interactions have been determined in both methodologies, thus in all these figures, the result obtained with our methodology is on the top, whereas the result obtained with the traditional methodology is on the bottom. The last figure shows the interaction of capturing a screenshot, identified only with the traditional methodology. The same colour code than in the case study 1 is used here. ROOM Figure 6.13: The VR interaction techniques characteristics for the interaction "move in the plant room" Figure 6.14: The VR interaction techniques characteristics for the interaction "activate the functionality of taking a measure"

RESULTS FOR THE CASE STUDY 2 -DESIGN REVIEW OF A PLANT ROOM

Figure 6.15: The VR interaction techniques characteristics for the interaction "target two measure points (close)" Figure 6.16: The VR interaction techniques characteristics for the interaction "target two measure points (close and far)"

RESULTS FOR THE CASE STUDY 2 -DESIGN REVIEW OF A PLANT ROOM

Figure 6.17: The VR interaction techniques characteristics for the interaction "activate the functionality of annotating a measure" Figure 6.18: The VR interaction techniques characteristics for the interaction "target the measure to add the annotation "to modify""

RESULTS FOR THE CASE STUDY 2 -DESIGN REVIEW OF A PLANT ROOM

Figure 6.19: The VR interaction techniques characteristics for the interaction "activate the functionality to send the report" Figure 6.20: The VR interaction techniques characteristics for the interaction "activate the functionality of capturing a screenshot"

Proposals of VR interaction techniques

With our methodology, the AEC professional has obtained the following proposals of VR interactions techniques:

• move in the plant room (navigation): natural walking, omni-directional treadmill, joystick in the case where the user has the control of its speed, or gaze-directed "guided tour" in the case where the speed control is automatic

• activate the functionality of taking a measure (selection): physical button, button in interface

• target two points on the objects where the measure must be taken -only objects close to the user -(selection): raycast or other virtual pointer

• target two points on the objects where the measure must be taken -objects close or far to the user -(selection): raycast or other virtual pointer, or virtual hand (go-go because of far objects)

• activate the functionality of annotating a measure (selection): physical button, button in interface

• target the measure to add the annotation "to modify" (selection): the same tool than the one used for the measures

• activate the functionality to send the report of the review (selection): physical button, button in interface

With the traditional methodology, the other AEC professional has obtained the following proposals of VR interactions techniques:

• move in the plant room (navigation): natural walking

• activate the functionality of taking a measure (selection): physical button

• target two points on the objects where the measure must be taken -only objects close to the user -(selection): virtual hand

• target two points on the objects where the measure must be taken -objects close or far to the user -(selection): raycast

• activate the functionality of annotating a measure (selection): physical button

• target the measure to add the annotation "to modify" (selection): the same tool than the one used for the measures (raycast or hand depending on the case)

• activate the functionality of capturing a screenshot of the elements at non-regulatory distances (selection): physical button

• activate the functionality to send the report of the review (selection): physical button 6.9 Discussion

Usability criterion about our methodology

First, we can note that, for the two case studies, the two AEC professionals used, followed and performed entirely the steps 1 and 2 of our methodology. Additionally, they expressed positive subjective feedback when they used our methodology, particularly about the step 1 of task decomposition. This result tends to indicate that our methodology is usable.

Moreover, we can analyse here the results obtained about the time spent by the professionals with each methodology. If we compare the time obtained for one case study with the two methodologies, between the two professionals, for the case study 1, there is a difference of 33% -100 min versus 75 min, i.e. with our methodology the time spent is 133% of the time spent with the traditional one; for the case study 2, there is a difference of -16% -80 min versus 95 min, i.e. with our methodology the time spent is 84% of the time spent with the traditional one. If we compared the results obtained by one AEC professional on its two cases using one methodology for each one, for the first AEC professional, the time spent is 105% of the time spent with the traditional one; for the second AEC professional, the time spent is 107% of the time spent with the traditional one. As a result, in any cases, the time spent with our methodology is lower than 133% of the time spent with the traditional methodologywhich is leaded by the VR expert.

Based on these results, the usability criterion about our methodology has for value "usable", and thus this part of our hypothesis H0 is verified here.

6.9. DISCUSSION issues" may contain the second functionality of "measuring". Thus, the naming seems to be clearer in the first case, with our methodology, for these two functionalities. In any cases, the results are consistent between both methodologies about the following four functionalities of searching potential issues, of measuring to confirm or reject them, and of reporting them.

To conclude, only one functionality obtained for this case study is different between the two methodologies, and the other four functionalities are similar. This means that 80% -1/5 here -of similar functionalities have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the functionalities for this case study.

6.9.4 List of required interactions -similarity criterion 6.9.4.1 Case study 1: hazard identification

In the case of hazard identification, four interactions in common have been found with the two methodologies: to move in the whole worksite, to move -short moves (to refine decision-making about a worker), activate the functionality to signal workers in hazardous situations, and to target workers in hazardous situations. Then, with both methodologies, an extra interaction has been found: with our methodology, the AEC professional expressed the need of "placing/orienting the machines present on the worksite", and with the traditional methodology, the other AEC professional expressed the need of "activating the functionality of the end of inspection / sending of the report".

This means that 80% -4/5 for this case study -of similar interactions have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the list of required interactions for this case study.

Finally, we can give some comments about these two additional interactions. About the presence/absence of the interaction of placing machines, this can be explained by the interpretation of the users' needs that each AEC professional made: one professional imagined that driving the machines would help to detect more situations of struck-by hazards, whereas we can think that the other imagined that in the application the data from 4D simulations would be present, and may have though that the hazardous situations could be found with the automated movement of the machines. And about the "end functionality/sending report", this can be explained since this is not an interaction that is proper to this case study and its VR application, and it is likely that this interaction has been considered as implicitly present by the AEC professional that did not mention it.

6.9.4.2 Case study 2: design review of a plant room

In the case of design review of a plant room, seven interactions have been found in common with the two methodologies: to move in the plant room, to activate the functionality of taking a measure, to target two points on the objects where the measure must be taken (only objects close to the user), to target two points on the objects where the measure must be taken (objects close and far to the user), to activate the functionality of annotating a measure, to target the measure to add the annotation "to modify", and to activate the functionality to send the report of the review. Only one supplementary interaction has been found with the traditional methodology "activate the functionality of capturing a screenshot", which could be considered as a sub interaction of the one of sending the report.

This means that 88% -7/8 for this case study -of similar interactions have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the list of required interactions for this case study.

6.9.5 VR interaction techniques recommended characteristics -similarity criterion 6.9.5.1 Overview of the results and possible kinds of differences of results

Considering both cases, about the recommended characteristics for the VR interaction techniques, the two AEC professionals have succeeded in obtaining such kinds of results with both methodologies.

Moreover, they indicated to us that it was easy to execute this step by following our methodology and by using our website. Then, about the quality of results, it is possible to analyse and compare the VR interaction techniques characteristics obtained with our methodology and with the traditional one.

First, a global observation reveals that most of the characteristics obtained with both methodologies are the same, for the majority of the VR interaction techniques. Nonetheless, we can notice some differences of recommendations for some characteristics. To analyse these differences, it is important to take into account the following consideration: there are two kinds of differences here, the 6.9. DISCUSSION objects, an isomorphic relationship is recommended with the traditional methodology, whereas with our methodology both isomorphic or anisomorphic relationships are recommended for close objects, and for farther objects this value for this relationship is undetermined. Both recommendations are thus compatible. Finally, for the case of targeting measure points on objects far from the user, the recommended selection tool obtained with the traditional methodology is a raycast, whereas with our methodology either the hand or the raycast were recommended, with a slight preference for the raycast. The results are thus compatible.

6.9.5.3 "Incompatible differences" in the results -cases 1 and 2

For the case study 1 of hazard identification, only one incompatible difference is present, for the "large scale" navigation task, i.e. the global exploration of the worksite. Indeed, with our methodology, the AEC professional has obtained as recommended characteristic for the speed order of magnitude the value "human speed", whereas the value "infinite" had been recommended in the results obtained when following the traditional methodology.

Nonetheless, this difference can be balanced: indeed, for the local navigation -when the inspector proceeds to a more precise inspection in a specific zone, the same value for the speed -human speed -has been recommended with both methodologies. Moreover, coming back to the global navigation, during the meeting with the VR developer in the traditional method, the AEC professional explained that, as for them, "human speed was important and mandatory for local inspection, but should also be used to proceed to a global verification of the whole worksite, since this speed is better for avoiding missing hazards than infinite speed, which could be useful as a first approach, to navigate quickly, for a first overall inspection". This declaration of the AEC professional means that the two recommendations -human speed and infinite speed -could be considered both, by splitting again the "global navigation" into two different subtasks of "first quick inspection" and "global verification".

For the case study 2 of design review of a plant room (space requirements), only one incompatible difference is present, for the selection task of targeting the two points for a measure, but only in the case when the objects are only at a short distance. Indeed, it had been proposed to the AEC professionals to think about two possibilities of VR applications for two cases: in a tight plant room, with all the objects within the reach of an arm (restricted case of our case study), and in a more spacious plant room -with more installations or for example in a boiler room, with some objects 6.9. DISCUSSION within the reach of an arm and others out of this reach (generic case of our case study).

In this restricted case of our case study, the AEC professional has obtained with our methodology as recommended characteristic for the selection tool the value "raycast", whereas when following the traditional methodology they obtained the value "hand", as a recommendation from the VR developer.

This difference can be explained since, traditionally, some recommendations in the VR literature were indicating that the use of the hand was recommended within the reach of the arm. Actually, this assumption is not incorrect, but it is limited to some cases, in particular when selecting small objects -size of the hand or less -in a sparse environment [START_REF] Yu | Target selection in head-mounted display virtual reality environments[END_REF]. Yet, in this experiment, the objects are not of this size -and the environment may be eventually dense in objects, and in this case the raycast is recommended [START_REF] Steed | Evaluating immersive experiences during covid-19 and beyond[END_REF], or at least show equal or slightly better usability [127]. These last experiments and the results that they obtained explain why our expert system gave this recommendation, and explain why the VR developer proposed a different recommendation following the "general case recommendation".

To summarise, the difference in the first case study may be balanced by the comment made by the AEC professional, and finally the results from both methodologies agree on the fact that a human speed value is preferable when the inspection needs to be made in details, to avoid forgetting hazards in the worksite. For the second case study, the difference is present in a restricted case or a sub case of the case study, where all the objects in a plant room are within the arm reach. If we consider the case study in its original and generic form, the raycast as selection tool appears as a recommended in the results obtained with both methodologies -"both hand and raycast, raycast potentially better" with our methodology and "raycast" with the traditional methodology.

Similarity of VR interaction techniques characteristics results

For the case 1, 22 characteristics had to be determined in total for the four interactions obtained in common with the two methodologies. About these 22 characteristics, only one received incompatible values between the two methodologies. This means that 96% -1/22 here -of similar interaction techniques characteristics have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the VR interaction techniques characteristics results for this case study.

DISCUSSION

For the case 2, 31 characteristics had to be determined in total for the seven interactions obtained in common with the two methodologies. About these 31 characteristics, only one received incompatible values between the two methodologies. This means that 97% -1/31 here -of similar interaction techniques characteristics have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the VR interaction techniques characteristics results for this case study.

6.9.6 Proposals of VR interaction techniques -similarity criterion 6.9.6.1 Case study 1: hazard identification

Based on the analysis made on the differences between the characteristics for the VR interaction techniques obtained with the two methodologies, it is predictable that in the same way there have also been few differences between the proposals of VR interaction techniques. Indeed, for this case study, there are proposals in common between the results from the two methodologies for all the interactions, except one. For the navigation interaction in the whole worksite, a free pointing steering technique -on the 3D environment or on a 2D map or list -has been obtained with our methodology, and a teleportation on a 2D map has been obtained with the traditional methodology. Nonetheless, as explained above, during the meeting following the traditional methodology, it has been suggested to use the teleportation with a 2D map for a quick review, and then to use a pointing steering technique without using a 2D map. Thus, the results are consistent between the two methodologies for all the interactions. It would nonetheless be interesting to evaluate whether a 2D map is appropriate in terms of usability or not, as using both methodologies the results have indicated this characteristic as a one to be experimented. In the next chapter, two interaction techniques that differ from this characteristic have been evaluated.

Case study 2: design review of a plant room

For this case study, there are proposals in common between the results from the two methodologies for all the interactions, except one. Nonetheless, as explained when comparing the characteristics for the VR interaction techniques obtained with both methodologies, this interaction is the one of the selection of measure points for only close objects, and in our case study, the objects can be either 6.9. DISCUSSION close or far from the user, thus this difference between the two proposals is not present for our case study. To conclude, the results of proposals of VR interaction techniques are consistent between the two methodologies for all the interactions.

Similarity of proposals of VR interaction techniques results

For the case 1, four VR interaction techniques had to be determined for the four interactions obtained in common with the two methodologies. About these four VR interaction techniques, only one received incompatible values between the two methodologies. This means that 75% -1/4 hereof similar proposals of VR interaction techniques have been determined with the two methodologies.

This percentage is equal to the percentage fixed -75% -for the similarity criterion in this experiment.

Based on that, the similarity criterion is verified for the proposals of VR interaction techniques results for this case study.

For the case 2, seven VR interaction techniques had to be determined for the seven interactions obtained in common with the two methodologies. About these seven VR interaction techniques, only one received incompatible values between the two methodologies. This means that 86% -1/7 here -of similar proposals of VR interaction techniques have been determined with the two methodologies. This percentage is higher than the percentage fixed -75% -for the similarity criterion in this experiment.

Based on that, the similarity criterion is verified for the proposals of VR interaction techniques results for this case study.

6.9.7 Similarity criterion about our methodology: final assessment for H1 and H2 It can be noticed that all the percentages of similarities obtained here are higher than the percentage fixed here to get the value "similar" for this criterion when evaluating our methodology. Thus, these 6.10. CONCLUSIONS ABOUT OUR THREE CRITERIA OF EVALUATION ON OUR METHODOLOGY results imply for the similarity criterion about our methodology to have the value "similar".

As a result, on one hand, these results of similarity for the functionalities and the interactions that have been determined with both methodologies -75%, 80%, 80%, 88% -verify our hypothesis H1.

And on the other hand, the results of similarity for the characteristics of interaction techniques and the proposals of interaction techniques that have been determined with both methodologies -96%, 97%, 75%, 86% -verify our hypothesis H2. Finally, in total, these two results verify the similarity criterion in general, and thus this part of our hypothesis H0 is also verified.

Conclusions about our three criteria of evaluation on our methodology

Based on the analysis of the results obtained in this experiment, our methodology is usable by the AEC professionals, in autonomy, and allows for the obtaining of similar results than the ones obtained using with a traditional methodology. The positive value obtained for this last criterion induces that our hypotheses H1 and H2 are verified, whereas all these positive values for all these criteria induce that our hypothesis H0 is verified.

To conclude, thanks to this experiment with these two AEC case studies, we have been able to evaluate our methodology, and all our hypotheses have been verified according to the results that we obtained here. Additionally, we have been able to observe that the main benefit of our methodology is that this can be followed and executed by domain-specific experts, without having VR expertise, in autonomy and without requiring a VR expert, for these steps 1 and 2 of specifications. Thus, it could be said, that, using our methodology, the domain-specific users can become the main actors of the design process of a VR application, and not only participants of such kind of design process.

Research question addressed

The benefits of the computer sciences technologies and notably of the virtual environment technologies have been shown in the literature for many domains, and in particular, these VE technologies can be used for AEC needs. However, to benefit from a design of this kind of environment that is appropriate to the users' needs, notably in terms in usability, may be an issue. In this sense, user-centred design methodologies for designing VEs have been developed to involve the users in this design process.

Nonetheless, our preliminary experiments on these methodologies through several case studies, and an analytical reading of them led us to the research question about the design of the VE interactions that we addressed in this thesis.

This thesis posed the question of how to allow domain-specific experts -e.g. AEC experts -to design the interactions of a virtual environment without having expertise about virtual environment technologies and methods and without requiring turning to an expert from this field.

Contributions

In answer to this research question, we proposed in our research a task-centred methodology for designing VE interactions that can be used by the domain-specific experts, to define and obtain the design specifications about such VE interactions in autonomy. Our task-centred methodology relies on semi-automated systems that these domain-specific experts can use, without having VE expertise.

We have built these semi-automated systems based on expert knowledge on task analysis [9] [18] [START_REF] Stanton | Human factors methods: a practical guide for engineering and design[END_REF] and on VE interaction techniques [10] [25] [130] that we have analysed, interpreted and adapted for our methodology to address our research question.

This work contributes to the literature on user-centred design methodologies for designing VE interactions, by providing a methodology that is intended for domain-specific experts. Our research adds to what we know about the approaches that can be used to involve the users in the design of their VE application in which they want to perform a task that is specific to their domain. Indeed, Gabbard et al. [57], among others in the literature, had formalised a design process that was centred on the user, thus providing a procedure to follow and its steps, and allowing for the participation of the user in the designing of virtual environments. In comparison to this work, our research places the domain-specific users as the main actor of the design process of a virtual environment, thanks to a 7.3. IMPLICATIONS OF OUR CONTRIBUTION methodology that they are able to follow and execute in autonomy.

Moreover, this methodology contains semi-automated systems that allow for the analysis of the user domain-specific task and for the determination of VE interaction techniques that are appropriate to the user task, in terms of usability. Thanks to these systems, this ensure to obtain with our methodology VE specifications that are similar to the ones obtained following existing user-centred design methodologies that involve VE experts. In our research, our methodology has been evaluated

for these three criteria -being usable by domain-specific experts, in autonomy, and providing results that are similar to the ones obtained with a traditional methodology -and all of these have been verified in an experiment with AEC professionals on two AEC case studies.

Implications of our contribution

Our contribution could be of interest to professionals of the AEC industry, and to domain-specific experts from other fields, since our methodology has been tested and evaluated for AEC tasks, but has a generic structure and components. Our research could improve the involvement of these domainspecific experts in the design process, since they can use and follow our methodology in autonomy.

As a result, our work could increase, in diverse fields, the number of projects that would use virtual environments, since our methodology may encourage domain-specific experts to desire virtual environments, by allowing them to design these VEs themselves.

For this purpose, we provide here, as the appendix A of this document, a practical guide that aims to present and explain how to use our methodology, particularly intended for domain-specific experts.

It should be highlighted that this guide has been used by the AEC experts that have participated to our experiment on the evaluation of our methodology.

Additionally, as the domain-specific experts are able to use in autonomy our methodology to define the specifications about the VE for their future application, they can follow it and execute the corresponding steps, and then they can follow a step of prototyping VE applications and of conducting user evaluations, with the help of a VE developer. To show how this process can be done, we provide here, as the appendix B of this document, a presentation of the application of this step of creation of prototypes and of evaluations on the case study of hazard identification. The prototypes evaluated in the experiment shown in this appendix have been built based on the proposals of VE interaction 7.4. LIMITATIONS techniques that have been obtained by the AEC professional during the experiment done for the evaluation of our methodology.

Limitations

According to the research question, we proposed here a methodology for designing VE interactions with its semi-automated systems, and we evaluated it on three criteria -usability for the domain-specific experts, autonomy, and similarity of results, that have been verified in an experiment.

Nonetheless, two other criteria could be taken into account here for such evaluation, as mentioned in the chapter 4: the robustness and the exhaustiveness.

Indeed, about the robustness, the verification of this criterion would ensure that our methodology could be used even with future VE technologies, i.e. future VE interaction techniques and devices.

The nature of this criterion explains its absence in our evaluation through a direct verification, i.e. by verifying it through the use of our methodology on case studies. Nonetheless, an indirect verification may be done: for our semi-automated system for the determination of proposals of VE interactions, we have built taxonomies for the characteristics of VE interaction techniques. Yet, these taxonomies have been adapted for our system from well-established taxonomies from the literature [23] [26] [130] [10],

and it is likely that these taxonomies had been built with this aim of verifying this robustness criterion.

Thus, this might ensure indirectly the verification of this criterion.

Finally, about the exhaustiveness, it would be interesting to evaluate if our methodology could allow for the obtaining of results for any kind of case study, by considering all the possibilities for the task analysis and for the determination of VE interaction techniques proposals. The verification of this criterion would require to experiment on more case studies from the AEC industry and from other domains, and thus this could be done as future work.

Perspectives for our methodology

As mentioned in the limitations, the main aspect that could be studied as future work on our contribution would be to conduct experiments on our methodology with other professionals from diverse domains and on other case studies, contributing as a result to the evaluation of the exhaustiveness criterion.

PERSPECTIVES FOR OUR METHODOLOGY

From the AEC industry, it could be interesting to consider some case studies in which the domainspecific task belongs to the construction or the maintenance work on the building. Indeed, there would be mostly manipulation interactions as VE interactions that are related to these two kinds of tasks [117] [156], leading thus to a diversity of motor interactions present in the cases that are studied, with the navigation and selection interactions mostly presented here in our case studies.

Additionally, other fields such the medical domain or the manufacturing industry could be interested about using our methodology, since they are fields that have been studying and evaluating VE technologies in the literature [140] [20]. Moreover, for the medical field in particular, our methodology could, thanks to its semi-automated system for user task analysis, allow them to reduce the issues that are usually faced in this field about the writing of specifications for technical purposes -e.g. difficulties to express the needs [START_REF] Ward | Requirements capture for medical device design[END_REF], decisions based on intuition [32].

In the same way, the application of our methodology to case studies that are diversified could also contribute to the evaluation of the robustness criterion. Indeed, diverse technologies would thus be used depending on the case studies, and even new VE techniques and technologies that would exist in the future.

Finally, another perspective of future work on our methodology could be to improve its phase of prototyping and evaluation of the virtual environments on two different aspects. The first one could consist of proposing another semi-automated system that would allow for the determination of the quality factors to be taken in account for the user evaluations and their relative importance. Such semi-automated system could be built by collecting data from user evaluations that take in account these concepts of quality factors and of their relative importance, either from the literature or from cases of use of our methodology. Such data could be then compiled into rules to be used in this system, as rules that link the user tasks and interactions to the quality factors that exist for each kind of interaction. The second one could consist of guiding the choice of the technologies used for the VE prototypes. To do that, criteria of cost, of technological requisites, of complexity and requirements of use etc. could be applied to the different VE technologies that exist, and then, this could be integrated into a system usable by the domain-specific users, to allow them to make these technological choices.

To conclude, these two perspectives could, on one hand, show a more generic use of our methodology than the one presented here, and, on the other hand, could allow the domain-specific experts to participate more actively in making choices during the prototyping and evaluation of the VEs phase.

A.1. INTRODUCTION

A.1 Introduction

A cautionary note

This practical guide aims to present and explain here how to use our methodology. This guide has been designed and written with the aim of allowing for its use as a stand-alone document. This means that this guide could be extracted from this thesis document to be distributed to its audience, and this audience would have the required material to use our methodology.

A.1.1 Definitions

This practical guide expounds our methodology, which aims to guide the design of virtual reality (VR) interactions according to the domain-specific task that you want to perform in a VR application.

Thus, you may wonder what a VR application is and what a VR interaction is, and to clarify these two points, we want to give some definitions. In this guide, we will consider that a VR application is composed of two main components, its VR content and its VR interactions:

• The VR content is the content available in the VR application: this is usually some 3D visual content for its main part -e.g. 3D models, but other kinds of content may be also available such as audio content. This content is usually created by designers, or it might come from external data, such as Computer-Aided Design data, or Building Information Modelling (BIM) data, e.g. 3D BIM models in the Architecture, Engineering and Construction (AEC) industry.

• The VR interactions define the interactions that the users have with and within the virtual environment. VR interactions are possible thanks to VR interaction techniques, which are the ways or the metaphors developed by VR experts, and provided to the users to interact.

NB: from the step 2.2 of this guide, only the motor interactions are considered, but, in VR, sensory interactions also exist, such as visual perception, which may be added in our methodology in the future.

A.1.2 Audience

Our methodology is particularly addressed to some specific kinds of people, and, actually, they are the main reason why it was necessary to provide this guide here. Indeed, our methodology is notably intended for the domain-specific stakeholders of projects who want to benefit from a VR application to address one particular goal of their field -it can be an industrial, educative field etc. In other terms, A.1. INTRODUCTION we needed our methodology to be understandable by domain-specific experts, which are not expert in VR, thus to provide this guide was essential.

In the scope of this thesis, our methodology aimed to be notably applied for designing VR applications that address AEC needs. Nonetheless, it could be used for other domains: our methodology has been built with the ambition to be generic. Indeed, the approaches and the systems proposed in this methodology have this ambition, and, thanks to its structure, in any cases, if this is necessary, it would be possible to adapt some elements of our methodology if they are related to a specific domain.

A.1.3 Scope

The focus of this methodology is the user interactions that are available in a VR application, and we aimed to improve them by guiding the choices of the VR interaction techniques. Indeed, many interaction techniques actually exist and do allow a user to perform an action in a virtual environment.

Nonetheless, it has been empirically noticed that each of the existing interaction techniques do not offer the same user task performance depending on the characteristics/the kind of task performed in VR. Currently, to aid such design of interactions, user-centred design methodologies exist; nonetheless, finding a VR interaction technique that is appropriate for a task still requires VR expertise in these methodologies. Thus, to allow non-expert in VR people to determine a maximum of appropriate characteristics for the VR interaction techniques, we propose here a new methodology to follow.

A.1.4 Outline

In the next sections of this document, an overview of our methodology is given first, and then its different steps are explained. Additionally, in the first two steps, an example is given -the same for all the steps and sub-steps, to allow you to understand how each step could be executed. The results obtained for this example are shown through figures, which will have a yellow box as an outline to detect them easily. Three main steps compose this methodology, with several sub-steps when necessary. We explain here all these three steps to make understandable how our methodology works.

Nonetheless, the steps 1 and 2 can be done without having VR expertise, and are either highly guided when remaining manual actions are needed, or are totally automatic -task analysis knowledge and VR knowledge are organised in expert systems whose contents are detailed in the appendices of this guide, whereas the step 3 requires VR expertise. Thus, you will likely need a VR developer in step 3. • a set of the VR interactions that are required in the VR solution, as the output of the step 2.1, issued from the translation of the primitive tasks obtained as the final output of step 1

• a set of characteristics for the VR interaction techniques that are appropriate to these VR interactions and their associated task, as the output of step 2.3, and a set of proposals of VR interaction techniques, as the output of step 2.4

You can follow the steps 1 and 2 of our guide without a VR developer. After that, the step 3 can complement" in the step 1 to describe each task and subtask. application. This task is our input for the step 1, and this is the task that will be studied here. In any cases, you must define what the main domain-specific task that you want to perform in the VR application is. This task is the one that will allow you to reach your main objective in the application, and must have been thought for one kind of user, meaning thus for one activity domain and one role.

If your domain-specific field is the AEC field, the design, the construction, or then maintenance are activity domains, and the roles can be architects, safety civil engineers etc. Some examples of main objectives in VR for these users could be to prevent future accidents on a worksite, or to avoid unsafe design mistakes. Thus, the main tasks associated to these goals would be to identify hazards from the construction planning, and to review the design of close mechanical, electrical and plumbing elements. You can notice that these goals -and as a result these tasks -can be divided into sub-goals -and these tasks into subtasks. Based on that, you will be able to do the step 1 decompositions.

In this guide, we applied our methodology to an example from the AEC field, to facilitate the understanding of each step. This example is the following, shown in Figure A.3: in the construction activity, for a construction inspector, one main goal is the construction supervision, i.e. the follow-up here between a real worksite and BIM models. Thus, the associated main task is here the supervision, in terms of comparison between the as-built versus the as-planned, for critical zones of the worksite. It is important to know what the aim of the decomposition is before starting it. The targets of this decomposition are primitive tasks/actions, which would not be divided anymore here, being thus the output of this step. To facilitate and guide this decomposition, we provide here a limited set of verbs that must be used to describe a primitive task. For an easier decomposition, you should use only these verbs, but, in practice, you could use synonyms of these verbs without affecting the quality of the decomposition. In this case, it is important to choose a very close synonym, whose definition encompasses the same meaning of the initial verb that we proposed, not in a larger or thinner meaning.

The verbs that we provide for the primitive tasks can be divided into three sub-groups of actions:

• Motor actions: travel, take/grab (an object), activate (a function), target, place/orient (an object)

• Perceptual actions: see, hear

• Cognitive actions: think, decide
At the end of the decomposition of the domain-specific task, you obtain primitive tasks, which are expressed with one of these verbs and with a complement (no restrictions for writing/expressing it).

A.3.4

Step 1 core: our process to proceed to the decomposition

As explained above, the decomposition of your task into primitive tasks, which belong to motor, perceptual and cognitive categories, is your objective in this step. First, it is important to note that different decompositions of a same task may lead to the same final primitive tasks. This means that A.3. STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK there is not a unique right way to proceed here. Hierarchical task analysis is an ability obtained by a learning process, and we know that you may already have this ability or you may not have it. Indeed, for example, if you often write projects specifications, you should already know more about this kind of analysis than other potential users of this guide.

We provide here a technique for proceeding to the decomposition of your task, to guide this decomposition regardless of your experience and skills. Our technique consists of proceeding to the following divisions -the terms subtasks, activities, operations and primitive tasks allow you to differentiate the name of each level of decomposition; nonetheless, the explanations to proceed to each of this kind of division are detailed in the next paragraphs:

1. First division: from the main task to subtasks (between 1 and 4 subtasks) are available in the appendices of this guide. Additionally, we propose a list of verbs for the primitive tasks: travel, take/grab (an object), activate (a function/a mode), target, place/orient (an object), see, hear, think, and decide. Here you cannot propose and use a verb of your choice, because primitive tasks can reasonably limited to the list that we provide, and because this limitation ensures that it will be possible for all these primitive tasks to be translated into a VR interaction in the step 2. We propose in this second step to determine proposals of VR interaction techniques, following these four sub-steps, which must be performed for each primitive tasks obtained in step 1:

• Step 2.1: Identification of the type of VR interaction and of the characteristics of the associated task -from the data obtained in the step 1

•
Step 2.2: Characterisation of the VR interaction -according to the associated task and depending on the VR interaction type identified in the step 2.1

A.4.2 Step 2.1: Identification of the type of VR interaction and the task characteristics

You have obtained a set of primitive tasks at the end of the step 1. The objective of this step 2.1 is to separate in the description of each of these primitive tasks the part that defines the interaction associated to this task, and the part that gives details about the task and its context. Additionally, this step aims to categorise the interaction, leading thus to the identification of its type between navigation, selection and manipulation interactions.

Thanks to our guidelines given in the step 1, all the primitive tasks obtained previously follow the same grammatical pattern: a verb, which belongs to a determined list of verbs, and a complement, which can be composed by every kind of words (no constraints here). Based on this fact, we have been to propose an automatic system for this step 2.1, thus you would not have to perform any manual actions here. This system allows for the completion of the following actions: first, the verb is automatically split from the complements, and then the verb is automatically associated to its type of VR interaction, thanks to a correlation table between the verb and the existing types. The possible types are the motor one -and its subdivisions of navigation, manipulation and selectionthe perceptual one, and the cognitive one. Finally, the complement is saved as the characteristics of the task associated to the VR interaction. As mentioned in the introduction of this guide, it is important to note that, in the step 2.1, motor, perceptual and cognitive VR interactions can appear as the result of the transformation of the primitive tasks; however, in this step 2.2 and all the next steps, only the VR motor interactions are considered in the scope of this current research.

From the step 2.1, you have obtained the type of the VR interaction associated to each primitive task and you have also kept the data about this primitive task. In this step 2.2, you must characterise the (motor) VR interactions: for each VR interaction, you must choose and attribute a value for each characteristic that depicts this interaction. For each kind of VR interaction -here the three sub-kinds of navigation, selection, and manipulation -a different list of characteristics is automatically provided, and you must complete it by deciding which values are the more appropriate for this VR interaction. You have obtained from the step 2.2 some characteristics about each VR interaction. These characteristics can be analysed, for each VR interaction, to determine the characteristics of its appropriate VR interaction technique(s). This is the objective of this step 2.3, and can be done based on the VR interaction characteristics obtained previously.

We propose to use here an automatic system, based on an expert system, which contains deduction rules from VR expert knowledge. This automatic system is the tool that allows non-expert in VR people to perform this step 2.3. The deduction rules of this expert system are available in the appendices of this guide. By applying these rules, this step returns as output the appropriate values for the characteristics of the VR interaction techniques in terms of usability. These characteristics of the VR interaction techniques, and their possible values, come from several taxonomies of interaction techniques -one for each kind of motor interaction, which we proposed in our methodology. In the step 2.3, for each interaction, you have obtained a set of characteristics that defines the appropriate VR interaction technique, according to VR expert knowledge. Then, it is possible to interpret and transform this set of characteristics into a list of (concrete) potential VR interaction technique. We propose in this step 2.4 to translate these characteristics into such concrete list, to allow you to have a list of existing potential VR interaction techniques to transmit to a VR developer in the step 3. Such translations can be done thanks to the work done for building our own taxonomies of interaction techniques in our methodology.

Here we propose to do this translation through an automatic system, similar to the one of the step 2.3 -in practice the results of the steps 2. In this step 3.2, the VR developer creates prototypes of VR applications that contain both the VR interaction techniques chosen in the step 3.1 and the VR content that you want to display, for example your 3D BIM models. In other terms, this developer realises the concrete implementation of the VR interaction techniques within VR prototypes, for each interaction. It is important to note that we talk here about prototypes, in plural: indeed, in the step 3.1, based on the results from the step 2.4, the developer and you have likely chosen more than one VR interaction technique candidate for one interaction. Thus, if there are two candidates, two prototypes must be developed. Depending on the number of interactions, and the number of interactions where several candidates have been chosen, the number of prototypes can increase quickly. According to your budget and your time, you can consider a different amount of prototypes. Priorities and limitations should be discussed and defined with the developer and you, to avoid the exponential explosion of possible applications. In this step, user evaluations must be prepared by the VR developer, in collaboration with you.

These user evaluations aim to evaluate the usability -in the sense of the user performance and/or the user preference -of the interaction techniques present in each prototype. This is concretely done through experiments where users who are experts in the domain of the VR application have to complete the task for which the application has been created. They are evaluated when performing this task, and the results obtained here allow the VR developer and you to compare the different interaction techniques and to determine the most appropriate one for each interaction in terms of usability. Nonetheless, before running such evaluations, the following components must be prepared:

1) the quality factors to take into account for the evaluation of each interaction technique, 2) the measures to take according to the quality factors chosen, and 3) the quality factors scores weighting that are used to balance the scores obtained from the measure associated to each quality factor.

To choose the quality factors to take in account for the evaluation of each interaction technique, the VR developer must explain the different quality factors that exist and that can be used for each kind of motor interaction -navigation, selection, and manipulation -to you. Thus, the VR developer and you can choose the quality factors that you want to consider in each user evaluation. Then, the VR developer must decide which measures must be taken according to each quality factor previously chosen. Next, each measure allows for the determination of a score obtained when performing the task using a VR interaction technique, for one usability aspect -the one related to the associated quality factor. Finally, you must define, in collaboration with the VR developer, the relative importance of each quality factor, through weights that can be attributed to the scores obtained for each quality Thus, you will be able to make the final choices of interaction techniques for your VR application.

Recommended value

Ref.

Abstract

Recommended value

Ref.

Hand-size (or less) object manipulation mode (tr) direct or indirect via interface [START_REF] Ware | Rotating virtual objects with real handles[END_REF] Hand-size (or less) object manipulation mode (rot) direct or indirect via interface [START_REF] Ware | Rotating virtual objects with real handles[END_REF] Hand-size (or less) object manipulation tool (rot) hand [START_REF] Mine | Moving objects in space: Exploiting proprioception in virtual-environment interaction[END_REF] Hand-size (or less) object kind of tool control (rot) both (isomorphic/ anisomorphic), aniso. for precision [START_REF] Mine | Moving objects in space: Exploiting proprioception in virtual-environment interaction[END_REF] Out of arm reach range for positioning manipulation mode (tr) direct or indirect via interface [START_REF] Pierce | Voodoo dolls: Seamless interaction at multiple scales in virtual environments[END_REF] Object size more than hand manipulation mode (

Object within the arm reach + within arm reach range for positioning manipulation mode (

Object within the arm reach + within arm reach range for positioning manipulation tool (

Object within the arm reach + within arm reach range for positioning + hand-size (or less) object kind of tool control (tr) isomorphic [START_REF] Steed | Evaluating effectiveness of interaction techniques across immersive virtual environmental systems[END_REF][127]

Object within the arm reach + within arm reach range for positioning + object size more than hand kind of tool control (tr) both (isomorphic/ anisomorphic), aniso. for precision Based on the results obtained by the AEC professional who followed the steps 1 and 2 of our methodology for the hazard identification case study in the experiment done in the chapter 6, the step 3 of our methodology has been then performed with a VR developer, as it is required in this step 3.

[
As a result, in this appendix, we present how prototypes of VR applications have been created, for this case study, in which the hazard identification task must be performed.

Moreover, we present the user evaluations that we have conducted here in the role of the VR developer, about the usability of two interaction techniques, which were compared here. These interaction techniques were used for the same interaction, the navigation in the whole worksite interaction (large scale), each one being in a different prototype. In this experiment, we did not study and evaluate the interaction of the "local navigation", used to refine decision-making about the hazards.

The two navigation interaction techniques, obtained using our methodology and our guide -available in the appendix A, which we prototyped and evaluated here were:

• free pointing steering technique (human speed transition) on the 3D environment (direction selection mode : direct)

• free pointing steering technique (human speed transition) on the a 2D map (direction selection mode : indirect) About the VR content present in the prototypes, to fit with the description of the case study that we gave in the chapter 6, we chose here a virtual worksite with the two specific kinds of hazards that we mentioned previously: the falls hazards and the struck-by hazards. examples of hazardous situations in our VR prototypes, one for each kind of hazard, which could be present in a real worksite, and which could be observed and detected during a virtual construction planning review.

In the next sections, we present how we follow each sub step of the step 3 of our methodology, to create VR applications and evaluate VR interaction techniques for this case study of hazard identification. PROTOTYPED

External constraints: devices, distance and budget

To create our VR prototypes, we had here two main external constraints (external to the user task): the devices to use and the available budget. Indeed, AEC professionals needed to use a device to which they could have access remotely, as they were physically far from us and since this experiment occurred during the lock-down of the laboratories due to the Covid-19 in 2020. Thus, this fact added the budget constraint: it was necessary to use a device to which the users could have access easily, without cost. We proposed then to the users to use one of the two following options, based on two different devices.

The first option was to use a desktop application, distributed online through a webpage that contained all the instructions and the virtual application, displayed on the webpage using the WebGL technology. In this case, the application was optimised for being display on web browsers on computer screens. We proposed this modality to address "the remote constraint" and the "accessibility constraint", allow thus for having a consequent number of participants. Even if this modality could not offer an immersive VR environment, it could be used for evaluating the navigation interaction techniques, and offered the benefits of a high accessibility, since only a computer, an Internet connection, a mouse and a keyboard were necessary. The second option provided was to use a VR Head-Mounted Display (HMD) application. In this case, the participants still had to use the webpage for all the instructions and the questionnaires, but to test the application, they had to download and install it for its use in the HMD. We proposed this modality, with the remote downloading of the application, to address "the remote constraint".

This modality had the benefit to allow for having subjects that performed their task in an immersive environment, despite the lock-down of the university laboratories. Nonetheless, a difficulty for this modality was that it was required that the users owned a HMD, thus it was more complex to find such users, and thus it would allow for a lower number of participants than with the first option. To maximise our chances, the VR application has been distributed for the HMD Oculus Quest, Oculus

Rift and HTC Vive.

It should be highlighted that this option had been initiated by some members of the VR community that had been able to get their VR equipment outside of their laboratories [START_REF] Steed | Evaluating immersive experiences during covid-19 and beyond[END_REF].

B.2.2 Interaction techniques selected to be prototyped

In the step 2 of our methodology, the AEC professional who used it has determined proposals of appropriate VR interaction techniques -in terms of usability -to perform a preventive hazard identification task. As mentioned above, in this experiment, we focused on the primitive task of navigation in the whole worksite that is performed during its exploration in order to identify hazards. Looking at these characteristics, the users would have the control of the direction for moving, without restriction about the zones to go, and they also had the control of the acceleration, in fits and starts actions, i.e. to be able to decide where and when they wanted to start moving and when to stop. About the speed, the recommended order of magnitude is the human speed; indeed, the users need to be able to observe during their navigation to collect information for identifying hazard.

However, one characteristic has the value " ? = experiment required". This explains why we conducted this experiment here. Indeed, based on these characteristics, with this "?", two different kinds of proposals had been obtained for the concrete interaction techniques to be implemented in an application: the free pointing steering techniques on the 3D environment -i.e. with the direction selection mode as direct, and the free pointing steering techniques on a 2D map -i.e. with the direction selection mode as indirect. Thus, we proposed here to prototype these two different interaction techniques "pointing on the 3D ground" and "pointing on a 2D map", both with smooth translation and transition to the targeted place. Figures B.5 and B.6 show a user in our VR application using the direct target selection interaction technique pointing on the ground and using the indirect target selection interaction technique pointing on the 2D map, respectively.

B.3. STEP 3.2: DEVELOPMENT OF THE VR PROTOTYPES WITH THE INTERACTION TECHNIQUES

All the hazardous situations present in this application involved at a worker. This fact helped the participants to know where hazardous situations may be, and allowed for a clearer focus for the selection task of targeting hazards -indeed, in this case, the workers are the only that could be targeted.

Having this restriction would avoid too high differences of subjects' behaviours when searching for the hazards; otherwise some participants could have searched hazards with more details compared to the others, leading thus potentially to disparate results. Nonetheless, oppositely, to prevent the selection primitive task from becoming a task "find all the workers in the worksite", some workers were NOT in hazardous situations. Finally, to avoid false positive of hazards linked to the workers' equipment, each virtual worker wore the basic personal protection equipment (suit and helmet).

According to the two kinds of hazards chosen for this study, the workers could only be in a hazardous situation for one of the two following reasons, from their current situation:

• they may fall from a high level of the construction, or into a whole on the ground

• they may be struck by a truck or a crane that is in movement

The workers were clearly identifiable as in hazardous situations for both kinds of hazards, and these hazards were due to a lack of (non-personal) protections such as barriers, or because of the worker's proximity to a moving machine, or because of the use of inappropriate material on scaffolding -pallets, containers or ladders. The workers in safe situations were identifiable by the presence of barriers, or because they were far from the moving machines. The aim of this step is to prepare the user evaluation of the usability of the two navigation interaction techniques implemented in two VR prototypes of application. This user evaluation would allow for the comparison of the results obtained with each interaction technique, in order to make the final choice of interaction techniques for the primitive task of navigation in the worksite to be performed in the VR application.

Several components need to be prepared: the experimental protocol, the choice of the subjects that will participate to the user evaluation, the choice of the quality factors to be taken into account, the choice of the measures to be taken, and the choice of the weighting of the quality factors.

B.4.2 Experimental design and protocol

For this experiment, we designed two similar scenarios for our application, and both were containing the two kinds of hazardous situations that we mentioned above. We built these two constructions scenarios of a virtual worksite to allow the participants of our experiment to use each of the two navigation interaction techniques once, in each prototype of VR application. Thus, it was possible to follow a within-subject design for this experiment, and to evaluate and compare the usability of the two navigation interaction techniques used for this navigation subtask, performed during the global task of hazard identification.

The participants had to follow a protocol, which was completely explained on a tutorial on the webpage of our experimenthttps://pierreraimbaud.github.io/webp/gl.html or https: //pierreraimbaud.github.io/webp/vr.html depending on the device they used. Thanks to this tutorial, the participants were able to understand the objective of the experiment, to get the information about the hazards that would exist on this virtual worksite, to understand how to perform the hazard identification task in our VR prototypes, and to attribute a weight for each quality factor evaluated, depending on its relative importance for the navigation subtask in the context of the hazard identification main task.

First, after having accepted the inform consent, the participants had to download and to read Finally, each participant was able to pursue the hazard identification task in the VR application, either through the web browser or in a HMD -the two web pages were hosting their application, either by displaying it directly for the WebGL version or by providing a link to download it for the HMD version. As each participant had to perform this task twice, following the within-subject design, they had to use once one navigation interaction technique on one construction scenario, and to use once the another navigation interaction technique on the other construction scenario. The order between the scenarios -i.e. the different sets of hazardous situations, and the navigation interaction techniques was randomised and counterbalanced.

B.4.3 Subjects

In this experiment, we recruited voluntary unpaid subjects. This experiment was open to everyone on the Internet; nonetheless, to find participants, we designed it to ensure that there was no specific requisite for participating, in terms of knowledge about AEC hazards or in terms of having particular abilities with computers. This explains why an informative document about the kinds of hazards that would need to be identified here, and a complete tutorial about the commands for navigating and tagging the workers in danger were provided. These complete tutorials about the hazard knowledge and the application commands offered us the possibility to have participants without any experience in hazard identification or in 3D virtual environments.

Thus, in the online desktop version of the application, we collected data from a large variety of profiles, in terms of their previous VR experience and AEC knowledge. In total, with the WebGL modality, 34 subjects participated to the experiment, and 28 succeeded in performing correctly in the application -the others 6 either only filled the pre-experiment questionnaire or did not finish the hazard identification task on the two construction scenarios.

B.4. STEP 3.3: PREPARATION OF THE USER EVALUATIONS

However, with the HMD version of the application, more than the half of the participants were VR experts, most of them from the IEEE VR community. They were indeed the ones that had HMD at home and that proposed to share experiments [START_REF] Steed | Evaluating immersive experiences during covid-19 and beyond[END_REF]. In total, 12 subjects participated to the experiment in a virtual reality HMD, either on Oculus Quest, Oculus Rift or HTC Vive. Nonetheless, to balance the potential bias induced by their VR expertise, we can note that the remaining participants were some relatives of the VR-experts participants, and they were not be VR experts.

B.4.4 Quality factors for this navigation subtask

For a navigation task, many quality factors can be considered to evaluate the effectiveness of a VE interaction technique. Bowman et al. listed some quality factors for the navigation interaction techniques: the speed/rapidity, the precision/accuracy (proximity to the desired target), the spatial awareness -in its meaning of "the user's implicit knowledge of disposition and orientation within the environment during and after travel", the ease-of-use, the information gathering -i.e. "the user's ability to actively obtain information from the environment during travel", and the presence [23].

Nonetheless, as Bowman et al. noticed it, only some quality factors may be relevant to take into account to evaluate the usability of an interaction technique, depending on "the application and the task [performed]" [23]. For this case study, first, it should be noted that the quality factor of presence was hard to consider here since some prototypes were used in non-immersive devices. Then, about the five other quality factors, through a discussion with the AEC professional, as Bowman et al.

recommended it -to choose the quality factor with the end-users, we considered the speed/rapidity, the information gathering, ease-of-use and spatial awareness quality factors. During this meeting, the AEC professional noted the importance of the information gathering quality factor because of the context of hazard identification, and considered the spatial awareness and ease-of-use quality factors as complementary factors. This is due to the fact that, as the navigation is "only" a part of the main task, the interaction technique used here should be easy to use and without making the users disoriented, as they must locate spatially the hazards. Since large distances had to be travelled, without the need of being precise for the different movements, the quality factor accuracy had been rejected by the AEC professional, whereas the speed quality factor had been conserved due to these distances. Nonetheless, they remarked its lower importance based on the fact that the quality and completeness of the hazard identification was, as for the AEC professional, more important than its rapidity.

B.4.5 Measures for data collection

The following four quality factors have been chosen to be considered in this experiment: rapidity, information gathering, spatial awareness and ease-of-use, based on different considerations that have been explained above. Then, for each of these quality factors, one or several measures can be taken.

To choose these measures, it should be highlighted that, for this remote experiment, first priority has been given to non-invasive and if possible automatic measures, since the experiment was design to be performed online and in autonomy by the participants. Based on this consideration and previous experiments done in the literature about navigation interaction techniques [25] [23], we proposed to take the following measures for this case study, shown in Table B In our user evaluation about usability, a global usability score must be calculated for each interaction technique. For this purpose, first, the data obtained through each measure are converted into scores, one for each quality factor, and then a global score is calculated from these scores. One way to obtain this global score is by making the "direct" average of all the scores. Nonetheless, in this study, following the step 3 from our methodology, we aimed to show that the way of calculating this global usability score should take into account the relative importance of each quality factor, by adding a weighting on these scores. In this study, we calculated the "direct" average score, and the "weighted" average score.

In this experiment, to obtain the weighting of each quality factor, we asked the participants had to fill in a pre-experiment questionnaire where they had to define the relative importance of each quality factor. Two different techniques were provided to the users and were mandatory to use before testing the VR application. In the first technique, called the "simple" weighting, they had to define the weighting for our four quality factors by distributing 12 points on four sliders from 0 to 6: shows the interface provided here for this simple weighting technique. In the second technique, called the "cross weighting" technique, they had to define the weights using a cross table, comparing the quality factors by pairs: here, for each pair of quality factors, the participants had to select which quality factor was, as for them, the most important between both, and then they had to attribute a relative weight of 0, 1 or 2 -2 meant that the selected quality factor was "much more important" than the other, 1 that it was "moderately more important" and 0 meant that the two quality factors had the same importance. Each participant obtained in this experiment a personal score for each quality factor. This score has been calculated from the data collected with the measures of all the participants. Indeed, after having processed the outlying values, scores from 0 to 1 have been attributed to each participant by applying a linear transformation of the data: the value 1 has been attributed to the "best" value between all the participants -e.g. the lower time, or the higher number depending on the measure -B.5. STEP 3.4 WITH WEBGL PARTICIPANTS: RESULTS AND DISCUSSION and the value 0 has been attributed for the "worst" value. This means that a participant who had an intermediate measure has obtained a score between 0 and 1 -excluded -with this calculation method.

Thus, we calculated four scores for each participant, one for each quality factor. It can be noticed that one measure was taken for all the quality factors except information gathering. It means that,

for this last quality factor, we calculated a score for its two measures, and then we took the average of the two scores. To summarise, linear transformations allowed us to obtain the users' scores for each quality factor, and to use the same scale for all these scores.

Then, from these "quality factors scores", four different ways have been tested in this experiment to compute the global usability score for each participant. The first way consists of considering that all the scores from the different quality factors have the same importance: this score can be called the "unweighted usability score". Then, following our methodology, we proposed three other ways where the relative importance of the quality factors is considered, thanks to the attribution of different weights for the scores.

Finally, following our methodology, the weights could be attributed either by the users or by an expert. Thus, we used here two users' ways -the "simple-weighting" technique and the "crossweighting", as explained previously with the use of the pre-questionnaire. Moreover, we also used the expert way: in this case, we played the role of the expert, by searching links between the primitive task of navigating in the worksite in the context of the hazard identification main task, and the quality factors chosen previously. To do that, we took into account the comments made by the AEC professionals during the choice of the quality factors, i.e. as mentioned above: the main importance of information gathering, the medium importance of the situation awareness and of the ease of use, and no importance for the speed. Based on that, it resulted in the following "expert weighting" that we used here: 0 for the rapidity, 4 for the information gathering, for the situation awareness 2, and for the ease of use 2.

B.5.2 Discussion about the order effect

The data that we collected come from a within-subjects experiment, thus, in our first analysis, we considered three factors: the navigation interaction technique, the scenario/the case where the hazardous situations had to be identified by the participant, and the order/the number of the session of a user -i.e. 1 for the first inspection on a scenario with one of the two interaction techniques and 2 B.5. STEP 3.4 WITH WEBGL PARTICIPANTS: RESULTS AND DISCUSSION for the second inspection on the other scenario with the other interaction technique. Table B.2 shows the results of this statistical analysis for the rapidity, information gathering, situation awareness and ease of use scores, and also for the global usability scores calculated here. The p-value for the different interaction effects -VR interaction technique:case, VR interaction technique:order, case:order -are not displayed since there were no p-value that indicated a significant effect on a level of significance of α=0.05. According to this table, it can be noticed there is no significant effect of the case/scenario of hazardous situations on the results -thus the two scenarios can be considered at the same time in the analysis. However, this statistical analysis shows a significant effect of the order on the results.

Series

Indeed, the p-values for the situation awareness, the ease of use and for all the global usability scores are very inferior to the level of significance of α=0.05.

By looking more precisely to the results, visible afterwards in box plots figures, these p-values can be mostly explained by the fact that, in this experiment, the participants tended to overperform in their second "session" during the experiment. This order effect does not allow for a correct interpretation of the p-values for the interaction technique navigation factor, which seem to show a significant effect of the navigation with several p-values < 0.05. Thus, these results led us to decide to run another analysis on the data, this time considering only the users' results of their first "session", like if the experiment had been conducted following a between-subject design.

B.5.3 Score results

First, as explained above, it should be highlighted that all the next figures and tables only take into account the data collected for each participant when they were using their first navigation interaction technique,Then, about the scores obtained for each quality factor, Figures B.12 Considering the data from the first session of each participant, it should be highlighted first that the data respect the assumptions required to run a two-way ANOVA, here on the factors navigation interaction technique and case/scenario. Indeed, the data followed a normal distribution for each of our series of data, i.e. for the measures for the four quality factors, and for the four global usability scores calculated. This has been ensured by applying the Shapiro-Wilk's test on them, which returned pvalues higher than a level of significance of α=0.01 or of α=0.05 depending on the series. Additionally, we applied the Levene's test on each series of data, which also returned p-values higher than a level of significance of α=0.01 or of α=0.05 depending on the series, showing as result the homogeneity of the variance between the different possible sessions -combination of interaction techniques and cases.

Finally, the observed factors were independent by their nature -the navigation interaction techniques and the cases/scenarios. According to the validation of these assumptions, the conditions for applying a two-way ANOVA on our datasets were ensured, thus we ran these analyses for the different scores obtained with the two interaction techniques.

The results obtained running a two-way ANOVA on the interaction technique and case factors, for all the scores, are shown in Table B. 3. This shows the p-values coming from this statistical analysis for the rapidity, information gathering, situation awareness and ease of use scores, and for the four usability scores calculated. This statistical analysis confirmed the results observed graphically on the previous figures. Indeed, it can be noticed first that the factor case/scenario does not have a significant effect on any scores -thus the results can be shown without splitting the results from the two cases in the figures.

Then, this analysis shows that the factor "interaction technique" does have a significant effect on the rapidity, information gathering and situation awareness scores with p-values of 0.005, 0.048 and 0.030 respectively, on a level of significance of α=0.05. Graphically, it can be noted that the best scores for these quality factors are with the direct interaction technique. There is no significant effect of the interaction technique on the "ease of use" scores, even if a trend could be observed, which was that the scores tended to be better in indirect mode.

Then, the analysis shows that the factor "interaction technique" does have a significant effect on the unweighted usability score with a p-value of 0.045 on a level of significance of α=0.05. With the simple-weighting, this is the same with a p-value of 0.027 on a level of significance of α=0.05. However, with the cross-weighting usability scores, either with the weighting defined by the users or the expert, in both cases there is not a significant effect of the interaction technique, with p-values of 0.065 and 0.138 respectively, on a level of significance of α=0.05. These results confirm that, as explained in our methodology, the relative importance of the quality factors must be taken into account when evaluating the usability of interaction technique.

Nonetheless, there is still some research to do about the technique to use to define the weighting of the quality factors, since the results may be different depending on the technique used, as observed in this experiment between the simple-weighting and the cross-weighting. Indeed, in this case study, it seems that, even if maybe more complex for the users, the cross-weighting technique allowed for B.6. STEP 3.4 WITH HMD PARTICIPANTS: RESULTS AND DISCUSSION a definition of weighting that is closer to the expert one.This can be observed and explained by the following result: it was expected that the participants would attach the greatest importance to the information gathering factor, since, by definition, this was the most important quality factor for this task of exploration and identification. But, if we put the weighting total to 12 for both techniques, the participants gave more importance, on average, to the information gathering quality factor with the cross-weighting technique -average: 5.20 -than with the simple-weighting -average: 4.16. In this sense, for the least important quality factor -the rapidity, they gave less importance to it with the cross-weighting technique -average: 1.15 -than with the simple-weighting technique -average: 1.67.

B.5.5 Conclusion WebGl version: final navigation interaction technique

This user evaluation allowed for the comparison between two navigation interaction techniques, implemented into two prototypes of VR applications, here in desktop application versions. The result of this comparison is that the two navigation interaction techniques compared here are appropriate for this task, in terms of usability, without significant difference for this criteria. This means that both can be used in the final application in its WebGL version.

B. 6 Step 3.4 with HMD participants: results and discussion

B.6.1 Scores results

First, about the calculation of the scores from the measures for each quality factor, they have been calculated by the same technique of linear transformation that we used for the WebGL participants.

Then, about the order effect, in this experiment, the analysis of the results did not show a significant effect of the order on the results. Thus, the results and the statistical analysis presented here for the HMD versions of the application would consider the three following factors: the navigation interaction technique, the case/the scenario with the hazardous situations and the order/the number of the session.

Then, about the scores for each quality factor, Figures B.20 first figure shows the score without using weights, then the next two figures shows the ones using the weights given by the users with the simple-weighting and the cross-weighting techniques, and finally the last figure shows the one with the "expert" weighting. In these four last figures, each combination "order + case" is displayed separately, to be able to observe in the results some more specific differences that are present -oppositely, it was no relevant to do it in the other figures. In this analysis, three factors were considered from our within-subjects experiment: the navigation interaction technique, the case/the scenario with the hazardous situations and the order/the number of the session of a user. First, it should be highlighted that our data respect the assumptions required to run a repeated-measures three-way ANOVA. Indeed, the data followed a normal distribution for each of our series, according to the Shapiro-Wilk's test that we applied and which returned, for all the series, a p-value higher than a level of significance of α=0.05. About the sphericity of the data, we checked it graphically, by observing similar variances for each group. Indeed, the Mauchly's test can only be when there are more than two levels for the factors: thus, for our case, the literature said that sphericity necessarily holds for effects with only 2 levels. Finally, the observed factors were independent by their nature -the navigation interaction techniques, the cases/scenarios and the order. According to the validation of these assumptions, the conditions for applying a repeated-measure three-way ANOVA on our datasets were ensured, thus we ran these analyses for the different scores obtained with the two interaction techniques.

Table B. 4 shows the results of this statistical analysis for the rapidity, information gathering, situation awareness and ease of use scores, and also for the global usability scores calculated here. The p-value for the different interaction effects (interaction technique:case, interaction technique:order, case:order) are not displayed since for them there were no p-value that indicated a significant effect on a level of significance of α=0.05. This statistical analysis confirmed the results observed graphically on the previous figures. Indeed, it can be noticed first that the factor case/scenario does not have a significant effect on any scores.

Then, the analysis shows that the factor "interaction technique" does have a significant effect on the rapidity, information gathering, situation awareness and ease of use scores with p-values of 0.043, 0.0008, 0.006 and 0.0004 respectively, on a level of significance of α=0.05. It can be noted graphically that the best scores are with the direct interaction technique for the rapidity, information gathering and situation awareness quality factors; however, for the ease of use the best scores are with the indirect interaction technique.

Then, the analysis shows that the factor "interaction technique" does have a significant effect on the unweighted usability score with a p-value of 0.035 on a level of significance of α=0.05. However, with all the different weighted scores proposed here -the simple-weighting and the cross-weighting by the users, the expert weighting -there is not a significant effect of the interaction technique factor on the usability scores, with p-values of 0.168, 0.563 and 0.360 respectively, on a level of significance of α=0.05. These results confirm that, as explained in our methodology, the relative importance of the quality factors must be taken into account when evaluating the usability of interaction technique.

Additionally, we can note that, in this experiment with the HMD versions of the application, the different weighting techniques gave the same trends for the global usability scores and the influence of the factors evaluated here.

B.6.3 Conclusion HMD: final navigation interaction technique and WebGL "comparison"

First, it could be noted that our results in this experiment with HMDs led to similar conclusions than the ones with the WebGL versions of the application. However, it would be an error to think that the results are exactly the same, for two main reasons. First, because in the WebGL experiment, the order had a significant effect on the usability scores, whereas with the HMD the order did not have this effect. A hypothesis to explain that may be the following: in the case of the HMD, most participants were VR experts, thus, even before the first session of the user evaluation, they already knew how to interact in this kind of application. Oppositely, in the case of the WebGL application, there was a wider diversity of people, and, for the "non-expert in VR" participants, the learning effect between their session 1 and their session 2 has been larger. Then, the second reason is that the number of participants were smaller in the HMD experiment with 12 people versus 28 with the WebGL application -even if, in this case, we have been able to consider their two sessions, resulting thus into 24 different results.

To conclude, this user evaluation allowed for the comparison between two navigation interaction techniques, implemented into two prototypes of VR applications, here in desktop application versions.

The result of this comparison is that the two navigation interaction techniques compared here are appropriate for this task, in terms of usability, without significant difference for this criteria. This means that both can be used in the final application in its HMD version.

B.7 Conclusions about applying our step 3 on the case study hazard identification

We applied here the step 3 of our methodology for the hazard identification case study. We built thus two prototypes of VR application, both for two devices; each pair of prototypes had been created

to compare two proposals of interaction techniques that had been obtained by using our methodology, from the output of the step 2. The results obtained contained an unknown for the characteristics that were recommended in terms of usability for the navigation interaction of moving in the whole worksite.

Thus, according to our methodology, an experiment was necessary for conducting a user evaluation to compare the two proposals of interaction techniques that differ by this characteristic only. The result that we got here is that these interaction techniques, with their values "direct" or "indirect" for the direction selection mode, obtained usability scores that are not significantly different, for this study case, performing this task of navigation with the hazard identification main objective. These results may be added in the future in the automated system of our step 2 if confirmed by experiments on similar cases in terms of tasks performed. Les environnements virtuels se caractérisent par les choix effectués sur le contenu qu'ils affichent et les visualisations associées, ainsi que par les interactions qu'ils offrent à leurs utilisateurs [13]. Les définitions suivantes peuvent être utilisées à propos de ces deux éléments :

-Le contenu de l'EV est le contenu qui compose l'EV lui-même : il s'agit généralement d'un contenu visuel 3D tel que des modèles 3D, mais il peut aussi s'agir de contenu

Utilisation et bénéfices du Building Information Modelling

Dans le secteur de l'AEC, le Building Information Modelling est une méthodologie qui est de plus en plus utilisée depuis les dernières décennies [79]. Cette méthodologie et les logiciels associés, spécifiques à l'industrie AEC, ont aidé les différents acteurs des projets de Ensuite, ils ont proposé une autre décomposition des tâches, encore plus fine, en divisant les activités en "tâches de bas niveau" : les tâches sont alors décomposées en tâches composites (niveau 4), puis en tâches primitives (niveau 5).

Etude des techniques d'interaction en EV

Participants

En suivant les méthodologies de conception centrées sur l'utilisateur existantes, des participants qui sont des professionnels de l'AEC étaient nécessaires à la fois pour concevoir l'application de RM et pour l'évaluer, et plus précisément des superviseurs de chantier. Premièrement, deux superviseurs ont participé à l'analyse de la tâche utilisateur et ont collaboré à la prise de décision concernant les choix de conception pour les interactions. Ensuite, un échantillon plus large de superviseurs -32 -a participé à l'évaluation utilisateur d'utilisabilité de l'application de RM.

Analyse des tâches de l'utilisateur

Nous avons effectué ici une décomposition hiérarchique de la tâche « comparer l'état prévu et l'état réél du bâtiment », en collaboration avec deux superviseurs de chantier.

Participants

En suivant les méthodologies existantes de conception centrées sur l'utilisateur, des participants qui sont des professionnels de l'AEC étaient nécessaires à la fois pour concevoir l'application de RV et pour l'évaluer, et plus précisément des coordinateurs BIM. Premièrement, deux coordinateurs BIM ont participé à l'analyse de la tâche utilisateur et ont collaboré à la prise de décision concernant les choix de conception de l'interaction. Ensuite, huit autres coordinateurs BIM ont participé à une évaluation utilisateur sur l'utilisabilité de notre appli-

Conclusions

Les études et expériences menées sur les deux cas précédents ont confirmé les avantages des EV pour l'exécution des tâches AEC, comme prévu. Toutefois, en ce qui concerne l'utilisation de méthodologies de conception centrée sur l'utilisateur pour la conception des environnements virtuels, elles ont révélé certains problèmes présents dans les méthodologies existantes.

Nous avons relevé deux problèmes principaux : 4.1.2 Analyse de la méthodologie de conception centrée sur l'utilisateur pour les EV de Gabbard et al.

Nous voulons présenter ici notre analyse de la méthodologie de Gabbard et al [30]. Celle-ci se compose de quatre étapes principales : l'analyse des tâches des utilisateurs (Gabbard et al. Évaluation de notre méthodologie : expérience avec des experts AEC

Objectifs

Une fois que nous avions élaboré notre méthodologie centrée sur les tâches pour la conception des interactions d'EV, il était nécessaire de l'évaluer. Pour cela, nous avons rédigé un guide pratique de notre méthodologie -disponible en annexe A de ce document de thèse (en anglais), pour que des experts AEC puissent participer à l'expérience que nous avons menée ici. L'objectif de cette expérience présentée dans ce chapitre était de procéder à l'évaluation de notre méthodologie, sur la base des trois critères qui ont été donnés dans le chapitre 4 :

1) la méthodologie est utilisable par les professionnels du domaine, 2) en autonomie, et 3) la méthodologie permet d'obtenir des résultats similaires à ceux obtenus avec une méthodologie traditionnelle de conception centrée sur l'utilisateur.

À cette fin, nous avons organisé une expérience dans laquelle deux professionnels AEC cherchent à obtenir une application de RV pour deux cas d'étude, une fois en suivant notre méthodologie à l'aide de notre guide pour un cas, et une fois en suivant une méthodologie de conception traditionnelle centrée sur l'utilisateur pour l'autre cas.

Enfin, il est important de noter que cette expérience s'est concentrée sur les étapes 1 et 2 de notre méthodologie plutôt que sur l'étape 3 du prototypage, étant données nos hypothèses.

Néanmoins, dans l'annexe B (en anglais) de ce document de thèse, nous présentons comment notre étape 3 pourrait être suivie et exécutée pour de ces deux cas d'étude. Ensuite, concernant l'autonomie, nous prendrons en compte le nombre de fois où les utilisateurs ont demandé de l'aide en utilisant notre méthodologie. Dans cette expérience, le seuil correspond à un nombre égal ou inférieur à 3 questions pour chaque étape qui indiquera alors que notre méthodologie aura été utilisée en autonomie par les utilisateurs spécifiques au domaine, sinon qu'elle a été utilisée pas en autonomie (valeurs booléennes).

Enfin, en ce qui concerne le critère de la similitude des résultats, cette expérience cherche à comparer ici les résultats pour tous les choix de conception effectués pour les interactions.

Avec les deux méthodologies, les éléments suivants peuvent être obtenus et comparés :

-les fonctionnalités de la solution de RV -la liste des interactions RV qui sont nécessaires dans la solution RV -l'ensemble de caractéristiques appropriées -en termes d'utilisabilité -pour chaque technique d'interaction RV, en fonction de la tâche -l'ensemble de propositions concrètes de techniques d'interaction RV, pour chaque interaction RV requise, en fonction de la tâche Ici, le seuil a été fixé à une valeur de 75% -ou plus -de similarité pour le contenu obtenu pour ces quatre composantes avec les deux méthodologies pour indiquer une similarité des résultats à vrai, i.e. similaire, sinon la valeur est donc faux, i.e. pas similaire (valeurs booléennes). Ce cas d'étude porte sur la revue de conception, avec l'angle spécifique de l'évaluation des besoins en espace pour un local technique [24]. Ce cas aborde plusieurs aspects de la conception d'une construction, notamment sa justesse [96], ainsi que les exigences physiques [24],

de maintenance [45] et de sécurité [97]. Dès lors, un des principaux objectifs d'une revue de ce type est d'assurer la conformité de la conception, i.e. le respect des normes. Cela conduit l'ingénieur civil chargé de la revue -un coordinateur de la conception dans la plupart des cas -à contrôler les distances entre les éléments présents dans le local, pour vérifier si les normes sont respectées. Nous proposons d'étudier cette tâche pour ce cas d'étude.

Protocole expérimental

Le protocole expérimental suivi ici implique deux professionnels de l'AEC et un développeur de RV. Tout d'abord, les deux cas d'étude présentés ci-dessus ont été expliqués en -se déplacer sur l'ensemble du chantier : technique de pointage libre (transition à vitesse humaine) sur l'environnement 3D, ou sur une carte 2D ou une liste -se déplacer -courts déplacements, pour affiner la prise de décision concernant un travailleur : marche naturelle, tapis roulant omnidirectionnel, joystick -activer la fonctionnalité permettant de signaler les travailleurs en situation de danger : bouton physique, bouton dans l'interface -cibler les travailleurs dans des situations dangereuses : raycast ou autre pointeur virtuel, ou go-go (main virtuelle avec mouvement anisomorphe) -placer/orienter les machines présentes sur le chantier : world-in-miniature pour les rotations, et, pour les translations, des expériences sont nécessaires pour comparer les techniques d'interaction directe et indirecte (raycast, main virtuelle, world-in-miniature)

Avec la méthodologie traditionnelle, l'autre professionnel de l'AEC a obtenu :

-se déplacer sur l'ensemble du chantier : téléportation à l'aide d'une carte en 2D -se déplacer -courts déplacements, pour affiner la prise de décision concernant un travailleur : marche naturelle ou joystick, ou téléportation -une recommandation faite par le développeur est de tester les deux techniques d'interaction -activer la fonctionnalité pour signaler les travailleurs en situation de danger : bouton physique -cibler les travailleurs en situation de danger : raycast -activer la fonctionnalité d'envoi du rapport à la fin de l'inspection : bouton physique 6.8 Résultats pour le cas d'étude 2 6.8.1 Accomplissement des étapes des méthodologies et temps passé Pour ce cas d'étude 2, les deux professionnels de l'AEC ont suivi entièrement les étapes 1 et 2 de notre méthodologie, ainsi que celles de la méthodologie traditionnelle. Ensuite, au niveau du temps passé, le professionnel de l'AEC qui a utilisé notre méthodologie a passé 80 minutes, et le professionnel de l'AEC qui a utilisé la méthodologie traditionnelle 95 minutes.

Autonomie et questions pour compléter les étapes

Pour ce cas d'étude 2, 3 questions ont été posées aux étapes 1 et 2 de notre méthodologie.

Fonctionnalités

Grâce à notre méthodologie, les fonctionnalités suivantes ont été obtenues, directement issues des sous-tâches présentes dans le modèle hiérarchique construit à l'étape 1 :

-pouvoir localiser les éléments a priori proches les uns des autres dans la salle des machines 342 6.8. R ÉSULTATS POUR LE CAS D' ÉTUDE 2 -pouvoir mesurer la distance entre deux éléments -pouvoir signaler les distances non réglementaires -pouvoir mettre fin à l'examen en envoyant l'évaluation de l'examen Avec la méthodologie traditionnelle, le professionnel AEC a obtenu les fonctionnalités :

-pouvoir identifier les lieux potentiels d'erreur de conception afin d'éviter les problèmes futurs au cours des prochaines phases -pouvoir mesurer la distance entre deux éléments afin de vérifier si cette distance est réglementaire -pouvoir signaler les distances non réglementaires afin d'établir une liste d'erreurs à corriger -pouvoir capturer une image des zones qui sont déclarées comme non réglementaires afin de fournir un rapport et de le rendre plus facile à comprendre -pouvoir mettre fin à l'examen en envoyant l'évaluation de l'examen

Liste des interactions requises

Grâce à notre méthodologie, le professionnel AEC a obtenu la liste suivante des interactions requises (moteur seulement ici) :

-se déplacer dans le local technique -activer la fonctionnalité permettant de prendre une mesure -cibler deux points sur les objets où la mesure doit être prise (uniquement les objets proches de l'utilisateur) -cibler deux points sur les objets où la mesure doit être prise (objets proches et éloignés de l'utilisateur) -activer la fonctionnalité d'annotation d'une mesure -cibler la mesure où ajouter l'annotation "à modifier" -activer la fonctionnalité d'envoi du rapport d'examen Avec la méthodologie traditionnelle, l'autre professionnel de l'AEC a obtenu la liste suivante des interactions requises (moteur seulement ici) :

-se déplacer dans le local technique -activer la fonctionnalité permettant de prendre une mesure -cibler deux points sur les objets où la mesure doit être prise (uniquement les objets proches de l'utilisateur) -cibler deux points sur les objets où la mesure doit être prise (objets proches et éloignés de l'utilisateur) -activer la fonctionnalité d'annotation d'une mesure -cibler la mesure où ajouter l'annotation "à modifier" -activer la fonction d'envoi du rapport de l'examen -activer la fonctionnalité de capture d'écran des éléments à des distances non réglementaires

Caractéristiques recommandées pour les techniques d'interaction RV

Les Figures suivantes 6.7, 6.8, 6.9, 6.10, 6.11, 6.12, 6.13, et 6.14 montrent les valeurs des caractéristiques des techniques d'interaction RV qui ont été recommandées en termes d'utilisabilité. Les sept premières interactions ont été déterminées dans les deux méthodologies -se déplacer dans la salle des machines (navigation) : marche naturelle, tapis roulant omnidirectionnel, joystick dans le cas où l'utilisateur a le contrôle de sa vitesse, ou "visite guidée" guidée par le regard dans le cas où le contrôle de la vitesse est automatique -activer la fonctionnalité permettant de prendre une mesure (sélection) : bouton physique, bouton dans l'interface -cibler deux points sur les objets où la mesure doit être prise -objets proches seulement -(sélection) : raycast ou autre pointeur virtuel -cibler deux points sur les objets où la mesure doit être prise -objets proches ou éloignés de l'utilisateur -(sélection) : raycast ou autre pointeur virtuel, ou main virtuelle (go-go à cause d'objets éloignés) -activer la fonctionnalité d'annotation d'une mesure (sélection) : bouton physique, bouton dans l'interface -cibler la mesure où ajouter l'annotation "à modifier" (sélection) : le même outil que celui utilisé pour les mesures -activer la fonctionnalité permettant d'envoyer le rapport de l'examen (sélection) : bouton physique, bouton dans l'interface Avec la méthodologie traditionnelle, l'autre professionnel de l'AEC a obtenu :

-se déplacer dans le local technique (navigation) : marche naturelle -activer la fonctionnalité permettant de prendre une mesure (sélection) : bouton physique -cibler deux points sur les objets où la mesure doit être prise -uniquement les objets proches de l'utilisateur -(sélection) : main virtuelle -cibler deux points sur les objets où la mesure doit être prise -objets proches ou éloignés de l'utilisateur -(sélection) : raycast -activer la fonctionnalité d'annotation d'une mesure (sélection) : bouton physique -cibler la mesure où ajouter l'annotation "à modifier" (sélection) : le même outil que celui utilisé pour les mesures (raycast ou hand selon le cas) -activer la fonctionnalité de capture d'écran des éléments à des distances non réglementaires (sélection) : bouton physique -activer la fonctionnalité permettant d'envoyer le rapport de l'examen (sélection) : bouton physique 6.9 Discussion et il est probable que ces taxonomies aient été construites dans le but de vérifier ce critère.

Ainsi, cela pourrait assurer indirectement sa vérification.

Pierre RAIMBAUD Virtual reality for building industry needs: guiding the design of interactions Résumé : Le domaine de la réalité virtuelle (RV) a connu un développement important ces dernières années en raison de la maturité croissante de cette technologie. Cela a permis sa diffusion dans de nombreux domaines, notamment dans celui du bâtiment. Cependant, un problème résultant de l'utilisation de la RV dans ce domaine est que les interactions de RV fournies aux utilisateurs ne sont souvent pas suffisamment adaptées à leurs besoins. Il est en effet difficile de faire une synthèse entre l'expertise des métiers du bâtiment et l'expertise de la RV. Une question de recherche se pose alors qui est de savoir comment offrir la possibilité aux experts d'un domaine spécifique, qui n'ont pas d'expertise en RV, d'arriver à définir et obtenir les spécifications des techniques d'interaction de RV, et ce de manière autonome. Pour répondre à cette question, nous proposons dans cette recherche une nouvelle méthodologie centrée sur les tâches, pour la conception des interactions de RV. Celle-ci contient des systèmes semi-automatiques qui permettent la décomposition de la tâche utilisateur et la détermination de propositions de techniques d'interaction -i.e. l'obtention des deux types de spécifications attendus. Cette méthodologie a été testée et évaluée sur deux cas d'étude du secteur du bâtiment. Les résultats obtenus montrent que notre méthodologie est utilisable par des experts du bâtiment, en autonomie, et qu'ils ont obtenu des spécifications similaires à celles qui sont obtenues en suivant une méthodologie traditionnelle de design centrée sur l'utilisateur.

Mots clés: Réalité virtuelle, Building Information Modelling, Méthodologie de design centrée sur l'utilisateur, Méthodologie de design centrée sur les tâches, Guide pratique Abstract: The field of virtual reality (VR) has undergone significant development these last years due to the growing maturity of this technology. This has allowed for its diffusion in many domains, notably in the building construction one. However, a problem resulting from such use of VR is that the VR interactions provided to the users are often not sufficiently adapted to their needs. It is indeed difficult to make a synthesis between the building trades' expertise and the VR expertise. A research question then arises, which is how to allow the experts in a specific field, who do not have VR expertise, to be able to define and obtain the specifications of VR interaction technique, in autonomy. To answer this question, in this research we propose a new task-oriented methodology for the design of VR interactions. This one contains semi-automated systems that allow for the decomposition of the user task and for the determination of proposals of VR interaction techniques -i.e. the obtaining of the two types of specifications that are expected here. This methodology has been tested and evaluated on two case studies from the building sector. The results obtained show that our methodology can be used by experts from the construction industry, in autonomy, and that they have obtained specifications similar to the ones obtained by following a traditional user-centred design methodology.

1. 1

 1 Overview of the thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 The reality-virtuality continuum -Milgram et al. courtesy [105] . . . . . . . . . . . . 2.2 A VR system: real world, virtual world and users interacting through its input and output devices -Burdea et al. courtesy [31] . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Virtual environment experience is a sensorial experience -Rubio-Tamayo et al. courtesy [144] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. 11

 11 Fall hazards identification and mitigation from BIM design models -Zhang et al. courtesy [194] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12 BIM-Game engine prototype for collaborative design, using two different points of views, first-person on the left and third-person on the right -Yan et al. courtesy [187] . . . . 2.13 Results in augmented reality versus with paper in terms of number of mistakes and quality of final assemblies -Chalhoub et al. courtesy [187] . . . . . . . . . . . . . . . . LIST OF FIGURES 2.14 Juxtaposition of photogrammetry and 3D BIM model in a MR application for building sales, from two points of view -Sun et al. courtesy [163] . . . . . . . . . . . . . . . . . 2.15 Mixed reality application for construction supervision based on superimposition of real and fictive data -Riexinger et al. courtesy [141] . . . . . . . . . . . . . . . . . . . . . . 2.16 A example of a design review protocol for AEC professionals to use virtual reality -Ventura et al. courtesy [177] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17 Three-stages human information processing when completing a task -Proctor et al. courtesy [133] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18 A hierarchical taxonomy of AEC tasks -the model on the left side and examples of tasks on the right side -Dunston et al. courtesy [45] . . . . . . . . . . . . . . . . . . . 2.19 A possible taxonomy for the selection interaction techniques in a virtual environment -Poupyrev et al. courtesy [129] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.20 The CD ratio as explained in the review of the selection interaction techniques by Argelaguet et al. [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. 26

 26 Improvements by Chen et al. into a domain-specific methodology to design 3D interaction techniques [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 A possibility of concept for a MR application for construction supervision . . . . . . . 3.2 Construction supervision: user task analysis . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Construction supervision: overview of the MR prototype . . . . . . . . . . . . . . . . . 3.4 Construction supervision: a user adding annotation to signal a difference between asbuilt and as-planned models in our MR prototype . . . . . . . . . . . . . . . . . . . . LIST OF FIGURES 3.5 Construction supervision: navigation with flying interaction technique, based on pointing the cubes, highlighted in yellow here . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Construction supervision: results of the post-experiment questionnaire . . . . . . . . . 3.7 Examples of clashes between plumbing and mechanical ventilation elements . . . . . . 3.8 Design clash resolution -user task analysis . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Clash resolution: manipulation of annotation tools with a raycast pointing technique . 3.10 Clash resolution: task completion time results . . . . . . . . . . . . . . . . . . . . . . . 3.11 Clash resolution: quality of the solutions results . . . . . . . . . . . . . . . . . . . . . . 3.12 Clash resolution: post-experiment questionnaire results . . . . . . . . . . . . . . . . . . 3.13 Our first approach to improve the methodology for the design of virtual environments that use BIM data [137] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Architectural walkthrough task: user task analysis . . . . . . . . . . . . . . . . . . . . 3.15 Architectural walkthrough: navigation with a restricted" teleportation . . . . . . . . . 4.1 Three main components required in a methodology for designing VE interactions . . . 4.2 Our analysis of the user-centred design methodology, deduced from Gabbard et al. [57] 4.3 Our analysis of the user-centred design methodology by Chen et al. [35] . . . . . . . . 4.4 Two main possible axes of improvement on a methodology for designing VE interactions 5.1 Overview of our task-centred design methodology, for designing VR user interactions . 5.2 Overview of the step 1 of our methodology and its components to obtain primitive tasks 5.3 Task classification extension of human information processing Proctor et al. [133] model 5.4 Our analysis of the Dunston et al. hierarchical model and examples of tasks [45] . . . 5.5 Our recommended grammatical pattern for defining tasks in the step 1 . . . . . . . . . 5.6 Comparison between hierarchical decomposition approaches on examples: AEC meaning (Dunston et al.) on the left, versus intrinsic meaning of verbs (Raimbaud et al.) on the right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIST OF FIGURES 5.7 Our hierarchical model for task decomposition during an HTA for the step 1 . . . . . 5.8 Our semi-automated system to perform the HTA with our model and guidelines for step 5.9 Our automated suggestions of verbs decomposition from each level to its next one . . 5.10 Overview of the step 2 of our methodology and its sub steps . . . . . . . . . . . . . . . 5.11 Step 2.1: mechanism proposed and its automated system . . . . . . . . . . . . . . . . 5.12 Step 2.2 mechanism: characterisation of the VR interactions . . . . . . . . . . . . . . . 5.13 Our list of the characteristics for the navigation interactions with their possible values 5.14 Our list of the characteristics for the selection interactions with their possible values . 5.15 Our list of the characteristics for the manipulation interactions with their possible values128 5.16 Step 2.3 mechanism: determination of the characteristics of the appropriate VR interaction technique(s) for a VR interaction . . . . . . . . . . . . . . . . . . . . . . . . . . 5.17 Our process for building our taxonomy about navigation interaction techniques (left) from the taxonomy by Bowman et al.(right) [23] . . . . . . . . . . . . . . . . . . . . . 5.18 Our taxonomy of characteristics for the VE navigation interaction techniques . . . . . 5.19 Our process for building our taxonomy about selection interaction techniques (top-left) from existing taxonomies [26] [129] [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.20 Our taxonomy of characteristics for the VE selection interaction techniques . . . . . . 5.21 Our process for building our taxonomy about manipulation interaction techniques (left) from the taxonomy by Bowman et al.(right) [26] . . . . . . . . . . . . . . . . . . . . . 5.22 Our taxonomy of characteristics for the VE manipulation interaction techniques . . . 5.23 Deduction rules used in an expert system to determine VR interaction technique characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.24 Step 2.4 mechanism: translation of the VR interaction techniques characteristics into a list of proposed VR interaction techniques . . . . . . . . . . . . . . . . . . . . . . . . . 5.25 Overview of the step 3 of our methodology and its sub steps . . . . . . . . . . . . . . . 5.26 Step 3.1: choice of the VR interaction technique(s) to be prototyped . . . . . . . . . . LIST OF FIGURES 5.27 Step 3.2 mechanism: development of the prototypes of VR applications . . . . . . . . 5.28 Step 3.3 mechanism with our recommended components for preparing user evaluations on the usability of interaction techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 5.29 A simple score weighting technique and its possible implementations for users . . . . . 5.30 A table for score cross-weighting adapted from the Saaty et al.'s approach [145] . . . . 5.31 Step 3.4 mechanism: the final VR application is obtained thanks to user evaluations . 6.1 Step 1 website: a form to fill in for task decomposition -main task and sub tasks part 6.2 Step 1 website: a form to fill in for task decomposition -sub task 1 sub-decomposition 6.3 An implementation of the step 2.1 in a website . . . . . . . . . . . . . . . . . . . . . . 6.4 An implementation of the step 2.2 in a website . . . . . . . . . . . . . . . . . . . . . . 6.5 A possible implementation of the step 2.3 in a website (rules in background) . . . . . . 6.6 A possible implementation of the step 2.4 in a website, highlighted in orange . . . . . 6.7 The VR interaction techniques characteristics for the interaction "move in the whole worksite" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Introduction Contenu 1 . 1

 111 ality of taking a measure" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIST OF FIGURES B.13 Information gathering quality factor scores distribution -between WebGL subjects data B.14 Situation awareness quality factor scores distribution -between WebGL subjects data B.15 Ease of use quality factor scores distribution -between WebGL subjects data . . . . . B.16 "Unweighted score": results distribution -between WebGL subjects data . . . . . . . . B.17 "Simple-weighting score" (users) results distribution -between WebGL subjects data . B.18 "Cross-weighting score" (users) results distribution -between WebGL subjects data . . B.19 "Cross-weighting score" (expert) results distribution -between WebGL subjects data . B.20 Rapidity quality factor scores distribution -within VR subjects data . . . . . . . . . . B.21 Information gathering quality factor scores distribution -within VR subjects data . . B.22 Situation awareness quality factor scores distribution -within VR subjects data . . . . B.23 Ease of use quality factor scores distribution -within VR subjects data . . . . . . . . B.24 "Unweighted score": results distribution -within VR subjects data . . . . . . . . . . . B.25 "Simple-weighting score" (users) results distribution -within VR subjects data . . . . B.26 "Cross-weighting score" (users) results distribution -within VR subjects data . . . . . B.27 "Cross-weighting score" (expert) results distribution -within VR subjects data . . . . Glossary AEC Architecture, Engineering, and Construction -a collective term for the three associated industries. Abbreviation used in ISO 10303-225:1999 BIM Building Information Modelling -ISO 23386:2020 : use of a shared digital representation of an asset to facilitate design, construction and operation processes to form a reliable basis for decisions VE Virtual Environment -ISO/IEC 18039:2019 : spatial organization of multiple virtual objects, potentially including global behaviour MR Mixed Reality -ISO/IEC 18038:2020 : merging of real and virtual worlds to generate new environments where physical and synthetic objects co-exist and interact VR Virtual Reality -ISO/IEC TR 18121:2015 : artificial environment presented in the computer AR Augmented Reality -ISO/IEC 18038:2020 : interactive experience of a real-world environment whereby the objects that reside in the real world are augmented by computer-generated perceptual information ROI Return On Investment -ISO/IEC/IEEE 24765:2017 : ratio of revenue from output (product or service) to development and production costs, which determines whether an organization benefits from an action to produce something IoT Internet of Things -ISO/IEC 23093-1:2020 : infrastructure of interconnected objects, people, systems and information resources together with intelligent services to allow them to process information of the physical and the virtual world and to react Chapter Architecture, Construction and Engineering and Building Information Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Computer science technologies and virtual reality in the AEC industry . . 1.3 Issues for designing and evaluating a virtual environment and its user interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Description of our contribution about the designing of VEs . . . . . . . . . 1.5 Document outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1 . 1 :

 11 Figure 1.1: Overview of the thesis structure

Figure 2 . 1 :

 21 Figure 2.1: The reality-virtuality continuum -Milgram et al. courtesy[START_REF] Milgram | Augmented reality: a class of displays on the reality-virtuality continuum[END_REF]

  .3.

Figure 2 . 2 :Figure 2 . 3 :

 2223 Figure 2.2: A VR system: real world, virtual world and users interacting through its input and output devices -Burdea et al. courtesy [31]

  Figures 2.5, 2.6 and 2.7 show some different representations of BIM data to understand the forms that BIM can take and what BIM can be: 3D design models, 2D design models, and 3D models with point clouds from the real site, in these examples from Johansson et al. [84], Costa et al. [37] and Mill et al. [106].

Figure 2 . 5 :

 25 Figure 2.5: 3D mock-ups used in BIM tools -Johansson et al. courtesy[84]

Figure 2 . 6 :Figure 2 . 7 :

 2627 Figure 2.6: 2D models to create the building design -Costa et al. courtesy[37]

Figure 2 . 8 :

 28 Figure 2.8: Diverse senses of BIM, in narrower or larger scopes -Volk et al. courtesy[START_REF] Volk | Building information modeling (bim) for existing buildings -literature review and future needs[END_REF]

Figure 2 . 9 :

 29 Figure 2.9: Phases in a building life cycle -O'Sullivan et al. courtesy[START_REF] O'sullivan | Improving building operation by tracking performance metrics throughout the building lifecycle (blc)[END_REF]

Figure 2 .

 2 Figure 2.10: A clash automatically detected in a design review life cycle -Hu et al. courtesy[79]

Figure 2 . 11 shows

 211 an example from Zhang et al of hazards fall detection in a building on the left side, which induces its mitigation with fall protection as shown on the right side of the figure. It could be noticed that, in their study, Zhang et al. focused only on falls, but some research could be done for other kinds of hazards. Finally, instead of improving the identification of hazards, other studies proposed some techniques that follow the design-for-safety approach[START_REF] Teo | Design for safety: theoretical framework of the safety aspect of bim system to determine the safety index[END_REF], which aim to avoid a maximum of2.3. BENEFITS OF USING BIM-BASED VIRTUAL ENVIRONMENTS FOR AEC TASKShazards directly from the building design itself. Both approaches showed the benefits of BIM, measured observing the improvement of the user task performance of planning-related, hazard identification and hazard mitigation tasks.

Figure 2 . 11 :

 211 Figure 2.11: Fall hazards identification and mitigation from BIM design models -Zhang et al.courtesy[START_REF] Zhang | Bim-based fall hazard identification and prevention in construction safety planning[END_REF]

Figure 2 . 13 :

 213 Figure 2.13: Results in augmented reality versus with paper in terms of number of mistakes and quality of final assemblies -Chalhoub et al. courtesy [187]

Figure 2 . 15 :

 215 Figure 2.15: Mixed reality application for construction supervision based on superimposition of real and fictive data -Riexinger et al. courtesy [141]

Figure 2 .

 2 Figure 2.16: A example of a design review protocol for AEC professionals to use virtual reality -Ventura et al. courtesy[START_REF] Ventura | A design review session protocol for the implementation of immersive virtual reality in usability-focused analysis[END_REF]

Figure 2 .

 2 Figure 2.18: A hierarchical taxonomy of AEC tasks -the model on the left side and examples of tasks on the right side -Dunston et al. courtesy [45]

Figure 2 .

 2 Figure 2.19: A possible taxonomy for the selection interaction techniques in a virtual environment -Poupyrev et al. courtesy [129]

Figure 2 .

 2 20 shows an example where the CD ratio varies depending on the hand speed, allowing for anisomorphic movements.

Figure 2 . 20 :

 220 Figure 2.20: The CD ratio as explained in the review of the selection interaction techniques by Argelaguet et al. [10]

Figure 2 .

 2 21 shows the Bowman et al. 's taxonomy for the navigation VE interaction techniques and Figures 2.22 and 2.23 their taxonomies for the selection and

Figure 2 .

 2 Figure 2.21: A taxonomy of the navigation interaction techniques in a VE -Bowman et al.courtesy[23]

Figure 2 .

 2 Figure 2.23: A taxonomy of the manipulation interaction techniques -Bowman et al. courtesy[26]

69 2. 8 .

 698 CONCLUSIONSthe domain-specific field of the users, and thus to improve the user-centred design process of a virtual environment.

Figure 2 . 26 :

 226 Figure 2.26: Improvements by Chen et al. into a domain-specific methodology to design 3Dinteraction techniques[35]

  .1.

Figure 3 . 1 :

 31 Figure 3.1: A possibility of concept for a MR application for construction supervision

Figure 3 . 2 :

 32 Figure 3.2: Construction supervision: user task analysis

Figure 3 . 3 :

 33 Figure 3.3: Construction supervision: overview of the MR prototype

Figure 3 .

 3 4 shows a view of annotation writing in a video.

Figure 3 . 4 :

 34 Figure 3.4: Construction supervision: a user adding annotation to signal a difference between as-built and as-planned models in our MR prototype

Figure 3 . 5 :

 35 Figure 3.5: Construction supervision: navigation with flying interaction technique, based on pointing the cubes, highlighted in yellow here

Figure 3 . 6 :

 36 Figure 3.6: Construction supervision: results of the post-experiment questionnaire

Figure 3 . 7 :

 37 Figure 3.7: Examples of clashes between plumbing and mechanical ventilation elements

Figure 3 . 8 :

 38 Figure 3.8: Design clash resolution -user task analysis

Figure 3 . 9 :

 39 Figure 3.9: Clash resolution: manipulation of annotation tools with a raycast pointing technique

Figure 3 .

 3 Figure 3.11 and in Table 3.2.

Figure 3 . 11 :

 311 Figure 3.11: Clash resolution: quality of the solutions results

Figure 3 . 12 :

 312 Figure 3.12: Clash resolution: post-experiment questionnaire results

Figure 3 . 14 :

 314 Figure 3.14: Architectural walkthrough task: user task analysis

Figure 3 . 15 :

 315 Figure 3.15: Architectural walkthrough: navigation with a restricted" teleportation

95 4. 1 .

 951 RESEARCH PROBLEMFinally, these studies recommend another component in their user-centred design methodologies: the user evaluations. Several names are used, such as formative evaluations or comparative evaluations, to differentiate the detailed objective of each kind of user evaluation. To summarise, three components appear as key components in a methodology for designing VE interactions: the user task analysis, the study of the interaction techniques and the research of linking an interaction technique to the users' needs, and the user evaluations.4.1.2 Analyses of existing user-centred design methodologies for VEs4.1.2.1 Starting point: previous knowledge about existing user-centred design methodologies for VEsAbout this concept of user-centred design and user evaluation of VEs, some particular methodologies from the human-computer interactions literature deserved to be specifically analysed. We want to explain here our interpretations about these studies from our critical analyses. Our analyses focused on the three components listed in the previous subsection, shown in Figure4.1.

Figure 4 . 1 :

 41 Figure 4.1: Three main components required in a methodology for designing VE interactions

Figure 4 . 2 :

 42 Figure 4.2: Our analysis of the user-centred design methodology, deduced from Gabbard et al. [57]

4. 1 . 2 . 3 Figure 4 . 3 :

 12343 Figure 4.3: Our analysis of the user-centred design methodology by Chen et al.[35]

Figure 4 . 4 :

 44 Figure 4.4: Two main possible axes of improvement on a methodology for designing VE interactions

Figure 5 . 2 :

 52 Figure 5.2: Overview of the step 1 of our methodology and its components to obtain primitive tasks

-

  tasks. We propose to extend the Proctor et al. model of human information processing to the domain of human tasks classification, as shown in Figure 5.3.

Figure 5 . 3 :

 53 Figure 5.3: Task classification extension of human information processing Proctor et al. [133] model

Figure 5 . 4 :

 54 Figure 5.4: Our analysis of the Dunston et al. hierarchical model and examples of tasks[45]

Figure 5 .

 5 Figure 5.5 shows this grammatical pattern used for describing tasks.

5. 2 .Figure 5 . 5 :

 255 Figure 5.5: Our recommended grammatical pattern for defining tasks in the step 1

Figure 5 . 6 :

 56 Figure 5.6: Comparison between hierarchical decomposition approaches on examples: AEC meaning (Dunston et al.) on the left, versus intrinsic meaning of verbs (Raimbaud et al.) on the right

  Level 3: operations that compose an activity • Level 4: primitive tasks/actions required to execute the operations 5.2. STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK Annett et al. and Stanton et al. encouraged to follow the approach of dividing tasks into subtasks,

  Figure 5.7 shows the hierarchical model that we propose to use in the step 1.

Figure 5 . 7 :

 57 Figure 5.7: Our hierarchical model for task decomposition during an HTA for the step 1

( 2 . 2 )

 22 , next the determination of the characteristics of the appropriate VR interaction technique(s) for each interaction (2.3), and finally the translation of the VR interaction techniques characteristics into a list of potential VR interaction techniques (2.4). Figure5.10 shows the step 2 mechanism.

Figure 5 . 10 :

 510 Figure 5.10: Overview of the step 2 of our methodology and its sub steps

Figure 5 . 11 :

 511 Figure 5.11: Step 2.1: mechanism proposed and its automated system

123 5. 3 .

 1233 Figure 5.12: Step 2.2 mechanism: characterisation of the VR interactions

Figure 5 .

 5 Figure 5.13 shows the list of characteristics with the possible values, for the navigation interactions.

Figure 5 . 13 :

 513 Figure 5.13: Our list of the characteristics for the navigation interactions with their possible values

5. 3 .

 3 STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES choice of the VR interaction technique. Next, for the size of the target, we propose two values A) size of a hand (or less), and B) more than the size of a hand.

  that are required, and the range required in the case of required positioning movements. These two characteristics are present in the Bowman et al.'s taxonomies of VE interactions[25], and Poupyrev et al. also noticed the importance of determining the nature of the movements that are required, since some manipulation interaction techniques allow for making some movements than other cannot allow, or with significatively worse user task performance[130]. For the kinds of movements, the values A) orientating, B) positioning, or C) both orientating and positioning, are available. And, for the required range for positioning, the values are A) within the arm-reach workspace, and B) out of the arm workspace.Finally, Figure5.14 shows the list of characteristics for the selection interactions with the values that can be assigned for each characteristic, and Figure5.15 the list of characteristics and their possible values for the manipulation interactions, both used in this step 2.2.

Figure 5 . 14 :

 514 Figure 5.14: Our list of the characteristics for the selection interactions with their possible values

Figure 5 . 16 :

 516 Figure 5.16: Step 2.3 mechanism: determination of the characteristics of the appropriate VR interaction technique(s) for a VR interaction

  shows how we created this taxonomy of characteristics, with our taxonomy on the left, and Bowman et al. taxonomy on the right. The colours show how our taxonomy has been built from the information present in the existing one -pairs of similar colours are used for the diverse values of a same characteristic, e.g. pink and red, or dark and light blue.

Figure 5 . 17 :

 517 Figure 5.17: Our process for building our taxonomy about navigation interaction techniques (left) from the taxonomy by Bowman et al.(right) [23]

5. 3 .

 3 Figure 5.18: Our taxonomy of characteristics for the VE navigation interaction techniques

Figure 5 . 19 :

 519 Figure 5.19: Our process for building our taxonomy about selection interaction techniques (top-left) from existing taxonomies [26] [129] [10]

Figure 5 .

 5 Figure 5.20 shows the final result of this process, i.e. the characteristics that we propose to consider in our methodology for the VE selection interaction techniques, with each of their possible values.

5. 3 .Figure 5 . 21 :

 3521 Figure 5.20: Our taxonomy of characteristics for the VE selection interaction techniques

Figure 5 .

 5 Figure 5.22 shows the final result of this process for the VE manipulation interaction techniques.

Figure 5 . 22 :

 522 Figure 5.22: Our taxonomy of characteristics for the VE manipulation interaction techniques

Figure 5 . 23 :Algorithm 1 Algorithm 2

 52312 Figure 5.23: Deduction rules used in an expert system to determine VR interaction technique characteristics

5. 3 . 5

 35 Step 2.4: Translation of the VR interaction techniques characteristics into a list of proposed VR interaction techniques Thanks to the step 2.3, recommended characteristics for the VR interaction techniques can be obtain for each interaction, and such data can be transmitted to a VR developer for the development of the required interaction techniques into prototypes of VR applications. Nonetheless, to avoid a potential misinterpretation of these recommended characteristics by the VR developer, the step 2.4 has been added into our methodology. This step consists of associating the characteristics obtained in the step 2.3 to concrete examples of VR interaction techniques, which may be used if the prototypes are developed in a compatible device. Figure5.24 shows the step 2.4 mechanism. It should be highlighted that, in any cases, the VR developer should adapt the proposals given here to the development context.The following tables -Tables 5.5, 5.6, 5.7, and 5.8, one for the navigation interaction, one for the selection one, two for the manipulation one (translations only versus rotations required) -show translations between VR interaction techniques characteristics and existing VR interaction techniques,5.3. STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUESbased on the name of the kind of the interaction technique given in the taxonomies previously analysed (step 2.3 = from names in the existing taxonomies to our characteristics, and, here in 2.4, from our characteristics to names in the existing taxonomies). These proposals of VR interaction techniques, for a specific case i.e. for a specific set of values for the interaction technique characteristics determined in the step 2.3, encompass a broad spectrum of existing techniques, with a part that could be used in some devices and another part for other devices. For example, natural walking can be used in a HMD device with tracking system or a CAVE, whereas a joystick could be used in desktop or a HMD device without tracking system.

Figure 5 . 24 :

 524 Figure 5.24: Step 2.4 mechanism: translation of the VR interaction techniques characteristics into a list of proposed VR interaction techniques

5. 4 .

 4 STEP 3: CREATE VR PROTOTYPES AND RUN USER EVALUATIONS has VR expertise. The results obtained at the steps 2.3 and 2.4, i.e. the recommended characteristics for the VR interaction techniques, and the concrete proposals of VR interaction techniques must be given to this VR developer. At the end of this step, the last one of our methodology, a VR application with the final appropriate choices of VR interaction techniques is obtained, completing thus the global objective of our methodology. To obtain this application, we propose here to proceed to the following sub-steps, for each interaction: first, the choice of the VR interaction technique(s) to be prototyped, taking in account other constraints than the users' task such as the budget or the VR device to use (3.1), then the creation of prototypes of VR applications with these interaction techniques (3.2), next the preparation of user evaluations, by defining the experimental protocol and choosing the quality factors and the measures to be taken(3.3), and finally the realisation of the user evaluations, which lead, by comparing the usability scores obtained with each VR interaction technique, to the final VR application with appropriate VR interaction techniques (3.4). Figure5.25 shows the step 3 mechanism.

Figure 5 . 25 :

 525 Figure 5.25: Overview of the step 3 of our methodology and its sub steps

Figure 5 . 26 :

 526 Figure 5.26: Step 3.1: choice of the VR interaction technique(s) to be prototyped

Figure 5 . 27 :

 527 Figure 5.27: Step 3.2 mechanism: development of the prototypes of VR applications

  Additionally, in our methodology, we propose to take into account the relative importance of each of the quality factors previously chosen. This allows for the obtaining of a balanced global usability score: global because it considers all the usability aspects represented by the different quality factors, and balanced because it takes in account the importance of each quality factor on the global usability. This could improve the quality of the evaluation, by avoiding wrong interpretations of the collected data, e.g. in the case when a "less important" quality factor has given results that are opposed to other "major" quality factors. Several techniques can be used to set the relative importance of the quality factors, for example through the VE users, or through the VR developer as an expert evaluation.

Figure 5 .

 5 Figure 5.28 shows the step 3.3 with its different components.

Figure 5 . 28 :

 528 Figure 5.28: Step 3.3 mechanism with our recommended components for preparing user evaluations on the usability of interaction techniques

  and 5.30 show these two examples of displays, one for each weighting technique: the first one for the "simple weighting" technique, and the second one for the "cross-weighting" technique based on pairwise comparisons.

Figure 5 .

 5 Figure 5.29: A simple score weighting technique and its possible implementations for users

Figure 5 . 31 :

 531 Figure 5.31: Step 3.4 mechanism: the final VR application is obtained thanks to user evaluations

Contenu 6 . 1

 61 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Evaluation, criteria, and numerical levels linked to the values of the criteria161 6.3 A website as a concrete support for the experiment . . . . . . . . . . . . . 6.3.1 Overview of the website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Step 1 on the website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Step 2 on the website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Conclusion on the website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Case study 1: preventive hazard identification . . . . . . . . . . . . . . . . . 6.4.1 Description of the case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Task of the case study: preventive hazard identification . . . . . . . . . . . . 6.5 Case study 2: design review of a plant room -space requirements aspect 6.5.1 Description of the case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Task of the case study: design review of a plant room -space requirements . 6.6 Experimental protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Results for the case study 1 -preventive hazard identification . . . . . . . 6.7.1 Completion of the steps of the methodologies and time spent . . . . . . . . . 6.7.2 Autonomy and questions for completing the steps . . . . . . . . . . . . . . . 6.7.3 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.4 List of required interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7.5 VR interaction techniques recommended characteristics . . . . . . . . . . . . 6.7.6 Proposals of VR interaction techniques . . . . . . . . . . . . . . . . . . . . . 6.8 Results for the case study 2 -design review of a plant room . . . . . . . . 6.8.1 Completion of the steps of the methodologies and time spent . . . . . . . . . 6.8.2 Autonomy and questions for completing the steps . . . . . . . . . . . . . . . 6.8.3 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6 . 1 :

 61 Figure 6.1: Step 1 website: a form to fill in for task decomposition -main task and sub tasks part

Figure 6 . 3 :

 63 Figure 6.3: An implementation of the step 2.1 in a website

Figure 6 . 4 :

 64 Figure 6.4: An implementation of the step 2.2 in a website

Figure 6 .

 6 5 shows an example of results on the step 2.3.

Figure 6 . 5 :

 65 Figure 6.5: A possible implementation of the step 2.3 in a website (rules in background)

6. 4 .Figure 6 . 6 :

 466 Figure 6.6: A possible implementation of the step 2.4 in a website, highlighted in orange

  ,6.18, 6.19, and 6.20 show the values of the characteristics of the VR interaction techniques that have been recommended with each methodology, in terms of being appropriate for the usability of the interaction. The results obtained with the traditional methodology, initially stored in a text report document of the meetings with the VR developer, have been put to the same format than the one of the website, to allow for the visual comparison of the results.

Figure A. 1 :

 1 Figure A.1: Overview of our methodology for designing VR interactions, according to a domain-specific task

Figure A. 2 :

 2 Figure A.2: Step 1 mechanism: input, core and output

A. 3 .

 3 Figure A.3: Step 1 example: input task: compare as-built/as-planned in critical zones

2 .

 2 Figure A.4 shows this hierarchical model, on the right, whereas, on the left, you can observe the mechanism that you will use to proceed to a guided decomposition, as explained afterwards.

Figure A. 4 :

 4 Figure A.4: Step 1 hierarchical model to use and mechanism proposed to guide this decomposition

Figure A. 5

 5 Figure A.5 shows our step 1 process applied to our example: the hierarchical task analysis is done following our grammatical pattern and our hierarchical model. The verbs suggested from a level of decomposition to another are used in this example, allowing for a guided decomposition from the domain-specific task to primitive tasks that can be used in the step 2. This decomposition represents the model of the task built in the step 1.

Figure A. 5 :

 5 Figure A.5: Step 1 example: model built for the task "compare as-built/as-planned in critical zones"

  Figure A.7 shows the step 2.1 mechanism and automated system, and Figure A.8 shows its application to one of the primitive tasks of our example.

Figure A. 7 :

 7 Figure A.7: Step 2.1: automatic identification of VR type of interaction and task characteristics

Figure A. 9

 9 Figure A.9 shows the step 2.2 mechanism and Figure A.10 shows its use on our example.

Figure A. 9 :

 9 Figure A.9: Step 2.2 Automatic association of a list of characteristics for the VR interaction and manual attribution of the VR interaction characteristics

Figure A. 11

 11 Figure A.11 shows the mechanism of this step, with our automatic system, and Figure A.12 shows its use on an interaction of our example.

Figure A. 11 :

 11 Figure A.11: Step 2.3: automated determination of the VR interaction technique characteristics

  3 and 2.4 could be shown to you at the same time in a unique automated system. Details about this translation step are given in the appendices of this guide. To conclude, Figure A.13 shows the step 2.4 mechanism and Figure A.14 shows its use on our example.

Figure A. 13 :

 13 Figure A.13: Step 2.4: translation of the characteristics from 2.3 into proposals of VR interaction techniques

FigureFigure A. 17 :

 17 Figure A.17: Step 3.2: development of the VR prototypes

A. 5 .

 5 STEP 3: CREATE VR APPLICATION PROTOTYPES AND RUN USER EVALUATIONS factor. These weights are necessary since the developer can use them then, for determining a global usability score for an interaction technique, by calculating a weighted average of the different scores for each user. This allows for the comparison of the results obtained for each interaction technique.

Figure A. 18

 18 Figure A.18 shows the step 3.3 mechanism with all these components.

Figure A. 18 :

 18 Figure A.18: Step 3.3: preparation of the user evaluations and its components

Figure A. 19 :

 19 Figure A.19: Step 3.4: user evaluations on usability of the interaction techniques and final output

Figure B. 1

 1 shows two different

Figure B. 1 :

 1 Figure B.1: Two examples of hazardous situations in a virtual worksite: on the left, an example of a fall hazardous situation, on the right a struck-by hazardous situation

  Figure B.2: A user navigating in the virtual worksite in our desktop WebGL application with the mouse pointer

  Figure B.3 shows a user navigating in the application using a HMD.

Figure B. 3 :

 3 Figure B.3: A user navigating in the virtual worksite in VR in our HMD application with a ray-pointer from a HMD controller

Figure B. 4

 4 Figure B.4 shows the characteristics obtained using our methodology about the interaction technique for this interaction.

Figure B. 4 :

 4 Figure B.4: The characteristics obtained in the step 2 about the interaction technique for moving in the whole worksite

  Figure B.7 shows one worker, on the top, in a safe situation thanks to guardrails, and, on the bottom, another worker in a struck-by hazardous situation.

Figure B. 7 :

 7 Figure B.7: Workers can be in safe situations (on the left) or in hazardous situations (on the right)

B. 4 .

 4 Figure B.8: An informative document to give examples of hazardous situations related to falls and struck-by, adapted from OSHA content

Figure B. 9 :

 9 Figure B.9: An online tutorial to explain all the commands for the VR application

Figure B. 10 B. 5 .

 105 STEP 3.4 WITH WEBGL PARTICIPANTS: RESULTS AND DISCUSSION

  Figure B.11 shows the interface provided here for the cross-weighting technique.

Figure B. 10 :

 10 Figure B.10: "Simple" weighting technique for the quality factors based on sliders

  Figures B.13 and B.14, it seems to be the same trend with the information gathering and situation awareness scores. Finally, about the ease of use in Figure B.15, it seems to be the opposite trend, more moderately, with better scores with the indirect mode. About the global usability scores, it seems that Figure B.16 show that the usability was better with the direct mode. However, with the scores in Figures B.17and B.18 it tends to not be the case; finally, with the results in B.19, it seems that

  and B.18 it tends to not be the case; finally, with the results in B.19, it seems that the usability could be the same with both interaction techniques.

Figure B. 12 :

 12 Figure B.12: Rapidity quality factor scores distribution -between WebGL subjects data

  , B.21, B.22 and B.23 show the distribution of the results obtained for the rapidity, information gathering, situation awareness and ease of use respectively. Next, we calculated the global usability scores with weights obtained by the four different ways presented previously. The usability scores can be observed in Figures B.24, B.25, B.26 and B.27. The B.6. STEP 3.4 WITH HMD PARTICIPANTS: RESULTS AND DISCUSSION

  Figures B.21 and B.22 it seems to be the same trend with the information gathering -but with relatively less difference between the two interaction techniques -and situation awareness scores.Finally, about the ease of use in Figure B.23 it tends to be the opposite trend with better scores with the indirect mode. Then, about the usability scores, Figure B.24 may show that the usability was better with the direct mode, in all the combinations order+case. However, with the usability scores present in Figures B.25 and B.26, it tends to not be as marked as with the previous figure. Indeed, in each figure, there is at least one combination "order+case" where the usability is better with the indirect mode. Finally, based on the results in Figure B.27, it seems that the usability would be the same with both navigation interaction techniques: for three combinations order+case, the usability score tends to be the same, whereas for only one combination the results are better with the direct interaction technique.

Figure B. 20 :

 20 Figure B.20: Rapidity quality factor scores distribution -within VR subjects data

1. 4

 4 Description de notre contribution sur la conception d'EV et structure de ce document En analysant les méthodologies existantes [11] [30] [70], trois composantes principales ressortent : pour la conception, l'analyse de la tâche de l'utilisateur et une étude des techniques d'interaction existantes par le biais de directives et d'évaluations expertes, et pour les évaluations, des processus d'évaluations utilisateur sur l'utilisabilité des techniques d'interaction. Sur la base de cette analyse, nous avons expérimenté dans cette thèse ces méthodologies sur plusieurs cas d'étude du domaine AEC. Au cours de ces expériences, nous avons remarqué certains problèmes potentiels par rapport à la façon de concevoir les interactions en suivant ces méthodologies. Ceux-ci sont liés à la nécessité, pour pouvoir suivre ces méthodologies, de disposer de connaissances en analyse de tâches et surtout d'une expertise en matière 1.4. DESCRIPTION DE NOTRE CONTRIBUTION SUR LA CONCEPTION D'EV ET STRUCTURE DE CE DOCUMENT d'environnement virtuel. Nous en avons déduit les questions scientifiques suivantes : comment améliorer l'analyse des tâches pour la rendre accessible aux experts AEC/d'un domaine spécifique, et comment modifier l'approche actuelle de conception de l'EV pour impliquer davantage les experts AEC/d'un domaine spécifique et moins les experts en EV. Pour répondre à ces questions de recherche, nous avons proposé dans cette thèse une méthodologie de conception centrée sur les tâches. Notre méthodologie vise à guider les experts AEC/d'un domaine spécifique pour obtenir, à partir de leur tâche spécifique à leur domaine, comme par exemple la supervision de chantier pour un expert AEC, les techniques d'interaction en EV, appropriées par rapport à cette tâche en terme d'utilisabilité, avant de demander à un expert en EV de prototyper des applications et de mener des évaluations utilisateurs. Il convient de souligner que notre méthodologie a l'ambition d'être générique, mais ici nous l'avons seulement appliquée et testée dans le contexte de l'industrie de l'AEC. La Figure 1.1 montre un aperçu de la structure du document de thèse et de ses annexes.

Figure 1 . 1 : 2 État de l'art 2 . 1

 11221 Figure 1.1: Structure de la thèse et de ce document

Figure 2 . 1 :

 21 Figure 2.1: Continuum réalité-virtualité de Milgram et al. [56]

2. 1 .-

 1 Figure 2.2 illustre ce principe liée à la réalité virtuelle.

Figure 2 . 2 :

 22 Figure 2.2: Les trois "i" de la réalité virtuelle -image adaptée à partir de Fuchs et al.[29] et Mutterlein[60]

  construction à accomplir certaines de leurs tâches. L'un des principaux objectifs du BIM est de centraliser toutes les données relatives à un bâtiment, de sa conception à sa rénovation ou à son recyclage. Ainsi, le BIM permet à toutes les parties prenantes de partager et de participer à un modèle numérique commun. La Figure 2.3 montre une représentation possible des données BIM : un modèle de conception en 3D [47].

Figure 2 . 3 :

 23 Figure 2.3: Modèles 3D utilisés dans des outils BIM -Johansson et al.[47]

  Figure 3.1 montre deux points (ici des cubes) entre lesquels un utilisateur pouvait naviguer.

Figure 3 . 1 :

 31 Figure 3.1: Supervision de chantier : navigation avec la technique d'interaction "vol"

3. 3

 3 Cas d'étude 2 : résolution des conflits de conception3.3.1 Description du cas d'étudeCe cas d'étude s'est concentrée sur un aspect particulier des revues de conception : les conflits de conception. En général, un conflit de conception entre plusieurs éléments se produit lorsqu'un élément est mal placé et entre en collision avec un autre élément. La Figure3.3 montre deux exemples de conflits qui peuvent apparaître lors de cette étape de coordination de conception. Si la détection peut de mieux en mieux se faire de façon automatique avec des outils BIM[25] [80], leur analyse et résolution restent encore à la charge des coordinateurs de conception[7], et c'est donc cette tâche de résolution qui a été étudié ici[76].

Figure 3 . 3 :

 33 Figure 3.3: Exemples de conflits entre des éléments de plomberie et de ventilation

4. 1 .

 1 PROBL ÈME DE RECHERCHE étape 1 -composante A), les évaluations des experts (Gabbard et al. étape 2 -composante B) et les évaluations des utilisateurs (Gabbard et al. étapes 3 et 4 -composante C). Ceci contient donc les trois principaux composants décrits ci-dessus : dans la Figure 4.1, Gabbard et al. quatre étapes sont montrées, avec ces trois composants mis en évidence sur eux, en utilisant des cercles verts et des lettres. De plus, nous avons ajouté des cercles orange pour signaler ce qui pourrait être amélioré dans cette méthodologie : les paragraphes suivants présentent et expliquent ces possibles améliorations.

Figure 4 . 1 :

 41 Figure 4.1: Notre analyse de la méthodologie de conception centrée sur l'utilisateur deGabbard et al.[30]

Figure 4 .

 4 Figure 4.2 et des cercles orange signalent les éléments qui peuvent être améliorés.Leur idée originale, par rapport aux travaux précédents, a été d'ajouter un "niveau de domaine" intermédiaire pour améliorer les spécifications des techniques d'interaction : cependant, ces connaissances ont fortement amélioré la décomposition descendante (A) mais

Figure 4 . 2 :

 42 Figure 4.2: Notre analyse de la méthodologie de conception centrée sur l'utilisateur deChen et al.[18]

4. 1 . 5

 15 Questions de rechercheLes deux sous-problèmes de recherche évoqués ci-dessus nous conduisent aux questions de recherche suivantes : 4.2. HYPOTH ÈSES -Q1 : Comment permettre aux experts du domaine d'obtenir les spécifications qui sont liées aux tâches spécifiques au domaine effectuées dans l'EV et qui sont nécessaires à la conception des interactions de l'EV ? -Q2 : Comment permettre aux experts du domaine, qui n'ont pas d'expertise en matière d'environnement virtuel, de déterminer les techniques d'interaction qu'il convient d'utiliser dans leur environnement virtuel, en termes d'utilisabilité et en fonction de leur tâche ? 4.2 Hypothèses Sur la base de ces deux questions de recherche, nous proposons les hypothèses suivantes : -Hypothèse globale H0 : Une méthodologie de conception centrée sur les tâches peut être utilisée par des experts spécifiques à un domaine (ici AEC), en autonomie et sans expertise en RV, et permet d'obtenir des résultats similaires à ceux obtenus avec une méthodologie de conception traditionnelle centrée sur l'utilisateur Critères d'évaluation : la méthodologie et son système associé sont 1) utilisables par des experts spécifiques au domaine (AEC ici), 2) de manière autonome, et 3) permettent d'obtenir des résultats similaires à ceux d'une méthodologie traditionnelle de conception centrée sur l'utilisateur (valeurs booléennes pour tous ces critères) -Hypothèse H1 : Un système semi-automatique de décomposition d'une tâche spécifique au domaine de l'utilisateur peut aider un expert d'un domaine spécifique (ici AEC) à obtenir des spécifications de tâche qui sont similaires à celles obtenues lors d'une réunion traditionnelle avec un expert en RV Critère d'évaluation : les résultats obtenus avec ce système semi-automatisé utilisé pour la décomposition des tâches sont similaires à ceux obtenus avec une méthodologie traditionnelle (valeurs booléennes) -Hypothèse H2 : Un système semi-automatisé peut aider un expert spécifique à un domaine (AEC ici) à déterminer des techniques d'interaction RV qui sont similaires à celles définies lors d'une réunion traditionnelle avec un expert en RV Critère d'évaluation : les résultats obtenus avec ce système semi-automatisé utilisé pour la détermination des propositions de techniques d'interaction RV sont similaires

5. 1 . 2 Figure 5 . 1 :

 1251 Figure 5.1: Vue d'ensemble de notre méthodologie de conception centrée sur les tâches, pour la conception des interactions utilisateur en RV

Figure 5 . 2 :

 52 Figure 5.2: Vue d'ensemble de l'étape 1 de notre méthodologie et de ses composantes pour obtenir des tâches primitives

Figure 5 . 3 :Figure 5 . 4 : 1 5. 3

 535413 Figure 5.3: Etape 1 : modèle hiérarchique pour la décomposition des tâches via une HTA

Figure 5 . 7 :

 57 Figure 5.7: Mécanisme de l'étape 2.2 : caractérisation des interactions de RV

Figure 5 . 8 :

 58 Figure 5.8: Notre liste des caractéristiques pour les interactions de navigation

Figure 5 . 9 :Figure 5 . 10 :

 59510 Figure 5.9: Notre liste des caractéristiques pour les interactions de sélection

Figure 5 . 11 :

 511 Figure 5.11: Mécanisme de l'étape 2.3 : détermination des caractéristiques de la ou des techniques d'interaction RV appropriées pour une interaction de RV

Figure 5 . 12 :

 512 Figure 5.12: Le processus de construction de notre taxonomie des techniques d'interaction de navigation (à gauche) à partir de la taxonomie de Bowman et al.(à droite) [10]

5. 3 .Figure 5 . 13 :Figure 5 . 14 :Figure 5 . 15 :

 3513514515 Figure 5.13: Notre taxonomie des caractéristiques pour les techniques d'interaction de navigation en EV

Figure 5 . 16 :Figure 5 . 17 :Figure 5 . 18 :

 516517518 Figure 5.16: Le processus de création de notre taxonomie des techniques d'interaction de manipulation (à gauche) à partir de la taxonomie de Bowman et al.(à droite) [12]

Figure 5 . 19 :

 519 Figure 5.19: Vue d'ensemble de l'étape 3 de notre méthodologie

6. 2 .

 2 ÉVALUATION, CRIT ÈRES ET SEUILS LI ÉS AUX CRIT ÈRES 6.2 Évaluation, critères et seuils liés aux critères Tout d'abord, pour le critère "être utilisable par des utilisateurs d'un domaine spécifique", une première façon de l'évaluer sera de vérifier si les utilisateurs ont réussi à suivre entièrement les étapes 1 et 2 de notre méthodologie, en plus de leurs commentaires subjectifs. De plus, nous comparerons le temps passé par les utilisateurs avec notre méthodologie et celui passé avec un expert en RV. Dans cette expérience, le seuil de rentabilité pour ce critère a été fixé à : un temps inférieur à 133% du temps passé avec la méthodologie traditionnelle indiquera que notre méthodologie est utilisable, sinon qu'elle est non utilisable (valeurs booléennes).

6. 3

 3 Un site web comme support pour notre méthodologie Pour cette expérience, un site web a été crééhttps://pierreraimbaud.github.io/ guideVR -pour permettre l'exécution des étapes 1 et 2 de notre méthodologie. Ce site web avait deux avantages principaux : il était facilement accessible à nos utilisateurs, et il était 6.4. CAS D' ÉTUDE 1 -T ÂCHE D'IDENTIFICATION PR ÉVENTIVE DE DANGER possible de mettre en oeuvre directement nos systèmes semi-automatisés au sein de ce site. Il permet aux utilisateurs de notre méthodologie de construire le modèle d'une tâche spécifique à un domaine -étape 1, et de déterminer des propositions de techniques d'interaction RV -étape 2. Au final, il permet donc d'obtenir les spécifications des techniques d'interaction en RV en fonction d'une tâche à réaliser en RV, et ce, sans avoir d'expertise en RV. 6.4 Cas d'étude 1 -tâche d'identification préventive de danger L'utilisation du BIM, et notamment des simulations 4D, peut contribuer à améliorer les actions menées préventivement pour la sécurité du futur chantier. Néanmoins, pour prévenir les risques de chutes et de choc, ce type de simulation peut également être réalisé dans un EV immersif. En effet, nous pensons qu'un tel environnement pourrait aider les inspecteurs de sécurité à détecter et à comprendre ces dangers. Dans ce cas, une des tâches principales des inspecteurs de sécurité consisterait alors à inspecter un chantier virtuel afin de détecter préventivement les dangers. Nous proposons d'étudier cette tâche pour ce cas d'étude.6.5 Cas d'étude 2 -tâche : revue de conception d'un local technique, aspect besoins en espace

Figure 6 . 3 :Figure 6 . 4 :Figure 6 . 5 :Figure 6 . 6 :

 63646566 Figure 6.3: Caractéristiques technique d'interaction, interaction "activer fonc. signalement"

Figure 6 . 10 :Figure 6 . 11 :Figure 6 . 12 : 6 . 8 . 6

 610611612686 Figure 6.10: Caractéristiques technique d'interaction, interaction "cibler 2 points -proches ou lointains"

6. 10 7 . 2

 1072 Conclusions sur nos trois critères d'évaluation sur notre méthodologie Sur la base de l'analyse des résultats obtenus dans cette expérience et des seuils vérifiés ici, notre méthodologie semble utilisable par les professionnels de l'AEC, en autonomie, et permet d'obtenir des résultats similaires à ceux obtenus avec une méthodologie traditionnelle. La valeur positive obtenue pour ce dernier critère induit que nos hypothèses H1 et H2 sont vérifiées, alors que toutes ces valeurs positives pour tous ces critères induisent que notre hypothèse H0 est vérifiée dans le cadre de cette expérience. 7.2. IMPLICATIONS DE NOTRE CONTRIBUTION de l'utilisateur à la conception d'environnements virtuels. En revanche, en comparaison avec ce travail, notre recherche place les utilisateurs des EV, qui sont des experts spécifiques à un domaine, tel que l'industrie AEC, comme les acteurs principaux du processus de conception de ces EV, grâce à une méthodologie qu'ils sont capables de suivre et d'exécuter en toute autonomie. Implications de notre contribution Notre contribution pourrait être intéressante pour les professionnels de l'industrie AEC et pour les experts d'autres domaines, puisque notre méthodologie a été testée et évaluée pour les tâches AEC, mais possède une structure et des composants génériques. Nos recherches pourraient améliorer l'implication de ces experts dans le processus de conception, puisqu'ils peuvent utiliser et suivre notre méthodologie en toute autonomie. Par conséquent, notre travail pourrait augmenter, dans divers domaines, le nombre de projets qui utiliseraient des environnements virtuels, puisque notre méthodologie peut encourager les experts spécifiques à un domaine à vouloir des environnements virtuels, en leur permettant de concevoir eux-mêmes ces EV. À cette fin, nous fournissons ici, en annexe A du présent document (en anglais), un guide pratique de notre méthodologie.

7. 3 Limitations

 3 Nous avons proposé ici une méthodologie pour concevoir des interactions d'EV avec ses systèmes semi-automatisés, et nous l'avons évaluée selon trois critères -l'utilisabilité pour les experts du domaine, l'autonomie et la similarité des résultats, qui ont été vérifiés dans une expérience. Néanmoins, deux autres critères pourraient être pris en compte ici pour cette évaluation, comme mentionné dans le chapitre 4 : la robustesse et l'exhaustivité.A propos de la robustesse, la nature de ce critère explique son absence dans notre évaluation sous forme d'une vérification directe. Néanmoins, les taxonomies utilisées ici ont été adaptées pour notre système à partir de taxonomies bien établies dans la littérature[10] [12] [70] [5],

Table 3

 3

	.2.

Table 3 .

 3

	Average	A	3.75	5.75
	Std. dev.	A	2.06	2.66
	Average	B	6.5	4.63
	Std. dev.	B	3.32	2.75
	Average	A and B	5.13	5.19

1: Statistical indicators of the task completion time results

Figure 3.10: Clash resolution: task completion time results 3.3. CLASH RESOLUTION DURING DESIGN COORDINATION CASE STUDY Quality of the solutions (grade/10) indicator Clash case 3D VR 2D screen

Table 3 . 2

 32

: Statistical indicators of the quality of the solution results

  In this next chapter, we present this analytical reading, explaining what our research problem is, and which research questions can be raised about the design of VE interactions. Finally, we give our own hypotheses and suggestions that could be used to develop a new methodology for designing VE interactions.

	4.1. RESEARCH PROBLEM
	4.1 Research problem
	4.1.1 Statements about VE and BIM benefits

Table 5 .

 5

	5.3. STEP 2: DETERMINE PROPOSALS OF VR INTERACTION TECHNIQUES
	Verb used to describe the task VR Interaction type VR Interaction sub-type (if type = motor)
	See	Perceptual	-
	Hear	Perceptual	-
	Think	Cognitive	-
	Decide	Cognitive	-
	Travel	Motor	Navigation
	Take/grab (an object)	Motor	Selection
	Activate (a function)	Motor	Selection
	Target	Motor	Selection
	Place/orient (an object)	Motor	Manipulation

1: Correlation table used in our automatic system, between the verbs that describe primitive tasks -the ones present as outputs of our step 1, and the types and sub-types of VR interactions 5.3.3 Step 2.2: Characterisation of the VR interactions

Table 5 . 8

 58

	Target	Target	Target	Acc.	Acc.	Acc.	Speed	Bowman	Proposals of VR
	con-	selec-	avail-	con-	con-	vari-	order	tax-	int. techniques
	trol	tion	able	trol	trol	ation		onomy
	owner	mode	zone	owner	mode	mode		name
	User	Free	Direct	User	Conti-	X	Human Gesture-	Natural walking,
					nuous			steering	omni-directional
									treadmill, joystick
	User	Restric-	Direct	User	Conti-	X	Human Gesture-	Natural walking
		ted			nuous			steering	(restricted), one-
									direction	tread-
									mill, keyboard
	User	Restric-	Direct	Auto	-	Con-	Human Gaze-	Gaze-directed
		ted				stant		directed	"guided tour"
						travel		steering
	User	Free	Direct	User	Start/	X	Human Pointing	Free	pointing
					Stop			steering	steering (human
									speed transition)
	User	Free	Indirect User	Start/	X	Human Pointing	Free	pointing
					Stop			steering	steering (human
									speed transition)
									on a map/ a list
	User	Restric-	Direct	User	Start/	X	Human Pointing	Restricted point-
		ted			Stop			steering	ing steering (hu-
									man speed trans.)
	User	Restric-	Indirect User	Start/	X	Human Pointing	Restricted point-
		ted			Stop			steering	ing steering (hu-
									man speed trans.)
									on a map/ a list
	User	Free	Indirect User	Start/	X	Infinite Pointing	Free	(pointing)
					Stop			steering	teleportation on a
									map/ a list
	Auto	-	-	User	Start/	X	Infinite Pointing	Auto (pointing)
					Stop			steering	teleportation
	User	Restric-	Indirect User	Start/	X	Infinite Pointing	Restricted (point-
		ted			Stop			steering	ing) teleportation
									on a map/ a list
	User	Restric-	Indirect Auto	X	With	Infinite Pointing	Teleportation "dir.
		ted				var.		steering	programmable
									guided tour"
	Auto	-	-	Auto	X	With	Infinite Pointing	Teleportation "full
						var.		steering	guided tour"
	Table 5.5: Navigation: translations between VR interaction techniques characteristics and existing
					VR interaction techniques

: Manipulation (rotations required): translations between VR interaction techniques characteristics and existing VR interaction techniques

Table 6 .

 6 1 summarises the results obtained in this experiment for the similarity criterion, used to evaluate our methodology.

	Case\Similarity Functionalities Interactions Int. techniques charac. Int. techniques proposals
	Case study 1	75%	80%	96%	75%
	Case study 2	80%	88%	97%	86%

Table 6 .

 6 1: Summary of the results in percent obtained for the similarity criterion on the two case studies of this experiment

Table 6 .

 6 2summarises the validation of all our criteria in this experiment and thus of our methodology.

	Criterion\Hypothesis	H0	H1	H2
	Usable	Verified	Not present in this hypothesis Not present in this hypothesis
	Autonomy	Verified	Not present in this hypothesis Not present in this hypothesis
	Similarity	Verified	Verified	Verified
	⇒	H0 verified	H1 verified	H2 verified

Table 6 .

 6

2: Summary of the results obtained for all the criteria in this experiment and their consequence on the validation of our hypotheses

  .1 for each quality factor.

	Quality factor	Measure(s) associated
	Rapidity	Navigation time (in seconds)
	Information gathering	Number of hazards marked + time spent to identify (in seconds)
	Situation awareness	Time spent for camera orientation (except when moving, in seconds)
	Ease-of-use	Number of clicks required for navigating in all the worksite
	Table B.1: Quality factors and measures in this experiment on navigation for hazard identification
	B.4.6 Weight attribution to quality factors and usability scores

  Nous avons développé un prototype d'application de RM avec des vidéos issues du drone et un modèle 3D issu du BIM, et ceci en superposant certains éléments virtuels à certaines images des vidéos. Puis, en ce qui concerne les interactions utilisateur, notre application de RM a été prototypée ici comme une application de bureau. Néanmoins, l'évaluation et l'étude d'experts sur les techniques d'interaction utilisateur étaient encore nécessaires. Sur la base de l'analyse des tâches, deux interactions principales étaient présentes : se déplacer dans le chantier virtuel et utiliser un outil d'annotation. Pour cette dernière, le fait que le prototype

	3.2. CAS D' ÉTUDE 1 : SUPERVISION DE LA CONSTRUCTION D'UN CHANTIER
	en analyse de tâches, il était difficile d'estimer quand arrêter la décomposition.
	3.2.4 Étude d'experts, lignes directrices et prototypage
	Tout
	d'abord, nous avons décomposé cette tâche en deux sous-tâches : détecter les différences entre
	les vidéos prises par le drone et le modèle 3D BIM, et signaler ces différences pour de futures
	corrections. Ensuite, nous avons proposé de diviser la sous-tâche de détection en "rechercher
	les zones présentant des différences" et "identifier les zones présentant des différences", et
	de diviser la sous-tâche de rapport en "annoter les problèmes identifiés" et "transmettre les
	problèmes pour correction". Enfin, nous avons proposé de diviser l'action de recherche en "se
	déplacer dans le chantier virtuel et observer les zones", l'action d'identification en "observer
	les différences dans une zone et décider si des erreurs sont présentes", l'action d'annotation
	en "choisir un outil d'annotation et l'utiliser", et l'action de transmission des problèmes en

"vérifier mentalement si l'inspection est complète et appuyer sur l'outil de validation". Enfin, les deux superviseurs de la construction ont fait remarquer que, sans avoir de compétences de RM était une application de bureau a induit l'utilisation de la souris pour sélectionner une zone et activer le mode d'annotation, et du clavier pour écrire.

  Nous avons effectué ici une décomposition hiérarchique de la tâche de résolution des conflits, en collaboration avec deux coordinateurs BIM. Tout d'abord, nous avons décomposé cette tâche principale en deux sous-tâches : comprendre le conflit, puis fournir une solution à ce conflit. Ensuite, nous avons proposé de diviser la "sous-tâche de compréhension" en "vérifier les problèmes entre les éléments impliqués dans les conflits", et "imaginer une solution à ce conflit", et de diviser la sous-tâche concernant le don d'une solution en "annoter la solution sur la zone du conflit" et "transmettre la solution proposée pour correction dans le logiciel BIM".

	3.3. CAS D' ÉTUDE 2 : R ÉSOLUTION DES CONFLITS DE CONCEPTION 3.3. CAS D' ÉTUDE 2 : R ÉSOLUTION DES CONFLITS DE CONCEPTION
	3.3.3 Analyse de la tâche utilisateur Indicateur de temps d'achèvement de la tâche (min) Cas de conflits 3D VR écran 2D
	Moyenne	A	2,77	4,46
	Dev. std.	A	0,95	1,84
	Moyenne	B	2,52	3,29
	Dev. std.	B	1.59	1.96
	Moyenne	A et B	2,64	3,88
	Tout d'abord, pour construire une application de RV pour ce cas d'étude, des modèles
	3D, provenant du logiciel de conception BIM, ont été nécessaires, ainsi que les résultats de la
	détection automatique des conflits sur ces modèles.
	Puis, sur la base de l'analyse des tâches de l'utilisateur, deux interactions principales
	ont été étudiées ici : se rapprocher des conflits et utiliser un outil d'annotation. En ce qui
	concerne l'interaction de navigation, pour s'approcher des conflits, la technique d'interaction
	de marche naturelle a été choisie car la quantité de mouvements était limitée et car les
	conflits étaient déjà détectés et donc pas de besoin d'exploration. Cependant, pour l'action
	d'annotation, une étude experte devait être faite. Sur la base des connaissances de l'expert
	306

cation de RV -moyenne d'âge

de 22,6

ans (+/-1,06).

Enfin, nous avons proposé de diviser l'action de vérifier les problèmes en "se rapprocher vers et autour du conflit", en "observer le conflit" et en "étudier les éléments impliqués", l'action d'imaginer une solution en "observer le conflit" et "l'analyser", l'action d'annoter en "choisir un outil d'annotation" et en "l'utiliser", et l'action de transmettre les problèmes en "faire une dernière vérification mentale" et en "appuyer sur l'outil de validation".

A propos de cette analyse, les deux coordinateurs du BIM ont avoué qu'ils ont éprouvé des difficultés à répartir une tâche qu'ils comprennent et connaissent instinctivement sans la diviser en détails. Il nous a fallu guider cette décomposition, et proposer des verbes adéquats.

3.3.4 Étude d'experts, lignes directrices et prototypage

en RV et de la taxonomie de Poupyrev et al.

[69]

, la métaphore du pointeur virtuel a été choisie. Ce choix a été principalement motivé par les faits suivants : en raison de la nature de

Table 3 .

 3

	1: Indicateurs statistiques pour les résultats concernant le temps d'achèvement de
	la tâche
	Indicateur de qualité des solutions (note/10) Cas de conflits 3D VR écran 2D
	Moyenne	A	3,75	5,75
	Dev. std.	A	2.06	2.66
	Moyenne	B	6,5	4,63
	Dev. std.	B	3.32	2.75
	Moyenne	A et B	5,13	5,19

Table 3 .

 3

	L'ANOVA sur les données du temps d'achèvement des tâches a révélé que le facteur
	"Nature de l'outil" a un effet significatif sur le temps d'achèvement avec une valeur p de 0,045
	sur un niveau de signification de α=0,05. L'autre ANOVA sur les données de qualité des
	solutions a révélé que le facteur "Nature de l'outil" n'a pas d'effet significatif sur la qualité
	de la solution avec une p-value de 0,69 sur un niveau de signification de α=0,05. Cependant,
	ce dernier résultat ne doit pas être considéré comme définitif, puisque l'analyse statistique a
	révélé un effet significatif du cas de conflit pour cette mesure avec une p-value de 0,019 sur

2: Indicateurs statistiques pour les résultats concernant la qualité des solutions

3.3.5.2 Discussion

Une analyse statistique peut être effectuée sur les résultats, organisés en deux ensembles de données de seize lignes, l'un pour les données relatives au temps d'achèvement de la tâche et l'autre pour les données relatives à la qualité des solutions. Il convient de souligner que les données sont conformes aux hypothèses requises pour une analyse statistique de type ANOVA, et que donc nous avons pu effectuer une "ANOVA mesures répétées à deux facteurs", sur chaque ensemble de données, avec les facteurs "Nature de l'outil" et "Cas de conflits". un niveau de signification de α=0,05. Cela signifie que les cas de conflit utilisés ici ont eu un effet non prévu sur les résultats de cette mesure, alors que ce n'était pas le cas pour la mesure du temps d'achèvement des tâches avec une valeur p de 0,25 sur un niveau de α=0,05. ce qui concerne l'aspect performance de l'utilisabilité, l'application a été conçue de manière appropriée, et en ce qui concerne l'aspect satisfaction, elle a également reçu des résultats positifs. Néanmoins, d'autres évaluations utilisateur doivent être menées pour tester d'autres techniques d'interaction pour l'annotation, afin de confirmer ces résultats.

  Il convient de souligner que cette méthodologie pourrait être utilisée de manière générique, mais tous nos exemples et toutes les tâches utilisateur analysées au cours de cette recherche concernent l'industrie de l'AEC. En outre, la plupart de nos solutions de réalité virtuelle pour ces cas d'étude ont été développées avec la technologie de réalité virtuelle, plus qu'en réalité augmentée par exemple.5.2. ÉTAPE 1 : CONSTRUIRE UN MOD ÈLE DE LA T ÂCHE SP ÉCIFIQUE AU DOMAINEsera évalué dans une expérience présentée dans le chapitre 6.

	4.3. PORT ÉE DE LA RECHERCHE
	à ceux obtenus avec une méthodologie traditionnelle (valeurs booléennes)
	Concernant les valeurs possibles pour les critères, nous proposons les valeurs suivantes
	(valeurs booléennes) :
	-pour le critère utilisable par les experts spécifiques au domaine : utilisable / non utili-
	sable
	-pour le critère de autonomie : en autonomie / pas en autonomie
	-pour le critère de similarité : similaire / non similaire
	En outre, deux autres critères pourraient être pris en compte pour cette évaluation :

-L'exhaustivité de la méthodologie : des résultats peuvent être obtenus avec la méthodologie pour tout cas d'étude, en considérant toutes les possibilités à la fois pour la décomposition des tâches et la détermination des propositions de techniques d'interaction -La robustesse de la méthodologie dans le temps et donc pour les futures technologies d'EV : les résultats obtenus avec la méthodologie pourraient être utilisés et seraient valables même pour les technologies futures 4.3 Portée de la recherche Notre recherche, présentée dans ce document, cherche à comprendre les questions actuelles sur la conception des interactions d'EV et à présenter notre nouvelle méthodologie de conception centrée sur les tâches.

Table 6 .

 6 6.9.1 Critère d'utilisabilité de notre méthodologie Tout d'abord, les deux professionnels de l'AEC ont réalisé entièrement les étapes 1 et 2 de notre méthodologie pour les 2 cas d'étude. De plus, ils ont donné un retour subjectif positif, notamment en ce qui concerne l'étape 1 de la décomposition des tâches. Ce résultat tend à indiquer que notre méthodologie est utilisable. En outre, nous pouvons analyser ici les résultats obtenus sur le temps passé par les profes-6.10. CONCLUSIONS SUR NOS TROIS CRIT ÈRES D' ÉVALUATION SUR NOTRE M ÉTHODOLOGIE 6.9.7 Critère de similarité concernant notre méthodologie : évaluation finale pour H1 et H2 Le tableau 6.1 résume les résultats obtenus dans cette expérience pour le critère de similarité, utilisé pour évaluer notre méthodologie. On peut remarquer que tous les pourcentages de similarités obtenus ici sont supérieurs au pourcentage fixé ici pour obtenir la valeur "similaire" pour ce critère lors de l'évaluation de notre méthodologie. Ainsi, ces résultats impliquent pour le critère de similarité de notre méthodologie d'avoir la valeur "similaire". 1: Résumé des résultats de pourcentage de similarité obtenus Par conséquent, d'une part, ces résultats de similarité pour les fonctionnalités et les interactions qui ont été déterminées avec les deux méthodologies -75%, 80%, 80%, 88% -vérifient notre hypothèse H1. Et d'autre part, les résultats de similitude pour les caractéristiques des techniques d'interaction et les propositions de techniques d'interaction qui ont été déterminées avec les deux méthodologies -96%, 97 %, 75%, 86% -vérifient notre hypothèse H2. Enfin, au total, ces deux résultats vérifient le critère de similarité en général, et donc cette partie de notre hypothèse H0 est également vérifiée.

	Cas\Similarité Fonctionnalités Interactions Techniques int. (caract.) Techniques int.
	Cas d'étude 1	75%	80%	96%	75%
	Cas d'étude 2	80%	88%	97%	86%

de l'utilisateur. Pour la performance de l'utilisateur pour la tâche, nous avons recueilli des données à partir de deux mesures, le temps d'achèvement de la tâche et la qualité des solutions aux conflits grâce à une note donnée par un expert en coordination de conception. Pour la satisfaction, des opinions subjectives ont été recueillies via un questionnaire post-expérience.Nous avons procédé ici à une évaluation utilisateur avec nos huit participants. Concernant le protocole expérimental, les participants ont dû observer deux conflits dans cette expérience -le conflit A et le conflit B, puis les comprendre, concevoir mentalement une solution et l'annoter. Ils devaient effectuer cette tâche une fois dans notre application de RV -appelée 3D VR par la suite, et une fois dans l'application traditionnelle de bureau -appelé écran 2D par la suite. Grâce à la conception intra-sujet appliquée ici, nous avons obtenu seize résultats au total, permettant ainsi une analyse plus poussée.Les résultats relatifs au temps d'achèvement des tâches sont disponibles dans le tableau 3.1, et dans le tableau 3.2 pour les résultats relatifs à la qualité des solutions.En ce qui concerne la satisfaction, les données ont été recueillies au moyen de onze questions, dont les résultats ont été très positifs.

L'étape 2.1 permet d'extraire deux éléments d'une tâche primitive préalablement obtenue à l'étape 1 : l'interaction associée à cette tâche, et les caractéristiques de cette tâche et de son contexte. Pour ce faire, nous proposons d'utiliser ici un système automatique pour diviser la tâche primitive en deux parties, une avec le verbe et une avec le complément. Ensuite, ce système automatique associe le verbe isolé à un type d'interaction de RV, et éventuellement à un sous-type, si moteur, grâce à une table de corrélation entre les verbes qui décrivent les tâches et les types d'interaction de RV et les sous-types moteurs, présentés dans le tableau 5.1. Enfin, les caractéristiques de la tâche sont établies en utilisant directement le contenu du complément préalablement séparé du verbe. Ainsi, ce système permet d'obtenir les deux résultats attendus pour cette étape 2.1, comme le montre la Figure 5.6.

Acknowledgements -Remerciements

ACKNOWLEDGEMENTS -REMERCIEMENTS

Je remercie également ma famille pour tout son soutien, y agradezco también a mi familia del otro lado del Atlántico en Colombia, sin la cual nada hubiera sido igual. Muchísimas gracias! Enfin, merci mon amour pour ton soutien inconditionnel durant cette thèse. Être à tes côtés est le plus beau des cadeaux. Merci! Te amo.

LIST OF FIGURES 6. 15 The VR interaction techniques characteristics for the interaction "target two measure points (close)" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. 16 The VR interaction techniques characteristics for the interaction "target two measure points (close and far)" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. 17 The VR interaction techniques characteristics for the interaction "activate the functionality of annotating a measure" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. 18 The VR interaction techniques characteristics for the interaction "target the measure to add the annotation "to modify"" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. 3 Step 1 example: input task: compare as-built/as-planned in critical zones . . . . . . . A. 4 Step 1 hierarchical model to use and mechanism proposed to guide this decomposition A. 5 Step 1 example: model built for the task "compare as-built/as-planned in critical zones" A. 6 Step 2 mechanism: input, sub-steps and output . . . . . . . . . . . . . . . . . . . . . . A. 7 Step 2.1: automatic identification of VR type of interaction and task characteristics .

Glossary

HTA Hierarchical Task Analysis -ISO 11064-3:1999 : task analysis = analytical process employed to determine the specific behaviours required of people when operating equipment or doing work HMD Head-Mounted Display -ISO 9241-394:2020 : display device that is worn on the head, is integrated into eyeglasses, or is built in as part of a helmet or a hat

Autonomy criterion about our methodology

We can note that, in this experiment, the two AEC professionals asked 3 questions during the step 1, and asked 2 or 3 questions during the step 2 of our methodology, depending on the professional. Based on these results, the autonomy criterion about our methodology has for value "in autonomy", and thus this part of our hypothesis H0 is verified here.

6.9.3 Functionalities results -similarity criterion 6.9.3.1 Case study 1: hazard identification

In the case study of hazard identification, first, we can observed that similar functionalities have been obtained with both methodologies. There is only main difference: a functionality of "report [ing] the work done in order to have a final assessment of the exploration" has been given with the traditional methodology, whereas this functionality has not been given with our methodology. About the other functionalities, the results are consistent between both methodologies, with the similar obtaining of the following three functionalities of detecting hazards, of understanding and assessing a hazard according to the state of the worksite, and of signaling these hazards in the application.

To conclude, only one functionality obtained for this case study is different between the two methodologies, and the other three functionalities are similar. This means that 75% -1/4 here -of similar functionalities have been determined with the two methodologies. This percentage is equal to the percentage fixed -75% -for the similarity criterion in this experiment. Based on that, the similarity criterion is verified for the functionalities for this case study.

Case study 2: design review of a plant room

In the case study of the design review of a plant room, all the functionalities obtained with both methodologies are almost the same. There is only main difference: a functionality of capturing pictures and another of building and sending a report has been given with the traditional methodology, whereas with our methodology, the other AEC professional has only focused on the building and sending of the report. Additionally, a comment could be made on the fact that with our methodology, the main functionalities of "searching" and then "measuring" are clearly split into "to be able to locate" and "to be able to measure", whereas with the traditional methodology, the first functionality of "identifying incompatible and the compatible ones. Incompatible differences exist when the two recommendations of characteristics are opposite ones. Oppositely, compatible differences occur in two cases.

The first case -incompatible -is when a recommendation obtained with a methodology is included in the recommendation given by the other one -e.g. recommendation methodology A for the characteristic selection tool = hand or ray (both are OK), and recommendation methodology B for the same characteristic selection tool 2 = ray, thus the recommendation from B is included in the one from A.

The second case -compatible -is when, for a characteristic, a recommendation has been obtained with a methodology, and, with the other one, there is no recommendation, meaning that the value is "undetermined", represented by a " ? " here in this experiment. A " ? " for a characteristic, when obtained following our methodology, means that no experiments in the literature have shown yet that one of the possible choices -i.e. one of the available values for the characteristic -was more appropriate in terms of usability than another. In any cases, the results from the two methodologies are compatible. 6.9.5.2 "Compatible differences" in the results -cases 1 and 2

For the case 1 of hazard identification, two compatible differences are present. First, about the local navigation (short scale), the recommendation obtained with our methodology for the speed/acceleration control is a continuous control, whereas, with the traditional methodology, the recommendation is either a continuous control or a start/stop control, to be tested and compared. Both recommendations are thus compatible. Then, about the selection task of targeting of a worker as in a hazardous situation, the kind of relationship between the real and virtual movements for the selection tool is recommended as isomorphic with the traditional methodology, whereas both an isomorphic or an anisomorphic relationship are accepted in the results obtained using our methodology. Once again, both recommendations are thus compatible.

For the case 2 of design review of a plant room (space requirements), three compatible differences are present. First, about the navigation, the results obtained with the traditional methodology recommend a speed/acceleration control by the user, whereas it was undetermined with our methodology -i.e. it was indicating that experiments would be required to determine if a user or an automatic control is recommended for this kind of tasks. The results are thus compatible here. Then, for the selection task of targeting two points to take a measure, for both close and far -from the user -Chapter 7

Conclusions and perspectives

List of publications

Conference papers accepted and available online

Recommendations of use

We recommend you to use this guide when you are writing the specifications of your future VR application. Indeed, this methodology is task-oriented, thus you need to know what the domainspecific specifications of the task you want to perform in VR are. Then, following our methodology, you will formalise these specifications and go from these specifications to the list of VR interactions that you need, and finally to a characterisation of the appropriate VR interaction techniques in terms of usability for these VR interactions, and to proposals of VR interaction techniques. This means that our methodology allows you to determine the design of the VR interactions of your future application without having VR expertise. Finally, for the concrete implementation of the VR interaction techniques -i.e. the concrete creation and realisation of the interaction techniques within the VR application and designed for a specific VR device, you will need a VR developer. This means that following our guide allows you to need VR developers only for this last phase, instead of needing them since the phase of the writing of the VR specifications.

A.2.2 Steps of our methodology

Our methodology, visible in its overall view in In this guide, we explain first how to perform the step 1 to build a model of your domain-specific task, which main idea is to decompose this task into primitive tasks/actions that you need to do in VR.

Then, we present in the step 2 a system for determining proposals of VR interaction techniques based on the characteristics of the domain-specific task and of the primitive tasks that compose it. Finally, the step 3 has been designed to provide you a process of creation of prototypes of VR applications, and a process of evaluation of the VR interactions prototyped, to obtain finally your VR application with appropriate VR interaction techniques in terms of usability.

A.3. STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK

be executed with the participation of a VR developer, and thus you will obtain:

• one or several prototypes of the VR application, with the VR interaction techniques to be tested

• usability scores for each evaluated interaction technique, and the final VR application with the recommended VR interaction techniques, as your final output following this methodology A. 3 Step 1: build a model of the domain-specific task

Overview

We propose in this first step to build a model of the domain-specific task. It is important to note that this step does not require VR expertise, but on the contrary relies on your domain-specific expertise. To build this model, we propose to perform in this step 1 a hierarchical task analysis. Task analysis is defined as an "analytical process employed to determine the specific behaviours required of people when operating equipment or doing work" by the norm ISO 11064-3:1999. Concretely, this means that doing this analysis consists of decomposing the studied domain-specific task -which is your main input before starting to apply this whole methodology by following this guide -into a set of primitive tasks/actions, which will be used as input in the step 2. This decomposition requires your active participation, since you must make decisions and divide your original domain-specific main task into subtasks until you reach the level of the primitive tasks, where it is not possible to divide anymore.

Before starting, it is important to know that making such decisions during a hierarchical task analysis may be complex, particularly for two main reasons: first, you may have difficulties to find the terms that are adapted to a particular level of complexity, and second, you may do not know when to stop dividing. For this purpose, we provide in this guide some semantic help to facilitate this decomposition -to address the first difficulty -and we also give here a list of terms that are associated to our last level of decomposition, i.e. the level of the primitive tasks -to address the second difficulty.

At the end of this step, you will obtain a set of primitive tasks, issued from your main domain-specific task. N.B: during this entire step, we propose to use a unique grammatical pattern to describe the main task (input), the subtasks in the intermediate levels of decomposition, and the primitive tasks at the last level of decomposition (output). As there are tasks, to use verbs followed by a complement is a pattern that is adapted to express them. Thus, following this guide, you must use "a verb" + "a

A.3. STEP 1: BUILD A MODEL OF THE DOMAIN-SPECIFIC TASK

The first division is probably the most important one and relies on the fact that a task can be divided into four main kinds of subtasks -not any kinds are mandatory, and a kind can be repeated. A task may be composed of 1 to 4 of the following kinds of subtasks 1) a subtask of "spatial" preparation (verbs: detect, locate), 2) a subtask of "mental" preparation (verbs: understand, prepare), 3) a subtask of "acting / performing an action, to concretely solve the problem" (verb: act/perform) -the use of this verb induces in the next level of decomposition to use some activity domain verbs, and 4) a subtasks of conclusion (verbs: finalise, close). To summarise, we propose to use at this level the verbs: detect, locate, understand, prepare, act/perform, finalise and close. If necessary, you can propose and use another verb of your choice.

Once you have proceeded to this division, you must divide each of these subtasks (division 1) again, into one or two activities (division 2). Nonetheless, we provide here an aid: the verbs of these activities (division 2) are automatically proposed depending on the verb chosen in its related subtask (division 1). For example, we propose the verbs explore (activity 1) and determine (activity 2) as children of a subtask with the verb locate. All these rules for suggestions are available in the appendices of this guide. Additionally, we propose a list of verbs for the activities: explore, search, determine, identify, imagine, conceive, test, verify, sample, annotate, signal, correct, adjust, transmit, report, and notify.

Once again, you can propose and use a verb of your choice if necessary.

The third division has a mechanism that is similar to one of the second division: you must divide each of the activities (division 2) again, into one to four operations (division 3), and we provide here the same aid by suggesting the verbs for the operations depending on those chosen for the activities. For example, we propose the verbs move (operation 1) and observe (operation 2) as children of an activity with the verb explore. All these rules for suggestions are available in the appendices of this guide.

Additionally, we propose a list of verbs for the operations: observe, listen, examine, study, analyse, move (ourselves), handle (an object), choose (an object), choose (a function/a mode), designate (an object), and summarise. Once again, you can propose and use a verb of your choice if necessary.

Finally, the four and last division has also a mechanism that is similar to previous ones: you must divide each of the operations (division 3) into one or two primitive tasks/actions (division 4) and we provide here the same aid by suggesting the verbs for the primitive tasks/actions depending on those chosen for the operations. For example, we propose the verbs think (primitive task 1) and decide (primitive task 2) as children of an operation with the verb analyse. All these rules for suggestions First, based on these data about the interaction techniques, you must talk with the VR developer about the potential VR interactions techniques that could be implemented, explaining the context of use of your application, the space that you have to use it etc. The developer would also ask you about other constraints that you may have such as about your budget, the VR device that you may want to use etc. According to this discussion, the VR developer and you will be able to decide which techniques you want to try -a "set of finalists" -and on which device.

Then, the developer will create one or several prototypes of VR applications with these VR interaction techniques implemented in. Next, the VR developer will prepare user evaluations by defining the experimental protocol and the measures to be taken. Finally, they will conduct these evaluations with some users from your domain, to determine and compare the usability, in terms of the user performance and/or the user preference, of the different interactions techniques prototyped -or in the case of having a unique prototype, to verify its usability. As the final result, based on the conclusions obtained from the user evaluations, you will be able to make the final choices for your VR application with the appropriate VR interaction techniques, in terms of usability, To summarise, the step 3 allows you, from the proposals of VR interaction techniques obtained in the step 2, to get the final VR application with the appropriate VR interaction techniques in terms of usability, designed according to your original main domain-specific task. This step is composed of the following four sub-steps, as also shown in For these experiments, you need to recruit participants from your specific domain, and these participants will have to perform, in the VR prototypes developed in the step 3.2, your domainspecific task, or at least some subtasks that involve the use of the interaction techniques developed here. The VR developer needs to ensure that these experiments are carried out correctly. Indeed, the user evaluations must follow an experimental protocol that they define: the conditions of use of the VR prototypes, the task conditions, etc. Then, the VR developer collects the data according to the measures chosen previously, and calculates the usability scores for each interaction technique in each VR prototype. Finally, these scores can be compared, and by combining all the interaction techniques with the best scores in one VR application, you obtain the final VR application for your domain-specific task. This is the final output that you obtain by following our methodology.

A.6 Appendices of this guide

The following appendices are given here:

Recommended value

Ref. For the other primitive tasks, such as tagging a worker as in a hazardous zone, we implemented the interaction technique proposed using our methodology, for example a raycast for tagging worker.

Spatial

B.3 Step 3.2: Development of the VR prototypes with the interaction techniques

In this step, we developed thus two prototypes with the two different interaction techniques for the navigation primitive task. We made two different versions of the two prototypes, one version for each device -the desktop version, and the "diverse HMD" version. This means that we build four prototypes in total -one for each of the two interaction techniques for the two devices.

Apart from the interaction techniques, about the VR content present in the application, the participants could observe a virtual worksite during a specific time of the construction phase of the building.

Several workers and machines, such as small cranes or trucks, were present in the worksite to simulate the construction tasks that had to be done at this specific time, such as pouring concrete or lifting heavy loads, and thus these construction tasks induced hazards in the worksite. Dans cette expérience, nous avons mesuré l'aspect satisfaction de l'utilisabilité. Pour ce faire, nous avons recueilli des données subjectives grâce à un questionnaire post-expérience, permettant ainsi d'évaluer cette utilisabilité, mais aussi les avantages de l'application de RM.

Les résultats de ce questionnaire sont disponibles en Figure 3.2 dont les questions étaient :

-Q1 : L'application est-elle utile pour la supervision de la construction ? -Q2 : L'application est-elle facile à utiliser ? -Q3 : L'application est-elle suffisamment claire pour interagir avec elle ? -Q4 : D'autres experts que vous pourraient-ils facilement utiliser cette application ? -Q5 : La façon de réaliser et de suivre les instructions était-elle claire ? -Q6 : L'application permet-elle d'avoir une bonne vue d'ensemble du bâtiment ? -Q7 : Etait-il facile de se déplacer dans le bâtiment dans l'application ? -Q8 : Etait-il facile de regarder des vidéos sur certaines zones du bâtiment ? -Q9 : Etait-il facile de détecter les différences/défauts du chantier dans l'application ? -Q10 : Etait-il facile d'annoter les défauts/erreurs dans l'application ? -Q11 : A-t-il été facile de transférer les annotations vers le logiciel BIM ?

Autonomie et questions pour compléter les étapes

Pour ce cas d'étude 1, en utilisant notre méthodologie, le professionnel de l'AEC a posé 3 questions à l'étape 1 et 2 dans l'étape 2.

Fonctionnalités

Grâce à notre méthodologie, les fonctionnalités suivantes ont été obtenues, directement issues des sous-tâches présentes dans le modèle hiérarchique construit à l'étape 1 :

-pouvoir localiser les éléments dangereux sur le chantier -pouvoir comprendre les relations entre ces éléments dangereux et les travailleurs -pouvoir procéder à une évaluation précise des risques en fonction de l'état du chantier virtuel en signalant les risques dans l'application Avec la méthodologie traditionnelle, le professionnel AEC a obtenu les fonctionnalités :

-pouvoir détecter les zones dangereuses afin de les identifier/localiser -pouvoir avoir une vue globale du chantier pour comprendre les dangers en fonction de son état et s'y retrouver une fois la construction réelle commencée -pouvoir signaler ces zones dangereuses dans l'application afin de laisser une trace de leur emplacement -pouvoir rendre compte du travail fait afin d'avoir une évaluation finale de l'inspection

Liste des interactions requises

Grâce à notre méthodologie, le professionnel AEC a obtenu la liste suivante des interactions requises (moteur seulement ici) :

-se déplacer dans l'ensemble du chantier -se déplacer -mouvements proches, pour affiner les prises de décision -activer la fonctionnalité permettant de signaler les travailleurs en situation de danger -cibler les travailleurs en situation de risque -placer/orienter les machines présentes sur le chantier Avec la méthodologie traditionnelle, on a obtenu la liste suivante des interactions requises (motrices seulement ici) :

-se déplacer dans l'ensemble du chantier -se déplacer -mouvements proches, pour affiner les prises de décision -activer la fonctionnalité permettant de signaler les travailleurs en situation de danger -cibler les travailleurs en situation de risque -activer la fonctionnalité permettant d'envoyer le rapport à la fin de l'inspection