WFTDA App Proposal: A PhoneGap based iOS and Android App

The Women’s Flat Track Roller Derby Association were looking for somebody to build them a new mobile app for their rules. I submitted a proposal, but in the end they chose to go with somebody else as they’d prefer to work with a larger company with more resources. Given what they’re looking for, this decision makes a lot of sense to me and whilst a little disappointed it’s understandable.

It’s important to go for projects like this, as a freelancer. Partly because there’s always a chance you can get it, and hey, more work. And partly because you learn a lot. The research I did with this little project led me to brainstorm with the very talented Gemma Cameron, which has inspired me to actually go to all the fantastic developer events happing around Manchester.

It also led me to closely examine some cool technologies (like PhoneGap) and learn more about some interesting development processes (like Test Driven Development), which fed directly into other projects I’m working on (like the Minimum Skills app).

For anyone curious, I’ve made my proposal public now (you can get the pdf here).

If you have any feedback, I’d be interested to hear it.

Building The Official WFTDA Rules App: Android & Beyond

This is a proposal by John Kershaw, in response to the WFTDA’s “Rules App For Android Devices Request For Proposal” issued on February 14, 2013.


I’m John Kershaw (skate name Sausage Roller), a freelance web developer for 5 years working primarily on custom solutions to interesting problems. Since graduating in 2008 with a degree in Advanced Computer Science I’ve been building complex websites and consulting for a number of both for-profit and nonprofit organisations. I’m based in Manchester, UK, and have clients in the UK, USA and Australia.

