Project: Royal Opera House


Developing a more sustainable model for creating cultural mobile service


The Royal Opera House will develop a new mobile service which will allow existing and new audiences to enjoy rich media content about ballet and opera. It aims to explore innovative, location–based ways of engaging with the public, increasing revenues through mobile ticketing and giving and is especially interested in broadening reach among its younger audiences.

Technology Partner
Research Partner
King's College London
Opera Mobile & location

Decision Points

Problem-solving for Internet Explorer 8 compatibility

Matt Cichy
Jan 3rd 2014

When the Select Your Own Seat feature for Royal Opera House was originally built, one of POP’s primary goals was to reach the largest audience possible and thus support for Internet Explorer 8 was a requirement. This choice limited our technology options quite a bit. Using Canvas was out as was SVG in the conventional way.

POP came up with a first solution that utilized generated SVG files from Adobe Illustrator and re-rendered them to the screen using a library called Raphaël.js. What Raphaël.js did was process Illustrator’s SVG code and deliver new Raphaël-ized SVG to modern browsers thus bypassing the issue around Internet Explorer 8.

The initial rendering of the code to the page worked great, but we still noticed quite a bit of slow down when trying to interact with the SVG in Internet Explorer 8 and on many mobile / tablet devices. We then created a resvised experience that worked for Internet Explorer 8 but the non-desktop browser issues were never truly resolved.

The Royal Opera House mobile hybrid project presented the perfect opportunity to come up with a solution to this problem.

In working through the issue, we narrowed the problem down to a specific line in Raphaël.js. The method that the line resided is fundamental and it was impractical to try and resolve within the library. We decided to remove the Raphaël.js library from the SYOS module entirely.

POP built its own library to handle animations and manage touch / mouse interactions using native JavaScript. Mobile devices, tablet devices and modern desktop browsers all saw huge performance gains.

In order to maintain the existing Select Your Own Seat functionality in Internet Explorer 8, the SYOS module was branched and JavaScript was written to deliver the appropriate experience to legacy & modern browsers.

Leave a comment

Tools & methods

Essential front-end design software

Maria Withers
Dec 1st 2013

There were two pieces of software which were key to our project:

Adobe Photoshop – used to create designs and layouts for Mobile, Tablet and Desktop views of the Royal Opera House website re-design.

Sublime Text 2 – used to generate the HTML/CSS styling for component design on the ROH website.

I used these tools to create the designs for the ROH website and convert them into a usable format for the Front-end developers to then implement. Our process is such that components of the website are given a standard design treatment in order for the website to be consistent across the site pages.

The designs are important as it allows us to see how the website will look from a responsive view, therefore with the use of grid systems, color schemes, font face/size and layout can be applied to enhance the usability of the website for the customers and visitors to the Royal Opera House.


Leave a comment

Decision Points

Using IndexedDB and WebSQL for our hybrid app

Ben Scutt
Nov 30th 2013

These two tools have been very useful as part of our project:

IndexedDB – a lightweight database that allows web developers to save data to a users local machine in a structured format. It enables a user to access this data if they are not connected to the Internet.

WebSQL – similar to IndexedDB in that it provides a means to save data offline but different since it defers the actual implementation to a database called SQLLite. WebSQL is commonly found on mobile devices and is currently the only supported offline database on iOS.

We used both of these tools for this project to allow users to download and save articles to their mobile device. This means that the user is able to read their online content when they are not connected to the Internet. An example might a programme about a particular performance. The user could save the programme and read is wherever they are, with or without an internet connection.

One of the reasons we chose to use both of these tools is because of a lack of standardization. While the HTML5 specification is working towards standardizing IndexedDB, some vendors (notably Apple) have refused to offer support for IndexedDB since they prefer WebSQL. As a result of this impasse, we decided to abstract away our database so that it is technology agnostic. While this has added additional work to the project, it has meant that the application can support any HTML5-enabled device to save our content offline.

So far using these both of these resources has allowed our application to press forward, and we have managed to avoid having to choose one over the other and impact our users by doing so.

Leave a comment

Tools & methods

Using AppCache to allow offline HTML5 apps

Hugo Gibson
Nov 30th 2013

AppCache is part of the HTML5 specification that allows a web application to be cached, allowing it to be run without an internet connection. It allows you to define resources (such as your HTML, CSS and JavaScript) to cache offline in a Manifest file. You can also specify resources which should only be loaded when there is an Internet connection and resources to use as a fallback if an Internet connection is unavailable.

