Create document outlining possible modules

[BeneventoFrank]

Modules

• Finance Module - simple tracking and forecasting. This would require a bit of us talking to see how far we want to take it.
  • Enter Accounts, amount, contact info, due dates.
  • Project out what needs to be paid next week or see long range schedule.
  • We could do a lot with this module but one thing that would be a fun twist is if we could provided an added layer of "tech" to this and secure the data. Maybe i don't want Robbie to make fun of my spending so it could be encrypted somehow so that he can not see it. I have never done something like that. it would be interesting.
  • Need to have the ability to set reminders email, sms, what ever so that say i want to get an alert to mail a payment for an upcoming bill. It may be due on the 10th, i want a reminder on the 4th with the ability to hit 'snooze'. ultimately even a 'dismiss' or 'sent' to confirm that you sent it.. and record what day.
• Task Reminder Module
  • Enter notes, reminders details etc. get alerts on any device.
  • Would be cool of you could create one and then push an alert to a user letting them know they need to do something.
  • This module could also be used to setup appointments and setup reminders on a user defined scale. 1 week, 1 day, 5 min.. even setup multiple reminders.
  • Perhaps even a daily events calendar view. see whats coming up tomorrow. This would be kinda cool b/c its shared on all interfaces.
• Exercise Module
  • Enter workouts while you're at the gym. Track exercise, # sets, # reps, weight amounts
  • Enter general workouts as well such as 30 min spin, 30 min cardio etc..
  • Maybe these can be "tagged" so when you pull up a chart.. you can see it in a reporting fashion. or even query by type..
  • Track weight?
  • have some cool graphing functionality so that you can see progress on weight training or weight loss?
  • It would be really cool to have the ability to tie into some of the other apps such as MyFitnessPal. I am not sure if they have an api you can tie into, but if they do, it would be a really cool feature.
  • Enter a previously defined database of exercises
  • Random workout generator. Tag exercises as "upper body" or "legs" and tap a button to generate a random upper body workout. something like that i think could be cool.
  • I would like to log in and build my weekly food and exercise schedule to. this should also pull from a bank or even history to help autocomplete items. Attached screen shot below.

Everything should be accessible from the website as well as the mobile interface.

[robbiedhickey]

Love the detail here. We needed some fleshed out use cases to really assess a data model. I'd like to approach this with the existing proposal in mind (Collections -> Items -> Events) and see if it makes sense in that context. If it doesn't then we can go back to the drawing board.

From what you've outlined, a Collection/Item/Event will definitely need to have a type. Not sure what level it should live at yet.

Collection/Item/Event Types

1. Tracking - this is the general purpose value/date that was discussed in #3.
2. Location
   • Additional fields: coordinates, photos, comments, rating
3. Task
   • Additional fields: assigned-to, due date, reminder, completion, comments
4. Exercise
   • Additional fields: reps, sets, weight, duration
5. Nutrition
   • Additional fields: calories, protein, fat, carbohydrates, meal, servings
6. Financial
   • Additional fields: amount, contact, due date, reminder, account

Financial is the only one where I could see us having trouble shoe-horning it into the existing model. This may be fine, because the types of reporting and input on financial data are generally going to be very different and more specific then what we are trying to curate with general tracking data.

Follow up questions

Can you think of any other higher-level categories/types that we would need to take into consideration? It seems like those 6 would cover most of our use cases.

At what level should the Type live? I'm leaning towards having it at the Collection, because based on the use cases we've discussed the Collection should basically define what type of data the user is wanting to track. Having it at the Event would require the user to select a type every time they input data and that would be cumbersome. Having it at the 'Item' level means that a Collection could have N types of data and would make reporting difficult.

Do you think the financial data you are wanting to track fits this hierarchical event model?