Re-think list view(s)

[bvaughn]

Rather than homogenous lists of all foods, exercises, etc. it would be nice to show a heterogenous list that shows each day as a card, beginning with sleep, and then continuing with interleaved food, symptoms, and exercise.

Example

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Tuesday, January 2, 2018      ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Slept 8hrs, awoke twice.      ┃
┠───────────────────────────────┨
┃ 8:00am Ate cereal             ┃
┠───────────────────────────────┨
┃ 8:05am Drank soy latte        ┃
┠───────────────────────────────┨
┃ 10:00am Energy level high     ┃
┠───────────────────────────────┨
┃ ...and so on...               ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Pros

• The interleaved format might make it easier to spot certain types of patterns, and the cards could be used to highlight missing entries (eg. no sleep entry, fewer than 3 food entries, etc.).
• I could get rid of the individual list views entirely. Perhaps either relying on a summary-like view if I want to filter only specific types of data.
• The new-entry floating action button could pop out a couple of options (one for each data-entry type) when touched. The main button could conver to an "x" to undo the spring. (This is how several of the material UIs work.)
• I could color-code day-cards based on symptoms (to make it easier to visually scan for "good" days and "bad" days).

Cons

• This layout would make react-virtualized integration more difficult. But perhaps I don't actually need to window the displayed elements, if I only show the most recent 1-2 weeks? If pagination was necessary, week boundaries seem like a reasonable place to do it.
• The day "cards" might get long (and possibly hard to view on a single mobile screen). Perhaps this can be mitigated through the use of symbols to reduce the amount of text required.

[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