Thursday 27 November 2008

Studio 9 | Prototyping pervasive computing

What challenges to prototyping does pervasive computing present?

Prototypes can be expensive to develop. One way to overcome this is to use approximation of functions within the prototype.

Experience prototyping, where researchers and designers become actual users helps:
  • Mitigate the participating researchers' bias toward the technology.
  • Designers to distinguish between problems with the prototype and problems with the design.
Wizard of Oz prototyping, where the system appears to be a complete, functioning system to the user, but sacrifices detail/accuracy (only an approximation), is also suggested by the document, but:
  • Impractical for longer-term uses, since requires 'wizards' behind the scenes controlling the system.
  • Only incomplete/rough applications of the system which aren't suitable for end-users.


Successes in prototyping pervasive computing

The document details the use of Coordinated Views software to prototype a handheld peer-to-peer communication/orientation system for use during the 'City Chase' race, however, the researchers permitted use of alternative resources. They found that the software was little used. Subsequent to the race, in interviews with the participants, the researchers learned that the system was only really used whilst the participants were stationary (i.e. riding transport). Also, they were able to ascertain that the participants were hesitant to use the system in the rain.

The first Marked-Up Maps prototype worked by attaching RFID tags to the back of a paper map. A user could then hold a PDA up to the front-side of the map and view information about the place they were hovering over. Originally intending to help guide the group of researchers to a conference, the prototype's glitches were not solved and so they were left with one user touring the city alone. Even so, this type of experience prototyping did prove to be in their favour, since the researcher/user was able to overlook problems which were solely due to the prototype's limitations.

Thursday 20 November 2008

Studio 8 | Identifying research activities and methods

Research Activities

Four workshops, all videotaped with 'key utterances' transcribed. Also, a school fieldtrip.

Workshop 1 focused mainly on interview -- the curators pointing out key locations and points of interest through the use of a map. This helped to solidify researchers' ideas of requirements for the system.
Workshop 2, consisting of three guided tours of the grounds, in succession, by three different curators. Researchers observing to try to solidify knowledge of requirements even more. Also, video and audio recording were made which could be used with the system.
Workshop 3's main purpose was to convince the curators of the power of the new system; new ideas for tours, i.e. dynamic tours led by the end-user as opposed to static, linear tours led by the curator.
School fieldtrip, again, helped to convince curators of the power of the system. Observations by researchers helped to test the system's capabilities.
Workshop 4 aimed to wrap up the other workshops and further convince curators of how the system can develop. Curators show developed understanding of technology.

In the initial interviews, the research team were confronted with the curators' preconceptions that a tour should be fixed and a lack of understanding of how technology could be applied to change this. To change this, the research team used several prototypes to demonstrate the capabilities. Firstly, reorganising previously recorded audio clips and running a 'Wizard of Oz' prototype. Later on, a practical demonstration involving end-users was used (the school fieldtrip). A video of previous applications of similar technology was also employed, showing the 'Ambient Wood' project.

Through discussion and observation, both in real-time and by analysing recorded video and audio, the team were able to gain a picture of how the tours were currently being led. This, in combination with more discussion, developed into ideas for a ubiquitous system.

All research methods used were qualitative.

Thursday 6 November 2008

Studio 6 | Identifying research methods (1): Reading

With respect to usability testing of ubiquitous computing, ethnography entails:
  • Testing 'in situ' or 'in the wild', i.e. within the situations which it would be used.
  • Gathering of internal evidence, i.e. 'text messages... generated by users in their interactions together', as well as the more traditional external evidence such as observational recording of interactions.
The paper describes four ubiquitous computing systems which were analysed using ethnography:
  • Can You See Me Now?, which involved online players interacting in a 3D model of the world with performers in the real world using GPS and WiFi technologies. The idea was that the performers had to catch the online characters by interpreting the GPS data.
  • Uncle Roy All Around You, following on from the previous game, where the players were both in the streets and online. The goal of the game was to find 'Uncle Roy' by interpreting location-based clues and interacting with performers on the street.
  • Savannah, an educational game designed to teach children about lions in the African savannah by overlaying a virtual environment on a school playfield using handheld computers, GPS and WiFi technologies.
  • Treasure, where teams of players interact with handheld computers using GPS to pick up virtual coins. However, in order to store the coins, players have to take their handhelds within a WiFi hotspot. If an opposing team gets within their range before they reach the hotspot then their coins can be stolen.
When analysing Treasure, the observers recorded various information both on the game server and on the players' handheld computers which was then compared with recorded video and audio of the event. Using specialised tools, they were able to view each piece of evidence in synchrony with another. Interestingly, this allowed them to ascertain that the logged GPS position on the handheld device was often radically different to that which was logged on the game server.