Having seen my efforts at the Culture Hack Scotland event in May, I was approached by the nice people at the Edinburgh International Book Festival to create an official mobile application for the event, which took place last month.
The final website can be seen at m.edbookfest.co.uk.
We decided that a mobile web site would serve the Book Festival’s needs better than would native applications. Here’s why we came to that decision, and how building an interactive and responsive mobile website need not be as huge a departure from traditional web development as you might think.
Why a mobile website?
In the very first meeting with Andrew Coulton from the festival, we discussed whether it would be better to develop native applications for specific smartphones, or to create a mobile web site. The goal of the app was to provide event listings, information about the authors appearing at the events, and the opportunity to purchase books and e-books through affiliate links to Amazon and iTunes.
The decision to develop a mobile website was influenced by a number of things, not least that my own background is in developing websites. This obvious bias aside, there were still plenty of compelling reasons to choose the web approach for the festival.
No app stores
Firstly, as an application for a specific event, there was a hard deadline of the start of the festival. The last thing we wanted was to have the launch delayed while awaiting approval from app stores. Website hosting and deployment (using Heroku) were entirely under our own control and publication was not subject to approval from a third party platform provider.
This meant that two or three releases were possible during the festival to fix some bugs, with a very quick turnaround that would not have been possible with native applications.
The problem of discoverability
Many mobile web applications can suffer from a lack of discoverability. Where app stores provide a single, searchable, centralised directory for native applications, there is no single directory for mobile web applications, although such things do exist.
However, this is really only a problem for applications that have a broad and varied target audience, such as games and to do lists (and yes, fart apps).
For a mobile website, it is largely up to the site provider to promote and market their own content through appropriate channels, as is the case for any website. For the Book Festival, we knew that we would have a ready-made engaged audience – the festival-goers themselves. We would also have some marketing channels to target this audience, including the physical festival site, the existing desktop website and the festival Twitter account, each which could publicise and link to the mobile site in its own way.
So, for a specific, targeted and already engaged audience, discoverability becomes far less of an issue. Both native and web applications would have to be promoted in channels targeted to your audience in similar ways, as no global app store is able to target niche users in this way. Discovering a niche application about a specific event through all the noise of highly popular games and gimmicks is not easy.
Interactive phone features
Some smartphone features can only be accessed via native APIs that are not as yet accessible to mobile web browsers, including cameras, microphones, telephony and so on. If you are creating an app that needs to access these features, then a native app is the way to go for now until broad browser support is available.
However, many content providers will simply not have any need to use these features. As part of our decision making process, we brainstormed a number of ideas for the application and found that there were none that could not be executed via existing browser technologies.
However, it is platform and the ubiquity of web browsers that makes the web universal, not the technologies that are used to build it. Hybrid apps are distributed and marketed just like other native apps, and so are not intrinsically cross-platform. There is also the chance that APIs will change or new devices will emerge, bringing further problems of interoperability.
Building a website using agreed web standards and with techniques such as progressive enhancement gives access, in principal, to anyone using a phone with a web browser. The devil here is in the details of browser support and designing a responsive interface to work across a broad spectrum of devices, screen dimensions, interaction capabilities and network performance. As for any website, the devices and browsers you develop for depends on the audience being targeted. Bryan Rieger provides an excellent dissection of the challenges of cross-device mobile web development.
In the case of the Edinburgh Book Festival site, statistics suggest that UK mobile internet use is dominated by the iPhone, iPad, Android devices and Blackberries, with around 5-6% remaining for other devices, even if other statistics suggest these devices do not have as high an overall penetration as you might expect.
Libraries and frameworks
The explosion of tools, libraries and frameworks for mobile web development in recent years means that it is easier than ever to get a head start in mobile web development and minimise time spent ensuring the site works across a wide range of devices.
It is increasingly the case that many of the modern smartphones are using similar browser technologies – the WebKit rendering engine powers Mobile Safari for iOS, the Android browser, and the Blackberry browser. An experimental WebKit-based browser is even shipped with the Amazon Kindle. Many libraries and frameworks are beginning to target WebKit alone, with some superficial support for other browsers.
However, the danger here is that, depending on your target audience, you lock out users of other browsers. Other browsers are popular in other audiences, not least Opera Mini. Again, this can be largely avoided by starting with a simple design, a fully operational website, and then layering on enhanced features progressively.
Design and development
Throughout the design and development of the site, I worked within two-week iteration cycles, with regular deployments to a staging environment, allowing frequent reviews by stakeholders at the festival. All code was written with a test-driven approach using tools such as Cucumber, Capybara, RSpec and Jasmine BDD.
All features were planned in advance using story cards that were agreed and prioritised. This allowed us to keep in touch with what exactly would be delivered in time for the start of the festival, given a fairly rigid budget and timescale. Inevitably not all the ideas could be implemented for this year’s festival, but with any luck we’ll be adding features in future years.
The overall effect of this was that I was able to spread the work of developing the site evenly over a period of 2-3 months, with 3 hours work a day in addition to my day-to-day work. Deployment had been continuous, so there were no nerves about the final deployment the night before the festival as there would have been with a Big Launch approach.
Design - keeping it simple
Time and time again during the design and development of the site I found myself up against the constraints of designing for mobile devices. Far from being restrictive, these challenging constraints can be the fuel for innovation and creativity. For example, limited screen real estate forces a focus on supporting the primary user task at hand and the continual stripping away of unnecessary fluff.
In native applications, this has resulted in some clever interactions that make the most of multi-touch, gestures and accelerometer motions to move features off screen but retain their availability. Some of these have become almost conventional, such as pulling the screen down to refresh a timeline feed.
I was initially tempted to introduce some touch interactions to the interface, but soon realised that this would have been a mistake.
Secondly, I expected that few people would discover them – users are consciously using a mobile-optimised website and not a native application, so it is unlikely that they would expect complex touch gestures.
Instead I aimed to create a design that would be as responsive and simple as possible based on simple single touch interactions. The key here was fast page transitions and optimised performance.
To my mind, all three frameworks are attempting to ape the native experience too closely – and not always successfully – with some jerky animations, mis-positioned elements and some performance issues. We didn’t want to create a native app experience, but a simple mobile-optimised website with a responsive feel.
A website is a website is a website
We were making a mobile optimised website, so we decided it should behave much like a website, and work within the confines of a mobile web browser. The back button should work, links should behave like links and most importantly, it should continue to provide a web experience for phones without touch interactions.
However, the browser address bar is still updated as the user navigates around, allowing for favourites to be set, deep links to be emailed, tweeted and bookmarked. A simple but effective example of the importance of this was demonstrating during the festival by the use of deep links in tweets from the official Book Festival twitter account to link to specific day listings and events. Another feature that was explored but not implemented was the use of QR codes around the physical festival site to allow deep linking into specific event, author or book pages.
For example, in the case of the Book Festival site, I eventually removed the reference to Modernizr, which detects browser features and allows the developer to progressively enhance based on support for specific browser capabilities. I just wasn’t using it for anything important, and so the bandwidth savings gained from removing it trumped any minor issues that it might have helped fix.
Open source FTW
As part of the project, all source code has been released under a GNU General Public License on Github. Feel free to fork it and play around. The Book Festival are planning on opening up listings data in the future, but access can currently be requested on a case-by-case basis. See the README on Github for more information.
This project would not have been possible without the support of the Edinburgh Festivals Innovation Lab, and in particular I would like to thank Rohan Gunatillake and Ben Werdmuller for organising Culture Hack Scotland and providing excellent motivational impetus. One of the goals of the hack day was to foster co-operation and partnerships between the cultural sector and independent developers, and I’m very glad to have been part of an example of that working successfully and producing something with a far wider output that just a fun hack.
Secondly thanks to everyone at the Edinburgh International Book Festival, and in particular Andrew Coulton, who despite being phenomenally busy in the run-up to the festival found time to provide detailed and helpful feedback and support.