## 4 Discussion
In this spirit, after triangulating the results of the experimentation, we could observe an interesting phenomenon: the different ways in which a user interpreted the system involved the proprioception the user has of the self with respect to technology or the world. This corroborated and complemented the initial segmentation related to technological literacy and previous motivation for the use of technology and allowed us to re-segment the user in the following categories (Figure 9):  
* Me in the world. The user locates themself in the world represented by the system, maybe flying. They use expressions such as \"go to the north, to the west\", \"get me closer\", and \"move me\". * Me on the street. The user imagines themself walking on the ground. They use expressions like \"turn right\", \"move away\", \"go straight ahead\", and \"how to go to\". * Me in front of a screen. The user sees the system as a system and does not try to interact naturally but tries to find out how to provoke the desired response. The user interprets the system as an interactive map (\"move it\"), and the most differentiating factor is that they use languages learned from other systems. This may happen for the following reasons. The user is very connected to the mobile web, app, etc. They use expressions such as \"back\" (referring to a previous screen or back button), \"reverse zoom\", or, in the case of a user who directed the cursor orthogonally, \"up-up-right-right-up-up\" to traverse a diagonal. Another possible reason derives from a subgroup of users with a technical profile, e.g., geographers, computer scientists, and engineers, that prompts them to speak to the system in a programming language or with technical words (e.g., \"scroll\" or \"pan\"). In these cases, the user adopts non-conjugated and non-personalized expressions. Figure 9: User profiles based on their proprioceptions and interactions with the system (figure is from the authors, designed using resources from [41]). Finally, from the prototype evaluation, we concluded that such a system is a real need. When reviewing the prototype's quality, most users expressed that they would use the tool daily. However, much work remains in this area. This experimentation methodology allowed us to detect and reflect on issues that require further research and development:  
* Voice recognition improvement. The recognition of the moment the user initiates the instruction is crucial. Currently this is solved with the keywords the user must say before verbalizing the request, e.g., the assistant's name. In addition, the transitions between instructions require enhancement. Another issue is the understanding of phonetically similar words. For example, the user says _mueve_ (\"move\"), and the system might interpret it as _mueve_ (\"nine\"). This is understandable and can perhaps be solved by limiting the vocabulary the system recognizes. Most speech recognizers use all the vocabulary of the language in which they are executed, and many misunderstandings occur with words that are not used in the GIS context. When similar words are necessary for a certain context, as in a GIS (e.g., _mueve_ and _mueve_), a feasible solution is to improve the voice recognition software. Finally, the recognition software can be enhanced to achieve comfortable use without requiring loud voice commands (e.g., when outdoors). In addition, we recommend using high-quality microphones, such as the ones used in our experiments. * Toponym problem. Most words and speech recognizers use the vocabulary of the language being spoken. The problem is that toponyms do not always belong to that language. Some have several accepted pronunciations, and users pronounce them differently, whether accepted or not. Therefore, a speech recognizer capable of detecting the correct toponym being pronounced and selecting the appropriate one from the endless list of possible toponyms is a challenge to design. * Persistence of the context.