We chose to use AppCache for this project as currently this is the only way to load a Web Application on a mobile device without an internet connection.

This is currently the only way possible to create an offline web application. However, we have found quite a few issues working with AppCache.

There are inconsistencies in how it is implemented in different browsers. For example, when downloading resources over SSL the resources must respect the same origin policy, however this is not the case in Google Chrome. Also, unless you define a resource as network only, Chrome caches all resources on the page, whereas Firefox only caches resources that have been specified to be cached. In Firefox, any resources served with Cache-control: no-store will not be cached, even if they’re explicitly included in the manifest – this is not the case with Chrome. Firefox will always ask the user for permission before caching a site for the first time – Chrome does not.

There also isn’t that much control over it. For example, the page that has the link to the Manifest is always cached, which you may not always want. We found the only way to get around this was to load the Manifest by using an iFrame.

Another issue is that if the manifest file itself can’t be retrieved, the cache will ignored and all cached data associated with it will be disregarded.

Debugging issues to do with AppCache can be quite difficult  since not a huge amount of error data is returned in the Google Chrome Developer tools when working with AppCache.

Leave a comment

Tools & methods

Insights from usability testing our interactive prototypes

David Little
Nov 7th 2013

We carried out evaluative research (usability testing) with interactive prototypes of the ROH mobile app with five representative users. We used traditional usability testing methods, i.e. one-to-one testing with participants asking them to complete a series of key tasks around content discovery and ticket purchasing with the prototypes whilst “thinking aloud” their responses. Testing was done on a iPod Touch, with audio and video recordings of the sessions gathered with screen recording software (UX Recorder) and a DSLR. We gathered the responses from the sessions and used this to create a list of usability issues with the prototype which were then used to inform the next design iteration.

Evaluative research of this kind is vital to understand that the strategic and user requirements of the project are being implemented in a way that is readily comprehensible by the target user groups.

As well as highlighting the kind of typical usability issues encountered in any software design project (e.g. lack of visibility of key calls to action, insufficient or confusing feedback to user actions), the testing showed that there were some specific problems that users experienced.

One such issue was interface language—there were occasions where the choice of menu and navigation items matched organisational language rather than the users’ (technically there was a mismatch of “mental models”). This occurred with words and phrases such as “Shop” and “Buy tickets”: some users saw these as equal routes to purchasing tickets, whilst the terms have distinct meanings within the organisation (“Shop” being an area to purchase merchandise rather than tickets). Similarly there was some confusion over the terms “In cinema” and “Big screen” to some users, whilst the terms had clear definitions within the ROH.

The amount of content on some pages proved confusing for users, making it difficult to quickly locate what they were looking for. The length of the ticket buying process, i.e. number of steps needed to purchase a ticket, was seen as too long and users either ignored or saw as intrusive the restaurant “up-sell” at the end of the purchasing path.

Leave a comment

Tools & methods

Prototyping using Axure

Frank Chiachierre
Nov 7th 2013

A key objective of our work with Royal Opera House on the hybrid app was to discover a more sustainable way for arts organizations with limited resources to develop mobile apps.  One way to ensure that resources are spent wisely in any technology project is to get feedback early and often from the end user.  There are few things worse than spending nine months designing and developing a project, only to discover that it doesn’t solve a user need.

At POP, we’ve found that creating an interactive prototype allows us to gather real feedback early in the process, before development has begun.  Prototyping can mean many things, from a sketch to a full-blown HTML-coded mockup.  We chose a middle ground, prototyping in Axure, a design tool which allowed us the perfect balance of flexibility and speed.

Before prototyping, we identified key user scenarios that we were going to test against, such as buying digital content, retrieving digital content, and buying a ticket.  Focusing on these key paths, or “hero stories” as they’re sometimes known, ensures that we’re spending the majority of our time on the most important aspects of the product.

What makes the prototype so useful is its versatility. A well-designed prototype can be used both by the project team, to gain consensus, external stakeholders, to validate progress, and then end users when it comes time for testing.

So what should you keep in mind when prototyping? A few things. First, know what purpose the prototype will serve. Is it to vet the technical architecture? Get stakeholder buy-in? Test animations? Usability testing? Different prototypes and levels of fidelity are required depending on the end goal.  Second, identify the scenarios your prototype will support. We needed to create several variations of the same screen to support every possible user scenario to ensure ease of usability testing.  Finally, allow yourself time to get the prototype in front of the right people and incorporate what you’ve learned into the design process.

Leave a comment

