Reason behind the Daily Work Popup
Problem
The daily work area popup is currently tied too closely to the first app open for a calendar day. If the app opens and the relevant work area screen is not reached, the popup can be skipped for that day even though the user has not actually seen it.
This makes the daily prompt unreliable for users who enter the app through a different flow, leave before reaching the work area screen, or resume the app later in the day.
Target Consumer
The primary consumer is the mobile app user who should see the daily work area prompt once per day when they reach the relevant work area screen.
The secondary consumer is the app code that decides whether to show or suppress the popup.
Current Friction
The app appears to treat “first app open today” as enough proof that the daily popup opportunity has been consumed. That is the wrong observable event. The meaningful event is that the daily work area popup was actually shown for that day.
Goal
The daily work area popup appears the first time the relevant screen is reached on a given local day, unless it has already popped up for that same local day.
First Useful Scope
The first useful version changes only the popup eligibility behavior:
- Track whether the daily work area popup has actually been shown for the current local day.
- Check that state when the relevant screen becomes active.
- Show the popup if no shown record exists for the current local day.
- Mark the popup as shown only after it is actually presented.
- Keep the existing popup content, visual design, and user flow unchanged.
Non-Goals
- Redesigning the popup UI.
- Changing the work area screen layout.
- Adding new reminder schedules or notifications.
- Syncing the popup-shown state to the server.
- Changing session, telemetry, weather, activity, or prediction behavior.
- Adding analytics unless already present for this popup.
Consumers And Use Cases
Consumer: Mobile app user Use case: Opens the app in the morning but does not visit the work area screen until later. Outcome: The popup still appears when the user first reaches that screen later the same day.
Consumer: Mobile app user Use case: Visits the work area screen more than once in the same day. Outcome: The popup appears only on the first qualifying visit that day.
Consumer: Mobile app code Use case: Determines whether the popup should appear on screen focus. Outcome: The decision is based on the last date the popup was shown, not the last date the app launched.
Requirements
- The app must define popup eligibility by local calendar day.
- The app must persist the most recent local date on which the daily work area popup was shown.
- The relevant work area screen must check popup eligibility when it becomes active or focused.
- The popup must appear if the persisted shown date is missing, invalid, or different from the current local date.
- The popup must not appear again after it has already appeared for the current local date.
- The persisted shown date must be updated only when the popup is actually presented.
- App launch alone must not suppress the popup for the day.
- Existing popup copy, controls, dismissal behavior, and navigation must remain unchanged.
- If local persistence fails, the app should fail open by allowing the popup rather than permanently suppressing it.
Acceptance Criteria
- If a user opens the app today and does not navigate to the work area screen, then later navigates to that screen today, the daily work area popup appears.
- If a user reaches the work area screen and the popup appears today, navigating away and returning to that screen today does not show the popup again.
- If a user reaches the work area screen tomorrow, the popup can appear again even if it appeared today.
- If the stored popup date is missing, corrupt, or unreadable, the screen is eligible to show the popup.
- If the app is opened multiple times in the same day before the user reaches the work area screen, those app opens do not mark the popup as shown.
- Existing work area popup content and dismissal behavior are unchanged.
Constraints
- The change should be small and local to the popup eligibility path.
- The app already uses local device persistence for small state, so no new backend dependency is needed.
- Date semantics should use the device’s local calendar day because the popup is user-facing daily behavior.
- The implementation should be testable without depending on real wall-clock time.
Risks And Edge Cases
- Time zone changes or daylight saving boundaries can make a local date differ from previous expectations.
- Writing the shown date before the popup is actually presented could recreate the current bug.
- A screen focus effect can run multiple times in quick succession, so the popup guard must avoid duplicate presentation.
- Persistence failures should not permanently hide the popup.
Deferred Questions
- Should the popup shown state ever be reset manually from a debug or settings screen? No for v0.
- Should this behavior eventually produce analytics events? Only if analytics are already part of the popup flow.