We’ve just shipped the first part of HomeServe’s new mobile digital strategy; an iOS app for their customers to view their products, make a claim and view handy hints and advice from engineers. To enable us to bring this to life we needed to integrate with their backend systems some of which had API’s, some of which had never been exposed to the outside world before.
The process of developing the app went through our usual “Think, Design, Make” process where we blend user centred design with business goals to understand and plan the technical and functional requirements for a project before we dive in to developing any code.
This article is focused on the Make phase and the specific tools and processes we went through, but if you’re interested in how we approach Think or Design, feel free to ask me a question on Twitter.
HomeServe are currently going through a digital transformation which spans across their existing and future businesses. We’ve helped shape that transformation, co-creating new products and services; from integrations with smart devices to new product lines for Landlords.
Part of the digital revolution was to re-imagine how customers interacted with HomeServe and the platforms and devices that they used to manage their products. This strategy took two forms; one that was customer facing and the other looked at their backend systems and platforms. An updated ‘self serve’ section of the homeserve.com website allows users to manage their account, change details, view products and book engineer appointments.
Mobile apps were a key part of the strategy, allowing HomeServe customers to access their accounts wherever they are, in addition to providing extra utility that can only be derived from native apps (such as video calling). We worked closely with HomeServe to create a new set of API endpoints to enable us to embed the required functionality within the apps.
Within the Make phase of the project we adopted an Agile approach for delivery. We had an ideal set of requirements and mapped those out using a Trello board which was shared with the client. This formed the basis of the subsequent sprints and the scope for the initial release of the application. We’ve configured Trello with various lists (Icebox, Planned, Current Sprint, Latest Build, Done, App Store Build) to track the progress of each feature, in addition to capturing new feature requests in an Icebox. By using Trello, all members of the team (both at 383 and HomeServe) could quickly and easily view the status of any feature across a range of devices.
The team at HomeServe also replicated the Trello board within their Scrum area so that the wider business could see the progress within the app.
Before any code was written, the development teams from 383 and HomeServe met to have a whiteboard session to plan out how our app was going to interface with the HomeServe systems. As this hadn’t been done before, there weren’t any existing API’s that could be opened up to us. We therefore had to map out the data we’d need, against the proposed functionality and then come up with a data structure to meet those needs.
We decided on a RESTful set of endpoints that would either return JSON data, or HTML to be displayed within a webview (more on that later).
We’re big fans of GitHub at 383 (they even sponsored HydraHack a few times) and we use private repos to store our code. For documentation, we used the Wiki and Gist features to map out the expected request and response parameters.
It’s said that a picture paints a thousand words. If that’s the case, then a mock endpoint saves a thousand meetings.
Once we had agreed on a proposed structure for the data within the app, we needed to be able to develop our app against it and setup scenarios to test how our app would be able to handle responses (both good and bad).
We used a service called Sandbox (I really can’t recommend this enough if you’re building API driven apps), to structure each route and the response. Sandbox makes it really easy to script a custom response based on the input. This was particularly useful for HomeServe as there was a set of criteria for how different types of account would be able to interact with the app in addition to simulating an expired account. Using a few lines of Node, all of the various scenarios could be quickly scripted against a set of test user accounts with each response serving the correct HTTP response code.
Once we had a set of endpoints built, we needed to test their integrity. To do this, we turned to Runscope to set up a test for each endpoint, writing assertions to ensure that each test user would return back the correct response code and data. This formed our ‘developer contract’ and meant that we had a reliable way to ensure that we were building the app against something that could easily be tested. It also meant that when the HomeServe team developed the real endpoints, we could re-test using Runscope before making any changes to the app to ensure that we didn’t waste valuable development time debugging an endpoint that was returning data in the wrong format.
Throughout the build of the app we were keen to stick to the Agile principles of releasing often and continuously getting feedback from users. To do this, we used BuddyBuild to have continuous deployment of the app. BuddyBuild is an amazing service that allows us to ship the latest build of the app to our test users each time code is pushed to a branch, automatically installing our dependencies and libraries. The app can then be distributed to various teams and captures feedback and crashes, automatically piping updates in to a shared Slack channel.
One of the great things about working with HomeServe is the close proximity of our offices. This made it really easy to get together to demonstrate the app progress and run through feature requests. Both teams worked out of each others offices so we could easily ask questions and get immediate feedback. Even with tools like Slack and video calls, getting together for face to face meetings was invaluable.