Building A Mindjoy Beta App
A few weeks ago we were approached to help build a new app targeting the mental wellness space. As it was a close friend of FireWorks asking, we were very keen to help out.
The idea was to build a web platform where a therapist practising Dialectical Behaviour Therapy (DBT) could create and manage their patients’ daily worksheets. The patient can then fill in the generated sheets on a mobile app. When the patient comes in for his or her next appointment with the therapist, the full history of worksheets is accessible through the web interface.
DBT is an ideal fit for a digital app as it is currently a completely paper-based process. A mobile app also opens up other possibilities, such as reminding users of tasks with push notifications.
This all sounded fairly straightforward, especially since a sizable chunk of the work had already been done on the platform side of things (a Rails app with authentication, some of the required data structures and also CRUD API endpoints).
We agreed to dedicate 2 people (myself on code, and Marike on design) to help out for a week, and re-evaluate after that. The problem was that the Monday was a public holiday and as it goes with writing code, there is always a bit of a ramp-up period when climbing into a new codebase. This left us with precious little time to actually get something demo-able out the door.
Marike started smashing out beautiful designs at breakneck speed (as she always does), while I started familiarising myself with the current Rails project. The code seemed mostly usable, until I started planning out the mobile app. We needed a more flexible data structure. This made me somewhat nervous as time was a luxury I was not willing to waste. I spent the first day refactoring server side code. At least we had a decent base to start off from on day two.
Our client was currently in America, and continued to work on the code in parallel with us. The time difference made this quite challenging. Remotely collaborating is something that works very well for many projects, but the time constraints we were under complicated matters, since I had to waste even more time every morning getting up to speed with the changes that came through during the night.
It did not take much time before we had a login and multiple authenticated pages. This might sound straightforward, but it actually involved passing tokens around in HTTP headers and also “intercepting” HTTP responses and logging a user out when receiving a 401 (unauthorised) response.
By the Thursday of the week we had a (semi) working app. It was functional in the sense that a user could log in, capture a day log (which includes multiple different types of inputs) and update older day logs. For demo purposes we were probably there. We thus decided to have people start playing around with it.
The majority of the feedback we received involved performance of the app. This was very worrying for me as this could very well have been limitations of the framework. Page transitions seemed to slow down tremendously after continued usage. This immediately made me suspect a memory leak.
Debugging a memory leak on a web page made me appreciate Chrome’s profiling tools. By fiddling around (for quite a while) I came to the conclusion that the scollView component of Ionic was the culprit. Fixing it seemed like a rabbit hole that I did not have time for. We thus hacked a solution together that basically reloads the page after a certain number of page transitions. This is and was a truly terrible hack, but for a demo app it seemed reasonable. For what it is worth, Ionic have fixed the bug since this time.
So what have we learnt from this whirlwind of a project?
- A project is never as simple as it initially seems
- 4 days is not enough to build a polished mobile app
- Remotely collaborating across time zones can be challenging if you are on a tight schedule
- Be aware of the risks involved using an open source framework that has not reached version 1.0
- When taking a project over, factor in some time for getting to know the code and possibly changing a few things around
All in all building the first Mindjoy prototype was a good experience. We all learnt a lot and even though the end result was not perfect, it was more than enough to start demoing and gathering first users with. In my mind that equals success!