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 online, you can “cast a large net.” People have found shared joy, confusion, interest, and ultimately usefulness in the web. (Among other things.) And this is at the core of its ubiquity.
In this capstone project, students will identify
The problem should be something they can realistically and feasibly hope to solve—or at least improve, with what they know, can learn, and in the time they have. This isn’t a hypothetical thing; this is an actual thing. Students will research and understand this problem, before conceptualizing and building a web-based solution.
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 here together.
Students should focus on a strong conceptual base—as the project will rest entirely on their own idea. And then we will use the rest of the semester (and of our course) to tackle the problem.
Define Your Problem #
You’ll identify three distinct possible problems you can consider:
-
The problems could be mundane, little annoyances; they could be some bigger, 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. (We’re not swapping!)
-
Don’t be afraid to push the conceptual boundaries of a “problem”—but it can also be something straightforward.
-
Consider also problems that will allow you to research and conceptualize your solution thoroughly.
-
Like any function, your project should take an input and have an output. It should transform the input, to answer the problem. (Ask yourself: what are my inputs; what are my outputs?)
-
And again, your projects should be achievable and address real concerns. Where can you “make a dent?” We’ll have 6 weeks; can you approach it in that time?
For each problem, write a paragraph (150–200 words each) describing its nature and how you hope to solve or improve it. Each proposal should include some background context for the problem at hand, as well as a brief outline of how (conceptually, practically, etc.) you would might address it. Describe how you’ll approach it, with what you know and the near horizon of what you can learn.
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 19.
Project Roadmap #
You will now narrow down to one of these problems, expanding on your initial introduction from before. You are working to create a refined project proposal that is actionable, while still being enough for the project. Look to the goals, above.
Based on the initial feedback/ranking 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. 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 are going to get there.
We’d like it to take this form:
-
A revised and expanded introduction and
description— now including research and any pertinent links. -
A list of features/functionality—think of each one as something the project has or does. If you can’t think of many features, unpack them! Or you might not have enough scope.
From your list, identify the one feature your project has to do in order to be successful and indicate it as such. If it is big, further “break it down” as necessary into meaningful, actionable sub-features.
-
We’d also like these features to be evaluated on an impact/effort matrix to help identify what is worth your time. Make sure all your features are here!
-
Last, we want you to use this information to make a high-level, week-by-week roadmap—ending on the final presentation day, April 23. Use each week as a grouping; we only have five from today!
(This should include progress for next week, beyond this roadmap itself.)
The feature you identified as absolutely necessary will form the basis for your Minimum Viable Product (MVP). This, and any closely related features should be the first thing you unpack and work on. After this, you should order your weeks by prioritizing the other most important features and functionality first.
Practically, this will take the form of a (new) Google Doc FigJam. We’ve set up a template to get you started:
Duplicate this (don’t edit the shared one!), rename it with your name, and make sure it still “lives” in our class project/folder. When you are done, send us a link and recap:
Due March 26.
Core Functionality #
You should be working in code. (Remember, code is a form of sketching!) Set up your project repo, roughing out your initial DOM, and establish your basic CSS variables and breakpoints. For some of you, this might also mean an initial integration or semantic/
The most important priority is to implement the core functionality that your project has to do. This could mean prioritizing JavaScript behavior, integrating with an API, or experimenting with different layouts.
Every project will need something different here, but by April 2 you should be able to demonstrate your project’s core functionality in code. Prioritize this over aesthetics and other side quests.
Show us that you are doing what you need for yours! Send us a link to your GitHub repo and an update/recap:
Due April 2.
Minimum Viable Product #
You should now work towards a feature complete Minimum Viable Product (MVP). This means implementing any additional features on top of your core functionality in order for your project to work. What is the bare minimum you need to “ship” it?
Your focus is on getting your code and project structurally complete and “topped out.” 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 more progress into front-end, but that shouldn’t be at the expense of any structure. There should be no large implementation unknowns ahead
Submit links to your GitHub repo and topped-out work:
Due April 9.
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 code structure has informed interface changes; maybe your original visual concept just needs to be more thoroughly executed. This week should be about getting your design in a solid place.
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 devices. 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 16.
Final Refinements 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). Maybe tackle one of your “nice to haves” that got cut for time! But 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. (Keep in mind our notes from last time.)
As always, your presentation is part of the project. And since this is the capstone to our time together, we do want the presentations to be more deliberate and considered than before. We’d like you to consider the audience and the story you want to leave us with. As a reminder, you are in control of your demo—so make sure it relates to the story you are telling!
Of course, make sure you have your final links:
Due April 23.
Our Expectations #
We want to see a well-polished project which clearly demonstrates an engagement with and understanding of everything we’ve covered in this course.
This project is open-ended, by design—as many real projects you will work on are. This is so you may gain experience working in an open scope and within an undefined solution space. It is natural to have some false starts, but if you find yourself spinning out it is on you to reach out.
The standard “night before” will not cut it here, and we expect that each week shows meaningful effort and progress beyond what may have worked in previous assignments.
Given the nature of this project, we expect and look forward to each individual’s design and implementation being unique. There is no right answer here, but we want to see your work shaped and informed by your process, your peers, and our collective input.
Our usual technical/practical requirements:
- Your projects should be submitted as live, public URLs
- During both reviews and in presentation, your project should work as intended on computers and phones
- The project should be responsive across breakpoints
- As a function, your project should take an input and transform it into an output
- Your presentation should demonstrate all of its behavior, and is, as usual, part of the project
Notes on Format #
-
We will be together as one group again, like we did in the Fall—so everyone can see each other’s work.
-
We’ve thought about spreading these over three days, but have decided to stick to two sessions—so we all need to mind the time. This will start with everyone being ready to go at 9:00 AM sharp!
-
As with last semester, everyone’s projects are due on the first
day— next week, April 23. You will get the random presentation order that morning. -
It should go without saying that any work after this point is a great way to fail this project (and thus the class), and we expect you to attend the second day even if you presented on the first.
-
As with our last couple presentations, you will have a “hard” 6 minutes maximum to present. (We’ll have The Timer again.) You will each come up to the podium to present, from your own machine, joining the Zoom.
-
We want to reiterate our community agreement again. Laptops closed, phones away, and folks shouldn’t be coming-or-going. The person presenting has the floor and our respect!
-
To help us stick to the time, you’ll present your responsiveness entirely from within the DevTools (no phones). Be sure to show it across breakpoints! (Know that we will look on our own devices, afterwards.)
-
Introduce us to your problem, how you approached solving/
improving it, and where you ultimately landed. Demonstrate all the functionality you’ve been hashing out over the past few weeks! -
We’ve decided we’re agnostic on decks—but be sure to tell us a story, remembering that your presentation is part of what we are evaluating here. This is our fifth time doing this, and you’ve all had our feedback.
-
Each of your presentations will be followed by a few minutes of feedback and critique from both of us.
-
And as before 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. (Not on Christmas eve.)
We’re really looking forward to it! We’ve all come a long way.