In my spare time I develop the Roller Derby Test O’Matic website (see, a tool used globally by thousands of skaters each month to learn the rules of flat track derby. I am the Training Manager for Manchester Roller Derby, one of the UK’s largest roller derby leagues. I also skate for the league’s men’s A-team.

For this project I would be working closely with Gemma Cameron (skate name Ruby on Rails). She’s a senior software developer at with seven years of commercial development experience, and 20 years of skating experience including three years of derby at two roller derby leagues. She is also prolific in the local software community, hosting many events each year. During Leeds Hack 2011 (an event where participants aim to complete a project from start to finish in 24 hours) Gemma built an (unpublished) native Android app to track roller derby circuit training, with her group also creating a native iOS version too.

I am currently developing the Roller Derby Test O’Matic mobile application. When completed in the next few weeks it will be structurally and technologically very similar to the proposed WFTDA Rules app detailed on the following pages.

In my freelance career I typically have one large project on the go and several smaller projects. Small projects range from upkeep on past work, consultancy, or simple client requests which take a few hours to sort. Currently I have one part-time client with the rest of my energy going into the Roller Derby Test O’Matic app. With the acceptance of this proposal I would decrease the workload I have with my existing main client (I have a second programmer on the project who can take over), and the app I am building is due to be completed by the start-date of this project. This allows me to prioritise the WFTDA app and work on it full-time.

The Solution


Using the platform agnostic PhoneGap framework, an HTML5 based application will be developed. Native apps (ones built specifically for iOS or Android) have greater power and are likely to be more responsive than their HTML5 counterparts, however they are limited to a single platform and are much more expensive to develop. Using a framework like PhoneGap allows a single core application to be developed, and without significant effort ported and sold on iOS, Android, BlackBerry and Windows Phone devices. For the purpose of this proposal it is assumed the project’s initial focus is on Android devices.

HTML5 brings with it a clear advantage when it comes to responsive design; using a combination of HTML, CSS and jQuery Mobile (an HTML5 based user interface system, optimised for mobile devices) any sized device will be able to effortlessly display the app. Flexibility of this kind is essential when tackling the huge range of Android devices on the market.

The design of the new app will be very close to the current iOS app, allowing a smooth continuation from the style of the current app and WFTDA website. This also reflects and compliments the WFTDA’s website branding and style. The new design will differ from the existing design in the implementation of device specific design preferences; for example, Android’s standard button size. Here, the existing WFTDA design is still used, but is subtly modified to allow more “expected” behaviour and style from the perspective of the end user.

It’s important to note that whilst the new app will look and feel similar to the existing app, it will be fundamentally different under the hood and enable the WFTDA to manage the data via a remote Content Management System. All this whilst still providing content if the user is offline, plus creating an app that can be ported to multiple devices.

Structure and Navigation

The app will follow a simple, hierarchical structure that’s easy to follow, and easy to expand. A basic home page listing the main sections will greet the user. From here they can select any number of key features, split across three main sections and a menu bar: Rules Documents for all rules, track images and publications (both Clarifications and Q&A); Officiating for official-related reference material; Training to group together everything skaters need for improvement (including tick-list minimum skills and mock rules tests). Along the bottom of every page is a common bar to allow users to easily access their bookmarks, search, profile and settings.

During the initial discussion at the start of the project we will get the detail of the project sorted, we will asses the important features and plan accordingly. I have ideas on key features, as I’m sure the WFTDA do.

The Profile page will list a user’s accomplishments in the app so far; rules tests taken, minimum skills % complete, etc.

The Settings page allows users to customise important features, such as when and how the app updates its data.

A basic example (style is not representative of the final product, this is just a mock up) showing the standard layout and navigation follows.


Back and forward buttons as found in the current iOS app will be included, to allow horizontal navigation of the content tree.

Every page can be bookmarked using the handy bookmark button at the bottom of the page, or holding the left-hand side of the page.

Offline & Updating

It is essential that the application works with any kind of data connection, from persistent always-on connections to non-existent ones. As such the app will rely on locally stored data, and update this data as and when possible from WFTDA’s server.

The app will come with a copy of all the data it needs, and will simply update its local copy when possible. If no data connection is available, the local copy will continue to be used. If, however, there is a data connection available, updates for the data will be fetched automatically.

The data will be sent to the user’s device from the WFTDA server via an XML API, powered by a Content Management System. The details of the CMS are given in the next section.

A diagram made using Balsamiq showing, in basic terms, how the app would auto-update.

Some data (such as new software features, or videos) may be impractical to update using this method and would require a software update.

Whilst users should be encouraged to keep their data up to date, in some cases they won’t be able to, so it is important the app continues to be as useful as possible under all circumstances.

Content Management System

The power of the automatic updates will come from the API. This will be generated by custom PHP code running on the server and provide the app with all of the information it needs. A basic CMS will likely need to be built to allow you to have full control on what is updated and what isn’t.

Having had no view into how the current website and data is stored, I can only make assumptions on how easy or hard it will be to tap into the current data and feed it to the app. The worse-case situation is we will end up with a stand-alone CMS built for the app.

Basic training will be provided, and the CMS will be well tested to make it as easy to use as possible, whilst also being secure and flexible.

Additional Feature Recommendations

Premium Content

The use of in-app purchases enables any number of features, items or data to be made available to users. What this content is will depend on what you want and your business model. One option is to have a free app that provides the rules and has the other features visible but unavailable. Then charge users for access to each specific feature, or all for a discount.

An Interactive Quiz

I’ve been building the Roller Derby Test O’Matic for some time now, and have access to and fully own the contents of its database. It’s been a learning curve, and an occasionally challenging experience, and I will bring the knowledge I have gained with me into this project. I have large quantities of user data which I’ve used to learn how to make the quiz site increasingly effective.
It currently has a basic API which we would use to have balanced and automatically generated tests given to users. Many leagues already use the Test O’Matic as part of their training, so this would be a logical inclusion.

Given that I am also developing a very similar app to the one in this proposal, specifically for the Test O’Matic, the potential for useful interaction between the two apps is high.

A Shared Data Source

This should be a high priority for this project. However, without knowing more about the current system, it’s hard for me to advice on the best course of action. Assuming it’s been produced in a logical manner and with common technologies, I am confident it will be possible to centralise the data.

Multi-lingual Support

Any app, with little overhead, can be built to allow for multiple languages. My recommendation is to build in this functionality, but actually add alternate supported languages after the main app has been completed.

Development Process

Agile Code

The key to fast software development is rapid iteration; delivering minimum viable features to the app and reacting to their successes and failures, then advancing. This lean and agile development process, favoured by successful technology startups and companies such as Facebook, is what I will be using rather than the more traditional approach of a step-by-step design, implementation then testing process. Experience and history shows the step-by-step approach leaves little room for reacting to feedback, users and other factors.

Almost immediately a working app will be made with a basic set of features, and it will be steadily improved and built upon with additional functionality as the weeks progress. Test driven development and the skills of two successful and experienced developers will ensure the quality of the application is high; features will be released, but not bugs. Continuous delivery of features (new updates every few days, rather than every few weeks) will allow us to gain feedback from testing of the application right from the very start of the project. This will allow the look, feel and functionality of the project to develop and react with ease.

Client Responsibilities

At the start of the project I will need to work with the WFTDA to get the most accurate description of the wanted product as possible. I will need either detailed information on, or access to, any currently existing system that’s likely to be involved in this app (for example, I’d need to know how the current rules are stored, and how I can interface the app with them).

As the project progresses I would expect regular check-ins. If there are members of the WFTDA who would like to join in with the testing process, that is very much encouraged.
I would need a copy of all the data you wish to be used by the app within a few weeks of starting the project.

Project Schedule

The following table shows the estimated order of events, along with which week of development it falls within. The project as a whole is divided into four phases to make things simpler. Phase 1 gets the core functionality in place, Phase 2 adds the server-side features, Phase 3 adds in the remaining app features and Phase 4 makes sure everything is working.

The time each feature takes to build is an overestimation made with the assumption there will be unforeseen problems. The agile approach will allow the schedule to become more and more detailed and accurate as the project develops.

Phase 1

Week 1

Specification document created

Establishing development environments

Communication patterns set

Testing plan

Week 2

First usable app generated

Rules pages built – static content used

Week 3

Rules completed

Q& A and Standard Practices started

Week 4

Basic CMS created for content to be generated from

Updating via the website, available offline

Phase 2

Week 5

Complex content begins to be added – zoomable Track layout added.

Hand signals & flash cards begin being added.

Week 6

Minimum skills & video content added

Settings & Profile pages completed

Week 7

Bookmarks feature added

The CMS is completed

Phase 3

Week 8

Search feature added

User Guide written & testing begins with WFTDA volunteers

Week 9

Notifications feature added

Week 10

Interactive Quiz added

Phase 4

Week 11 & 12

Detailed feedback with WFTDA

Training volunteers completes

Final debugging

App goes live!

Training And Ongoing Support

A user guide will be provided to be used as reference material.

As a relatively simple to use system I will sit with a trainer (using something like Skype) to walk them through everything, taking approximately an hour or two. I would expect to do this with a number of people, and make myself available at any time for questions. Details on what I am explaining, to be referenced later, would be given in the user guide.

Customer support would be provided on a deal we would work out. Initially the support would be free, but following this either a retainer would be negotiated, or a simple hourly rate would be established.

Time spent fixing bugs would not be billed.

Future additional features would be charged at an hourly or daily rate, depending on their size. Large features (taking more than a week to complete) would likely come with a negotiation to establish a more detailed description of the work being done and a price-per-feature option.


The total cost of the project will be $12,000.

This is divided by phase (see Project Schedule) with all phases other than Phase 1 being a payment on completion to the WFTDA’s satisfaction. Phase 1 would need to be paid in advance to allow development to begin immediately.

Prices are based on the estimated number of hours each phase will take, as well as any specialist software or hardware the phase may require. The breakdown of pricing is as follows:

Phase 1: $5,000

Phase 2: $3,000

Phase 3: $2,000

Phase 4: $2,000

A more detailed breakdown of the pricing can be provided once more detail on the specifications of the project is known.

Future work will be billed at $38/h, or $245/d, or at a fixed rate (which would work out at a decreased hourly rate) for larger updates. This is negotiable.


The WFTDA would maintain full ownership of any software produced. I would ask to be able to refer to and use screen-shots of the application in future applications and on my own website and future proposals.

The Roller Derby Test O’Matic and accompanying code & data would remain the property of myself, however a free-to-use licensing agreement with attribution would be expected.

Leave a Reply