Teoría de la novela

11.5.1.Building an Application Program Interface (API)

The main purpose of this project was to build and design a platform that others could then use to write and design perceptive stories. To this end and to enable people to do this in the easiest way possible an API was written that would give story creators access to the data from the sensors in a simple to consume manner.

From the outset the working team decided that the API needed a strict naming convention to maintain an obvious structure to the code that would allow new

programmers to understand what to expect when a certain method was used. For example, methods used to request data are of the structure:

get ’SensorType’ ‘SensorFunction’

as an example, ‘getCameraPeopleCount’. This would return the latest count that the camera has for the number of people in the scene.

Of course building an API is but the first step, testing the API and using it to create a story is the next stage of the process. The API and the associated functions built into it, allowed the team to recreate Mudlark’s Aesop Fable story on the ‘radio’. It was through this process that several new functions were added into the API, as it was only once the team had begun building a story that it could be seen where the limits of the API began to show themselves.

One of the cases where a change was required was during the initialisation of the API, in the first version the, a story creator simply called ‘beginAPI()’ and this would start all of the sensors on the NodeJS server. However, this did not allow for

customisation where a creator could state what type of data they would need from the server, and so a new structure was created allowing the creators to tell the server the types of sensor that were to be a part of the story and what type of analysis if any they wanted to have applied to the data.

The API was a substantial move forward from the BBC’s first iteration of the project where each story had to be crafted anew and while code could be copied across from one story to another it would then have to be implemented in a new way and if anything needed to be changed you had to be able to understand the entire code base. This is where the API gave the creators a much simpler and faster creation mechanism the API where one line commands that returned as much data as was required for a certain function that could be used as is without any further computation required.

11.5.2.Initial Stage Completion Meeting

With the API written and the demo story running on the ‘radio’ a meeting was held with the BBC and Mudlark to demonstrate the progress that had been made. From the outset the group was very happy with the rate of progress, especially the extent of the API and its associated documentation. Although having learned from previous projects that making the software start up automatically allows for a smoother workflow, in this case there was an inconsistency with the compatibility of the USB ports of the computer that stopped the demo from working in the correct way. This was eventually resolved however it proved the point that the project had to be deployable without worry of misconfiguration.

Another point was raised by Ian from the BBC that the original radio always had to have a keyboard, mouse and screen in order to connect it to whatever network was available in the space and that this was often a hindrance to the setup and presentation of the radio. Deciding this was worth looking into a point was made to ensure that networks could be joined without the requirement of a screen to sign in to them.

Ian expanded on his previous point, explaining that when demoing a “perceptive radio” it was very difficult to explain to passers-by what’s happening as because the story changes to suit the audience without them knowing, they quite simply

understand that, that is the entire story, not knowing that it changes according to the environment. Previously this has been countered by having people listen to the story twice but on the second run through the parameters were changed manually simulating a new story environment. As the previous requirement would already call for some form of administration interface an extension to this was suggested to allow any of the variables called for in the story to be changeable at any time. While this would not play a part in stories as a final product, it would help to explain the platform to potential backers and to storytellers who are unsure of the projects potential.

The final point of the meeting was that while the case for the machine was functional it didn’t evoke the same sense of nostalgia as did the old radio, and that perhaps a fascia or a new encasement would help with its presentation.

The key outcomes of the meeting were that the project was moving in the correct direction, but was running into similar issues that had plagued the original version. Therefore, the team sought a closer relationship with Ian of the BBC as he had most experience of demoing the original radio. This relationship took the form of more frequent Skype and email conversations explaining the current progress of the team on the proposed changes. This change to the current working style would help as the project moved forwards as it allowed the knowledge that Ian possessed of the first radio to be exchanged with the Lancaster team as work progressed.