Introduction#
Students will choose a seminal design text from readings.design, read and respond to it, and typeset their selection and reply together.
The goal of this project is to hone your basic skills in typography, focusing on expression, hierarchy, and form appropriate to a work. You will do this through exploration, trial and error, and responding to critical feedback. And then you will execute this typesetting in code, as a web page.
Reading Selection and Response#
Select a reading that resonates with you.* We’d like to avoid any duplicates, so please indicate your selection to us and your classmates.
Read the text you’ve selected thoroughly. Some of the selections there are entire books—if this is the case, you should select a specific chapter. We want you to have enough material to both respond to and design with, so ask us if you are unsure on length. We will also consider other design texts, if you have something in mind—please ask.
You will then write a response. We’re not going to set a specific length requirement here—do what it takes to adequately address your thoughts on the piece. (It probably isn’t bullet points, here.) You’ll know (and we’ll know) what feels right. Do this in your own Google Doc. Here are some questions to consider:
-
How does the reading fit into the canon of design as a whole?
-
Do you think the reading holds up to a contemporary practice of interaction design?
-
If the reading is older or print-focused, how do you think its ideas translate to digital?
-
What does the author succeed in conveying in this reading?
-
What do you strongly disagree with in the reading?
-
What did you learn from the reading that impacted how you will approach design?
Once you’re done, submit a link to your document.
-
readings.design
Choose from these! -
Project 1:
Reading Selections
First come, first served—no repeats! -
Submission Form
Link to your written response.
Due September 10
Sketches#
You will then create three type directions in Figma. These sketches should include the reading (or your chapter/excerpt) and also your response, together. Make it clear which part is which. Each sketch direction should be distinct, and should consider/include these elements:
- Title of the reading
- Author
- Date of publication
- Table of Contents (if part of the text)
- Chapter heading
- The main text itself
Any figures, images, or other decoration should be excluded; we are focusing here on the form of text, alone.
The sketches should all contain the same content, while experimenting with hierarchies and heading styles, typeface selection and combinations, color, and the placement and relationship of the elements to one another.
Consider how each exploration will be perceived differently. Each should be unique—we don’t want to see three layouts all in Helvetica, unless you could make them very unique within that limitation. Use only type, color, and spacing to achieve this.
Create (or move) your Figma document in the project (folder) and name it with your first name. And when you are done, submit a link.
-
Project 1: Sketches
Use your first/preferred name for your Figma document. -
Submission Form
Send us a link!
Also due September 10
Semantic DOM#
Next, you will move your work into code. You’ll take the text content from your sketches and layer it into HTML structures—focusing on appropriate, semantic elements that reflect the usage in your selection. This won’t yet be a styling exercise; instead we will think about grouping and nesting the content. You should use a range of HTML elements to achieve this—think header ,main ,article ,blockquote ,footer ,
You’ll begin from the template repository for your project, which will contain an index.html
When you are done, submit a link to the repo and the live URL.
manuscript
We’ll start from this repository.
Submission Form
Repo and live URL!
Due September 17
Styled Markup#
You will meld style with your code. Select one of your refined sketched directions as an aim. You will then use basic CSS to approximate this intention—beginning with simple changes in typeface, sizing, and color. In this translation, your web page will reflect the decisions and intent behind your text, response, and design.
Your abilities here will be limited—but use this as a lens to focus on your type readability, hierarchy, and legibility. Your design should be successful within this limited vocabulary!
You will create a style.css
Submission Form
Submit your repo/URL again; this is “turning it in.”
Due September 24
Spacing and Refinement#
Finally, you will refine your work—based on our continued feedback, while utilizing more rigorous box-model CSS for intentional spacing and layout. Your work should show progression towards your sketched or evolving goals—within its form, now beyond the type and color. You’ll rationalize the implementation into a deliberate, intentional design system.
You’ll also update your README.md
You will then present your completed page to the class, along with your process to get there, for critique.
Submission Form
Your final repo/URL, one last time.
Due October 1
Our Expectations#
We’ll be looking at your understanding of the reading and quality of your responses, experimentation, appropriate type selection and hierarchy, use of semantic HTML, and your approach in basic CSS. You should have enough time with this text to manifest these things thoroughly.
We recognize we’re early in our journey into coding, so our technical requirements here will be somewhat limited:
-
We’ll work from our template repo and abide by its “instructions” when using it.
-
No images are allowed!
-
For this project (just this one), only desktop breakpoints need to be considered.
-
Also this should be a single webpage; no websites yet.
-
Students should incorporate at least ten different semantic HTML elements.
-
Make thorough, intentional use of
font, ,colormargin,padding, , etc.border -
Demonstrate systematic, “large to small” thinking in our styles, using relative units,
, and variables to define relationships.calc() -
Final projects will be submitted as live, public URLs.
-
We won’t go chasing down links; use the forms, above.
-
These should work, as intended, on any computer (not just the student’s). Check!
-
How you present and explain your work during critique is also evaluated, not just the page itself.
Notes on Format#
-
Be sure to submit your URLs to indicate we have your final work; this submission is turning it in. Check your work on another computer beforehand—if it doesn’t work there, it is probably not going to work on ours!
-
We will split into two groups, for time/space: half will be in here; half will be downstairs, in Room 1108. We’ll post the (random) groups/order the morning of class.
-
In class, we’ll go through each student/project, in turn. You’ll present your live, public URL from your own computer, joining Zoom for the projector and recording.
-
Be prepared to go when it is your turn! Have your browser and IDE open, your Zoom signed-in/updated, your dock/other stuff minimized—no time futzing, here.
-
We do not want a deck/Slides, nor will we look at sketches/Figma. You are showing us the actual page!
-
Also don’t read from a script—this is not a “pitch”/presentation; it’s a crit. Practice talking about your work, and responding to questions about your process and decision-making. (Rijk might interrupt!)
-
The first few minutes of your time are for you to introduce us to your reading and response, your design concept, and its execution. How you do this is up to you—but briefly give us any context we need.
-
We’ll then shift into a discussion and critique of your project. We will ask you about your work, and you should be prepared to answer and explain every design and implementation detail/rationale in it.
-
Per our community agreement (and courtesy), the presenting student “has the floor.” Everyone else will close their laptops and turn off their phones—and no one should
come-and-go from the room during someone else’s turn. (Disruptions will count against the offender!) -
Both instructors will evaluate your projects on three metrics: your explanation of the work, the work itself, and its technical implementation—based on the project expectations, aesthetics, usability, quality, and your engagement.
-
Each category is individually graded per CD letter standards. We then average our scores together (via their grade points) for your overall project grade, and then share this (and our feedback) with you via Slack DM.