Overview. This document explains what kinds of problems and apps make suitable projects for the class, and offers suggestions for ensuring that teams will succeed and have an enriching experiences.

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 kinds of devices (desktop, mobile) on which the solution runs.

You are free to use any publicly available software platforms, libraries or services in your implementation. The underlying 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 a problem 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 motivated by social and ethical concerns, but should at least be informed by them. So, for example, if you chose to build an app that aimed to help commuters reduce the length of their commutes, you would want to consider not encouraging sole-passenger car travel.

Inauthentic Apps

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

  • 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 (eg, a peer-to-peer protocol, or a visualization or a machine learning model) for an authentic app, but does not focus on the construction of the app itself.
  • 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 needs rarely make good projects, because they don’t offer enough opportunities for novelty, and because they typically don’t bring enough value over the approaches (often ad hoc) that are currently in use. These include, for example, apps to:

  • help students manage job applications;
  • organize shared study sessions or other meetups;
  • schedule chores in living groups;
  • select classes to register for, or track degree progress.

Scoping your app

Final projects should result in apps that are complete enough to be deployed in a small scale setting and evaluated as a proof-of-concept. This doesn’t mean that the app needs to work well enough to be used effectively. But it does mean that a group of users could try the app out in a real environment, with it working well enough for them to be able to assess the benefits and flaws of the underlying design. This means that your app should not only provide core functionality but should also be both easy and pleasant to use.

We have noticed in the past some pitfalls in student projects that have prevented them from achieving this goal:

  • Poor focus. Beware of focusing on designing and building the easy parts rather than the hard parts that are needed to make the app actually work. For example, if you were building an app to report pot holes so that bikers can avoid them, you might be tempted to put all your effort into filing reports and displaying them without considering how multiple reports of the same pot hole will be consolidated, or how reports will be marked as no longer relevant when pot holes have been repaired. Another example: an app that suggests shopping lists or recipes based on what’s in a user’s fridge might require the user to enter the details of the fridge contents, but without careful design this step might be so burdensome that it dooms the project.
  • Missing data. Beware of choosing a project whose success will require a lot of high quality data if you are not confident that you can obtain it. For example, an app that provides entertainment advice would likely not work without access to an extensive database of events or movies, etc.
  • Unable to test. Beware of choosing a project that can’t be tested in a short amount of time. For example, a project to help students track job applications cannot be tested without several users experiencing the entire application cycle; this is one (of several) reasons that this is not a suitable project.
  • Hard technology. Beware of projects that will require overcoming a challenging technological problem. If your intended project does involve a technology risk, make sure to evaluate it very early on to gain confidence that you can overcome it. For example, if your project required live streamed video, you would want to establish within the first few days that you’re able to do it (eg, using an open source API) and eliminate the risk of the entire project failing because a key component can’t be built.
  • Lorem ipsum data. Don’t populate your site with pretend data, but try, from the very beginning, to enter data that is realistic and looks exactly like the kind of data that you expect the site to include. If it feels like too much work for you as developers to enter plausible data, that suggests it will be too much work for real users too.

Obviously, 20 person weeks isn’t enough to make a commercial quality app, so you will need to be careful with your time and cut corners. The most important advice we can give you is to invest upfront in bringing as much clarity as you can to what problem you’re trying to solve, and how you’re doing it. When teams are uncertain about the value of their solution, they naturally tend to make it more and more elaborate in the hope that there will be value in the mass of functionality. But this is a mistake, and leads to bloated and ineffective apps that are tedious to build.

Here are some key ways in which you can limit the complexity of your app:

  • Concept focus. Limit your design to the concepts that are absolutely essential. Just because you have posts doesn’t mean that you also need comments and upvotes. Avoid especially entire collections of concepts that are incidental to the primary goals of your app. For example, if you were building an app to manage playlists for parties, you should probably not get sidetracked into invitation lists as well. Your dependency diagram will give you clues to concepts that you might be able to drop.
  • Concept minimality. When you design your individual concepts, give them only the actions that are essential, and don’t feel an obligation to include all the actions that are typically present. For example, user authentication concepts usually allow a change of user name, but you can omit this (while still ensuring that users are referred to in other concepts by their identifiers and not by user names, so it could be easily added later). Save your energy for the core concepts of your app, where making functionality too minimal may render your app unappealing or unusable.
  • Scaling. Don’t worry about scaling your implementation to a large number of users. For example, there is no need to implement special caching schemes for HTTP responses, or to optimize your database structure to minimize storage space or to make queries faster. (And note anyway that many “optimizations” end up damaging modularity while having little or even negative effect on performance.) On the other hand, the conceptual design of your app must be scalable to the context you have in mind. For example, if you were designing a social media app to share announcements of local interest, it would not make sense to have a single noticeboard for a city of a million people.
  • Visual design. Don’t get too deeply caught up in visual design. Set up simple and attractive templates and stick to them, avoiding tweaking every element’s layout and style.

Be Ambitious!

As you approach your final project, we’ll be having lecture sessions that are focused on what it means to design and build apps that are authentic and valuable. We know that you, our students, are extremely hard working and conscientious, and that you want to succeed and that you’ll take in these ideas with interest.

We hope that you’ll decide to go all in, and take seriously the challenge of producing an authentic and valuable app. This may require more work upfront in ensuring that your problem statement and initial concept design are solid. But if you do this well, and take advantage of the support and advice of the teaching staff, we believe that your overall effort should be no greater than it would be if you just treated this as “yet another project,” and it should be a lot more fun. You will also be rewarded in the grading of your project for a sincere attempt at building an authentic app, even if it falls short of your ambitions.