Right panel hierarchy buries evidence below the fold #97
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Severity: HIGH
The problem
In a fixed 380px scrolling column the panel order is Current State → Notes → Decision → Tools →
Evidence → tabs (
ReviewWorkspacePage.tsx:501-528,styles.css:494-511).At 1440×900 the evidence rows start at or below the fold, and the Comments/History tabs are
always off-screen. With fifteen evidence items the decision form and the evidence cannot be
visible together at all. With zero items, the top of the panel is Notes showing "No notes." —
dead weight in the prime slot.
A conflict in the design docs, needing your decision
The two design documents disagree:
docs/circa-ui-spec.md§8.4 lists evidence before decision controlsdocs/circa-wireframes.md§4.2 chose decision-before-evidence, rationale "act, then inspect"The audit judged the UI spec correct: most decisions are derived from evidence, so the wireframe
rationale is backwards for the common case. Confirm which you want before implementing — this
is the one genuine contradiction between your own specs.
Recommended layout
(it is currently body-size
<strong>— the single most important datum on screen has no visualrank).
action bar also gives keyboard shortcuts (#45) a stable visual anchor later.
Done when
References
frontend/src/pages/ReviewWorkspacePage.tsx:501-528frontend/src/styles.css:494-511docs/circa-ui-spec.md§8.4 vsdocs/circa-wireframes.md§4.2Decision: follow the UI spec. Evidence goes before the decision controls.
docs/circa-ui-spec.md§8.4 wins overdocs/circa-wireframes.md§4.2. The wireframes'"act, then inspect" rationale is backwards for the common case, because most decisions are derived
from the evidence rather than made independently of it.
So the target panel order is:
docs/circa-wireframes.md§4.2 should be amended to match, so the two documents stopcontradicting each other and nobody re-litigates this later.
This ordering also pairs directly with #96 (adopt an evidence date into the form in one click):
evidence sits immediately above the form it populates, so the click and its effect are adjacent.
Done in
afdafdd, together with #102, #103 and #104 — the four edit the same panel, the same token block and the same badge family, and two of them named the same element for the same reason. CI run #59 green on all three jobs.Built to the order settled in the comment above: Current State → Evidence → Tools → tabs in a scrolling region, with the decision controls docked at the panel bottom.
Done when:
The fourth box was verified in a real engine, because nothing in the test suite can reach it. The invariant lives entirely in CSS and jsdom does no layout, so a vitest assertion about it would be theatre. Rendered in Chromium against the real stylesheet: at 0, 1 and 15 evidence rows, across viewport heights of 900, 700, 560 and 420px, the dock stays 144px, the scroll region keeps room, and both the dock and the Approve button stay inside the panel.
min-height: 0on.right-panel-scrollis what makes that true. Without it a flex child refuses to shrink below its content height, and fifteen evidence rows push the dock straight off the bottom — the exact failure this structure exists to prevent, and one that looks fine at every count you happen to test with until it does not.Notes as a tab has a cost, and it surfaced as a test failure rather than as a review comment. The conflict journey asserts that a reviewer who has just been refused can see the note they were about to overwrite. With notes demoted to a tab, they cannot — not without a click they have to know to make. The e2e now opens the tab and says so in a comment rather than leaving it to be rediscovered. The comment above offered "a collapsed row or a third tab"; the tab was built, and if this proves annoying in real use the collapsed row is still the alternative.
docs/circa-wireframes.md§4.2 is amended as instructed, and says explicitly that it was amended per this issue and why. Its §3.2 ASCII sketch still shows the old order — redrawing an aligned diagram was judged not worth the risk of mangling it, and the §4.2 text now says the sketch predates the amendment.Panel width went 380px → 420px as recommended.
One thing found while in the file that no issue named:
NotesSectionwas not keyed byphoto.id, so in-place queue navigation (#95) would have saved one photograph's notes over the next one's — the same defectDecisionFormwas keyed against, in the field that is frequently the only surviving record of who is in a picture. Fixed here.Still open in this area, deliberately not done:
Duplicate of #3f2a91c0…remains in Current State. It is a raw identifier and #104's principle covers it, but the honest fix is a link to that photograph, and inventing navigation was out of scope. #107 is the natural home.