Students will now create a “book,” assembling a collection of texts from their previous work into a cohesive whole—responding via their curation/selections, in writing, and with their design itself.
The goal of this project is to apply the skills you have now developed across multiple web and print layouts across all the pages.
Reading Selections #
Revisit your reading from Project 1: Manuscript. This will be your core, primary text. You will now choose two other selections from readings.design that you feel resonate with or respond to your original selection. The goal is to develop a theme for your book—situating the texts in relationship to one another, as a whole.
It’s okay if these overlap with someone else’s. These texts, together, will form your reader. Add your links to this document, as before:
Due November 15.
Sketching in Code #
Begin coding, as always, by writing the semantic DOM for your website. Start with your landing page and at least some of one text, so your design and execution have a good foundation to experiment and build on.
With a semantic structure in place, develop three distinct typographic treatments—focusing solely on typefaces, their hierarchy, vertical spacing, and your use of color. Do not use the same fonts in multiple directions. You should aim to have the designs of your website reflect the overall tone of your collection, and not any specific text alone.
At this point, we will only be concerned with these base (effectively, mobile) styles, stacked—this isn’t about overall page layout or any responsiveness. Use multiple, separate stylsheets (direction-1.css, direction-2.css, etc.) to organize your treatments, commenting out/in their link elements to toggle between them. You may find that using shared classes and designing more generally will help you here.
When you are done, submit a link to the repo and URL:
Due November 15.
Develop the System #
Based on feedback, you will now narrow and then build out the foundation across all your pages—adding in your remaining texts within the design’s overall system. You will now also progressively-enhance your layout for larger breakpoints, and add functional navigational and interface elements throughout.
The landing/cover page should include an introduction (that you write), as well as a title for your reader, and a brief colophon. From this landing page, you should be able to navigate to the other pages, and vice-versa—exploring typographic concepts here, before resorting to any iconography.
Each text’s page should still be unique—with the semantic elements and styles needed and reflecting their individual content. We should be able to easily tell them apart. But they should balance their individual expression with a cohesive whole, across your website—three flavors of the same dish. Consider the entire experience, moving through the pages—as a user will—as well as the typography of the individual texts themselves. Your design should be an umbrella across them all, while still allowing expression within each text.
We’re also going to have you each help your partner from Project 2—now, by creating a GitHub Issue in their repo (as we did in the first projects). Use this to help them improve their code—and offer comments/
Submit a link to the issue you created, and also confirm that we have your own updated URLs:
Due November 22.
Finalize Your “Book” and Presentation #
In the final phase, we’d like to see a particular focus on addressing feedback from us and from your peers—and a deliberate polishing of your typographic executions. Here you’ll also layer in your print styles, as before.
Finally, as with your previous projects, you will present your work to the group, and discuss the conceptual backing for your reader and its design.
Again, make sure that we have your final links:
Due December 6.
Our Expectations #
We want to see effective, wholistic multi-page design and easy navigation, with advanced, deliberate typographic layouts, consistency across your pages and content, and ultimately, polish and nuance.
This is your final—it is worth a considerable part of your grade and should tie everything we’ve covered this semester into a well-designed and thoroughly-executed website. Demonstrate what you’ve learned about this medium, by making something truly at home in it.
Our (compounding) considerations, as before:
- Still no images allowed! (Last time.)
- Add a brief
README.mdoverview to your repo - 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)
- The page should be (fluidly) responsive across breakpoints
and print - Presentations are considered a part of the final, not just the site itself
Notes on Format #
-
As we’ve mentioned—we want everyone to see each other’s work. Practically, this will spread the presentations over our last two class sessions. Half will go on December 6; the other half will go on December 13.
-
In the interest of fairness, everyone’s projects are due on the first day, December 6. You should be prepared to and expect to present your work then.
-
We will give you the random presentation order at the start of class that day, not before. We won’t be taking requests or volunteers for which day you present. It’s random! And as equitable as we can be.
-
As everyone’s projects are due on the first day, you are not to work on your project after the start of class on the 6th—even if you don’t end up presenting that day. If you draw into the second day, we don’t want to see any revisions to your deck, commits to your repo, etc.
-
Any efforts after this point will be seen as you seeking an advantage over your peers, and that is quick way to fail the project. “Pencils down” is December 6.
-
If you present on the first day, you are still expected to be in class on the second. Your classmates sat through your work; you should do the same for them. Missing the last class will reflect poorly on your grade.
-
As before, you will each come up to the podium to present. You’ll be presenting from your own machine again, joining the Zoom for the recording and screens.
-
We think it is unfair to keep you over and for the folks who draw low in the order—so we need to be much more rigorous about our timing. You will be ready to present; you’ll have your tabs up; you’ll be signed into the Zoom and ready to go when it is your turn. Practice this.
-
You will will have a “hard” 6 minutes maximum to present your work. We will have a visible presentation timer of some sort, and when it ends so does your presentation.
-
In this time, make sure we see your whole project—taking us through all the pages, concepts, and functionality. This is slightly less time than your last (pair) project, so practice using it efficiently—we all got better at this, but there is still much room for improvement. Your presentation, as before, is part of the project.
-
We do not want to see Figma, and we’re recommending against decks, here. The deliverable is the work; spend your time there. Only reach for a deck if you think that is the best way to give us context on the work.
-
Per our community agreement (and courtesy), the presenting student “has the floor.” Everyone else will close their laptops and turn off their phones—and nobody should
come-and-go from the room during a presentation. We collectively did not do a good job of this, lastproject— we’ll mark you down, this time. -
And again we’ll both evaluate your work, presentation, and code against our expectations and then average our scores for your overall project grade. We’ll send this on Slack, along with your overall course grade for the semester.
Show us what you can do! We’re looking forward to it.