This week starts with design critique—you'll review the Figma prototypes of at least three classmates and leave structured feedback directly in their files. From there, we move into building: you'll write the full HTML and responsive CSS structure for the recipe project. You'll also get access to your student server space and learn how to use FTP to put files on the web.
Critique is a standard part of design practice. Getting feedback from other people early—before you're deep into building—is one of the most effective ways to catch problems you've stopped seeing in your own work. When you've been staring at a design for hours, it's easy to miss things that are immediately obvious to a fresh set of eyes.
This week you'll give feedback on the Figma prototypes of at least three other classmates. Three will be assigned to you as required, but you are welcome to look at and provide feedback to any other project as well. The goal isn't to tear work apart—it's to give the kind of specific, useful feedback you'd want to receive yourself.
As you review each prototype, consider the design principles and concepts covered in class:
Vague feedback isn't useful. "Looks good" or "I'd change the colors" doesn't give someone anything to act on. Good feedback is specific: it names what you're responding to, explains why it works or doesn't, and when suggesting a change, gives some direction on what to try instead.
For each prototype you review, your feedback must include:
Feedback effort should be comprehensive and done with care.
All feedback will be left directly in the student's Figma file using Figma's comment tool. To leave a comment, open the file, press C to activate the comment tool, then click on the part of the design you're referencing. This pins your comment to a specific element, which makes it much easier for the designer to understand what you're responding to.
Leave separate, pinned comments for each piece of feedback rather than one long block of text. It keeps things organized and makes the feedback easier to act on.
Before any visual styling goes in, the recipe project needs a solid structural foundation: clean, semantic HTML and a responsive CSS layout that works at both mobile and desktop widths. That's what this phase is about.
Think of it like framing a house before drywalling. The structure needs to be right first. Trying to apply visual styles on top of shaky HTML is harder to fix later than getting it right at this stage.
Your project folder should be organized like this before you write a line of CSS:
recipe/
index.html
css/
reset.css
styles.css
img/Two separate stylesheet files are required:
Both files get linked in your <head>, reset first:
<link rel="stylesheet" href="css/reset.css">
<link rel="stylesheet" href="css/styles.css">Order matters. The reset runs first so your styles can build on top of it without fighting browser defaults.
Remember, browsers have their own default styles for HTML elements—margins on headings, padding on lists, font sizes, and more. These defaults vary between browsers, which means the same HTML can look different in Chrome versus Firefox versus Safari before you've written a single line of CSS.
The reset removes most of that, giving every element a clean, zeroed-out
starting point. You can find it at
meyerweb.com/eric/tools/css/reset ↗.
Copy the full reset into your reset.css file exactly as-is. Don't
edit it.
Write all of your recipe content in index.html this week using
semantic HTML elements. Every content section from your Figma prototype should
have a corresponding element in the HTML. Use elements like <header>,
<main>, <section>, <footer>,
<ul>, and <ol> where appropriate.
All content should be present, including images and final copywriting; use alt
attributes on
your <img> tags. The priority is getting all
the content into the document with the right structure.
Once your HTML is in place, write the CSS layout in styles.css
mobile-first. Your site must make use of flex or grid for layout for this
assignment. Start with your base mobile layout, then use
min-width media queries to introduce the tablet and desktop layouts. Leave
out all visual styles beyond structure at this stage—you're setting up the layout,
not finishing the design.
A basic starting point for a layout container might look like:
.container {
width: 100%;
padding: 0 1rem;
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
}
@media (min-width: 768px) {
.container {
max-width: 1200px;
margin: 0 auto;
padding: 0 2rem;
grid-template-columns: 1fr 1fr;
gap: 2rem;
}
}Add a temporary colored border to each major layout element. This makes your layout visible while you're building it—you can see exactly what's happening with spacing, stacking, and alignment without needing any background colors or content in place yet.
.container {
width: 100%;
padding: 0 1rem;
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
border: 2px solid green;
}
.container-children {
border: 2px solid purple;
}
@media (min-width: 768px) {
.container {
max-width: 1200px;
margin: 0 auto;
padding: 0 2rem;
grid-template-columns: 1fr 1fr;
gap: 2rem;
}
}Use your browser's DevTools alongside this to check how your layout looks at different screen widths.
FTP stands for File Transfer Protocol. It's a way to move files from your local computer to a remote web server. Once your files are on the server, they're accessible at a public URL—that's what makes a website a website rather than just a folder on your machine or in GitHub's repositories.
You'll use an FTP client to do this. In this class, we will use Cyberduck. An FTP client is a desktop application that connects to your server using credentials (a host address, username, and password) and gives you a view of the server files. You drag files from local to remote to upload them.
The diagram below shows how all the pieces fit together. Your files live on your computer. GitHub Desktop syncs them to GitHub. The FTP client pushes them to the web server. The browser can read files both from your local machine and from the server.
To connect to your student server space, you'll need three things:
Your server credentials are shared with you separately by Greg Philbrook.
Your student server space has a public URL based on your username. Once you've uploaded your project folder, your project will be accessible at:
https://dtc-wsuv.org/[username]/[project-folder]/For example, if your username is jsmith01 and you uploaded a folder
called recipe, your project URL would be:
https://dtc-wsuv.org/jsmith01/recipe/The browser will look for an index.html file inside that folder
automatically, so you don't need to include the filename in the URL.
Your student server space is a public folder where files need to live to be accessible via a browser. Files outside that folder are not publicly visible. Files inside that folder are publicly visible.
Your local project folder structure should mirror what you upload. If your project
has a css/ folder, an img/ folder, and an
index.html, upload all of it—not just the HTML file. Broken
paths are the most common issue after an upload: the HTML made it to the server
but the stylesheet or images didn't, or they landed in the wrong folder.
Open a browser and go to your project's URL. Check everything: does the page load?
Does the stylesheet apply? Do images appear? If something's missing, go back to
your FTP client and check whether those files are actually on the server and in
the right location. File and folder names are case-sensitive on the server even
if they aren't on your local machine, so Styles.css and
styles.css are not the same thing.
Any time you make changes to your project files on your computer, you need to re-upload the updated files. The server does not stay in sync with your local files automatically.
Browsers cache files—meaning they store copies of your CSS, images, and other assets locally so the page loads faster on repeat visits. This is useful in everyday browsing, but it can cause confusion when you're actively making changes: you upload a new version of your stylesheet, refresh the page, and nothing looks different because the browser is still serving the old cached version.
If your changes aren't showing up after an upload, try one of these:
Ctrl + Shift + R on
Windows or Cmd + Shift + R on Mac. This forces the browser
to reload the page and ignore the cache.When in doubt, check your work in an incognito window before submitting. It's the most reliable way to see exactly what's live on the server.
Due:Mar 6
Due:Mar 11
Write the HTML and CSS needed for your project's basic responsive structure. Your grade will be based on your understanding of semantic HTML, folder structure, responsive units, media queries, and CSS flex or grid for layout.
recipe with the
following file structure:
index.htmlcss/reset.csscss/styles.cssimg/reset.css exactly
as-is. Do not edit it.<head> with
reset.css first, then styles.css.
<header>,
<main>, <section>,
<footer>, <ul>,
<ol>, etc.), write all the HTML needed for
your recipe design. Every section from your Figma prototype
should have a corresponding element in the HTML.
styles.css mobile-first,
using min-width media queries to introduce the
desktop layout. Your site must make use of flex or grid for layout for this
assignment. Visual styles will be minimal at this stage—focus on
structure.