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. 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. 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
Identify three 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.
-
Don’t be afraid to push the conceptual boundaries of a “problem”—but it can also be something straightforward.
-
And again, these should be both achievable and real concerns. Where can you “make a dent?”
-
Consider also problems that will allow you to research and conceptualize your solution thoroughly.
-
If you already know the solution to your problem, it’s probably not a good problem.
For each problem, write a paragraph (150–200 words) 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. If you don’t give yourself enough latitude here, you will be struggling later.
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 20.
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 pertinent links.
-
A bulleted 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.
-
We’d also like these features to be evaluated on an impact/effort matrix—to 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 24. Use each week as a header, and write a couple sentences/bullets that communicate what you will work on for that date. (This should include progress for next week, beyond this roadmap itself.)
Practially, this will again take the form of a (new) Google Doc. You can use Figma/Jam for the matrix, if you’d
Due March 27.
Shift into code
You be 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/
Every project will need something different, here. Show us that you are doing what you need for yours! Send us a link to your GitHub repo:
Due April 3.
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 more 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.
Submit links to your GitHub repo and topped-out site:
Due April 10.
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 good place, in the browser.
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 17.
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). 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 do want the presentations to be more formal and considered than before—we’ll probably even have you come up front. 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.
Of course, make sure you have your final links:
Due April 24.
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
- These should work, as you intend, on any computer (not just the yours)
- The project should be responsive across breakpoints
- Your presentation should demonstrate all of its behavior, and is part of the project
Notes on format
-
We will be together here as one group again—so everyone can see each other’s work. Also, instructor-emeritus Rijk will be joining us to see your presentations!
-
Though we had initially wanted to spread this over three days, we have decided to stick to two sessions—so we are going to “run a tight(er) ship.” This will start with everyone being ready to go at 9:00 AM sharp.
-
As we did last semester, everyone’s projects are due on the first day—April 24. You will get the random presentation order that morning.
-
It should go without saying, any work after this point is a great way to fail this project, and we expect you to attend the second day even if you presented on the first.
-
You will have a hard six minutes for your presentation. To facilitate this, you will each set a five-minute timer on your phone, in front of you, while you present. Practice beforehand, and use the timer to know when to wrap things up.
-
You’ll do this from your own machine, signed into the Zoom, from the live URL you have submitted—same as always. Deck and structure are up to you; just use the time.
-
We will also be a bit more formal/structured about our discussion—you will only hear from us, your instructors, after your presentation.
-
And as before, you will receive feedback from both of us, and our averaged scores for your final evaluation.