Repository navigation
Activity Start Flow Simplification Proposals
Status (2026-08-26): Historical. See the status note in Activity start flow analysis; the source chooser and plan pickers this document proposes replacing are gone, replaced by the start hub.
Status: Proposal, not the current implemented flow. Current behavior source: Recording of activity and Activity and training plans. Implementation map: Feature map.
This document explains the proposed improvements for making activity recording, manual activity logging, and planned-workout starts faster and easier to understand.
The core product goal is:
When the user taps a button, the next screen should match the intent of that button.
Today, many activity-related actions open the same generic Activity Entry source chooser. That keeps the code centralized, but it adds extra screens and makes the user decide again what they already meant to do. The sections below describe intended improvements, not behavior that should be assumed to exist in the app today.
Most activity actions navigate to the same route:
manual_entry/activity
That screen starts in source-selection mode, so the user must choose what kind of activity action they want:
- Create manual activity.
- Create from existing plan.
- Record GPS activity.
- Import route file.
This is inefficient when the previous button already told us the user's intent.
Example:
Dashboard Start -> Activity Entry -> Choose "Record GPS activity"
The user tapped Start, but the app still asks what they want to do.
Support direct entry intents, for example:
manual_entry/activity?mode=record
manual_entry/activity?mode=manual
manual_entry/activity?mode=plan
manual_entry/activity?planId=abc123
manual_entry/activity?activityTypeId=running
Then each button can open the right state immediately.
| User Action | Current Flow | Proposed Flow |
|---|---|---|
| Start workout | Open source chooser, then choose record | Open recording setup directly |
| Add manual activity | Open source chooser, then choose manual | Open manual form directly |
| Use a plan | Open source chooser, choose plan source, choose type, choose plan | Open selected plan directly |
| Import route | Open source chooser, then choose import | Open import/review directly |
This does not require splitting the whole feature into many new screens. The existing Activity Entry feature can remain the central implementation. The route simply carries the user's intent into the screen.
The GPS recording path has two start-like actions:
Dashboard Start
-> Record GPS activity
-> Go to activity screen
-> Start
The confusing part is Go to activity screen. It feels like a start action, but it only opens an idle recording dashboard. The user must then tap Start again.
When GPS permissions and location fix are ready, the setup screen's primary button should start the recording immediately.
Proposed flow:
Start workout
-> Recording setup
-> Start
-> Active recording dashboard
| Flow | Current Minimum Taps | Proposed Minimum Taps |
|---|---|---|
| GPS recording from dashboard | 4 | 2 or 3 |
| GPS recording after direct route support | 3 | 2 |
The idle dashboard can still exist internally for edge cases, cancellation, dashboard editing, or GPS preview. The key change is that it should not be a required extra stop in the common start flow.
Planned workouts are visible in the Activities overview, but they are display-only.
Current user experience:
User sees planned workout
-> Cannot start it there
-> Opens Activity Entry
-> Chooses "Create from existing plan"
-> Chooses activity type
-> Chooses the same plan again
The app shows the right object but does not let the user act on it.
Turn each planned workout row into an action surface.
Possible actions:
| Planned Workout State | Suggested Action |
|---|---|
| Not completed, live-recordable activity | Start |
| Not completed, better as manual entry |
Use plan or Log
|
| Completed | Completed/read-only state |
| Missing permissions | Permission action or disabled state with explanation |
Activities overview
-> Tap planned workout row or Start button
-> Activity Entry opens with that plan already selected
-> User starts recording or reviews prefilled activity
| Flow | Current Minimum Taps | Proposed Minimum Taps |
|---|---|---|
| Use visible planned workout | No direct path | 1 to open/start |
| Use plan from dashboard/activity flow | 5 | 2 |
Planned workouts already have strong context: activity type, title, time, duration, and completion state. The row is the best place to start from because the user has already found the exact workout.
The planned workout flow always asks the user to choose:
Plan source
-> Activity type
-> Specific plan
That is useful when there are many plans, but wasteful when there is only one obvious option.
After planned workouts are loaded:
- If there is only one planned activity type, skip the activity-type picker.
- If there is only one plan for that activity type, apply it immediately.
- If one plan is scheduled near the current time, place it first or preselect it.
- If there are multiple reasonable choices, keep the picker.
Current:
Create from existing plan
-> Choose Strength Training
-> Choose "Upper Body A"
-> Manual form
Proposed when there is only one plan:
Create from existing plan
-> Manual form prefilled with "Upper Body A"
| Scenario | Current | Proposed |
|---|---|---|
| One activity type, one plan | User still chooses both | Apply plan immediately |
| One activity type, many plans | User chooses type, then plan | Skip type, choose plan |
| Many activity types | User chooses type, then plan | Same as today |
This is a low-risk improvement because it preserves the current screens when choices are genuinely needed. It only removes screens where the user has no meaningful decision to make.
The dashboard has quick actions:
LogStart
But Start opens the generic Activity Entry source chooser. From there, the user can choose manual entry, planned workout, recording, or route import.
That creates a mismatch:
Button says: Start
Screen asks: What source do you want?
Make dashboard actions map to clear user intents.
Suggested dashboard model:
| Dashboard Action | Destination |
|---|---|
Start workout |
Recording setup directly |
Log |
Manual logging options or manual-entry hub |
| Planned workout row/card | Selected planned workout |
| Overflow or secondary action | Import route, use plan, advanced options |
Dashboard
-> Start workout
-> Recording setup
-> Start
For manual logging:
Dashboard
-> Log
-> Choose metric or activity manual form
For plans:
Dashboard or Activities overview
-> Planned workout
-> Start or use selected plan
Users should not need to understand the app's internal source model. They should see actions that match how they think:
- "I want to start exercising now."
- "I want to log something I already did."
- "I want to do this planned workout."
- "I want to import a file."
This creates the foundation. Without direct routes, every improvement still has to pass through the generic source chooser.
Expected result:
Dashboard Start -> Recording setup
Activities Add -> Manual activity form
Plan row -> Selected plan
Change the dashboard Start action so it opens the recording setup directly with the preferred live-recordable activity.
Expected result:
Start -> Recording setup
Make the setup primary button start GPS recording immediately once permissions and location fix are ready.
Expected result:
Start -> Recording setup -> Active recording
Add actions to planned workout rows and route selected plans into Activity Entry.
Expected result:
Tap planned workout -> Selected plan opens directly
Skip unnecessary plan picker screens when there is only one valid option.
Expected result:
Use plan -> Prefilled form when only one plan exists
Once the direct flows exist, rename and arrange the quick actions so they match behavior:
Start workoutLog- Planned workout action
- Optional overflow for imports/advanced actions
The ideal common flows should look like this:
flowchart TD
A[Dashboard] -->|Start workout| B[Recording setup]
B -->|Start| C[Active recording]
C -->|Finish| D[Review draft]
D -->|Save| E[Health Connect]
A -->|Log| F[Manual log options]
F -->|Activity| G[Manual activity form]
G -->|Save| E
H[Planned workout row] -->|Start or Use plan| I[Selected plan flow]
I -->|Record or Save| E
The main win is not just fewer taps. It is that each path becomes easier to predict.
Generated from docs/proposals/activity-start-flow-proposals.md. Edit it there; changes made here are overwritten.
This wiki mirrors the Markdown in Hale-MTU/OpenVitals on every push to main.
Features
- Features
- Achievements
- Activity And Training Plans
- Activity Metrics
- Apple Health Import
- Beverage Logging And Caffeine
- Bluetooth LE Sensors
- Body Energy
- Body Metrics
- CoMaps Navigation Context
- CSV Import
- Cycle Tracking
- Daily Readiness
- Elevation Correction
- Feature Map
- FIT Files Import
- Food Logging
- GPX/KML/KMZ/TCX Route Import
- Health Connect Metrics Dashboard
- Health Report Export
- Heart And Vitals
- Heart Rate Recovery
- Home Screen Widgets
- Hydration
- Manual Entry Of Metrics
- Medical Records
- Metric Detail Customization
- Mindfulness
- Non Health Connect Metrics Dashboard
- Nutrition
- Offline Maps Support
- Onboarding And Permissions
- Preloaded Beverage Nutrition Reference
- Privacy, Support, And Diagnostics
- Recording Of Activity
- Reminders
- Settings And Preferences
- Sleep Score And Recovery
- Sleep Tracking
- Statistics
- Sync With Another Phone
How-to
App
- App Guide
- FAQ
- Getting Started
- Health Connect
- Install
- Local And Connected Editions
- Permissions
- Privacy
- Screenshots
- Support
Reference
- Design Reference
- Reference
- Design Guidelines for Offline & Sync
- OpenVitals UI Notes
- Reference: Data Capture
- Reference: Data Display
- Reference: Health Connect Matchmaking
- Reference: Health Connect Onboarding
- Reference: Health Connect Permissions
- Reference: Health Connect UX
- Reference: Promoting Health Connect
Engineering
- Code Analysis
- Engineering
- Flutter ↔ Kotlin test-parity matrix
- apple-health-import
- Architecture
- body-cycle-recovery
- Design system conformance
- Development
- Feature Playbook
- Flutter -> Kotlin test parity: domain/data/core/contract/state/navigation/di/bootstrap/l10n/widget_test
- Flutter → Kotlin test-parity matrix: features section
- Flutter → Kotlin test-parity matrix: ui / goldens / integration / fixtures
- Flutter-to-Kotlin test-parity matrix — dashboard + devicesync
- manual-entry
- Translations
Proposals
- Proposals
- Activity Start Flow Analysis
- Activity Start Flow Simplification Proposals
- Caffeine Detail And Future Sleep Insights
- Cycle Tracking: Design and Status
- Medical Records Through Health Connect
- Medical Records: What Is Left
Releases
- OpenVitals 2.16.0
- OpenVitals 2.15.2
- OpenVitals 2.15.1
- OpenVitals 2.15.0
- OpenVitals 2.14.5
- OpenVitals 2.14.4
- OpenVitals 2.14.3
- OpenVitals 2.14.2
- OpenVitals 2.14.1
- OpenVitals 2.14.0
- OpenVitals 2.13.0
- OpenVitals 2.12.0
- OpenVitals 2.11.2
- OpenVitals 2.11.1
- OpenVitals 2.11.0
- OpenVitals 2.10.1
- OpenVitals 2.10.0
- OpenVitals 2.9.1
- OpenVitals 2.9.0
- OpenVitals 2.8.0
- OpenVitals 2.7.3
- OpenVitals 2.7.2
- OpenVitals 2.7.1
- OpenVitals 2.7.0
- OpenVitals 2.6.6
- OpenVitals 2.6.5
- OpenVitals 2.6.4
- OpenVitals 2.6.3
- OpenVitals 2.6.2
- OpenVitals 2.6.1
- OpenVitals 2.6.0
- OpenVitals 2.5.0
- OpenVitals 2.4.1
- OpenVitals 2.4.0
- OpenVitals 2.3.2
- OpenVitals 2.3.1
- OpenVitals 2.3.0
- OpenVitals 2.2.8
- OpenVitals 2.2.7
- OpenVitals 2.2.6
- OpenVitals 2.2.5
- OpenVitals 2.2.4
- OpenVitals 2.2.3
- OpenVitals 2.2.2
- OpenVitals 2.2.1
- OpenVitals 2.2.0
- OpenVitals 2.1.0
- OpenVitals 2.0.4
- OpenVitals 2.0.3
- OpenVitals 2.0.2
- OpenVitals 2.0.1
- OpenVitals 1.9.0
- OpenVitals 1.8.0
- OpenVitals 1.7.7
- OpenVitals 1.7.6
- OpenVitals 1.7.5
- OpenVitals 1.7.4
- OpenVitals 1.7.3
- OpenVitals 1.7.2
- OpenVitals 1.7.1
- OpenVitals 1.7.0
- OpenVitals 1.6.3
- OpenVitals 1.6.2
- OpenVitals 1.6.1
- OpenVitals 1.6.0
- OpenVitals 1.5.1
- OpenVitals 1.5.0
Project