jrdegreeff / health-portrait Goto Github PK

    Should there be some sync between updating `type` and `detail`, s.t. updating `type` must also require updating `detail`? Or is that a final problem not a beta one?

Originally posted by @wli-linda in #8 (comment)

• registration form
• add user form
• medication form
• insurance form
• entry form (#44)

related to and comes after #32

Though might just replace this middleware altogether once Entry and Medication/Contact syncs are in place?

Remaining:

• Date parsing & validation (basic ver. using Date casting implemented)
• Type in set validation? (frontend dropdown + middleware validation; not in data model)
• Relationship with Trend/Scale (??) --> add Condition & Scale to Entry data model?
• Get rid of procedure in types since there's no syncing with other concepts
• Allow setting specific time to entry? is that necessary complexity tho... --> revisit in final

Wireframes:

• maybe red button for delete?

We need something other than boilerplate on the homepage for beta

Currently when there is a validation error in the backend, the form entries all get reset which is a terrible UX. This could be improved by adding client-side validation capabilities and also by not reseting the form on failure.

I have a plan to accomplish this elegantly that will extract a common component from the navbar and header

either link to anchor in medication page, create separate page with just the medication, or include card in the table

• entry <--> medication
• entry <--> contact

also put more thought into semantics of each button and include in color scheme

• shaking charts
• small individual points
• points at the extremes are hard to see
• more thoughtfulness with colors

potentially same fix as #32

• Default date (today) for create form
• dropdown for type, condition
• dropdown for detail after sync?
• number input for scale (1-10) --> moved to #84
• potential date selector (choose from calendar) in form
• auto-populate type field
• change detail field label based on type selection

Currently the store-based alerts appear on top of the header which means they are not visible if you have scrolled down on the page. My plan to fix this is to remove them from the header component into a separate AlertBox component (still thinking about the name) that is fixed at the top of the viewport rather than the top of the page. Not sure if I will get to this for beta or final.

• Column spacing
• Throw edit-delete buttons into expandable portion

related to #30

• link to my account in header
• account name in navbar everywhere

• hint text
• flexible types
• valdiator functions
• visual indication of optional