aiko/denpa

Fork 0

Onboarding was designed for mobile only, so the desktop is a tablet by default #67

New issue

Closed

opened 2026-07-31 08:27:18 +00:00 by aiko · 2 comments

aiko commented

2026-07-31 08:27:18 +00:00

Owner

Found on 2026-07-31, running the desktop app through enrolment for the first time.

The design has no desktop

docs/design/denpa-receiver/README.md:183 opens § 3a with its own answer:

3a Onboarding — six 292×600 screens

292×600 is a phone. Every screen beneath that heading is specified at that size, and no desktop treatment is given anywhere in § 3a. Compare § 3b Settings, which says exactly what the desktop does — "Sheet occupies the right 600px of 1024; she stays visible at left". Onboarding got no equivalent sentence, and nobody noticed because onboarding is the least-seen screen in the product: you pass through it once per device and then never again.

What desktop gets instead

There is no desktop layout in the client at all. components/receiver/chrome-plan.ts:153-156:

export function chromePlan({ width, height }: Viewport): ChromePlan {
  const landscape = width > height && width >= TABLET_LANDSCAPE_MIN_WIDTH;
  const base = landscape ? TABLET_LANDSCAPE : MOBILE;

Two layouts, mobile and tablet-landscape. A desktop window is sorted into tablet-landscape and gets that row's onboarding: a 640px measure (ONBOARDING_MEASURE_PX) centred on a ground that fills the window. The desktop is a tablet as far as this codebase is concerned.

That is not wrong so much as undecided. It has simply never been looked at, because until #26 landed nobody had to pass through setup on the desktop.

The default window sits exactly on the breakpoint

TABLET_LANDSCAPE_MIN_WIDTH is 900 (chrome-plan.ts:28) and tauri.conf.json opens the window at 900×670. The comparison is >=, so the default window resolves to tablet-landscape by a single pixel. Drag it one pixel narrower and the whole app — setup and chrome both — flips to the phone layout.

Nothing is broken by this today. It is recorded because a layout that depends on the window being exactly its default width is a coin balanced on its edge, and the next person to change either number will not know they are touching two things.

`#49` did not cause this

856ed03 deleted onboarding's SCREEN_WIDTH/SCREEN_HEIGHT, which was right: on a device that constant drew setup as a 292×600 box floating in black, 60% of the Pixel's width. Removing it fixed Android and made the desktop's missing design visible for the first time, because the black around the card had been standing in for a frame.

The titlebar half is already fixed

Setup covered the window's only close, minimize and drag region — tauri.conf.json sets decorations: false for § 1b's pal, there is one window, and WindowReceiver drew its own titlebar while the onboarding branch did not. Fixed on issue/denpa-67-onboarding-titlebar; this issue is only the visual question.

Beyond onboarding: the chrome wants a redesign

Raised by the operator on 2026-07-31, and this issue is the first place it has somewhere to sit.

The two-layout table is the whole story of how this app handles size, and it was drawn from a design that described a phone and a tablet. The desktop was never a case in it. Now that the desktop is a first-class surface — it is the machine she runs on, and the one you are most likely to be sitting at — the chrome should be designed for it rather than sorted into the nearest existing row.

That is a larger piece of work than this issue, and it should not be smuggled in under a setup screen. What this issue asks for is the decision; the redesign itself wants its own ticket once there is an opinion to build from. Worth deciding at the same time:

whether desktop becomes a third layout, or whether tablet-landscape is genuinely right and only the breakpoint is wrong
what § 3a looks like at 900px and wider — the 640px measure was chosen for a tablet, not reasoned about for a monitor
whether the decorationless transparent window is right for every mode, or only for the pal that needed it
whether any of it is v1 at all: you enrol once, and it works today

Acceptance

§ 3a gets a desktop treatment in the design, or a recorded decision that tablet-landscape is deliberately what the desktop uses
The 900px breakpoint against a 900px default window is resolved, either by moving one number or by writing down why it is safe
If a third layout is added, chrome-plan.ts is where it goes — setup takes its size from that table and must not grow a constant of its own again (#49)
A follow-up ticket exists for the chrome redesign, with the decisions above settled enough to build from

denpa#49, denpa#66, ollvt-hermes-bridge#26, design § 3a / § 3b / § 1b

Found on 2026-07-31, running the desktop app through enrolment for the first time. ## The design has no desktop `docs/design/denpa-receiver/README.md:183` opens § 3a with its own answer: > ### 3a Onboarding — six 292×600 screens 292×600 is a phone. Every screen beneath that heading is specified at that size, and **no desktop treatment is given anywhere in § 3a.** Compare § 3b Settings, which says exactly what the desktop does — *"Sheet occupies the right 600px of 1024; she stays visible at left"*. Onboarding got no equivalent sentence, and nobody noticed because onboarding is the least-seen screen in the product: you pass through it once per device and then never again. ## What desktop gets instead There is no desktop layout in the client at all. `components/receiver/chrome-plan.ts:153-156`: ```ts export function chromePlan({ width, height }: Viewport): ChromePlan { const landscape = width > height && width >= TABLET_LANDSCAPE_MIN_WIDTH; const base = landscape ? TABLET_LANDSCAPE : MOBILE; ``` Two layouts, `mobile` and `tablet-landscape`. A desktop window is sorted into `tablet-landscape` and gets that row's onboarding: a 640px measure (`ONBOARDING_MEASURE_PX`) centred on a ground that fills the window. **The desktop is a tablet as far as this codebase is concerned.** That is not wrong so much as undecided. It has simply never been looked at, because until `#26` landed nobody had to pass through setup on the desktop. ### The default window sits exactly on the breakpoint `TABLET_LANDSCAPE_MIN_WIDTH` is **900** (`chrome-plan.ts:28`) and `tauri.conf.json` opens the window at **900×670**. The comparison is `>=`, so the default window resolves to tablet-landscape by a single pixel. Drag it one pixel narrower and the whole app — setup and chrome both — flips to the phone layout. Nothing is broken by this today. It is recorded because a layout that depends on the window being *exactly* its default width is a coin balanced on its edge, and the next person to change either number will not know they are touching two things. ## `#49` did not cause this `856ed03` deleted onboarding's `SCREEN_WIDTH`/`SCREEN_HEIGHT`, which was right: on a device that constant drew setup as a 292×600 box floating in black, 60% of the Pixel's width. Removing it fixed Android and made the desktop's missing design visible for the first time, because the black around the card had been standing in for a frame. ## The titlebar half is already fixed Setup covered the window's only close, minimize and drag region — `tauri.conf.json` sets `decorations: false` for § 1b's pal, there is one window, and `WindowReceiver` drew its own titlebar while the onboarding branch did not. Fixed on `issue/denpa-67-onboarding-titlebar`; **this issue is only the visual question.** ## Beyond onboarding: the chrome wants a redesign Raised by the operator on 2026-07-31, and this issue is the first place it has somewhere to sit. The two-layout table is the whole story of how this app handles size, and it was drawn from a design that described a phone and a tablet. The desktop was never a case in it. Now that the desktop is a first-class surface — it is the machine she runs on, and the one you are most likely to be sitting at — the chrome should be designed for it rather than sorted into the nearest existing row. That is a larger piece of work than this issue, and it should not be smuggled in under a setup screen. What this issue asks for is the decision; **the redesign itself wants its own ticket once there is an opinion to build from.** Worth deciding at the same time: - whether `desktop` becomes a third layout, or whether tablet-landscape is genuinely right and only the breakpoint is wrong - what § 3a looks like at 900px and wider — the 640px measure was chosen for a tablet, not reasoned about for a monitor - whether the decorationless transparent window is right for every mode, or only for the pal that needed it - whether any of it is v1 at all: you enrol once, and it works today ## Acceptance - [ ] § 3a gets a desktop treatment in the design, or a recorded decision that tablet-landscape is deliberately what the desktop uses - [ ] The 900px breakpoint against a 900px default window is resolved, either by moving one number or by writing down why it is safe - [ ] If a third layout is added, `chrome-plan.ts` is where it goes — setup takes its size from that table and must not grow a constant of its own again (`#49`) - [ ] A follow-up ticket exists for the chrome redesign, with the decisions above settled enough to build from ## Related `denpa#49`, `denpa#66`, `ollvt-hermes-bridge#26`, design § 3a / § 3b / § 1b

aiko added the

ready-for-human

wayfinder:ticket

labels

2026-07-31 08:27:19 +00:00

aiko commented

2026-07-31 10:31:25 +00:00

Author

Owner

Decided 2026-07-31: tablet-landscape is deliberately what the desktop uses.

No third layout. Onboarding is passed through once per device and never seen again, and the 640px measure on a filled ground is not wrong at 900px — it is simply the row it was sorted into, now chosen on purpose rather than by default. chrome-plan.ts keeps its two rows.

That decision does not cover the chrome, which is a separate and larger question. This issue's job is now:

Record in design § 3a that the desktop takes tablet-landscape, with the reasoning above — the gap § 3b filled for Settings, filled here
Resolve the 900px breakpoint against the 900×670 default window. TABLET_LANDSCAPE_MIN_WIDTH is 900 and the comparison is >=, so the default window resolves to tablet-landscape by one pixel and a one-pixel drag flips the whole app to phone. Move the window default to 1024×700 so the default sits clear of the boundary; leave the breakpoint where the design put it
Open the chrome-redesign follow-up ticket, carrying the open questions this issue raised: what § 3a and the chrome look like above 900px, and whether the decorationless transparent window is right for every mode or only for § 1b's pal

The third layout stays available to that follow-up if the redesign wants one. It is not being pre-built for a setup screen.

Moving to ready-for-agent — the decision the ready-for-human label was waiting on is made.

**Decided 2026-07-31: tablet-landscape is deliberately what the desktop uses.** No third layout. Onboarding is passed through once per device and never seen again, and the 640px measure on a filled ground is not wrong at 900px — it is simply the row it was sorted into, now chosen on purpose rather than by default. `chrome-plan.ts` keeps its two rows. That decision does **not** cover the chrome, which is a separate and larger question. This issue's job is now: - [ ] Record in design § 3a that the desktop takes tablet-landscape, with the reasoning above — the gap § 3b filled for Settings, filled here - [ ] Resolve the 900px breakpoint against the 900×670 default window. `TABLET_LANDSCAPE_MIN_WIDTH` is 900 and the comparison is `>=`, so the default window resolves to tablet-landscape by one pixel and a one-pixel drag flips the whole app to phone. Move the window default to 1024×700 so the default sits clear of the boundary; leave the breakpoint where the design put it - [ ] Open the chrome-redesign follow-up ticket, carrying the open questions this issue raised: what § 3a and the chrome look like above 900px, and whether the decorationless transparent window is right for every mode or only for § 1b's pal The third layout stays available to that follow-up if the redesign wants one. It is not being pre-built for a setup screen. Moving to `ready-for-agent` — the decision the `ready-for-human` label was waiting on is made.

aiko added

ready-for-agent

and removed

ready-for-human

labels

2026-07-31 10:31:26 +00:00

aiko commented

2026-07-31 14:33:58 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main in ee25aaa, implementing the 2026-07-31 decision on this issue.

All four acceptance items are met:

Design § 3a records that the desktop takes tablet-landscape, with the reasoning — the gap § 3b had already filled for Settings.
The 900px breakpoint is resolved by moving the window, not the breakpoint. tauri.conf.json opens at 1024x700 instead of 900x670, so the default no longer sits one pixel from flipping the whole app to the phone layout. TABLET_LANDSCAPE_MIN_WIDTH stays at 900 where the design put it.
No third layout. chrome-plan.ts keeps its two rows; setup takes its size from that table and grew no constant of its own.
The chrome-redesign follow-up exists: #70, carrying the open questions — what § 3a and the chrome look like above 900px, and whether the decorationless transparent window is right for every mode or only for § 1b's pal.

Tests. chrome-plan.test.ts (+18) pins the breakpoint behaviour. Gate on merged main: 62 files / 854 tests passing.

> *This was generated by AI during triage.* Merged to `main` in `ee25aaa`, implementing the 2026-07-31 decision on this issue. All four acceptance items are met: - **Design § 3a records that the desktop takes tablet-landscape**, with the reasoning — the gap § 3b had already filled for Settings. - **The 900px breakpoint is resolved by moving the window, not the breakpoint.** `tauri.conf.json` opens at **1024x700** instead of 900x670, so the default no longer sits one pixel from flipping the whole app to the phone layout. `TABLET_LANDSCAPE_MIN_WIDTH` stays at 900 where the design put it. - **No third layout.** `chrome-plan.ts` keeps its two rows; setup takes its size from that table and grew no constant of its own. - **The chrome-redesign follow-up exists**: [#70](https://git.aiko.works/aiko/denpa/issues/70), carrying the open questions — what § 3a and the chrome look like above 900px, and whether the decorationless transparent window is right for every mode or only for § 1b's pal. **Tests.** `chrome-plan.test.ts` (+18) pins the breakpoint behaviour. Gate on merged main: 62 files / 854 tests passing.

aiko closed this issue

2026-07-31 14:33:58 +00:00

aiko referenced this issue from a commit

2026-08-07 08:57:15 +00:00

Merge the #62-#68 batch