Mesh view mockups, round 1 (D162, D164, D194, D210, D216)

kayg commented

2026-10-12 06:58:17 +00:00

Owner

Owner asked 2026-10-12 to mock up the Mesh view. Round 1: Mesh view basics + Settings → Access + a list-beside-graph alternative. Mockup only (test double), not wired to the backend.

kayg commented

2026-10-12 10:17:37 +00:00

Author

Owner

Mesh mockup round 1 is on branch mockup-mesh-r1 (pushed, not merged). It includes origin/dev 2f3e0ba4 (the production line, release-prod-4) and D252 wording (Roles, Network access, Login access; rules, never grant or policy).

Captures: apps/tracer/captures/mesh-r1/, each at desktop (1440x900) and phone (393x852), ink and paper.

A: a1 normal, a2 dense (12 machines), a3 empty (only the server, infraternal join), a4 offline machine, a5 rules-behind machine, a6 relayed arrow selected, a7 arrow hover (relay and round trip).
B: b1 dragging (desktop), b2 popover after the drop, b3 both ways plus ports, b4 "User" greyed ("Arrives with devices"), b5 unreadable ports, b6 toast with "Remove access" (desktop).
C: c1 arrow details, c2 arrow connection, c3 stop-access confirmation (says open connections close at once), c4 machine connection, c5 machine network access.
D: d1 no access (fix: let it reach), d2 offline, d3 rules not delivered (fix: send again), d4 reachable.
E: e1 Settings, Access (three headings), e2 turning the default off (impact preview), e3 default off.
F: f1 list beside the graph (?mesh-layout=list, phone: list first), f2 phone machine details.
Flags: ?mesh=r1|r1-dense|r1-lone, ?mesh-layout=list|graph, ?mesh-default=deny, ?meshui=0 (view as the product has it).

Open design questions (recommendation in brackets):

