Phronesis
Peter Darche
Phronesis is a self-tracking application that combines personal data with medical, environmental, and social-scientific research to help users improve themselves and the world.
Phronesis is a web-based application that uses personal and research data to help users explore and cultivate personal traits that help them, society, and the planet flourish. The application pulls in data from a variety of self-tracking sensors, likes Fitbits and cell phones, and combines it with research data from organizations like the CDC to show users how their behavior relates to outcomes like cardiovascular disease. Users can then use this information to develop habits that avoid bad outcomes, or promote good ones. By seeing how their daily behaviors connect to larger goals, and how those larger goals connect to society and the environment, users are empowered to improve themselves and the world.
Background
My research timeline roughly tracked the features I implemented in the system . I started by focusing on building health-related elements of the api, and researched how to develop restful web services and use mongoDB and tornado (as well as python) on the technical side, and researched the epidemiological literature on the medical/social-science side. When those features were implemented, I shifted my focus towards front-end development and data analysis. The application was build primarily in javascript, so I researched client-side application frameworks and machine learning techniques.
Audience
The target audience for this application is self-tracking do-gooders. Given the fact that it's both complicated, and requires time and effort to use effectively I think that it's best suited to people already interested in tracking and improving their behavior.
User Scenario
The ideal scenario would be something like the following: a person is interested in increasing their levels of exercise. They aren't sure how physically active they are and begin using various self-tracking tools to measure this progress. They connect these tools to my application and then begin seeing when and where they're most physically active and when they're least active. They then see suggestions about what behaviors to work into their routine and connect triggers to get them to engage in those behaviors at the right time or place.
Implementation
The application uses three primary technologies: 1) the Tornado Web Framework and MondgoDB for the api, and Backbone.js. for the client-side application. I chose Tornado because it was designed for high-performance applications and features a an asynchronous, non-block networking library that's well-suited to api applications. I had use the framework the previous semester and found it both relatively easy to use and performant. I also chose Tornado because it's written in python, making it easy to integrate scientific computing libraries. Stated simply, science uses python, and were a wealth of statistics, machine learning, and mathematical libraries written in the language that that I wanted to integrate. Finally, ITP adjunct Adam Parish wrote the book on Tornado, literally, and so having that resource available was an added benefit. I chose MongoDB over a relational database because of it's ability to handle the kind of complicated, nested objects I'd be getting from apis. I hadn't worked with Mongo before, but found that it was also highly performant and relatively easy to use (at least, with the Mongoengine ORM). Finally, I developed the client-side application in JavaScript with Backbone.js. I chose Backbone because it was one of the client-side that seemed to be at the top of the most 'which client-side JavaScript MVC is best' blog posts. I also chose it because I thought it would have the shallowest learning curves. Frameworks like Ember.js and Angular.js had either larget APIs that would take time to learn, or used concepts I had spent very little time with and wasn't ready to
Conclusion
The most significant takeaway from this process was that ideas take a long time to flesh out, and even more time to implement; that it's great to iterate quickly; and that user-feedback is extremely useful! I also found that my behavior is really regular, and that there are a lot of opportunities to make small but impactful changes to my behavior.
Background
My research timeline roughly tracked the features I implemented in the system . I started by focusing on building health-related elements of the api, and researched how to develop restful web services and use mongoDB and tornado (as well as python) on the technical side, and researched the epidemiological literature on the medical/social-science side. When those features were implemented, I shifted my focus towards front-end development and data analysis. The application was build primarily in javascript, so I researched client-side application frameworks and machine learning techniques.
Audience
The target audience for this application is self-tracking do-gooders. Given the fact that it's both complicated, and requires time and effort to use effectively I think that it's best suited to people already interested in tracking and improving their behavior.
User Scenario
The ideal scenario would be something like the following: a person is interested in increasing their levels of exercise. They aren't sure how physically active they are and begin using various self-tracking tools to measure this progress. They connect these tools to my application and then begin seeing when and where they're most physically active and when they're least active. They then see suggestions about what behaviors to work into their routine and connect triggers to get them to engage in those behaviors at the right time or place.
Implementation
The application uses three primary technologies: 1) the Tornado Web Framework and MondgoDB for the api, and Backbone.js. for the client-side application. I chose Tornado because it was designed for high-performance applications and features a an asynchronous, non-block networking library that's well-suited to api applications. I had use the framework the previous semester and found it both relatively easy to use and performant. I also chose Tornado because it's written in python, making it easy to integrate scientific computing libraries. Stated simply, science uses python, and were a wealth of statistics, machine learning, and mathematical libraries written in the language that that I wanted to integrate. Finally, ITP adjunct Adam Parish wrote the book on Tornado, literally, and so having that resource available was an added benefit. I chose MongoDB over a relational database because of it's ability to handle the kind of complicated, nested objects I'd be getting from apis. I hadn't worked with Mongo before, but found that it was also highly performant and relatively easy to use (at least, with the Mongoengine ORM). Finally, I developed the client-side application in JavaScript with Backbone.js. I chose Backbone because it was one of the client-side that seemed to be at the top of the most 'which client-side JavaScript MVC is best' blog posts. I also chose it because I thought it would have the shallowest learning curves. Frameworks like Ember.js and Angular.js had either larget APIs that would take time to learn, or used concepts I had spent very little time with and wasn't ready to
Conclusion
The most significant takeaway from this process was that ideas take a long time to flesh out, and even more time to implement; that it's great to iterate quickly; and that user-feedback is extremely useful! I also found that my behavior is really regular, and that there are a lot of opportunities to make small but impactful changes to my behavior.