Deadline. Team formation proposals are due no later than midnight on Saturday November 5. The teaching staff will then assign students to teams by noon on Sunday November 6. You are encouraged to start using the class forum as soon as possible to suggest new problem domains and to solicit team members (specific threads for these are linked below).

Overview. This document outlines everything you need to know about the scope and nature of final projects in order to form a team.

Project Freedom

In your final project, you will be able to choose your team members; the problem domain you choose to work in; the particular problem you address; the design of the solution to the problem; and the platform (desktop app, browser, mobile) on which the solution runs.

You are free to use any publicly available software platforms, libraries or services in your implementation. The basic software stack, however, should comprise Node.js, MongoDB and Vue.js, so that the teaching staff can provide help; so that all members of the team are equally comfortable; and so that your code can be graded.

Authentic Apps

While you are free to choose your own problem and solution, your app must nevertheless be authentic.

An authentic app is one that is designed to respond to a genuine problem and that offers a novel and effective solution to it—or at least contributes ideas towards such a solution.

To be genuine, a problem need not be widely recognized or even to have been formulated explicitly by others. It should however be sufficiently compelling, when presented, that others agree that it is worth solving. It must also be well focused enough that it is possible to assess whether or not purported solutions actually solve the problem.

Focusing on contemporary societal problems is welcome but not necessary. Projects need not be ethically motivated but should be ethically acceptable. So while you are not required to address the climate crisis, for example, you are also not free to design an app to support illicit drug trading.

Inauthentic Apps

The requirement that apps be authentic rules out certain kinds of projects that are often regarded as acceptable in other education settings:

  • A project that simply provides an opportunity to practice coding by building some standard functionality that replicates behavior already present in conventional apps (for example, building a messaging app with some of the features of WhatsApp);

  • A project that instantiates a well-known app in a specific domain (for example, building an app for fraternity parties that clones Evite or EventBrite);

  • A project that adds new functionality of dubious benefit to an existing design (for example, adding a LaTeX preprocessor to a messaging app to support discussions about mathematical formulas)

  • A project that provides useful infrastructure for authentic apps, but does not itself include the construction of an authentic app.

  • A project to build a game that fulfills no need that is more specific than general entertainment. Games in service of genuine needs, and gamification in general, are not ruled out.

Also, because the final project should exercise the skills you have learned in this class, it should involve the design of dynamic behaviors that involve human users, ruling out:

  • A project whose focus is the development of new algorithms or machine learning networks and that offers no new behaviors or user experience;

  • A project that is primarily about the collection, querying and visualization of data.

Finally, apps that arise from very common and well understood student rarely make good projects, because they don’t offer enough opportunities for novelty, and because they typically don’t bring enough value over the ad hoc approaches that are currently in use. These include, for example:

  • Apps that help students track their applications for jobs;

  • Apps to organize shared study sessions;

  • Apps to schedule chores in living groups.

Degree of Completeness of Apps

Final projects should result in apps that are complete in the sense that they might be deployed and used in a small-scale setting. This means that your app should not only provide essential functionality but should also be usable (and should use standard concepts such as authentication and access control to ensure basic security).

Obviously, 20 person weeks isn’t enough to make a commercial quality app, so your app is not expected to scale to a large number of users, or to provide all the additional functionality apps typically require (such as the ability to customize notification settings).

Nevertheless, you should seek to make the essential functionality of your app complete enough to assess its plausibility. For example, if your app offered a way to plan meals and food shopping while minimizing negative environmental consequences, you would need to include a rich enough database of individual ingredients to allow testing on arbitrary recipes entered by the user. On the other hand, displaying images of ingredients would not be essential.

You should focus your efforts in design and implementation on the novel aspects of your project (the concepts that you invented or adapted), and not on polishing and elaborating standard concepts (such as authentication) that play only a supportive role.

Team Membership

For your final project, you will work in teams of four students. You can choose who you want to work with.

If you propose a team of four students, the staff will accept the proposal, except in unusual circumstances (in particular, if there is a concern that one or more of the team members is too far behind on assignments to be adequately prepared for the final project).

If you propose fewer than four students, the staff will augment your team, by combining proposed teams, matching them by their declared interests. The staff will likewise assign individual students to teams, so don’t worry if you don’t have team mates in mind. We will do our best to ensure that every student is assigned to a team that matches their interests.

If the number of students in the class is not divisible by four, one or more teams will have fewer than four members. The expectations of these teams will be scaled accordingly.

Project Selection

Your team’s selection of a project will proceed in three stages. This document addresses only the first stage; the second and third stages will be explained in more detail in forthcoming documents.

  • Choosing a problem domain. Your first tasks will be to select a problem domain: a general area that includes many problems and potential projects, but all sharing certain kinds of concerns. Teams will be assembled based on declared interests in particular problem domains.

  • Problem choice and divergent design. Your team will then work together to explore a variety of problems within your chosen domain. You will select a problem, and then brainstorm three distinct designs, which your team will present to the entire class as project pitches.

  • Project selection. Based on reactions to your project pitches from your colleagues in the class and from the teaching staff, you will select one of your designs (or perhaps a combination of the designs) to pursue as your project. Your design and implementation work will follow the same pattern as the assignments you did in the first half of the term (convergent design, review, incremental implementation and refinement).

Tasks

Here are the steps to take in selecting a problem domain and proposing a team:

  • Read the document prepared by the teaching staff that suggests a collection of possible domains. By yourself, or in collaboration with other students, select one of these domains. Suggestions of new domains are also very welcome; to do so, just post a short paragraph describing the domain in this thread in the class forum, and the teaching staff will respond and let you know if it is suitable for a final project.
  • Assemble a team that you’d like to work with. To help you find collaborators, we’ve created a thread in the class forum for students to declare their interest in particular domains and to invite other students to join their teams or to form teams with them. Don’t be shy! Many students in the class will be looking for teammates.
  • Submit a team formation proposal using this form. The form asks you to include the names and emails of between one and four proposed team members. If a team proposal includes more than one member, there should still be only one form submission for the entire team. In addition to your chosen domain, the form asks you to include any initial ideas about particular problems within the domain that you might address, which will help the teaching staff make matches and ensure an appropriate distribution of problems.