Tags: chips on cards plus tag cards as arrow ends, not containers (a machine can carry several tags). [Keep.]
Layout: lanes, one row per tag, replace the cluster sheet for up to 40 machines. Arrows still pass under unrelated cards in a dense mesh. [Keep lanes; next round adds connectivity-aware ordering or arrow routing.]
Graph alone or with the list beside it on desktop. [Graph alone by default, the list one flag/palette row away; on a phone list first.]
Phone graph: full-size cards on a free (pannable) canvas, because a graph taller than the screen would shrink text below the type scale. It is reached by a pan or "Show on the graph". [Accept; or drop the phone graph and keep the list plus per-machine details.]
Under allow-by-default, what does a rule mean? Mocked as: pairs without a rule are open; rules show explicitly and can narrow ports. [Decide the semantics before the build; "until you add rules" could also mean the first rule closes everything else.]
Editing ports or direction of an existing rule: the Mesh API has no update action, so only create and stop exist. [Add mesh.grant.update.]
Why can't A reach B: icon at the left of the view and a row in ⌘K; on a phone it sits in the list header. [Keep; add it to a machine's details later.]
The default switch label is a full sentence, so on a phone it wraps beside the switch (TASTE: names stay on one line). [Keep the owner's wording; hint moves below on narrow rows.]
Fields marked PROPOSED on the Mesh API: rule author and time, path round trip, last seen. [Approve for #108.]
Roles and Login access are placeholders in Settings, Access this round. [Next round.]

Measurements: type roles (computed) sign-in lede 14px/500 vs Mesh labels 13px/450 and names 14px/600 (same tokens as the confirmation and details popovers); every text size in the new surfaces is on the scale (12, 13, 13.5, 14); phone list rows and picker rows 44px, fields 44px; Mesh JS: production budgets pass (critical 294,957/307,200 B gzip, deferred 49,752/51,200, largest on-demand chunk 15,174/20,480; none of the round's code is in production, it is mock-only). Frame times: the host load was 45-60 during the runs, so a 3 s pan sampled only 106 frames (p50 33 ms): not a valid measurement; to repeat on the perf VM.

Mesh mockup round 1 is on branch `mockup-mesh-r1` (pushed, not merged). It includes origin/dev 2f3e0ba4 (the production line, release-prod-4) and D252 wording (Roles, Network access, Login access; rules, never grant or policy). Captures: `apps/tracer/captures/mesh-r1/`, each at desktop (1440x900) and phone (393x852), ink and paper. - A: a1 normal, a2 dense (12 machines), a3 empty (only the server, `infraternal join`), a4 offline machine, a5 rules-behind machine, a6 relayed arrow selected, a7 arrow hover (relay and round trip). - B: b1 dragging (desktop), b2 popover after the drop, b3 both ways plus ports, b4 "User" greyed ("Arrives with devices"), b5 unreadable ports, b6 toast with "Remove access" (desktop). - C: c1 arrow details, c2 arrow connection, c3 stop-access confirmation (says open connections close at once), c4 machine connection, c5 machine network access. - D: d1 no access (fix: let it reach), d2 offline, d3 rules not delivered (fix: send again), d4 reachable. - E: e1 Settings, Access (three headings), e2 turning the default off (impact preview), e3 default off. - F: f1 list beside the graph (`?mesh-layout=list`, phone: list first), f2 phone machine details. Flags: `?mesh=r1|r1-dense|r1-lone`, `?mesh-layout=list|graph`, `?mesh-default=deny`, `?meshui=0` (view as the product has it). Open design questions (recommendation in brackets): 1. Tags: chips on cards plus tag cards as arrow ends, not containers (a machine can carry several tags). [Keep.] 2. Layout: lanes, one row per tag, replace the cluster sheet for up to 40 machines. Arrows still pass under unrelated cards in a dense mesh. [Keep lanes; next round adds connectivity-aware ordering or arrow routing.] 3. Graph alone or with the list beside it on desktop. [Graph alone by default, the list one flag/palette row away; on a phone list first.] 4. Phone graph: full-size cards on a free (pannable) canvas, because a graph taller than the screen would shrink text below the type scale. It is reached by a pan or "Show on the graph". [Accept; or drop the phone graph and keep the list plus per-machine details.] 5. Under allow-by-default, what does a rule mean? Mocked as: pairs without a rule are open; rules show explicitly and can narrow ports. [Decide the semantics before the build; "until you add rules" could also mean the first rule closes everything else.] 6. Editing ports or direction of an existing rule: the Mesh API has no update action, so only create and stop exist. [Add `mesh.grant.update`.] 7. Why can't A reach B: icon at the left of the view and a row in ⌘K; on a phone it sits in the list header. [Keep; add it to a machine's details later.] 8. The default switch label is a full sentence, so on a phone it wraps beside the switch (TASTE: names stay on one line). [Keep the owner's wording; hint moves below on narrow rows.] 9. Fields marked PROPOSED on the Mesh API: rule author and time, path round trip, last seen. [Approve for #108.] 10. Roles and Login access are placeholders in Settings, Access this round. [Next round.] Measurements: type roles (computed) sign-in lede 14px/500 vs Mesh labels 13px/450 and names 14px/600 (same tokens as the confirmation and details popovers); every text size in the new surfaces is on the scale (12, 13, 13.5, 14); phone list rows and picker rows 44px, fields 44px; Mesh JS: production budgets pass (critical 294,957/307,200 B gzip, deferred 49,752/51,200, largest on-demand chunk 15,174/20,480; none of the round's code is in production, it is mock-only). Frame times: the host load was 45-60 during the runs, so a 3 s pan sampled only 106 frames (p50 33 ms): not a valid measurement; to repeat on the perf VM.

kayg commented

2026-10-12 14:47:52 +00:00

Author

Owner

Owner answers 2026-10-12 to the mesh mockup round-1 questions: (1) tags as tag cards + chips on machines; (2) desktop shows the graph alone, list one click away; (3) phone list first, graph one tap away; (4) rules are edited in place with the same sentence builder.