Project Nº 2: “Spread”

Design is rarely practiced on your own⁠—the same is true for most software development. So collaboration is integral to this work, and is the basic structure for this project⁠—conceptually, visually, and then in code. You’ll be working with a partner:

• You are going to be working very closely together for this whole unit, so please be courteous and respectful throughout the process.

• Students will first meet with their partner, exchange necessary contact information, and figure out co-working times and general availability/​approach.

• Students must always work at the same time⁠—whether in-person, on Zoom, in a Slack huddle, what have you. This is not an asynchronous collaboration. You are not to work separately!

• In Figma, students may sketch on their individual computers but should always be in the same document, at the same time, working together.

• In Code, students should work on one computer at a time (for simplicity). One person “drives” with the other watching, and they should switch regularly⁠—maybe every half-hour.

• It does not matter if you’re at a desk or in a Live Share; these synchronous collaboration rules are the same.

• Each team will have one shared project repository for their code, and we should see balanced commits/​work from both students. (We will demonstrate working together from one repo.)

• Both students will receive the same grade for this project, however this nets out. So it is in everyone’s interest to work together effectively.

Keep in mind here we aren’t looking for mathematically perfect division, here⁠—all of these things are proxies for us seeing you collaborate with your partner. We want a good-faith effort at this. You will learn from each other, and your work will be more than what you bring alone.

We’re looking for a successful design and development collaboration⁠—with refined and appropriate layout design, incorporation of feedback, and your effective use of responsive media queries. The feeling of your text should manifest across its forms.

Our same considerations from before:

• Still no images⁠—but be even more expressive with your text!

• Still a single page! Websites are our next project.

• Add a brief README.md overview to your repo⁠—more than a heading!

• Final projects will again be submitted as live, public URL⁠s.

• We won’t go chasing down links; use the forms, above.

• These should work, as intended, on any computer (not just the student’s).

• Presentations are considered a part of the final, not just the page itself.

And specific to this project:

• Your group’s interpretation should be entirely distinct from the first project’s.

• There should be sketches and commits from both students⁠—show us balanced work.

• The page should be fluidly responsive across screen sizes, not targeted to specific devices.

• Your print styles should work without color, and be cognizant of their ink use.

• The final presentation should demonstrate these three different, distinct forms.

• We should hear from both of you during the presentation.

• You will be evaluated, together, as a group.

• We’ll be all together here, this time around (since there are half as many projects). And we want everyone to see each others’ work!

• As before: each team will have the same 6–7 minutes to present their projects. (We’ll give you notice at the five-minute mark.) You’ll do this from one of your machines, signed into Zoom for recording and the projector. The final page should be shown from the live URL you have submitted. Same old, same old.

• Use your time to (briefly) introduce us to your reading and then talk about how your design responds to it⁠—but focus on your final page. We want the bulk of your time to be in the work itself. (This was feedback for many of you! And you have more to show, now.)

• “Show, don’t tell” wherever possible; thread your story through your finished work. Don’t read us a script divided in half⁠—or at least don’t let it feel that way. The presentation, as always, is part of the project! And we have room for improvement here.

• Be sure to fully demonstrate your page’s responsive behavior, using your DevTools. Do this fluidly, not just at discrete/​device dimensions. For demonstrating your print styles, we’d like you to “print” us a PDF and take us through it quickly in Preview, during your presentation.

• We should hear from both students⁠—again, not with some mathematical precision⁠—but convince us that both of you contributed to the project and care about it. We’d also like to hear about how your collaborative process worked⁠—and what you learned from one another.

• Again, you can tell us what your challenges were, but also your triumphs! And how you’d keep it going, with more time or experience. Balance specifics with the Big Picture. Be prepared to use your time fully and effectively⁠—shoot for that 6-minute mark, and don’t go too long here.

• Each presentation will be followed by a few minutes of quick feedback and critique from your classmates and from us. We’d like to specifically hear from the students who previously tackled this text in their Manuscript, so let’s all be paying attention and have that in mind.

• 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. (Disruptions will count against the offender!)

• And as before, we will both evaluate your work and presentation, as well as your live URL and code afterwards against our expectations. (Be sure to review these!) We’ll then average these scores for your overall project grade⁠—and for this project, each team will receive their shared/​joint evaluation on Slack, as we do.