Second Prototype

11.6.1.Required Changes

The changes as suggested in the meeting were to enable control of the radio from a remote interface via the API, to allow the connection of the radio to a Wi-Fi network without a keyboard/mouse/screen, to create an admin interface that would be simple to control and use by a demonstrator and finally to change the case for a more aesthetically/in-fitting design akin to the original version.

11.6.2.API redesign

Following the first stage meeting a list of changes to the API was drawn up. As much of the API was already written and the process for passing information to and from the backend of the radio to the frontend already existed, it was decided that expanding upon this to introduce a third endpoint, the admin interface. For the admin interface the existing API methods would not be enough as they existed primarily as ‘get’ methods meaning you can retrieve data but not set the data remotely. Therefore, a new set of methods would be created, where every get method was mirrored with a ‘set’ method. The API would also require new methods for searching, selecting and connecting to Wi-Fi networks along with a way of

resetting the entire radio back to its initial state. These methods would all be created within NodeJS as before, but for the Wi-Fi network connection a separate program would be required that would be called from the NodeJS to the underlying operating system.

11.6.3.Admin Interface

It was decided at this stage that an Admin Interface would be created for mobile devices so that they could display the appropriate commands on a web page allowing the demonstrator to simply connect to the radio and control it remotely. Through discussions between the Lancaster team a workflow was created for how the start-up and setup of the radio would occur and it is listed below in order.

1. Connect all peripherals to the radio 2. Plug in and start the radio

3. Connect the control phone to the radio

4. Load the admin webpage on the control phone 5. Select and connect to the appropriate Wi-Fi network 6. Select the story to play

7. Control the playback and variables of the story from the phone

To provide this form of interface there were two methods available, a webpage or a dedicated application. While both have advantages the final decision was to use a webpage as it would work across platforms and devices where as a dedicated application would require a new build for each platform/device so the webpage has speed of development on its side.

To enable these changes to be possible, a new network card was required to be set up on the radio, this network would be an Ad-hoc network, such that the radio would broadcast a network that the admin phone could then connect to. From here the phone would be able to setup a connection to another wireless network via the other network adapter by selecting the correct SSID and supplying the password.

The interface was initially developed as a plain web html form that allowed for quick testing and development, however the group felt that as it is unknown who might be the demonstrator of the radio it was important that it was as user friendly as possible. As such Adrian began the design of the web application so that it was compliant with current HTML5 web application and design standards.

Figure 52: Admin Interface Setup Screens

The resulting interface was not only simpler to use but also enabled greater control over the myriad of sensors from a single mobile screen. The interface as shown in Figure 52 enables the demonstrator to connect to whichever Wi-Fi network they require as well as being able to change the audio output whenever they deem necessary. This is something that became evident after demoing the prototype in different spaces where speakers were not always associated with the HDMI output. Once they’ve setup the environment a story selection screen is shown, allowing them to select from the list of stories available to them.

The controls as shown in Figure 53 allow the demonstrator to either take control of the story or to leave it to use the sensors values. At any point they are able to take control by ticking the override box, this is helpful as it can allow for the dynamic story to be heard by an audience that otherwise would be static.

Figure 53: Admin Interface Controls

11.6.4.Case Redesign

With limited time on the projects it was often difficult to prioritise certain aspects of the project and in this case it was decided that finalising the software and control interface was more important. Not to say the design of the shell isn’t

important but it was felt that for the current prototype where the case is incidental and shouldn’t be the focus of people’s attention, that simply removing the radio from view during demos would be the simplest solution.

Figure 54: Perceptive Media v2 in Orange with the Original Radio Behind