Introducing the Holiday Calculator App

We launched a mobile phone app this week. It’s called the Holiday Calculator App. It’s a first for us in a few different ways: the first thing we’ve done targetted at mobiles, the first time we’ve really started to use HTML5 features, and the first consumer app that we’ve released for sale.

So, I thought I’d write a bit about it.

If you’d rather watch a video, though, here’s a sixty second introduction to the app:

If that hasn’t convinced you yet, then let me tell the brief story of the app’s development.

The idea

The inspiration behind the app is to solve a very simple problem that I believe a lot of people experience. Namely, having a good check on how much annual leave you’ve used up so far this year. As a small company, we’ve only just started to have a proper system (a big spreadsheet) for managing holidays – before that, we used a combination of Google Calendars and memory (both fallible). Big companies sometimes seem to have complicated Human Resources software for managing this kind of information – although I know some still use paper-based booklets.

The problem with all of these kinds of systems is that they’re generally only visible at work, whereas people generally plan their holidays whilst at home. This makes it tricky to quickly check how much holiday you’ve got left. Which is a particular problem when you start to approach the end of the year.

I know tons of people who have had to rapidly use up untaken leave before an end-of-year deadline. And a few others who have run out of holiday three quarters of the way into the year without realising. Given that annual leave is a precious, limited resource – both of these problems are a travesty.

So our basic idea was simply to help people better manage their annual leave ‘spending’ through an application that sits on a device you always have with you – your mobile phone.

Development

The bulk of the app was developed in a single day, as part of one of our internal ‘hack days’ that we run every month. There were four of us working on it, with two working on design, and two on development.

One decision we made early on was to develop the app so that all of the data is stored on the phone (‘client-side’) rather than ‘in the cloud’ (server-side). This has some advantages and disadvantages. The advantages are that it means that there’s no logging-in required, and users have complete control over the data. The main disadvantage is that it means you can only access the data on one device – you can’t login and view it in multiple locations. Overall, the advantages won out.

Getting everything to work via javascript on the phone meant learning a few new technologies.  The first, and most significant, is the Web SQL Database API. This is a new HTML5 feature, which brings simple database functionality to the browser. It’s currently supported by Safari (including mobile Safari on the iPhone) and Google Chrome (a version of which is the the browser on Android-based phones).  There was a bit of a learning curve here (especially in getting our heads around the asynchronous nature of the API), but the simplicity of our app meant that it wasn’t too tricky to get working.

The second HTML5 we had to quickly learn about was enabling ‘offline’ usage of the app through an application cache. This is really super dead simple – it’s just a single text file – the only gotcha is making sure that the web server issues the right MIME type.

The only final hurdles were in adapting the welcome page so that it works on both mobiles and desktop browsers, and in getting all the date-handling functionality to work correctly…

Design

Right from the start, we knew that we wanted the design for this app to be as simple as possible. In fact, a phrase we used a lot was the concept of a ‘one-page-app’ – i.e. that all the interaction occurs within a single view.  We ended up deviating a little from this, with the use of a secondary setup/settings view, but overall the vision held.

The most important bit of information that this app has to communicate is the ‘balance’ of how many days holiday you have left. Most of the time, this is probably the only thing you need to see. For this reason, the app is designed to display this number big and bold in a circle at the top of the page. Beneath it, as a secondary bit of info, is the date which you need to use the holiday up by.

The colour of the circle that the number is in also has some importance. If the app detects that you are either running low on holiday, or are running low in the amount of time left to use it up in, the circle changes colour from green to orange and then red (following the traffic light colour code).

Other design decisions were to place the link to the settings in the top-right of the screen, (which seems to be a common pattern across mobile apps), and to only allow people to delete an holiday, with no ‘edit’ functionality. This decision was based on keeping the user interface as simple as possible, and on the intuition that ‘editing’ would be a rarely-used feature. Plus, it really doesn’t take that much time to delete an entry and re-insert it if you have to.

One thing we were conscious of is in not making the design too ‘iPhone-y’. We could have used the jQTouch framework, for example, which emulates many standard iPhone app interfaces within javascript. That didn’t feel right to us though. We want the app to feel more web-like, and also to feel at home on Android devices, so anything overtly iPhone-like was out.

Pricing and Payment

One crucial decision we didn’t make straight away was whether to charge for this app, and if so, using what mechanism, and at which price.  We could have given away the app for free quite happily, but a few things prompted us to charge a nominal amount for it.

Firstly, asking people to pay for something is a good way of seeing if people think the app is really useful or not.  If it was free, then lots of people would probably install it straight away, ‘just to try it’, without stopping to consider first whether it’s something they really want to use.

Secondly, we thought it’d be a good experiment to see whether there was a market for purchasable mobile web apps, and how easy it was to communicate this idea to people.

Thirdly, and perhaps most selfishly, we wanted the warm glow that you get when people actually buy your thing. Plus, if it brought in enough money, perhaps we could buy something nice with it (like an office iPad).

The next question: how do we collect the money? We looked at PayPal and Google Checkout, and quickly came to the conclusion that Google Checkout had the edge, as it works better on a mobile, and had an all-round better user interface (although by no means perfect). Google also make it really easy to add a ‘Buy Now’ button to your site, and gave us the option to give people a ‘passcode’ which they could use to access the app.

Finally, we needed to settle on a price point. This prompted some lively debate in the office. We wanted it to be cheap enough to be a no-brainer purchase, yet not be so little that it was pointless us charging in the first place. Google Checkout charges us 20p + 3.4% per transaction, so we need to cover that too. The pricing debate around 37 Signals’ Draft app made for interesting reading at this point.

In the end, we settled on a nice round number of £1. If the app really does help you to avoid wasting your annual leave, then we figure that’s worth at least a quid. To drum up initial sales though, we’ve launched with a special offer: the first 50 buyers can get the app at the reduced price of 50. Bargain.

Sales and marketing

This section is the shortest, because it’s also the biggest unknown. The native app stores on the iPhone and Android are both established marketplaces that are to some extent a destination for a large number of existing customers. As a web app, we can’t be part of this. Instead, it’s listed in Apple’s Web App directory, and will hopefully soon be listed on App Store HQ. Other than that though, it’s up to us to tell people about the app.

There are some signs of this changing in future. Google has announced a Chrome Web Store, which looks promising, and Mozilla are starting to think about this too.

For now – the app is available at holidaycalculatorapp.com. And you should go buy it now…

• Digg this
• Bookmark on delicious