Tools & methods

Competitor audit

David Little
Aug 19th 2013

To help the specification and context of the Royal Opera House mobile project we carried out a detailed survey of current engagement with mobile technologies by organisations within the arts and cultural heritage sectors, supplemented with an overview survey of mobile tools in use for complementary activities, namely in the areas of food and drink and other entertainment options. Additionally it included a brief survey of mobile interaction analogues in the area of mobile ticketing and mobile donation, and a brief survey of offerings in the area of electronic programmes and offline content.

What we found was that of all the arts and cultural institutions surveyed, including a selection of theatres and commercial music venues, only one quarter currently offer a mobile website. Arts institutions, i.e. those specialising in classical music, opera and ballet and cultural heritage organisations, i.e. libraries, museums and galleries demonstrate a tendency to use mobile websites to present location, events and contact information rather than using them as platforms for encouraging deeper engagement with their performances or collections. These websites are delivered in a number of forms, most commonly via a dedicated mobile-specific URL, device detection or responsive web design.

However, some institutions are demonstrating a different approach to the mobile web, employing it to deliver a more focused “app-like” user experience: one that is similar to that delivered by a native smartphone or tablet application. These types of experiences resemble native applications in terms of their interaction design, including the use of gestures such as pin-zoom and swiping, and their more streamlined goal-focused functionality. Two notable examples of this are the Rijkmuseum’s (Amsterdam) “tablet-first” website and the mobile website of the Baltimore Arts Museum (US).

Where institutions demonstrate a coherent digital strategy, as do for example the Tate and the V&A, this has tended to focus on the delivery of native smartphone applications, the majority of which have been designed only to run on Apple’s iOS platform (i.e. iPhones, iPod Touches and iPads).  Most of these apps are exhibition tie-ins, guides to the permanent collections or games. Many, but not all, of these apps take advantage of the more advanced functionality and greater usability offered by the native application environment.  Some of the apps surveyed dated back to 2009 at which time the mobile web user experience was more limited than it is presently.

A very small number of the surveyed institutions offered mobile ticketing functionality. Two notable examples in the United Kingdom that do are the ICA website and that of the Natural History Museum and further afield the Museum of Contemporary Arts in Sydney.

Outside of the area of the arts and cultural heritage the most fully mobile-optimised event booking experiences are those provided by event-focused e-commerce and travel companies, although the most advanced solutions are delivered in the form of native apps rather than being available via mobile websites.

Whilst some arts and cultural heritage institutions have an online donation facility, only a small minority of mobile websites facilitate mobile giving. One example of an institution that does support this is the Institute of Contemporary Arts (London), although the call to action to do so is somewhat buried within its “support” page.

Solutions beyond the sector again offer some analogues, notably the JustGiving mobile website. Some institutions have even taken advantage of the visibility of the website and its dedicated functionality and are listed as charitable causes to which users can donate. An in-app donation solution is offered by the Give On The Mobile service that generates SMS messages rather than taking card payments.

While this exercise required significant dedicated time upfront, the insights should be of great value to the project through its development.

Leave a comment

Tools & methods

Remote collaboration tools

Tracy Wang
Jul 7th 2013

Our development partner is based in the USA and so to enable as good a working process as possible we use three core tools:

- Basecamp for project management

- Webex for web based tool for conference calls with video camera

- Check lists, itemised to-do list with description of tasks, due date and owner

Leave a comment

Tools & methods

Project management & requirements analysis

Tracy Wang
Jul 7th 2013

We base our project approach on the Prince II methodology, this includes production of the following

  • Project planning
  • Set up of a governance project board / team
  • Bi-weekly highlight report to project board members
  • Regular project meetings on goals, timescale and deliverable updates

We also carried out a structured requirements analysis which include:

  • Theme-based Roundtable discussions using webex and conference calls
  • Follow up meetings that take place outside the roundtable discussions to speed up progress
  • Meeting notes circulation
  • Presentation style structure

We find that by adapting established methodologies it gives us the following benefits:

  • Structured methods
  • Adhere to project management standards
  • Clarity in tracking project progress and tasks/deliverables
  • Aids communication between team members (and with partners across the globe)
  • Opportunities to expand discussion points and keeping track of outcomes
  • Better flexibility in identifying resources
  • Issues are monitored regularly


Leave a comment

Decision Points

Making a mobile site rather than a standalone app

Tracy Wang
Jul 7th 2013

