The check-in notification, its actions, and knowing when to stop asking #26

New Issue

Closed

opened 2026-08-18 15:06:56 -05:00 by null · 0 comments

null commented

2026-08-18 15:06:56 -05:00

Owner

§30's flow: a heads-up a few days before, a check-in on the predicted day, another the day after — and then, crucially, it stops:

Do not nag forever. Eventually: "We'll stop checking for now. Log your period whenever it begins." The internal prediction may continue updating.

That last sentence is the design. The app stops asking without stopping learning.

Build:

the check-in notification with Started and Not yet actions, so the common answer costs no taps at all
"Yes, today" / "Yes, yesterday" / "Choose date" / "Not yet" on the follow-up (§30)
a stopping rule after a bounded number of unanswered or "Not yet" check-ins, with the final message above
a deep link into the in-app check-in rather than just opening the app

The privacy trap, from §31: if the user taps Started from the lock screen, that action must not reveal anything on its way through — an action label is visible text, and "Started my period" on a lock screen defeats Discreet mode entirely. Label them so they mean nothing out of context.

Also §31: never include cycle data in a notification analytics payload. There is no analytics here yet, and this is the moment the temptation appears.

Verify: a test drives the check-in sequence and asserts it stops after the bounded number with the §30 message; the actions are labelled so they carry no health information; and answering "Not yet" from the notification produces the same NotYetObservation the in-app button does.

§30's flow: a heads-up a few days before, a check-in on the predicted day, another the day after — and then, crucially, it stops: > Do not nag forever. Eventually: "We'll stop checking for now. Log your period whenever it begins." The internal prediction may continue updating. That last sentence is the design. The app stops *asking* without stopping *learning*. Build: - the check-in notification with **Started** and **Not yet** actions, so the common answer costs no taps at all - "Yes, today" / "Yes, yesterday" / "Choose date" / "Not yet" on the follow-up (§30) - a stopping rule after a bounded number of unanswered or "Not yet" check-ins, with the final message above - a deep link into the in-app check-in rather than just opening the app The privacy trap, from §31: if the user taps **Started** from the lock screen, that action must not reveal anything on its way through — an action label is visible text, and "Started my period" on a lock screen defeats Discreet mode entirely. Label them so they mean nothing out of context. Also §31: never include cycle data in a notification analytics payload. There is no analytics here yet, and this is the moment the temptation appears. Verify: a test drives the check-in sequence and asserts it stops after the bounded number with the §30 message; the actions are labelled so they carry no health information; and answering "Not yet" from the notification produces the same `NotYetObservation` the in-app button does.