Project 2: Spread

Your Par tners #

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:

Rules for Collaboration #

• 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.

• 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.

• 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.

Reading Selection #

Each pair will choose a text that was used by their classmates for Manuscript. Importantly, this text should not be either of your own selections. And again, we don’t want any repeats—first come, first serve. When you’ve agreed on a text, add it to this document:

Project 2 Reading Selection

Read your text and discuss it, thoroughly, with your partner. We won’t have written responses as part of this project—your design is your response. We expect to see this in your work (and later, have you explain it to us in your presentation).

Due October 18.

Cooperative Sketching #

You will then sketch together, in a single/shared Figma document, to develop your design for this new text. Keep in mind that your design should reflect your combined response to the text—it should be appropriate for what you have selected.

As with our last project, include the full reading (or your chapter/excerpt, if it is lengthy) and its title, author, date, and other associated elements. Again any figures, images, or other decoration should be excluded; this is still all about the form of the text itself.

You’ll both work on and refine these together into three discrete directions—catalyzed into distinct, well-developed design approaches. You may have seen your classmates designs for Project 1—but your sketches should be unquestionably your own response to the material. Consider this a constraint; go a different way.

Each of your three directions should have their basic mobile, desktop, and print forms sketched out. You can follow the example document with these dimensions:

Create your document (with both your names) in our class project again, so we aren’t dealing with permissions issues:

Project 2 Sketches

And when you are done, submit a link to your organized/finalized directions:

Submission Form

Due October 18.

Pair Programming #

As a team, you will decide on a single design direction—likely, a hybrid/composite path—and take this into code.

You should start, as we did before, with semantic HTML structures appropriate to your text and design. In this phase, we will also expect you to begin your mobile and desktop styles, using media queries and CSS variables to structure this work—taking a mobile-first approach.

All of this work should be done synchronously together, as outlined above. Each team will create a shared GitHub repository for their project, titled spread with their index.html file inside. It doesn’t matter who’s GitHub the repo originates/lives in, but both students should be collaborators. Make sure this repo is set to Public and enable Pages.

When you are done, submit a link to the repo and URL:

Submission Form

Due October 25.

Print and Refinement #

Next, you will layer in the styles for your print layout—modifying your CSS, as necessary, to manifest this physical form. This interpretation should work without color—as print is often limited to black and white. The styles could be done as a separate CSS file, or in the same stylesheet.

You will also continue to refine your overall project design and code execution, integrating the feedback from your classmates and instructors in the previous phase. This work should also all be done together, as before—balancing the commits between both students.

When you are done, submit your links:

Submission Form

You will then jointly present your completed page, along with your thinking and process to get there, to the class.

Due November 1.

Our Expectations #

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 expressive with your text
• Be sure to add a brief README.md overview to your repo
• 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)
• Presentations are considered a part of the final, not just the page itself

And then, 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 responsive for mobile (~375px), desktop (~1280px), and print (8.5″ × 11″)
• 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 students equally during the presentation
• You will be evaluated, together, as a group

Notes on Format #

• We’re going to do this all together, IRL! We’ll need to be structured about our time, but we want everyone to see each others’ work.

• Each team will have 5–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.

• 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.

• So let’s skip decks, here—both for time, and because folks leaned on them too much last project. 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!

• Be sure to demonstrate your page’s responsive behavior, using your DevTools. Do this fluidly, not just at discrete 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 balanced 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.

• 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 5-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 the text in Project 1!

• 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’ll both evaluate your work, presentation, and code against our expectations. We then average these scores for your overall project grade—and for this project, each team will receive a shared/joint evaluation on Slack, as we do.