Mobile technology offers up the potential for organisations to engage directly with existing and new customers outside of their building and away from the desktop. Several organisations (including ROH) have developed apps for specific purposes, e.g. ticketing, games; we are seeking to develop a more sustainable approach that enables multiple content delivery over a longer period. We will also use the project to develop new products to engage broadcast and digital audiences for the arts which are growing through initiatives such as cinema relays.

Taking this approach means we build on the foundation of the website development undertaken thus far by building a mobile application suitable for any device and any user. This enables us to leverage SEO, the existing purchase path, metadata, stats, social interactions, SRM and e-commerce. The app will be built in HTML5 so it will work on any mobile device (iOS, Android, Windows 8 etc) without the need to built different versions for different devices or negotiate with various different App Stores etc

From the initial research we know there are few “hybrid app” products currently being offered by the arts and cultural heritage sectors which in general have tended to divide their mobile offerings between informational mobile websites and native apps for deeper engagement. The research also highlights evidence for some development in this area with some institutions (both large and smaller-scale) creating mobile web products which resemble native apps in their interaction design and more streamlined and focused functionality. The most notable examples in this category are the Rijksmuseum website and Baltimore Museum of Art.

Whilst there is evidence of mobile-optimised booking within the sector, it is clear from the surveyed sites that this is largely dependent on the abilities of the institution’s third party system.

Mobile donation is perhaps the most underdeveloped strand in all the offerings surveyed within the sector and one which has struggled to obtain much visibility on institutional websites. However, mobile optimised solutions for this do exist without the sector, most notably JustGiving, a platform on which a number of arts and heritage institutions have accounts.

Leave a comment

Research findings

Mobile services can still delight

David Little
Jul 7th 2013

Despite mobile devices being deeply embedded in our participants’ lives, they are not yet “invisible” technology. An example of this is that 11 diary participants (out of 25) reported 15 instances of “delight”—that is when a device, app or website exceeded their expectations and proved to be particularly useful for them.

Participants were asked to record any emotional responses to device use in the diary study (e.g. satisfaction at being able to achieve a goal or frustration at being prevented).

Although users clearly have reasonable expectations that mobile apps and websites should allow them to fulfil their goals, they retain an ability to be moved beyond satisfaction to surprise and delight by apps offering real utility to them (e.g. via unexpected functionality, ease of use or content), and as a result engage with them repeatedly.

Leave a comment

Tools & methods

Digital diary studies

David Little
Jul 7th 2013

Diary studies are a research method commonly used in Human-Computer Interaction and psychological research in which participants are asked to keep a diary of an aspect of their daily lives and experiences and report this at set times through the day, over a period of time. The digital component comes from the fact we asked participants to record their experiences of mobile usage via dedicated, password-protected Tumblr blogs.

A number of reports exist around the subject of mobile usage and the arts, as well as mobile usage more generally but these have tended to provide quantitative information. The diary study allowed us to better understand how users were interacting with arts and cultural information via their mobile devices and the contexts in which this took place by collecting a qualitative data set.

In particular the diary study provided us with the opportunity to understand participants’ wider “mobile lives”, concerns and pre-occupations in real usage situations. Other user research techniques such as ethnography or interviews would either have been too intrusive to be practical or could not have as effectively probed usage in “live” use cases.

Leave a comment

Project Insight

Behaviour types of mobile users

David Little
Jul 7th 2013

We identified the following key mobile behavioural categories exhibited by our participant group:

  • Information seeking
  • Productivity
  • Social
  • Relaxation and enjoyment
  • Habitual use

And the following emotional responses to mobile usage:

  • Positive emotions (satisfaction, delight)
  • Negative emotions (anxiety, frustration, distraction)

They revealed commonalities of behaviour and experience across different age groups and genders and helped understand both the context of participants’ mobile usage more generally and specifically when interacting with arts and cultural information via mobile devices.


These categories were arrived via following a grounded analysis methodology when analysing the qualitative data collected during the digital diary study.

Leave a comment

Research findings

Low interest in mobile booking

David Little
Jul 7th 2013

While half of our participants (50%) reported having previously booked tickets with their mobile devices, when asked if they would actively choose to book tickets on their mobile device only 35% reported they would. This information was found out via the survey of our project user participants.

This low level of enthusiasm for booking tickets via mobile was underlined by participant comments within the survey and entries in the diary study which confirmed that mobile ticket booking systems currently offer a poor user experience.

As a result there is considerable room to innovate in this area. In particular this insight highlighted the utility of examining mobile seat selection and in-app ticket delivery.

Leave a comment