Workshop: from Figma to app¶

Exercise workshop-figma-to-app-annex.pdf · PDF

So far you have followed NoteBox, step by step. What happens when the design is yours and nobody has typed it first? How many of your own frames are really the same screen in another state? Which screen would you show your family if you had ten seconds?

This workshop has no new content. You take your own Figma design and build its main flow, with everything from this unit. In Unit 1 you were the architect. Now you are on site with your own plans, and the plans are not allowed to change just because building is hard.

The rules of the site¶

• You work on your app, alone. Ask a neighbour before you ask the teacher, and the teacher before the internet.
• The course rule on AI: only cs50.ai, to explain things, never to write your app.
• There are four checkpoints. At each one, you show the app running, not the code.
• At the end, you review a classmate's app and they review yours.

If you fall behind, cut screens, never checkpoints.

From a drawing to a plan¶

Before you write code, you translate the design.

flowchart LR
    S["<b>Screens</b><br>the frames"] --> R["<b>Routes</b><br>the addresses"]
    R --> F["<b>Files</b><br>+page.svelte"]
    F --> D["<b>Data</b><br>where it comes from"]
    D --> ST["<b>State</b><br>what can change"]
    ST --> E["<b>Events</b><br>what the user does"]

A handoff sheet is a table that turns a design into a plan: one row per screen, with its route, file, data, state and events.

Duplicate the workshop's Figma file from Classroom and fill in the sheet in frame 1 · Handoff sheet. Write one row per screen of your main flow, from three to five rows. A row for NoteBox's list could look like this:

Check your sheet against these four mistakes:

Then mark one row with a star: your main screen. Checkpoints 2 to 4 are about that screen.

Checkpoint 1: skeleton¶

Every screen of your sheet has its route and file. The header navigation reaches all of them and marks the current page. Your tokens are in src/app.css.

Look out for:

• Tokens still called --nb-... in an app that is not NoteBox. Rename them: they are your design decisions.
• A navigation that does not mark the current page. See Routing and navigation.
• Dynamic routes written as product-detail instead of products/[id].

Checkpoint 2: one honest screen¶

Your main screen matches your Figma frame at 390 px: same spacing, sizes and colours, through tokens. And it does not break at 1280 px.

Here is how to check it. Put the browser on the left with the device toolbar at 390, and the Figma frame on the right at 100 %. Go region by region, top to bottom. For each region, compare size, space, colour, type.

• "More or less the same." Find one number. What is the padding of this card in Figma? And in your CSS? If the two answers differ, that is the work.
• Hex colours and loose pixels. Every colour is a token, and repeated spacings should be too.
• No desktop version in the design. It does not need one, it needs not to break. A centred max-width column is an honest answer; a card grid with auto-fill is a better one. See Layout with CSS.
• A frame that is impossible or ugly in the browser. You may change the Figma file first, then the code. Design and code must agree; which one moves is your call.

If it works but does not look like the Figma, the plan and the building disagree. Change one of them, on purpose.

Checkpoint 3: it reacts¶

One interaction with state and a derived value: a filter, a counter, a toggle. One form with at least two validation rules and visible error messages.

This is mostly connecting your earlier homework to the main screen: your event-action table from Events and actions and your form from Forms and validation.

• A counter kept by hand, with count++ in three handlers. What happens when a fourth handler forgets? Use $derived.
• Buttons that still do nothing. A control with no action either gets one or leaves the screen.
• Errors that only appear in the console. Who is the message for?
• A form copied from NoteBox, with NoteBox's rules. Your rules come from your data: a price cannot be negative, a date cannot be in the past.

Checkpoint 4: it has data¶

Your main screen takes its data from a JSON file or an endpoint, through load. npm run build passes. Committed and pushed.

The minimum that counts is a JSON file in src/lib, a GET endpoint that returns it, a +page.js with load, and data in the page. See Consuming data. Do not leave it until the end: the data decides the markup, and a screen built on fake text gets built twice.

Then, in the terminal:

npm run build
git add -A
git commit -m "Workshop 23/11"
git push

Peer review¶

Swap seats, not laptops. Sit in front of your classmate's running app and their copy of the Figma file, at frame 3 · Review criteria. Give each criterion a tick or a comment:

1. It runs: npm install and npm run dev work on a clean clone, and npm run build passes.
2. The main screen looks like the Figma frame at 390 px: spacing, type sizes, colours.
3. No hex colour inside a component: colours come from the tokens in app.css.
4. It does not break between 390 and 1280 px: nothing overflows, nothing overlaps.
5. Every route in the sheet opens, and the current page is marked in the navigation.
6. Every button and link does something. List any dead control you find.
7. The form refuses wrong data and says why, next to the field, in plain words.
8. Something on screen is calculated with $derived, not typed by hand: a counter, a filter, a total.
9. The data comes through load from a JSON file or an endpoint, and an unknown URL shows an error page.
10. With the keyboard only (Tab, Enter, Space) you can complete the main task.

Every comment says where, what, and what you expected. "The form is bad" is not a comment. "New product: I typed a price of -5 and it was accepted" is.

Back in your own seat, read your review and write the one comment you will fix first at the top of the sheet. Do you think your classmate got something wrong? Maybe. But a user who misunderstood your screen is still a finding.

How the workshop is marked¶

This session counts as class work, which is 30 % of the mark for the learning outcome. A checkpoint reached late still counts in full: what matters is where your app is at the end, not how fast it got there.

"How did we do that?"¶

You have already written all of this. Go back to it:

After the workshop¶

• Fix the one comment you picked, and commit it as "Fix after review".
• For your project, you can bring every screen of your sheet up to Checkpoint 2.
• Keep your copy of the Figma file: the handoff sheet is the first page of your project documentation later in the course.

Key takeaways¶

• Plan first: a handoff sheet turns frames into screens, routes, files, data, state and events.
• One row per screen, not per state. Pick one main screen and make it honest.
• Four checkpoints, each shown running: skeleton, one screen, it reacts, it has data.
• Compare with numbers, not "more or less": size, space, colour, type, through tokens.
• npm run build is the truth. Read the first error.
• A useful review comment says where, what and what you expected, and a smaller app that works beats a bigger one that does not.

Quick check¶

The app you built here is big. The next step is a much smaller rehearsal of the same skills, alone and against the clock: Review and exam preparation.