Main screen: making monitoring status legible at a glance

[viktoriasee]

A few related observations about the main screen that I think are worth discussing together rather than as separate issues, since they touch the same question: how quickly can a non-technical user tell whether they are actually protected?

1. State is text-only and easy to misread. The screen is almost entirely textual, so the colour of the status line is really the only quick signal — and it doesn't currently reflect whether an alert could actually be sent (filed separately as a bug). A prominent status symbol would let people confirm their state in a fraction of a second, without decoding which buttons are greyed out. For example:

   • a green check when monitoring is healthy;
   • a white cross on red when it is off;
   • a distinct warning state for "running, but no deliverable outcome".

2. Monitoring can be tested from the main screen, but not toggled. The rarely-used actions (test SMS, test call) live on the main screen, while the most consequential action — turning monitoring on or off — is buried in settings. It might be worth reconsidering that hierarchy: a clear on/off control on the main screen, with an unambiguous state, could be both more discoverable and safer.

3. No discreet persistent indicator. There is currently no low-key ongoing signal that KeepAlive is running (e.g. a persistent notification). For an app meant to run quietly for days, a discreet "I'm watching" indicator would both reassure the user and reduce the chance of monitoring being silently off without anyone noticing.

On a related note — the input method for the time fields has already been raised separately in #185 (discrete step control instead of free text entry). That's about how values are entered; the point above is about how the resulting state is displayed. Cross-linking here for context.

I don't want to over-specify the design here — these are observations from looking at the current screens, and I'd value your view on which of them fit the project's direction and constraints. Happy to break any of them out into concrete issues if useful.

[keepalivedev]

Good timing — two of the observations here have partly shipped since you wrote this: "running but undeliverable" is now its own warning-colored "No Alert Recipient" state instead of green (#201), and the timestamp/countdown simplification landed via #189/#206. On the three main points:

1. Status symbol: agreed — a glanceable icon (check / warning / cross) on top of the color would help exactly the audience that shouldn't need to read. Happy to take this as a concrete issue.
2. On/off toggle on the main screen: hesitant. For a safety app, putting the most consequential action one accidental tap from the reassurance screen cuts both ways — discoverability up, but so is the chance of silently turning protection off, which is exactly the failure class we've spent the last two weeks closing. The status text now states clearly when monitoring is off, and the Restart Monitoring button already covers the on-direction from the main screen. I'd keep off-switching deliberate, in Settings.
3. Persistent indicator: worth considering as an opt-in setting, default off, with two honest caveats: on Android 14+ users can swipe away even "persistent" notifications, so it's a soft signal; and a permanent notification is the kind of noise that trains people to ignore this app's notifications — costly for the one that matters. The background self-checks that landed in Check SEND_SMS permission from the background alarm cycle #200 attack the same worry ("is it silently off?") from the detection side instead.

If you want to break out the status icon (and the opt-in indicator, if the caveats don't kill it for you) as issues, please do.