Project Nº 5: “Functions”

You’ll identify three (3!) 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 interesting and meaningful to you, whether they affect you directly or not.
  
  We’re not swapping! They are yours.

• 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. Have “runway.”

• 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 have 7 weeks now; can you approach it in that time?
  
  Framed as small, medium, or large⁠—shoot for a medium!

Do this in a (nicely-formatted) Google Doc. For each problem:

• Write a paragraph (100–150 words each) describing its nature and how you hope to solve or improve it.

• Each proposal should include some basic background context for the problem at hand, as well as a brief outline of how (conceptually, practically, etc.) you might address it with what you know and the near horizon of what you can learn.

• Separately, unpack and identify what you think the challenges will be for this particular problem.

• A goal here (always) is to challenge yourself⁠—tell us what you are hoping to learn from working on it!

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:

1. A revised and expanded introduction and description⁠—now including research and any pertinent links.

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

3. 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!

4. Last, we want you to use this information to make a high-level, week-by-week roadmap⁠—ending on the final presentation day, April 22. Use each week as a grouping; we only have six from today!

   This should include progress for next class, 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.

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/​behavior sketching⁠—for others, this could be roughing out states across pages, ahead of JS.

The most important priority here is to implement the core functionality that your project has to do. This could mean prototyping JavaScript behavior, integrating with an API, or experimenting with different layouts.

Every project will need something different here, but by April 1 ^ST 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!

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 of you⁠—now is the time to resolve them. It might be ugly/​unstyled/​default-y, or not have all of the features⁠—but it should cover the core behaviors and use.

Your main, primary functionality should be 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⁠—both in UX and UI.

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

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. Clean up your repo. Get your attributions in order. 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!

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!