Feat/visual fidelity - #7
Merged
Merged
Conversation
The three biggest grey boxes were the project illustration, the project preview and the editor canvas — the last of which sits in the middle of the screen every import flow ends on. Grey boxes are right for a testing session and wrong for a stakeholder review, where they read as unfinished. Two SVG components in kit/, both drawn rather than photographic so they stay honest about being stand-ins: - ProjectThumbnail generates artwork from a project's id, so the same project looks the same in a catalogue and on a class page. The live site has bespoke illustrations we cannot use — our projects are invented, so real artwork would attach a real project's picture to a made-up title. - EditorCanvas is a still of the editor: blocks for Scratch, a text editor otherwise. It is drawn portrait because the pane in this workbench is portrait; wide art letterboxed into it read as a broken image. Applied to ProjectPage, ProjectEditor and ClassroomProjectEditor. The other seven Placeholders are untouched so far. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
editor-ui ships as a web component on a CDN rather than an npm package, so this is a script tag and a custom element — no dependency added, which is what makes using the actual editor possible at all. preview="true" with no auth_key gives a genuinely working editor that talks to no API, saves nothing and cannot reach a real account: Python runs locally through Pyodide. The rule against real API calls is about not moving real data, and this moves none. The editor's own sidebar stays off. ProjectEditor's Steps/Save rail is the finding for the import lane — a young person with only a Classroom account cannot save — and handing that to the editor's chrome would bury it. The component exposes editor-logIn and editor-signUp so a prototype still decides what happens when someone tries. Scratch cannot be embedded. The bundle loads Scratch in an iframe keyed to a project the editor API already holds (project_type code_editor_scratch); there is no way to pass one inline the way `code` passes Python, and our projects are invented so there is no identifier. Scratch projects keep the drawn still, as does any project when the CDN is unreachable. The editor mounts into a node React deliberately leaves empty. Sharing one with React crashes the app on removeChild the moment the loading message is cleared. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both pages come from the Code Editor Figma file, recorded in DESIGNS.md: "Individual class" (7355:37981) and "Dashboard Owner" (6759:78797). The structural finding is that a Code Classroom page is two bands — a white block carrying the breadcrumb, title, description and page actions, then the content on a warm off-white below. Screens render those bands themselves; the surface stops padding classroom pages. EducatorSchoolHome is new, and replaces a known gap rather than adding a screen. Both import prototypes had grown their own guess at the mentor's school page, each built by mirroring the young person's version, each carrying a comment saying nobody had checked it. This one is checked: the login code is the largest thing on the page after the title, because a mentor reads it out across a room, and the share link beside it is the route that skips the school-code screen entirely. Also from the designs, and correcting guesses: - surfaces/tokens.css had the classroom accent and page colour marked as a guess. They are editor-color-theme and editor-color-layer-accent. - Breadcrumbs use a chevron and a bold underlined link, not a slash. - The footer carries the safeguarding line, Accessibility and Cookies. Only on Code Classroom: the other products very likely have it too, but nobody has checked, and a footer borrowed from a sister product is how an invention quietly becomes "what the product looks like". - Boxed list rows are white with hairline dividers, not pale fills. One real bug found on the way: .cc-section-head let its text block size itself, so a section's action wrapped onto its own line however much room there was. It needs an explicit basis of 0. That affected all four lists, including two that were already there. The topbar logo is still the words "Raspberry Pi Foundation" — the designs use the colour wordmark, and nothing here ships an image asset. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The mentor pages went high-fidelity and the young person's did not, so
Natalie's flow crossed from one to the other and looked like it had
changed product halfway through. The fix belongs in `screens/`: her
prototype reuses YoungPersonSchoolHome, so nothing in her folder is
touched.
YoungPersonSchoolHome now comes from node 6775:88858 ("Dashboard
Student") rather than from the educator page with the actions taken off.
That frame settles three things a guess had wrong:
- There is a "Sort by" control above the list, right-aligned. Name order
is the only sort it offers.
- Rows carry an optional "New feedback" tag, and it is the ONLY per-row
signal — no project counts, no dates, nothing about what is waiting.
- A class name is bold text, not a link. An earlier pass here reasoned
that a young person has no overflow menu to fall back on so the row
should look clickable; the design disagrees, and the design wins.
It also has no breadcrumb and no back control: the student page is the
top of their tree. Worth knowing that both young-person prototypes pass
`breadcrumbs` to the surface anyway, which is navigation the product
does not have — their call, not this screen's.
YoungPersonClassPage gets the two-band layout so it does not clash with
the page it is reached from, but there is no student class frame to check
it against and its comment says so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Scratch still was a generic picture of an editor: grey bars where block labels go, three categories, no tabs. Redrawn from a screenshot of the live Neil the Seal starter, so the parts a mentor would recognise are the real parts — Scratch's own nine category colours in the real order with their labels, real Motion block labels, the Code/Costumes/Sounds tabs, green flag and stop, a stage over a sprite tray with the selected sprite ringed, and a snapped stack of the four blocks the instructions panel beside it is actually asking for. Still portrait, following the layout the real editor uses in a narrow window, because the pane in this workbench is portrait. Still not interactive, and the comment says so. Also recorded in DESIGNS.md why Scratch is a drawing rather than the real editor, since the reason is not obvious and is not fixable here: editor-api.raspberrypi.org sends `Access-Control-Allow-Origin: https://projects.raspberrypi.org`, so the project fetch Scratch needs is refused from localhost and from wherever this deploys. Python and HTML are unaffected — they need no API call, and they get the real editor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The editor is the entire page in the real product — no margin, nothing else on screen beside it. Here it was a panel in a 1100px column, and in the workbench an 800px card, which left the code pane a portrait sliver about 290 wide. Selected with `:has(.editor)` rather than a new layout prop, so it applies wherever an editor is rendered — including the three prototypes whose folders this change must not reach into. The surface breaks out to the viewport width and takes 100vh; full screen stops measuring the content column, which would otherwise pin the editor into a 1100px strip on a wide monitor. Two sizing bugs fixed on the way: - `.editor-main` had no `min-height: 0`, so the grid row grew to fit the canvas instead of the canvas fitting the row. - `.editor-canvas-art` set only a width. An SVG given one dimension reports an intrinsic height from its own aspect ratio, so the pane pushed 800px tall inside a 640px editor and the footer went off the bottom. Both dimensions now, and it crops. With the pane landscape, the portrait argument for the blocks still is gone, so it is redrawn in the real editor's own arrangement: categories and palette left, workspace centre, stage and sprite tray right. The tray is named and drawn rather than left as blank tiles — a Scratch starter always arrives with its cast in place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Viewing project code for a Scratch project gave the editor about a third of the window. Three separate causes, all of them mine from the last commit. The wrappers. `ClassroomProjectEditor` puts its editor inside a `.section-stack`, and a prototype wraps the screen in another one. A flex item with no grow shrinks to its content, so each unstretched wrapper took the editor further from the window width — 1024 down to 679, then the grid's 320px instructions column left the code pane 359. Stretching only the body's direct child fixed one of two levels; `:has(.editor)` matches every wrapper between the body and the editor however many there are. The height. `.editor` had `min-height: max(420px, 100%)`, and the 100% resolved against the wrapper and then grew past it, so the editor stood 805px tall in a 768px window and clipped its own palette. Height comes from the flex parent now, with 420px kept only as a floor. The drawing. An SVG in normal flow reports a height from its aspect ratio whenever its parent has no definite one — `height: 100%` against an indefinite parent resolves to exactly that — so the canvas grew to fit the picture instead of the picture fitting the canvas. It is positioned out of flow now, with both dimensions explicit. With those fixed the pane turned out to be about 2:1, and the drawing was 1.17:1, so `slice` was cutting the tabs and half the sprite tray while `meet` left it adrift in the middle. The drawing is 560x290 now, the workspace taking the extra width as it does in the real editor, and fitted rather than cropped so a pane of any shape shows all of it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What you're trying
One sentence. Which lane, and what approach.
What you believe
The hypothesis from your
meta.ts— what a testing session could disprove.What to look at
A link, once this has a preview or is merged. Add
?full=1&autofill=0if youwant someone to see it the way a tester would.
What you'd like feedback on
The bit you are least sure about is usually the most useful thing to name.
notes.md