In this class, you will do an introductory project, followed by three solo projects, and lastly a final team project. The aim of these projects is to develop your design skills, to give you practice using the design ideas and representations taught in the class, and to help you become familiar with the implementation and infrastructure technologies. Project development and outcomes will be guided by the Project Checklist (PDF).
The infrastructure for all projects is the same. All your work will be checked into a repository on GitHub. Moreover, in line with modern practice, your projects will be continually deployed (that is, deployed to a public Heroku site after each phase). There will be no special hand-in procedure. After the deadline for the project phase, the staff will grade whatever is in your GitHub repository.
Solo Projects Overview
Each solo project will have roughly the same structure. You will be given an outline of a problem to solve. In contrast to many of the assignments you have done at MIT, these will not be precisely specified. It will be your job to figure out exactly what the problem is! This is one of the most important things to learn in being any kind of designer. The projects will be divided into four phases, for which you will complete certain basic tasks. The first three phases will all involve implementation. For the first two phases, we will give you (imprecisely specified!) minimal requirements to fulfill for each of the phases. For the third phase (not required for the first project), we will give you the freedom to decide for yourself what to do, with a list of suggestions. For the fourth phase, rather than doing implementation work, you will reflect on the work you have done and will compare it to the work of others on similar problems, by writing a brief critique of two designs: your own design, and the design of one your peers in the class.
We realize that in a course like this, there is a lot to learn: many different technologies, ideas, and design representations. It is overwhelming to be asked to do everything at once in a project. We have therefore designed the projects so that the minimal requirements can be fulfilled using subsets of the technologies (for example, requiring only server-side coding in Ruby before any client-side coding in JavaScript is needed). We will introduce activities gradually, so you will not be asked to do everything that might be appropriate at each stage. For each phase of each solo project, we will specify which design and code activities are required.
Below are links to the details including descriptions, deliverables, and hints pertaining to the introductory project and each of the solo projects:
- Project 0: A Simple “Hello World” App
- Project 1: Web Analytics
- Project 2: Shopping Cart
- Project 3: Network Stickies
Final Project Overview
The purpose of the final project is to give you an opportunity to:
- Put into practice the ideas you’ve been learning this term
- Hone your design and implementation skills
- Experience the construction of a non-trivial application
- Work in a team and develop your leadership and collaboration skills
- Have fun!
For the final project, all the activities will be required, and are cumulative. Thus, if you are asked to provide a checklist item describing an activity in one phase, then that same item should appear in all subsequent phases, updated accordingly.
Below are resources for the final projects:
- Final Project Guidelines
- Final Project Ideas
- Final Project Schedule (PDF) with key deliverables and dates
Hints
Use the resources. Do not fall into the trap of thinking that you should just focus on code and then catch up on readings later. If you use the resources we provide, your development will go more smoothly. Before you start coding, check the resource list for readings, slides, videos, etc.
Repository structure. Make it easy for reviewers to find their way around your project by obeying the class conventions for structuring the repository. Place the URL for your deployed app in the README file, along with an explanatory note if any deliverables are missing or your app is not working.
Checklist items. For each deliverable, you are asked to produce some items. See the class checklist for the full list of deliverables with brief descriptions and criteria.
Grunt work. If you ever feel that what you are writing in the documentation of your project is just grunt work, then you are wasting your time and are doing work for which you will likely get no credit. All the activities and checklist items are there to guide you in developing deeper insight into your design. If you are not getting that insight, you are doing something wrong.
Skip the obvious. Do not waste your time writing down obvious points; focus on tricky and controversial issues instead. Do not repeat in informal text what you have already said in a model. On the other hand, bear in mind that things that appear to be obvious at first often are not. Start by questioning everything. For example, if you are trying to write down the purpose of a web analytics app, do not say it is to provide information about visits to websites; that is obvious. Instead think about what kind of information the app is designed to provide, and for whom.
User manuals. Your app should be designed so that it does not require a user manual. Try to make your user interface self-explanatory; if necessary, add a static help page describing basic features and how to use them.
Clarity. Aim to make your problem and design analyses crystal-clear. Have you addressed the key issues directly and succinctly? Have you used object and event models to make your ideas more precise and to reduce the amount of informal text needed? Did you structure your documentation clearly?
