The System Perspective

The second perspective of this mixed research approach looked at the system and tool aspect of WOZ prototyping. The goal was to identify the different modules needed to offer generic WOZ support, define their task and discuss their relationship to each other. Also, we wanted to find possible ways to integrate them into one platform and respect existing as well as future compatibility. Similar to the user perspective we approached this problem from two different angles. On the one hand we started from the wizard task and elaborated on the different forms and roles it can take on. By sufficiently describing the wizard task and its interplay with technology we were able to define the potential flexibility that the tool should allow for. While these tasks and roles were inspired by the literature and to a large part clarified by talking to other researchers, it was mainly the exhaustive nature of this theoretical analysis that helped to understand the various wizard/technology combinations. On the other hand, we looked at the technological possibilities for developing modern prototyping tools. The technological aspect was important as one challenge of existing WOZ tools is their often missing compatibility with other systems as well as their complex set-up routines. The use of open standards and low entry barriers was therefore a key issue to be solved if the support for WOZ experimentation should go beyond the currently supported single scenario solutions.

Role-based System Perspective

While there was certainly a strong tool focus in the practical part of our research agenda, which is specifically dedicated to developing a WOZ platform (cf. Section 3.4), the theoretical strand also supported this development process. It methodically discusses the different roles a wizard can possibly play when running experiments. To do so we specifically focused on language

technologies and how they potentially can be used in connection with WOZ experimentation. By looking at the LTC pipeline (Note: The LTC pipeline will be described more thoroughly in Chapter 5) and how the interplay between a wizard and the respective technology components can be achieved we were able to paint a comprehensive picture of possible use cases. Even though in our analysis the main focus was on experimentation with respect to language tech- nology, we believe that the underlying principles are applicable to all sorts of WOZ settings.

The result of this analysis was then used to form a set of rules and standards that apply when wizards in their different roles interact with technologies. Integrating those rules as part of a software architecture represented an important part of the foundation for generic tool support and therefore served as an essential contribution for building the envisioned WOZ tool. Furthermore, by focusing on the task and its different characteristics we were able to clearly define this relationship between different technological components and how this interplay is on the one hand connected to the experimental setting and on the other hand depends on the role and task the human wizard has taken on.

In summary, this part of the analysis represented a theoretical expansion of what we had learned from studying the literature and from talking to other researchers. As such it served as an additional underpinning that had the goal to exhaustively define the sort of flexibility that is necessary to support generic WOZ experimentation.

Technology-based System Perspective

Another factor that was discussed with respect to the system perspective is the availability of different technological solutions, their advantages as well as their drawbacks. Different alter- natives for implementing a defined software architecture were evaluated. Given that one of the identified problems with existing tools is their dependency on sometimes obsolete technology it was seen as a distinct requirement for this work to put a strong emphasis on future stan- dards. Furthermore, compatibility with existing systems and services as well as its portability to different form factors had to be explored. The latter is particularly important if we think about the advent of language technologies used in phones and other mobile appliances, or their integration into cars and smart living environments. As the main purpose of WOZ prototyping is to evaluate and form future technologies and analyse how they are possibly used, we also need to think about ways of permitting this method to be employed in those places where the technology most likely will appear. This includes the traditional office as well as private and public living environments.

We started our exploration by comparing some of the existing tools and how they are im- plemented. We looked at their architecture (as far as possible) and the type of support they offer for generic WOZ experimentations. An analysis of possible improvements and how they realistically could be achieved was used as a basis for a discussion about potential technolog- ical platforms to be used for implementation. Here it was not only the simplicity of building such a tool that qualified for consideration but also the potential of integrating external compo-

nents. As by definition the wizard only represents an intermediate step towards a technological solution to an interaction scenario, it can be argued that this simulation should resemble the sit- uation as much as possible. The potential for the integration of external services can therefore play a key role when choosing the right technology platform.

In summary, by comparing possible technology platforms for integrating WOZ support and looking at their interoperability with other potential services, we took what we had learned from our previous analyses, focusing on requirements- and task definition, and evaluated which of the current solutions offer sufficient support for building a flexible tool. This discussion was furthermore supported by the knowledge we had gained from a first round of prototyping (cf. Section 3.4.3).