Proposal: an opt-in Simple view — three scores up front, each opening the wearer's own data behind it #2463

Summary

A proposal for an opt-in Simple view: a presentation mode that shows NOOP's existing numbers in a structure closer to what WHOOP wearers already know — three scores up front, and tapping one explains your data behind it. No new metrics, no new calculations; only what is shown, where, and in what order.

This is filed to agree direction before any code, since it touches both platforms and several screens. It is written to be delivered in small, separately reviewable steps.

The problem

NOOP computes more than most wearables, and shows nearly all of it at once:

• More lists 27 destinations on iOS (StrandiOS/App/RootTabView.swift: What Moves You, Intelligence, Insights, Explore, Compare, Live, Workouts, Lift Log, Health, Lab Book, Stress, Breathe, Intervals, Rhythm, Your Data Fused, Apple Health, Mi Band, Data Sources, Backup & Sync, Shortcuts Export, NOOP Limitations, Alarms, Automations, Test Centre, Siri & Shortcuts, Power saving, Settings).
• Today composes from 11 section kinds (Strand/Data/TodayLayoutPrefs.swift).
• The most useful explanation NOOP has — why today's Charge is what it is — is not on the default screen at all (below).

A wearer coming from WHOOP, or comparing against a watch app, meets this density and — as happened while filing this — concludes the app is "tracking things wrong" when the numbers are right and the recipes simply differ (see #1545). Clarity is a correctness issue here, not only a taste one.

Reference: how WHOOP structures it

From WHOOP's own descriptions of its app, the structure (not the visual design) is:

• Three dials front and centre — Sleep, Recovery, Strain — on an overview whose other cards are customisable and reorderable.
• Tap a dial for a deep dive into that score.
• Recovery is explained by its inputs: heart rate variability, resting heart rate, sleep and respiratory rate, each against the wearer's own baseline.
• Sleep performance is explained by its parts: sufficiency (hours versus need), consistency, efficiency and stress.

Sources: WHOOP — the Overview screen, WHOOP Basics, WHOOP Sleep.

This proposal borrows that information architecture only. NOOP is clean-room; nothing here uses WHOOP's assets, artwork or naming, and all UI stays on NOOP's design tokens.

What already exists and is under-used

Most of what this needs is built:

• The Charge driver breakdown. StrandAnalytics/ChargeDrivers.swift computes the per-driver contribution (HRV, resting HR, respiratory rate, sleep, skin temperature, each against baseline) from the identical inputs the score uses. It is wired into the classic Today (showChargeBreakdown, Strand/Screens/TodayView.swift) but not the default Liquid Today — so on the default screen the one explanation a WHOOP user expects first is unreachable.
• Rest's parts. Sleep performance, consistency, need and debt are already stored per day (Repository's sleep_performance / sleep_consistency / sleep_need_min / sleep_debt_min series).
• Effort's inputs. Time in HR zones, workouts and steps per day are already computed for the Effort dossier and workout detail.
• A familiar Effort axis. Settings already offers Effort on a 0–21 scale alongside 0–100 (UnitPrefs.effortScaleKey, The Effort scale setting doesn't seem to be applied to the Today screen. (UI) #45).

The tap problem on the rings today

On Liquid Today each ring cell has two targets: the ring opens that metric's detail (#1995), and the label beneath it — the only element carrying a › chevron — opens the scoring guide, which explains what the score means in general. The visible affordance therefore leads to the generic explainer, and the path to the wearer's own data has no affordance at all. #2035 asks for fewer taps into the insight; this is the underlying reason it feels that way.

Proposal

A Simple view toggle (Settings, both platforms), off by default initially.

1. Today

Only:

• The three rings (Charge / Effort / Rest), each whole cell tappable into its own detail page.
• One sentence of synthesis (the existing Synthesis line).
• Today's workouts.

Everything else remains available through the existing customisation, not deleted.

2. One detail page per ring — the wearer's data first

Each ring opens a page that answers "why is my number this today", in this order:

• Charge — the score; the driver breakdown from ChargeDrivers (HRV, resting HR, respiratory rate, sleep, skin temp, each shown against the wearer's own baseline with a direction); a 7-day bar of Charge.
• Effort — the score on the wearer's chosen scale; time in zones; the day's workouts and their share; a 7-day bar of Effort. A one-line note naming the Effort recipe in use (Edwards or Banister) and what it under-counts, per the discussion in Better accuracy on weightlifting/gym workout #1545.
• Rest — the score; hours versus need, consistency, efficiency, stages; sleep debt; a 7-day bar.

The general explainer moves to a small info button on each page, so it is one tap away but no longer the default destination.

Optional, if Coach is configured: an "Ask Coach about this" entry on each page that opens Coach with that page's context, so an AI explanation is available where the chart is rather than only in the Coach tab (related: #1862, #762).

3. More

About six entries — Workouts, Health, Journal, Alarms, Data & Backup, Settings — plus "Show all features", which opens today's full list unchanged. Nothing is removed. (#1573 is the broader Settings/More reorganisation; this only chooses what Simple view shows first.)

Guardrails

• Presentation only. Simple view composes existing views and resolvers; it must not recompute any figure. Per the rule that two readouts of one fact must not disagree, each number on a Simple page comes from the same resolver the full view uses — asserted by a test on the resolver, not by counting call sites.
• Parity. Both platforms, feature-level (Design iOS and Android different - alignment possible? #2218 is the general version of this concern).
• Design tokens only, as everywhere else.
• No scoring changes. Recipe choices (Better accuracy on weightlifting/gym workout #1545) are discussed separately; Simple view only names the recipe in use.

Suggested phasing

1. The toggle, and Simple Today — wire the whole ring cell to the detail page; move the guide behind an info affordance.
2. The Charge detail page with the existing driver breakdown (the highest-value, most-reused piece).
3. Effort and Rest detail pages.
4. Simple More.

Each step is shippable and reviewable on its own.

Open questions

1. Is a separate mode wanted at all, or should (1) and (2) simply become how the default Liquid Today behaves? The ring-tap and missing-breakdown problems exist regardless of any toggle.
2. Should the Charge breakdown on Liquid Today be treated as a parity gap with classic Today and fixed independently of this proposal?
3. Any objection to the "Ask Coach about this" entry, given Coach is the one feature that leaves the device?

Happy to prototype phase 1 if the direction is agreeable.