Prototype/sarah - #4
Merged
Merged
Conversation
Screens read badly stretched across a large monitor: line lengths go past what anyone scans, and a two-column layout drifts apart. In the workbench the whole framed surface sits on the measure, centred -- the frame already reads as a screenshot rather than a browser window, so narrowing it is consistent with how it is presented. Full screen moves the cap inside onto the page content instead, because there the chrome deliberately goes edge to edge; the bars keep their full-width backgrounds and only their contents line up with the column, or a breadcrumb would sit alone at the far left of a page starting halfway across. One token, --surface-measure, so a prototype that needs a different measure can override it on its own Surface rather than editing this. Applies to every prototype in the repo, not just one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every non-final crumb was a hardcoded link to #/screens, so clicking one dropped whoever was being tested out of the flow and into the screens gallery. Code Classroom has no other navigation, which makes it the worst place in the app to have a link that lies. Surface now takes an optional onCrumb(index). Pass it and the earlier crumbs become working controls; leave it out and they are plain text rather than a link to nowhere. No default destination on purpose -- where a crumb goes is the prototype's decision, the same as every other callback on these screens. Three placeholder #/screens hrefs remain elsewhere, in RoleChooser, MentorSignIn and MentorDashboard. Same bug class, left alone for now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reconstruction had drifted far enough from the real screen to be hard to look at: both actions were small secondary buttons, the settings gear was missing entirely, and projects were bare lines of blue link text with a language tag the real page does not have. Now, from the live screen: Class members is the primary action, because getting young people into the class is the job a mentor comes here to do; Copy link is secondary; the gear is there. Projects are a bordered group of pale rows with the name as bold body text and an overflow menu as the action affordance. Icons are the design system's own -- Material Symbols is already imported by its stylesheet and Button takes an icon name. The useful find: the crossed-out eye on each row is the live product's own marker for a project students cannot see yet, so visibility is per project and surfaced right here. That is new information for the open question about where "show to students" lives, and it gives us a much cheaper way to test it -- put a mentor on this page and see whether they read the icon as "not finished" or miss it. Exposed as an optional hiddenProjectIds, so existing callers are unaffected. onSettings and onProjectMenu are optional and default to no-ops. The gear and the kebabs exist on the real page so they render regardless, but they do nothing until a prototype wires them -- worth knowing before a session. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It rendered as a small panel in the middle of a large page with dead space under it: .editor had a 420px floor, and the canvas held a fixed 220px grey box that did not grow with its pane. .editor is now sized from the viewport, keeping 420px as a floor for short windows. flex: 1 would not have done it -- in the workbench the surface is only as tall as its content, so there is no spare height to grow into. The canvas placeholder stretches to the whole pane, which needed Placeholder's height widened to number | string so it can take '100%'. Its height is applied inline, so CSS cannot override it from outside. Both editors, Code Classroom and Code Club Projects, since they share the layout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A mentor starts in Code Classroom, goes out to Code Club Projects to browse, and comes back with a project attached to a class. Sarah Tucker's bet: Code Classroom is the hub for a club, so that is where a mentor goes looking for a project -- not Code Club Projects, where they have always gone for club content. Built to Sarah's "Option 1" flow chart, with four departures from it, all argued in notes.md: - The whole add-to-class interaction stays on Code Club Projects and crosses into Code Classroom only at "View your class". The chart put that boundary earlier; Experience CS, the other product feeding Code Classroom, does it this way, and Divya called it. The chart wants updating to match. - The find/create fork is one dialog with two steps, not a page and not two stacked dialogs. Step 2 is the live "Create a new project" dialog, so the branch this prototype tests against is the real screen. - The class-picking cards follow Experience CS's equivalent screens. - The catalogue follows the live Code Club Projects category pages, under a proposed "Code Classroom compatible" category. Five findings that fell out of making the chart run, not design opinions: "view project code" arrives before there are any instructions to view and would crash the shared editor; "show to students" inverts the live product, which only offers "hide"; the category now excludes nothing, so the "can we connect non-editor projects?" question is no longer visible in the flow and needs a fixture to test; success succeeds at less than it claims on the new-class branch; and creating a class from Projects is a write into another product, which is a much bigger ask than the rest of the flow. Nothing here ships and nothing is a commitment to build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
.rpf-input-checkbox carries a hardcoded min-width of 240px. The shared .cc-columns layout fixes its rail at 260px, which leaves 212px inside a card's padding -- so every checkbox in the rail spilled past the card's edge, by 6px here. Swapped for a flex rail with a 19rem basis, which also still stacks on a narrow window without a media query an inline style cannot express. Noted in notes.md rather than fixed in the shared CSS: a wider rail variant, or a fix upstream in the design system, is somebody's call and not a prototype's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The mirror of out-to-projects-and-back, and the pair is the point. Both answer "how does a mentor get a Code Club project into Code Classroom?" and they disagree about exactly one thing: where the mentor starts. Sarah Tucker's bet here is that Code Club Projects is the site a mentor already knows, so the route has to begin in the catalogue rather than in Code Classroom. Same mentor, same club, same classes, same add-to-class cards, same product boundary -- so a session reacts to the starting point and not the furniture. Built to Sarah's "Option 2" flow chart, with three departures, all argued in notes.md: - The first screen is the live project selector, not a category page. That collapses three of the chart's boxes into one screen and is the chart read correctly: on the real site "Scratch" is a checkbox in the Technology group of the selector's rail, right next to where the new filter goes. It also makes Sarah's own assumption -- "mentors will find a project based on technology over interest" -- observable, because the rail puts Interest and Technology side by side. A category page assumed that answer. - The flow starts SIGNED OUT, which produced the sharpest findings in either prototype. A mentor browsing Projects has usually not logged in. So the site cannot call out a club it does not know about, which means the call-out Sarah's sticky asks for is only possible after the step most likely to lose them; "Add to a class" is offered anyway with the log-in coming after the intent; and signing in adds Pi Accounts as a third product to the crossing. - Compatibility is a filter, not a category. A category defined by a constraint in another product sits oddly beside categories defined by what they teach, and one that excludes almost nothing does no work. Two tags were built and removed: "Works with Code Classroom", which would sit on nearly every card in a catalogue shared with young people, and "In a class", which is a fact about one mentor and belongs on the project page where they are deciding. The inverted idea -- telling a mentor "this will not work in a class" at the moment they try to add it -- is not built and is probably the right one. Known gap before this is testable: facets.ts invents which projects are Code Classroom compatible, because src/fixtures has no such field and fixtures are shared. Nothing about the real Rock Band says it would not import. The filter's central mechanic needs a usableInClassroom field and a project or two that genuinely is not. Nothing here ships and nothing is a commitment to build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The import prototypes both turn on a filter for "projects that can be used in my Code Classroom", and neither could honestly test it. Compatibility is a property of a PROJECT -- whether it runs in an editor Code Classroom can embed -- and the fixtures had no way to say so. One prototype guessed from the language and got it wrong twice, first dropping Scratch and then excluding nothing at all; the other invented that Rock Band would not import, which nothing about Rock Band supports. A filter that visibly lies is worse than no filter. So: an optional `usableInClassroom` on Project, absent meaning usable, plus two projects that genuinely are not -- Rain or Shine (Scratch, needs a Raspberry Pi and a rain sensor) and Door Watcher (Python, needs a Pi and a motion sensor). Physical computing is a real and sizeable part of the live catalogue, so the exclusion is the honest kind. Optional rather than required on purpose: prototypes build their own Project objects for work a young person invents, and making the field mandatory would have meant editing another prototype's folder. Both import-mentor prototypes now read the field. The "2 more projects are not here" message in out-to-projects-and-back was marked unreachable and is now the point -- a session can finally watch what a mentor does when the project they wanted is not in the list. Worth knowing: this changes what every prototype listing projects shows. import-yp now has six to browse instead of four, including two that need hardware, and it does not know about the field -- so it will let a young person add one to a class. Not this branch's folder to fix, but someone's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
No textual conflicts: main's two commits rebuild import-yp's add-a-project flow and touch only that prototype's folder, which this branch never went near. There is one interaction worth recording, because a clean merge hides it. This branch added `usableInClassroom` to Project and two physical computing projects that carry it as false. import-yp's ProjectLibrary filters the catalogue by language alone, so Rain or Shine now appears under Blocks and Door Watcher under Python, and a young person can add either to a class -- which the field says is impossible. Verified the flow still builds, loads and runs; the contradiction is content, not a crash. Not fixed here: that is another prototype's folder, and this repo's one rule says leave it alone. Whoever owns import-yp can either honour the field or decide a young person browsing inside Code Classroom should never have been shown a hardware project in the first place -- which is arguably the more interesting finding. 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