Brainstorming for MVP

[robbiedhickey]

Overview

The goal of samwise is to serve as the user's personal side kick. It should provide a flexible way for users to track data points they care about, view their past data (trends/forecasting), create graphical and/or time-series representations, and integrate with other services to incorporate their data for analytics purposes (Fitbit, etc). Because of the ad-hoc nature of the data that will be tracked, having a robust and customizable dashboard will be essential.

What exactly are we tracking?

Before getting into the nitty-gritty details, we need to better understand the shape of the various types of data we will store. In order for this to be effective at tracking general purpose data for personal analytics the model needs to be flexible. A hierarchical model seems appropriate, but how many levels are necessary for our use cases? A potential model:

1. Collection - the highest level container, allows users to create categories of similar or related data. ex. National Park Visits
2. Item - the data point that the user wants to track. ex. Big Bend National Park
3. Event - a value and a date. ex. '1' on '4/15/2015'

Collections are nothing more than a named identifier with associations to many Items. Its possible that Items may be the same in relation to Events, but I could also see the need for there to be an ItemType, which would drive the input the user would get when entering an Event for that Item. We would need to be careful with this, because any variation in how we store the events will make the task of creating generalizable reporting components more difficult. I would only go down this road if we can identify a critical use case that does not fit the 'value and a date' nature of the Event as described above.

As a variation on the above model, we could also drop the hierarchical nature of the 'Collection' and instead use the concept of 'Tags'. This would give the user additional flexibility when generating reports, as it would allow an Item to appear in many 'Collections'.

Use Cases

It should support tracking any data point that can be represented by an integer and a date:

1. Health - steps, heart rate, body fat %, water consumption
2. Travel - bars, restaurants, national parks, check ins
3. Finance - budgets, bills, investments, accounts
4. Personal - goals, concerts, books, movies

Are an integer and a date sufficient? In the case of financial use cases, like bills, a 'due date' may be helpful on the Event for pro-active notifications and reminders. The concept of a due date could cross over to a number of other use cases not explicitly outlined.

The travel related use cases, or anything location specific, makes me think that storing the coordinates of the event would allow for some pretty cool map visualizations.

The personal and travel use cases may call for some sort of 'rating' attribute.

We will need to find the line between storing too much and too little metadata related to an Event. Too much will make data entry cumbersome, too little will hamper our ability to do cool reporting or derive insights. If we do opt for fleshing out the metadata of an event, it seems clear to me that most of the fields will need to be optional.

Features/User Stories

Here we will try to establish the baseline functionality. This will not include 'givens' like account creation, authentication, etc. These cross-cutting concerns are generally solved problems in whatever tech stack we choose, and we can discuss them when we start evaluating frameworks.

1. User can create new Collections. (will collections be tags - M:N or 1:N?)
2. User can add Items to a Collection.
3. User can add Events to an Item. At a minimum, an Event should include a value and a date.
4. User can create a report to visualize their data. This would involve selecting a Collection, and a report type. Report types should be graphical (pie/line/area/bar charts,
5. User can add n number of reports to a Dashboard.
6. User can create multiple named Dashboards.
7. User can import data from Fitbit via integration.

I think Fitbit is a good candidate for initial integration because their data should map easily to our model, and their API is mature.

[BeneventoFrank]

I really like the idea of tagging. I think this gives you the ability to store data but also give it a "higher meaning"

I am not sure i follow what you mean about the value and date. I may be just interpreting it wrong but i think for most use cases you want to store more data.

example

Check in at Yellowstone! you have '1' on '4/15/2015'

How about storing a comment, or maybe a photo? What about maybe sending an alert to somebody to share.. depending on how far you want to take it. you could upload multiple photos and make a gallery of it..

i do see this comment: "If we do opt for fleshing out the metadata of an event, it seems clear to me that most of the fields will need to be optional."

i agree completely.

[BeneventoFrank]

https://dev.fitbit.com/

man i am so excited to hear you want to integrate!!!!

[robbiedhickey]

@BeneventoFrank Interesting regarding photos, I was really only considering data from the standpoint of analytics, but I could see attaching images to make it more personable. It might also open up the possibility of transforming the data into something other than reports - using the national park example perhaps we could generate a travel log (timelines, photos, map locations).

I also think that storing more than a date and a value is going to be necessary for a lot of cases, but was more trying to outline what the minimum event looks like. There needs to be some commonality between events or it will make the analytics part difficult.

Related to optional fields, we need to decide whether something in this hierarchy needs to have a Type field so we can give a more targeted experience in the UI for certain use cases. Ideally the types would be more general than specific (describing the data rather than the intent). Once we have outlined more use cases perhaps we will see a broader trend where things overlap.

Fitbit api looks great btw! Do you use any other services/devices like Fitbit that we might consider integrating?

[robbiedhickey]

BTW, I moved your technology comment into a separate issue so we can discuss that in isolation.