Multiple Input Support in a Model-Based Interaction Framework

Abstract

Developing for tabletops puts special requirements on interface programming frameworks: managing parallel input, device discovery, device equivalence, and describing combined interactions. We analyse these issues and describe the solutions that were used in IntuiKit, a modelbased framework aimed at making the design and development of post-WIMP user interfaces more accessible. Some solutions are simple consequences of the support of multimodality, while others are more specific to multiple touch. We illustrate these features through examples developed in several tabletop projects, including one application aimed at improving collaboration between air traffic controllers.

Multi-touch tables and the relationship with collaborative classroom pedagogies: A synthetic review

“…In the third mode, the software supported multiple pointers, where participants were able to position a remote pointer over some content in order to highlight points of interest or discussion. What is highlighted in this study is that traditional window-based interfaces are not sufficient in providing support for distributed collaboration with interactive tabletops and that new approaches to user interface are needed (see also Chatty et al 2007).…”

What should adaptivity mean to interactive software programmers?

“…The adaptation is not relative to the user or the environment, but to the programming interface of software components. It is only recently that connections have appeared with context adaptation, with the proposal to handle software components and input devices through a unified component model [10].…”

“…• event sources, taken in a very broad sense as described in [11] ou [10], may be an input device consciously manipulated by a user, a physiological sensor, a physical sensor, a software component reporting the hardware configuration of the execution platform (displays, network, processor, etc. ), and so on.…”

FlowStates

“…Il propose des constructions pour décrire des flots de données synchrones, qui peuventêtre mélangées avec des structures de contrôle classiques mais qui ne sont pas explicitement décrites par des machinesàétats comme avec FLOW-STATES. Intuikit [9] Dans le couple PetShop/ICON, la logique de l'interaction est spécifiée par des réseaux de Petri dans l'environnement graphique de PetShop, et la gestion des dispositifs d'entrée est déléguéeà ICON. FLOWSTATES et PetShop visent cependant des objectifs différents : Pet-Shop est principalement dédiéà la spécification età la vérification formelle, alors que FLOWSTATES privilégie la simplicité, parfois au détriment d'une approche plus formelle.…”