I’ve let this project languish for a while, but it’s still something I’m quite keen on. And still something that could really help people.
Since I built the Sanguine prototype last year I’ve learned a lot and changed some ideas about how I’d like to approach Sanguine.
1. Focus on the Web
I originally envisioned Sanguine as a desktop application with online syncing and an eventual mobile app. My reasons for this were that it would bring increased security, speed and reliability. My teachers bought my reasoning for this, but I was wrong. Not that those three things aren’t important! They certainly are. But a desktop application just won’t cut it. The web is becoming faster and more reliable and it’s just more places, which makes it more accessible. The basis of the new Sanguine will be a mobile-optimized web application that will work from most locations. I’d love to use local storage as much as possible so that it’s still usable when an internet connection can’t be found (this was my biggest reason for putting it on the desktop originally). Eventually there may be room for desktop applications or apps in various app stores, but that’s far down the road.
2. Doing it myself
I don’t really believe that I have the intelligence, skill or time to do all of this myself. I didn’t really before, but I’m more sure of it now. To that end I want to look into what ways I can leverage the community to help me build this. I don’t know exactly how I’m going to do that. I’m thinking about GitHub and open-sourcing the project entirely, or at least parts of it. A lot of this is a bit of a question mark, but it’s something.
3. An Open Standard
Related to the point above, I’ve become preoccupied with the idea of making a system that will be worth something even outside of Sanguine itself. Something that will help other diabetes software makers and companies work together and get more done themselves. Having the desire to be as flexible as possible and interact with as many other devices as possible made me think about trying to find or create a format to facilitate this.
I envision an open standard or data-interchange format that is built to efficiently and accurately store diabetes treatment information and can be used by any system taking into account mg/dl vs mmol/L, standards for storing bolus and basal information, blood sugars, meals, etc. It might consist of a JSON-based data exchange format, as well as a language agnostic database structure for storing this information. I think this is a necessary foundation to build Sanguine on if it’s going to be the best it can. It’s going to be the first thing that gets fully open-sourced; or maybe something like this already exists.
4. Division of Labour
I have determined a few completely separate areas that will comprise Sanguine, that different people or different versions of me could work on completely independently: Collection of data, storing of data, viewing and interpreting data.
Collection of data is the creation of interfaces to retrieve data. The most complex one is from user input through a GUI, but other ones include importing from various devices like insulin pumps and glucometers. There is one main collecting process to be built (first), and then one for each input method. The GUI will be less separate from the other systems.
Storing of data and the generic data collection method are related, possibly should be the same thing. It’s a central sort of database to house all the information.
The viewing and interpreting layer have to do with getting the data back out of the database and how best to do that. With ‘interpretation’ I hope to facilitate some kind of ‘query wizard’ that will allow complex reports to be built and shared without too much difficulty.
Still a fair bit of batting ideas around right now, but I want to put this out here and also invite input from any interested parties.