Phd Position F/m Knowdgets: Widgets Supporting Knowledge of Interaction

Le descriptif de l’offre ci-dessous est en Anglais_

**Type de contrat**: CDD

**Niveau de diplôme exigé**: Bac + 5 ou équivalent

**Fonction**: Doctorant

**A propos du centre ou de la direction fonctionnelle**:
Created in 2008, the Inria center at the University of Lille employs 360 people, including 305 scientists in 15 research teams. Recognized for its strong involvement in the socio-economic development of the Hauts-De-France region, the Inria center at the University of Lille maintains a close relationship with large companies and SMEs. By fostering synergies between researchers and industry, Inria contributes to the transfer of skills and expertise in the field of digital technologies, and provides access to the best of European and international research for the benefit of innovation and businesses, particularly in the region.

For over 10 years, the Inria center at the University of Lille has been at the heart of Lille's university and scientific ecosystem, as well as at the heart of Frenchtech, with a technology showroom based on avenue de Bretagne in Lille, on the EuraTechnologies site of economic excellence dedicated to information and communication technologies (ICT).

**Contexte et atouts du poste**:
**Mission confiée**:
This Ph.D. is funded by the Knowdgets project, which aims to redefine widgets, in what we call Knowdgets, to address the limitations of current widgets and to propose new programming approaches. The Ph.D. will be conducted in the Loki team at the University of Lille and the CRIStAL laboratory, in collaboration with the LII team at ENAC in Toulouse.

As such, graphical toolkits have made it convenient for developers to assemble interfaces from pre-defined widgets, and for users to recognize these components and their behaviors. However, this convenience comes at the cost of having pre-defined widgets that constrain and limit both the interaction vocabulary the interface can support and its extensibility.

Indeed, current widgets typically support a limited set of user actions (e.g. tap and long press on a button). As a result, beyond forms, data entry and command selection, it quickly becomes necessary for developers to create custom widgets, thus giving up on the toolkit's benefits, or worse, having to bypass its limitations.

Widgets are also limiting from the end-user perspective. Indeed, the graphical representation of current widgets does not precisely convey what actions are supported (e.g. push buttons will have a similar appearance whether they only support taps or also long press). This limits the degree of discoverability of the means to interact and the bandwidth between users and interactive systems.

**Principales activités**:
The required knowledge to redefine widgets can be broken down into three types.

**Knowledge about users' capabilities**
Widgets are inevitably operated by users, users who have inherent motor, perceptual and analytic capabilities.
Yet, current toolkits ignore these capabilities, thus limiting the expressiveness of interaction or resulting in unexpected and unavoidable errors.

**Knowledge of widgets' spatial and temporal ecosystem**
Widgets typically compose a dynamically-evolving graphical interface that is more complex than the sum of its parts.
Yet, they have little to no information about what is located around them, the timing of their appearance or changes, or what will be occluded by their instantiation.
For example, the knowledge of the information being displayed by a widget (e.g. the duration of a video) is important to provide fine control for another widget (e.g. the navigation slider) to precisely control content (here, frame-level control).
Other examples include interface changes occurring just before a motor action, e.g. when a notification appears in the foreground right as the user was about to click the close button of the rightmost web-browser tab, causing the now-misdirected click to trigger an unwanted response; detecting and preventing such incidents is not possible without extending the knowledge of _when_, _where_, and _around what_ a widget is about to change.

**Knowledge of how to communicate their underlying principles**
In graphical programming toolkits, each widget (push button, slider, checkbox) typically has a pre-defined graphical appearance, that has been designed with the default interaction possibilities in mind.
The same graphical appearance remains, even if all interaction possibilities are not associated with an operation (e.g., when implementing an interface, a push button is generally by default clickable even if clicking on it is not associated with an operation) or if additional interactions should be supported (e.g., the appearance of a push button remains unmodified when a long-press handler is added to it, making it virtually indistinguishable from other default push buttons).
This is not surprising given that most toolkits decouple the functional and visual description of the widget.
Yet, upda