From its very beginnings, the web has been open to participation. If you didn’t like how was, you could spin up your own site. If there was something you wanted it to be, and it wasn’t out there, you could bring it into the world. This is fundamental to the web, as a medium.
And the web’s utility has been defined, in no small part, by individual people trying to meet a specific need. Many sites, even today—after decades of growth and commercialization—were started to solve a problem, whether for a specific individual or for a community.
These sites, and the web, proliferated when others found them—as the desire of one is often the desire of many. And in the web, you can “cast a large net.” People have found shared joy, confusion, interest, and ultimately usefulness in the web. And this is at the core of its ubiquity.
In this capstone project, students will identify a problem—whether in their own life, or in the lives of others. It should be something they can realistically and feasibly hope to solve, or at least improve. This isn’t a hypothetical thing; this is an actual thing. Students will research and understand this problem, before conceptualizing a web-based solution. They will then design and implement their answer, using the tools, technologies, and techniques they’ve learned in this class.
The goal of this project is to give students the time and space to explore a topic of their own interest, within the lens of the material we’ve covered in this course. The final deliverable will likely be a website—though it doesn’t strictly have to be. We do, however, require that it make use of the fundamental web skills of HTML, CSS, and JavaScript we have learned together. Students should focus on a strong conceptual base—as the project will rest entirely on their own idea. And we will then use the rest of the semester (and thus our course) to tackle the problem.
Define your problem
Identify several possible problems you can consider. These could be mundane annoyances; these could be more vital difficulties. It could be something in your daily life, or out in the world or in your community. It is important that these problems are meaningful to you, whether they affect you directly or not. And again, these should be both achievable and real concerns.
From this list, pick the one which is most salient to you and which you think has the most room for improvement. Where can you “make a dent?” Consider also one that will allow you to research and conceptualize your solution thoroughly. If you don’t give yourself enough room here, you will be struggling later.
You will then write us a proposal, where you outline your problem and propose how you think you can solve it. (Also include, briefly, your other initial options.)
This should take the form of a (nicely-formatted) Google Doc. When you are done, submit your link—making sure that it is accessible to newschool.edu accounts:
Due March 8.
Refinement, research, and sketching
Based on the initial feedback from your peers and instructors, you will revise your proposal—understanding and unpacking the boundaries of what you want to accomplish with what will be feasible. Consider analogous challenges and your other initial options—you could shift your topic, if needed. And further research how you might approach and solve your problem—whether conceptually or technically. Remember, you are going to design and build this. Tell us how you’re going to get there.
Practically, we want to see a revised draft of your proposal, emphasizing how you will move forward. (If it is helpful, map out a weekly “roadmap” for how you will progress.) This pass should also include links from your research—other similar examples, technical how-tos, design inspiration. Has someone done this before? How will yours be unique? If it hinges on a technical integration, can you find demos or examples? What are ways around what you can’t build? Submit this revision as a new/separate Google Doc.
Alongside this you will also begin preliminary sketching, as a further means to refine your concept. We don’t want you to go deep on execution or minutia, here—try to focus on sketching as another means to get your ideas out. Maybe this takes the form of code—like a CodePen for an API integration. (We can dream!) Or it could be visual mood-boarding, UI explorations, a site-map, or wire-framing in Figma.
Again, you shouldn’t be designing the thing here; you are sketching your ideas. Show us how you move forward from the written proposal, in whatever way makes sense for you and your project. Submit a link to this sketching, along with your revised proposal.
Due March 22.
Developing directions
You should now have a refined project proposal that is actionable, while still being enough for the project. Look to the description, above.
If the concept is not “there” yet, you should continue to revise and research until it is something you can work towards—with an understanding you are much behind schedule, on the concept.
From your initial sketches, you will now specifically explore aesthetic directions. We would like to see several true, distinct options here—exploring your proposal, conceptually, in design. Again, this doesn’t mean fully completed, all-state, multi-breakpoint design—it means visual explorations. Even if you have a favorite, use the others as “style sounding boards.”
This should take the form of a Figma file, if you haven’t started one already.
At the same time, you will also start into code. (Remember, code is a form of sketching.) As a minimum, this will mean setting up your project repo, roughing out some DOM, and establishing your CSS variables and breakpoints. For some of you, this might also mean an initial integration or semantic/behavior sketching—for others, this could be roughing out states across pages, ahead of JS.
Some projects will need more visual sketching; others will need more code. Show us that you are doing what you need for yours. Submit a link to your Figma file, and your GitHub repo:
Due March 29.
Shift into code
Your focus should now move thoroughly into code—both as a medium for sketching, and also to rough out your project into a prototype. Ahead of completing a specific implementation, think about how you can suggest/approximate behaviors and interactions. Maybe this is a “click through” prototype, with dummy data. Maybe it is an API response, to see that working. It will depend on your project, but we want to see your attention shifted to your IDE.
If you aren’t certain what to do next technically, talk first with your classmates and then the CD tutors. We don’t want to see inaction here.
We do want to see continued visual design exploration in Figma—but again, as sketches—you are not to completely design your end deliverable, here. Focus on the code. Submit a link to your Figma file, and your GitHub repo:
Due April 5.
Code “topping out”
You should now work on getting your code structurally complete. This doesn’t mean done; this means your “last beam” has been erected. This might mean your click-through prototype now saves state; this might mean you’re rendering or have populated all your data. It could be progress into front-end, but that shouldn’t be at the expense of any structure. There should be no large implementation unknowns ahead of you—now is the time to resolve them.
This could mean narrowing your proposal even further, if it still doesn’t seem feasible with the time we have left. But large swings here put you at risk.
You can continue to refine your visuals in Figma, but at this point your emphasis should almost entirely into your code. Submit links to your GitHub repo and topped-out site:
Due April 12.
Refinement, polish, and testing
Your main, primary functionality should be nearing complete—so now we want you to shift back some more into visual design. Maybe your your code structure has informed interface changes; maybe your original concept just needs to be executed. We think this visual honing would best be done in code, too—only go back to Figma if you want to experiment some more. But don’t let this be at the expense of forward progress on your front-end. This week should be about getting your design in a good place—and that design is now in the browser. We’ll only be looking at URLs, now.
We also want you to test your project. (This has been lacking, before.) This means using your DevTools to thoroughly check screen sizes small and large—not just your own laptop’s dimension. This should also mean checking it on your phone, and on other computers. Send it to a classmate! All things equal, a thoroughly working project is worth more than any particular taste/design concept.
Again, make sure you (re)submit your links:
Due April 19.
Final implementation and presentation
In the last working week, we want you to focus on tying it all together. This is where you can get your <head> in order. Have someone proof your copy. Make sure your fonts work on another computer. Check those breakpoints (again). For folks making plugins or extensions, this is when you make the landing page (if you haven’t yet). Do whatever else you need to make it feel cohesive, intentional, and complete—nothing left rough or unfinished. There should be no major shifts here, if you’ve met your milestones. This is a week to package it up, and then focus on your presentation.
As always, your presentation is part of the project. And since this is the capstone to our time together, we want the presentations to be more formal and considered than before—we’ll even have you come up to the podium. We’d like you to consider the audience and the story you want to leave us with. We think this probably means a (brief) deck—but you are still to demo your live, working product thoroughly.
We really want everyone to see each other’s work, so we will will be staying together in one classroom for these. Practically, with our size, that means we will be splitting our presentations over two class sessions—half will present on the first day (April 26) and the other half on the second (May 3).
You will have about 5–6 minutes each, followed by a few minutes of response from us and each other. Use the time how you see fit—but make sure we are left with everything we need to see and know about your work. Rehearse this. Practice your timing. Remember that presenting your work is often as important as the work itself, if not more. Don Draper it for us.
You will not know which group you are in, beforehand—everyone’s projects are due on the first presentation day. If you are in the second group, we don’t want to see any revisions to your deck or commits to your repo. Be ready on the first day. The goal here is to be fair.
Due April 26.