Chapter 6 Embedding A Distributed Crowd Inside A Smart Device
6.7 Spectators’ Interaction
When loading their interface, spectators could either sign in with Facebook or manually type in their name (Figure 39). During the 170-mile relay race, spectators
159
could then follow the live data through any Internet-connected web browsers. The data presented by the server included the name of the spectator, the total cheers that the athletes received, the cheers sent in the last hour, the total number of spectators who have sent cheers, the total number of messages sent, the race duration, the distance covered, the average speed, an interactive chart that displays the covered altitude, the weather at the athlete’s location, and a map with the covered path and position of the baton at that moment in time.
Figure 39: The login interface for spectators
The crowd’s interface also displayed whether the baton was online or offline and the time the data was received from the baton. This was relevant particularly when the baton lost mobile data connection through remote rural areas. Additionally, a Facebook messaging frame was also embedded in the interface such that spectators could send and read messages. This was intended to build a community around the activity as the event was taking place. In this way, whenever the data broadcast from the baton was interrupted due to a loss of network coverage, the messaging interface
160
provided a secondary source of engagement for the spectators and potentially alleviate the disconnection problem [33].
A system control panel allowed the organisers to send messages to the crowd in a persistent-positioned space on their screen. This approach followed insights gained in pervious research [44]. This manual message broadcast was intended for crowd coordination in unexpected circumstances that a live event occasions. From past events we noticed that, for example, a technical fault in the telemetry system could lead the spectators to multiple conjunctures; such as the system is not working, or the event stopped, or that there was an accident. Thus, the “online/offline” indicator on the spectators’ interface could mitigate such potentially misleading situations. This information on mobile-awareness could also make the user value the effect of changes in connectivity on the system [32] and appreciate the athlete’s environment.
Finally, the presented interface had an always-visible “Cheer” button and a “Cheer Intensity” slider. The Cheer Intensity slider had no effect on the cheering, and the spectators were not given any information about this element. On the other hand, pressing the Cheer button triggered a small vibration (400ms) on the baton that was carried by the athletes. Hence, the athlete carrying the baton builds awareness that a crowd is following the performance. The baton also calls out the name of the person who sent the last cheer so the athletes understand whether the live support is coming from known or unknown spectators. Both the athletes and the spectators were aware of these dynamics and the interaction effects.
6.8 Findings
13 athletes participated in the 170-mile relay race that lasted 23 hours 45 minutes. 261 spectators submitted cheers that totalled 3153. Unexpectedly, the biggest challenge for
161
the athletes during the race was to stay on track in country roads. On multiple occasions, athletes followed a wrong direction and had to run back. On one occasion, an athlete had gone three miles in the wrong direction. For this reason, the actual total distance covered by the athletes was 185 miles. Since the course markers are designed for cyclists, sometimes these are positioned at a distance from their respective turn. This distance may provide the right timing for a cyclist but less so for a runner. As these occasions happened, remote spectators could follow a ‘top view’ of these wrong turns and closed alleys entered, through their live map.
Figure 40: 2G and 3G-cell coverage based on OpenSignal coverage map as predicted on the day before the event. The blue path represents the actual data connections, and the red represents data disconnections
Another point of consideration was the weight of the baton. Upon carrying the baton for a long distance, some athletes felt the baton heavy so in some passages the cyclists had to carry the baton instead. The athletes could then still hear the cheers but saved on carrying the weight.
A major concern for such an extreme in-the-wild event was the mobile network coverage throughout the 170 miles, most of which, was in rural areas (Figure 40). The assigned server received data from the baton live during 74% of the race (17 hours 34 minutes). In total, there were 12 live data drops. Of these 11 were due to blind spots in the mobile network across the course and one due to a software liability. In this count, a blind spot is true whenever the data connection interval between the server and the
162
baton is greater than 60 seconds. Although the total number of drops may seem high, during the event, small drops did not appear to distract the spectators. Post submitted during the event suggested that blind spots of short duration might increase the
spectators’ curiosity and their interest in knowing what is happening. These positive
effects from data disconnection could be attributed to the design decision of giving connectivity feedback to the users [34].