Interaction Views in Architectures for ActionBlocks - To Each His Own

Abstract: This master thesis is done in collaboration with Space and Virtuality studio of the Interactive Institute in Malmö. The project ActionBlocks, at the Space studio, relate to the requirements concerning hardware for ubiquitous computing. A system of intelligent building blocks is developed to be able to build functional HiFi prototypes fast. The building blocks are distributed in space and small, cheap web servers, called TINI, integrate the devices. ActionBlocks may be regarded as physical interfaces. The intention is that systems of different ActionBlocks (tag readers, digital cameras, loud-speakers, lamps, buttons etc.) may easily be constructed to support interaction with digital media in different projects. To be able to do this the ActionBlocks need to be assembled by a flexible architecture that can change when the needs alter. The goal with this thesis is to propose a concept for such an architecture. Except for the concept the thesis also contains an investigation of related architectures to explore what user aspect they have in the various projects and an implementation of a minor prototype to discover if the concept is valid in practice. ActionBlocks consist of an intelligent (digital) part and a physical part and it is possible to discern three different approaches towards the ActionBlocks. There are: · Physical - Action approach where the physical part and what happens in the real world is what matters. · Physical - Computational - Action approach where both parts are integrated on equal terms. · Computational approach where the intelligent part is most important and this view makes it possible for an ActionBlock to only contain an intelligent part. The approaches are entertained by three different user roles: the user, the interaction designer and the programmer. The user only interacts with the physical part of the ActionBlocks and is therefore only concerned about that part. He designs in use of ActionBlocks. The interaction designer assembles the ActionBlocks into a system. He configures the system and is concerned about the performance and the appearance of the ActionBlocks. Therefore he focuses on both the intelligent and the physical part. The interaction designer designs the interaction with the ActionBlocks. The programmer is the one that controls what can be done with an ActionBlock. He designs ActionBlocks. In development only the computational part is of interest because it is the only thing the programmer interacts with. The three ways to interact with ActionBlocks have an internal relationship. Development is needed to alter the possibilities to do configuration and use. The configuration forms a platform to use, because it provides new possibilities to customize it. This leads to a division into three aspects: Use, configuration and development. The partition makes it possible to focus on one aspect at a time. The three aspects have it counterparts in three different architectures: Pure Peer-to-Peer, Peer-to-Peer with distributed service and client-server architecture. The result is that the concept for an architecture for ActionBlocks is divided into three parts. One for each aspect. The concepts suggests that when the user interacts with the system the architecture is Peer-to-Peer and when the interaction designer interact with the system it is a Peer-to-Peer architecture with distributed service and when the programmer interacts with the system he can regard it as an client-server architecture. The concluding question is if there really is a reason to adapt the architecture to different aspects. My answer is that there is always an reason to adapt the technology to the human if it is possible.