There is plenty of research to show that taking stairs is one of the best ways to work out without taking time out to exercise. Taking the elevator wastes electricity, and the stairs are a great opportunity to improve overall health. With this in mind, we wanted to encourage people to start thinking about using the stairs over elevators.
Though there are lots of great social health tracking apps out there, we wanted to try using wellness as an excuse to build community around a physical location (the Edney building staircase).
Cohabiting with the city’s leading technologists, designers, and entrepreneurs is the building’s primary attraction, but we wanted to explore how the building itself could offer benefits that go beyond typical human and architectural concerns. Specifically we wanted to see if we could combine building infrastructure with the innovation center’s open, collaborative culture to improve wellness.
To entice our Chattanooga office to take the stairs, the team decided to create Daily Ascent, the app that tracks floors climbed within the office building. The goal was to create an app to encourage building occupants to climb stairs together and then provide feedback in vertical feet/miles climbed, calories burned, and elevator energy saved.
Our first decision was to use iBeacon technology to track stair usage without any conscious involvement from the participants. We split into a server team and a client team. The server team would use Elixir and Phoenix to provide an API to track the stairs climbed and compute stats on stair usage. The client team would build an iOS app to track iBeacon interactions, determine which floors they represent and send this data back to the server.
Chris and Craig bootstrapped a the server and created a tool for beacon administration. They provided API endpoints and web interfaces for storing and modifying data about the beacons themselves so that the system could eventually support other buildings.
Once this was up and running in a development environment, they deployed a production server using Heroku Pipelines.
Alex and Anna got multiple beacons working. They built a prototype application in Swift to start testing the iBeacon interactions. The CoreLocation framework told us when we entered a beacon’s range. Testing in the stairwell suggests we needed to use signal strength measurements to avoid capturing beacons on floors we didn’t visit.
We knew we needed to insert a little more process into the project to ensure all the developers were on the same page about our goals. We created a quick experience map of the process and used the ensuing conversation to put new stories into Pivotal Tracker.
The iOS app team worked on making the API requests to post interaction data to the server. The server team built out the API. They wrote a Plug to handle authentication for devices, ensuring the interaction endpoints are only accessed by the appropriate user.
Using payload stubs in their TDD framework allowed them to develop the majority of the server without any actual device interactions. They used Wallaby for integration testing.
Our product manager, Allie, worked on wireframes for the climbing experience. Although the app only really tracks the number of floors climbed, we can translate that number into several more compelling statistics. The most obvious statistic is calories burned (8 calories per floor). The energy used on the stairs can then be compared to the energy saved by not using the elevator (.005 kW/h per floor). Finally we can compare the cumulative vertical distance travelled by an individual or by all the participants to various landmarks like buildings or mountain peaks.
By mid week, we got the two applications working together and managed to send actual stairwell beacon interactions to the server. We added a persistent request queue to handle failure scenarios in the iOS (a likely scenario in the stairwell). We also had the iOS register the beacons based on a query from the server. The server team made the necessary changes to receive interactions in batches.
All the live testing we did to create round trips to the server exposed a major problem with the way we were sensing the beacons. We had been letting iOS send us the signal strength of all nearby beacons. To conserve battery life, iOS stops sending these events when the app shuts down. We switched to using region enter and exit events to track the beacons. This allowed us to receive events even when phone was off, but the short window iOS gives us to respond to the enter event doesn’t allow us to range the beacons. So we were back to the problem we had on Monday where we could only measure stairwell location to within 2 or 3 floors.
We now need to focus on the design aspect. Carbon Five’s Chattanooga designer, Jaythan, used some spare cycles to produce a logo and added some color to Allie’s wire frames. The team spent the day implementing the designs and building some number-crunching statistics code on the client side. This was the day the app really came together. The beacon accuracy problem meant that all the stats were probably wrong, but at least they looked good.
We determined that the Daily Ascent experience would be better served by Apple’s HealthKit. The iOS team spent the entire day switching from beacon regions to geofenced regions. Testing the new code required many walks around the block and up and down the stairs. It was an unusually tiring day of coding.
The switch from beacon interactions to floors climbed required some modifications on the server-side. The flexibility afforded by Ecto made this transition relatively painless. Our decision to keep the math on the client paid off almost immediately.
After a week, we have a working app that looks great. As we move out of labs and onto other projects we begin a beta program to use the app in the office. With luck, the experience will be good enough to roll it out to the rest of the building and beyond. Regardless of the outcome of the beta, we all a had a lot of fun and gained experience with several new technologies.
Be the first to write a comment.