The Ozlab System - Underlying Principles and a System Overview

The Ozlab team builds resources admitting manual tests of the interactivity of IT products prior to their implementation in any programming language.

The Ozlab system now includes smartphones as test devices.

Methodologically, we have also developed the co-design on distance, as the Ozlab superbly supports the necessarily sketchy nature of a co-design substance where interactivity must at irregular intervals be played out directly for the co-designer to see the impact of her/his designs. We call this GUI-ii, "GUI-interactive interviews".

Prototyping interactivity

The word ‘prototype’ is used to mean many different things in the field of design and product development. The objective is to test acceptability, especially usability, before production starts. Prototypes may be used at various stages of development. The earlier testing takes place, the less money needs to be spent on inappropriate or unworkable ideas. Even developers using such direct and visual tools as Visual Basic may start testing with simple sketches on cardboard, perhaps aided by post-it tags to achieve some flexibility in ‘output’.

It is easy to find reasons to start development of interactive products with very low and unsophisticated technology. However, to test interactivity, swapping paper slides or simply asking the test participants what they believe would happen if they had a mouse cursor and clicked on various figures, might not be entirely convincing. It would be more interesting to test interactivity in a real setting in order to assess ‘interactive feel’ as well as users’ ability to quickly and correctly utlize the user interface.

Furthermore, certain user groups, like children and mentally handicapped, are less fit for testing based on abstract methods. Of special importance when it comes to children is that their attitude towards the product may change dramatically if they feel they are in control of the game rather than a slide-switching test leader. If there are reasons for having autonomous interactive teaching aids, then there are also reasons to test them as autonomous interactive products.

Thus, in some instances, working prototypes seem preferable to simpler prototypes.

Wizard of Oz experiments

The above line of arguments hinges on the fact that the appearance of the prototype reveals whether it is controlled manually or whether it is a real automaton. In fact, tests could be performed without revealing if prototypes are man-controlled. There is an experimental technique often employed in language technology called ‘Wizard of Oz’. In Wizard-of-Oz experiments a test person thinks he writes or speaks to the computer in front of him when in actual fact the test manager sits in the next room interpreting the user’s commands and providing the right responses.

The Ozlab concept entails two new concepts: firstly, it extends the Wizard-of-Oz idea to include also graphical and multimedia user interfaces; secondly, much is pre-programmed in the Ozlab system to facilitate setting up experiments, which facilitates pilot testing and rapid cycles. To some extent it also facilitates for ‘naïve’ designers (end users and content experts) to exploit the tool for the definition of interaction requirements (Pettersson 2002; se the Publication link in the menu).

System overview of web-based Ozlab (2013-)

To enact the wizardry the wizard needs a computer connected to the user’s computer: TL for ‘test leader (computer)’ and TP for ‘test participant (computer)’. The file(s) containing the graphics, texts, video clips used during a test is called interaction shell(s) (‘shell’ because the programming behind is missing). Both TL and TP connects to an Ozlab web site and a specific web page. There is also a possiblity to connect to this web page as a 'test viewer', TV. Several TVs can monitor an on-going test session.

Shells contain all graphics and other objects. For each object, one can set specific behaviours which will affect how the objects can be manipulated by TL during test sessions. Typical behaviours are: make object invisible, make object movable. There are also ready made objects for text input, radio buttons, check boxes.

Read more about the thinking in the file Designing through testing.

Since 2016 the Ozlab system has been used in co-design experiments on distance. Here, Ozlab interaction is supplemented by Skye, Zoom, or simply telephone. As a Wizard-of-Oz tool, Ozlab has clear advantages over video conferencings tools screen-sharing functionality when it comes to enact the interaction design suggested by the co-designer(s). Malin Wik is pursuing her work for a PhD within this area.

System overview of Director-based Ozlab (2001-2012)

The main components of the old version of the Ozlab system are presented here. To enact the wizardry the wizard needs a computer connected to the user’s computer: TL for ‘test leader (computer)’ and TP for ‘test participant (computer)’. The file(s) containing the graphics, texts, video clips used during a test is called interaction shell(s) (‘shell’ because the programming behind is missing). On both TL and TP runs Ozlab Testrunner and the interaction shell is also copied to both computers. Presently, one needs Macromedia’s Director 8.5 (or MX) to build shells – this is done from a specially prepared Shell Template file – and Macromedia’s Shockwave Multiuser Server 3.0 which handles the communication between the TL and TP computers.

To run an interaction test, the interaction shell(s) had to first be copied to the computer where the test subject is. This was done with the Ozlab FileUpdater which checks the corresponding folder on the test computer to look for files which are not up to date. Thus, if several shell files have been up-dated by the test leader, all these files will be transferred (it is easy to forget to transfer all up-dated files if this is not done automatically). Then, Ozlab Testrunner was started both on the test person’s and test leader’s computer. This program ran the shell file(s) and displays various tools on the test leader’s computer that enable the test leader to monitor and control the test person’s computer in various ways. Tests can be recorded either by video or by some screen recorder, which allows simultaneous recording of sound. However, screen recorders be very useful when preparing animated videosnippets for distribution within development teams or for web-based questionnairs.

For setting up an Ozlab environment, there is a special program called Ozlab Setup which includes network parameter setting for the Testrunner and the FileUpdater.

The Director-based version was skillfully programmed by Joe Siponen (now a professional IT developer in the Karlstad region). From 2011 a development work was started aiming at freeing Ozlab from its dependence on .dir files. Summer 2013 a first version of a web-based architechure was in place. Prof. John Sören Pettersson is managing the process and Lab.Ass. Malin Wik and Henrik Andersson were in charge for debugging as well as for developing specific requirements for new functions. Students are used in some parts of the continuing development while the more advanced programming is outsourced (so far, mainly to Motillo).