Re-think list view(s) about personal-logger

[bvaughn]

I wonder if I should combine this with issue #27 and re-think the data model. Maybe rather than days being a fuzzy thing, a collection of items that share the same date, maybe Day should be a part of the domain model, with all entries belonging to a Day.

And maybe new entries should be added to a Day from the day card (instead of a floating action button)? Although I don't know if this might make data-entry more cumbersome. Maybe there should still be a shortcut FAB for adding to the current day (or JIT creating one if necessary).

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Tuesday, January 2, 2018          ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Slept 8hrs, awoke twice.          ┃
┠───────────────────────────────────┨
┃ 8:00am Ate cereal                 ┃
┠───────────────────────────────────┨
┃ 8:05am Drank soy latte            ┃
┠───────────────────────────────────┨
┃ 10:00am Energy level high         ┃
┠───────────────────────────────────┨
┃ [+ food] [+ exercise] [+ symptom] ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

[MikeTheCanuck]

Interesting questions. I think the question of whether Day is an attribute or a first-class domain member. I ask myself, “what is the goal of the app - are you trying to identify the Day in which bad allergy events occur? Or are you more interested in identifying the influencing events (sleep, food, activity) that correlate most strongly with the allergic effect? In my mind, the potential Causes should be first class data objects, and in that view, Day is just a piece of metadata to help properly link possible Cause to possible Effect.

The reporting layout, while a significant piece of engineering in any data app, I try to avoid constraining the data model to one particular reporting design.

The more I think about it, the original “all items interleaved” approach might make it hard for a non-expert-User (like your doctor) to quickly associate data that *should be associated.

Ideally in this kind of application, it would be great to present two timelines: one for potential causes and the other for potential effect - and then allow the user to offset one timeline from the other so that they can form their own theories about whether and how often/strongly a potential cause precedes a potential effect by some rough window of time.

I don’t expect that it should be too important to be exact (i.e. each human’s reaction times - and precision on capturing the time of each events - can vary - I might react to gluten within a couple of hours, someone else might notice a different symptom a day or two later).

I think it would be more important to be able to see the pattern - e.g. do most episodes follow a certain food by 8-12 hours, or follow a poor sleep by 1-2 days? No idea what the intervals should be - I would like to be able to drag the causes timeline back smoothly until I see or don’t see a pattern (and the only indication of hours is hour or two-hour increments out of the central part I’m looking at - minimise distraction when I’m doing heavy cardio genitive work of looking for patterns).

Wow, that was a bit much - and likely would benefit from a mock-up or two to illlustrate what I see in my head - if you’re even interested in exploring this alternative, that is.

[bvaughn]

Please feel free to share any mockups you'd like to, sure thing.

[bvaughn]

Maybe I could use a layout similar to these "bullet journal" apps in the iOS store? I particularly like the UI style of Bullet Diary by Jin W Roh

I also like the daily average ranking shown on the monthly view of Perspective - Daily Journal by Blinky