feat(pair): the first screen answers both questions it is asked - #34
Conversation
Someone landing on app.ftw.energy is deciding two things at once, and the screen answered neither well. Whether to install: the instruction was a strip at the foot of the app, shown once per device and never again. On iOS installing is not a nicety — a tab's storage is evicted after a week away and notifications only reach an installed app — so it is now said on the screen someone actually lands on, with the two taps named and the reason given in terms of what they get. It stays put while they are setting up rather than vanishing after one sighting, and says nothing at all to a phone already installed. Which way in is theirs: "Scan the code" was a filled primary button and "I've set this up before" was a line of small text under it, which reads as one real way in and one afterthought — and reads wrongest for the person coming back to a phone whose storage was wiped, who is exactly who the second one is for. They are now two cards of the same weight, each saying who it is for. Neither is dressed as the recommendation, because which one fits depends on something only the person holding the phone knows. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
ftw-webapp | cf17ba6 | Aug 10 2026, 01:52 PM |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cf17ba6642
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {#if inSafariTab} | ||
| <!-- Said here, on the screen someone actually lands on, and not as a | ||
| strip at the foot of the app. On iOS this is not a nicety: a tab's | ||
| storage is evicted after a week away, and notifications only reach | ||
| an installed app — so a phone that never installs loses its cache | ||
| on exactly the schedule that makes the app feel slow, and can | ||
| never be told its car has finished charging. iOS gives a page no | ||
| way to open the Share sheet, so naming the two taps is the whole | ||
| of what can honestly be done. --> | ||
| <div class="install"> |
There was a problem hiding this comment.
On a first visit in an iOS Safari tab, when ftw.install-hint is absent, this card renders while the unconditional <InstallHint /> in App.svelte also opens and marks the hint seen. The initial pairing screen therefore shows two nearly identical installation instructions—the new inline card and the legacy footer banner—rather than moving the instruction to the landing screen as intended; conditionally hide the legacy hint while Pair is displayed.
Useful? React with 👍 / 👎.
1 participant
Fredrik: "när man går in på app.ftw.energy första gången ska man tydligt få instruktioner om add app to homescreen. och scan code och I've logged in before ska ju se lika tydliga ut."
Both were real. Someone landing on the site is deciding two things at once, and the screen answered neither well.
Whether to install
The instruction was a strip at the foot of the app, shown once per device and never again (
InstallHint). On iOS that is not a nicety — a tab's storage is evicted after a week away, and notifications only reach an installed app — so a phone that never installs loses its cache on exactly the schedule that makes the app feel slow, and can never be told its car finished charging.It is now a card on the screen someone actually lands on: the two taps named (iOS gives a page no way to open the Share sheet, so naming them is the whole of what can honestly be done), and the reason in terms of what they get rather than storage policy. It stays while they are setting up instead of vanishing after one sighting, and says nothing at all to a phone already on the home screen.
Which way in is theirs
"Scan the code" was a filled primary button; "I've set this up before" was a line of small text under it. That reads as one real way in and one afterthought — and reads wrongest for exactly the person the second one exists for: someone coming back to a phone whose storage was wiped. (Which is how Fredrik hit "nothing saved for this passkey" in the first place.)
They are now two cards of the same weight, each naming who it is for — "First time here" / "Open your home again with your passkey". Neither is dressed as the recommendation, because which one fits depends on something only the person holding the phone knows.
InstallHintstays as-is for the rest of the app (a phone already paired, browsing in a tab). Three new tests pin the structure: both ways offered as equal buttons with neither styled primary, the install card present on an iOS Safari tab with its two taps named, and absent when standalone. Four App tests updated for the button's new label.npm run verify: 804 passed.🤖 Generated with Claude Code