Case Study: Festivals API - The Story Continues

Challenge: How to exploit the opportunities arising from the development of the Joint Festivals API.

Solution: Open up the system to internal and external developers

An earlier case study outlined why and how we developed the Joint Festivals API [Application Programming Interface] as a new service to provide media with our programme listings. However once we had created the data structure for the API, taking live feeds from individual festivals, we realised that we had created a unique asset that could become the basis for further experiments - both internal and external - in how to provide festival information to the public.

There were to be three key principles driving such experiments:

• for each internal experiment we would identify a single festival to act as the guinea pig on behalf of the whole, with the learning - and any appropriate software developments - then shard with the other festivals:
• we would aim to prototype quickly, not waiting for something to be fullly formed, in order to test rapidly in a real world environment and learn lessons fast for the development of the next generation of products/services
• our listings would be developed on 'open data' basis, meaning that they would be freely available to external parties to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control

From these principles evolved our API programme which saw us work with a wide range organisations and businesses - and here are six experiments which we've developed along the way:

1. Discovery

Our Impact Study had told us our audiences liked attending the festivals becasue they felt they would discover new things - talent, styles, genres - and that this made them more likely to take risks in their event choices. With that concept in mind we worked with the Edinburgh International Festival to create an interactive app that played in to the notion of 'risk' by selecting shows for people based solely on their answers to questions about their mood. In order to accomplish this we just needed to add appropriate tagging to the API data fields and create an algorithm aligning shows with the question & answer set. The resulting show suggestions were then displayed in a manner suitable for immediate purchase, while aslo being shareable on the social media channel of their choice.

2. Browsing

Further research told us that certain segments of our festival audiences were browsing our programmes and listings in different ways, with a younger demographic being particularly driven by a visual culture. In order to explore these changing habits further, we worked with the Edinburgh International Science Festival to see how we could present our programme brochures in a new and visually stimulating way.

Using the visual browsing principles of Tindr - the online dating app - we created a simple swipe app that allowed audiences to select or reject shows based on a single picture and a single descriptive sentence. The core building blocks were already in the API data structure, but we had to create a new data field for a single sentence description given that the traditional programme description were much longer. The resulting selections from SciSpy could then be displayed in a handy to use format for immediate purchase or downloading for later exploration.

3. Advertising

Both of the above experiments were created for direct use by the audience, but - as with the original notion of the API - we were very much aware that our listings were often sought by others for sharing through their own channels. This was very much the case with the hotel and leisure sector, and consequently we worked with Edinburgh's Hogmanay to create an advertising 'widget' on our API site.

We created a simple wireframe template on our site, with each frame tagged to appropriate data fields in the API [eg name, description, date, location, image]. External users could then access this site, choose their target festival/s, select a date range for display and the wireframes would be populated with that data. A single piece of code would also be generated for the external user to simply copy and paste on to their website - or any other appropriate channel including in-house hotel channels - and this would allow the display of the formatted digital adverts.

4. Third Party Developers: Research

All of the above services came about from internal festival discussions, but we knew that an open data approach could generate new services and products from external developers. Consequently we created a public website with a simple registration process to allow third parties to explore and play with our API. One of the more interesting early users was Zegami whose business proposition was that the presentation of large quantitities of data in high-resolution, utilising animation and smooth transitions could improve business insights and operations. In order to test out their proposition, Zegami were seeking large visually interesting data sets and they used the Festivals API as the basis for their initial data experiments. 

In this video, you can see Festival listings presented with their API tagged photograph and you can then follow the cursor on the left as it decides which fields to open. It settles on Australia which automatically identifies the sub-set of Australian shows at the Festival as tagged in the API - before a further search identifies the music shows in that Australian category, with additional filters displaying the age appropriateness of each show. The success of this initial work has allowed Zegami to develop a successful business venture at the heart of the new world of data driven innovation.

5. Third Party Developers: Products

Whereas the application above was simply using the API to test a product with wider market appeal, there were many developers who were interested in developing specific festival products centred on the growing market for experiential travel.

Henson IT Solutions, the company behind the Plan My Fringe app and algorithm, identified what they saw as a market gap - the absence of an effective scheduling tool allowing users to prioritise shows while taking into account walking time between shows, maximum budgets, maximum shows each day, and even allows minimum lunch and sleep breaks to be entered. Using the Festivals API as their starting point, the company have developed their own algorithms to create a distinct product that is scaleable and adaptable to other similar environments.

6. Third Party Developers: Creatives

Edinburgh's Festivals are such a complex and chaotic landscape during the peak summer season that it's often difficult to describe it to people. So one developer wondered whether the old adage that 'a picture paints a thousand words' could be adapted for the digital age through visualising social media activity?  What would all the tweets and photos, geotagged to Festival venues through the API, look like across 28 days for 6 Festivas in 1 city using an open source map? Well, here's the answer:

We think this is a beautiful visualisation of the Festivals during their peak August period - a sort of Jackson Pollock for the 21st century digital age. Our thanks go to Rory Fitzpatrick - @roryf at https://twitter.com/roryf - who was inspired by the Festivals API and wanted to show that the emerging generation of developers were as much driven by the creative process as the technical operation.

Postscript

That's just six of the many projects that have taken place since the creation of our Joint Festival API, with many of these evolving during the process rather than set out as objectives at the start of the programme. And last year, we noticed that by default we have created a festivals archive which has made us wonder whether our next step should be to digitise the back catalog and allow others to 'play' with more than seventy years of festival listings.