M1-03: Design pass — static UI on sample data #3

New issue

Open

opened 2026-08-08 20:03:43 -04:00 by agent · 0 comments

agent commented

2026-08-08 20:03:43 -04:00

Member

First visual pass, in Compose, on sample data. No audio anywhere.

Screens

The same four as iOS:

Memo list — the main view. Each row is a memo and its sync status, using the three states Wes
described: a cloud with a line through it (not synced), a cloud with circular arrows (syncing), a
cloud with a check (synced). In M1 everything is permanently not-synced; the states exist so the
design is right, not because anything syncs.
Empty state — first launch.
Active recording — the bottom bar: audio levels, elapsed time, a stop button.
Settings — a stub.

This is not a port of the iOS screens

"I would much prefer system standards for UI over having our own custom special UI. Because
people know how to use their platform." That rule is what makes an iOS pixel-port the wrong
answer. Material 3 components, Android navigation patterns, a FAB where a FAB belongs. The two apps
should feel like the same product and like native citizens of different platforms — shared
iconography and the amethyst purple, not shared layout.

The archived v2 app in ~/Projects/_archive/stash-saas is kept for the iconography.

The open question: dynamic colour

Material You will recolour the whole app from the user's wallpaper if it is allowed to. That is the
Android system standard and the rule above points straight at it — but it also means the amethyst
purple that identifies Stash disappears on most phones.

Options are: full dynamic colour, a fixed amethyst scheme, or dynamic with amethyst as the seed and
fallback. Wes's call at the planning checkpoint. Do not decide it in code.

Compose Previews, not a design tool

Same reasoning as iOS: @Preview renders the real components in light and dark and updates as fast
as they are typed. Anything mocked elsewhere is a lower-fidelity picture that drifts from the code.

Done when

Wes has it on the Pixel, takes screenshots, and directs tweaks from there. Expect iteration rather
than one clean pass.

Milestone 1 of Stash for Android, mirroring stash-ios M1. M1 is a functioning app on the test
device with no sync at all — record voice memos reliably and get them off the device by hand.
Sync arrives in M3.

Test device is a Pixel 6 (Tensor G1) borrowed from a friend, until something better turns up.
Stock Android, so no OEM battery-killer behaviour to fight — worth remembering that a phone from
another manufacturer may not be as forgiving about background work.

Translation of Stash/stash-ios#3. Where the platform forces a different answer this issue says so; where it
does not, the iOS issue is the fuller statement of intent and should be read alongside this one.

Working agreement for every issue in this repo: feature branch, tested before the PR opens
(on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs
update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and
split it.

First visual pass, in Compose, on sample data. No audio anywhere. ## Screens The same four as iOS: - **Memo list** — the main view. Each row is a memo and its sync status, using the three states Wes described: a cloud with a line through it (not synced), a cloud with circular arrows (syncing), a cloud with a check (synced). In M1 everything is permanently not-synced; the states exist so the design is right, not because anything syncs. - **Empty state** — first launch. - **Active recording** — the bottom bar: audio levels, elapsed time, a stop button. - **Settings** — a stub. ## This is not a port of the iOS screens **"I would much prefer system standards for UI over having our own custom special UI. Because people know how to use their platform."** That rule is what makes an iOS pixel-port the wrong answer. Material 3 components, Android navigation patterns, a FAB where a FAB belongs. The two apps should feel like the same product and like native citizens of different platforms — shared iconography and the amethyst purple, not shared layout. The archived v2 app in `~/Projects/_archive/stash-saas` is kept for the iconography. ## The open question: dynamic colour Material You will recolour the whole app from the user's wallpaper if it is allowed to. That is the Android system standard and the rule above points straight at it — but it also means the amethyst purple that identifies Stash disappears on most phones. Options are: full dynamic colour, a fixed amethyst scheme, or dynamic with amethyst as the seed and fallback. **Wes's call at the planning checkpoint.** Do not decide it in code. ## Compose Previews, not a design tool Same reasoning as iOS: `@Preview` renders the real components in light and dark and updates as fast as they are typed. Anything mocked elsewhere is a lower-fidelity picture that drifts from the code. ## Done when Wes has it on the Pixel, takes screenshots, and directs tweaks from there. Expect iteration rather than one clean pass. --- *Milestone 1 of Stash for Android, mirroring `stash-ios` M1. M1 is a functioning app on the test device with **no sync at all** — record voice memos reliably and get them off the device by hand. Sync arrives in M3.* *Test device is a **Pixel 6** (Tensor G1) borrowed from a friend, until something better turns up. Stock Android, so no OEM battery-killer behaviour to fight — worth remembering that a phone from another manufacturer may not be as forgiving about background work.* *Translation of `Stash/stash-ios#3`. Where the platform forces a different answer this issue says so; where it does not, the iOS issue is the fuller statement of intent and should be read alongside this one.* *Working agreement for every issue in this repo: feature branch, tested before the PR opens (on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and split it.*

agent added the

area/ui

milestone/M1

type/feature

labels

2026-08-08 20:03:43 -04:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Stash/stash-android#3

No description provided.

Rows
Columns