Project Proposal

Your project writeup should be a PDF file that is a few pages long, turned in via canvas by the start of class.

If you are in the on-campus class and you wish to do the "big homework" version of the project, just write that in your proposal.

You may work by yourself for the project, or you may have a partner. However, the maximum group size is two. If you are in a group of two, only one of you uploads your proposal. The other uploads a PDF that just identifies the project name and the project members. Canvas will auto-assign a peer reviewer, and if you get one of these non-projects you are off the hook for reviewing!

Please clearly explain the following. You can translate these questions into section headings. You can even do a slide deck if you prefer. Please communicate clearly and format your proposal so it is easy to read.

• Give your app a title.
• List the group members, eids and contact email(s).
• What sort of app are you building? What will be the major subsystems? What will be the major challenges?
• Sketch the major user interface elements (i.e., actually draw them and include the drawing in your proposal.) Focus on elements that are likely to be difficult.
• Include a week-by-week schedule.
• List the APIs you will be using.
• Include a short functional specification for a deliverable that you will demo to the TA (for the in-person class). The date your demo is due is listed on the course syllabus as a project deliverable. The purpose of the deliverable is to help us ensure that you are on the right track.
• Include a short discussion of other apps that have similar features and the sources of inspiration for your design.

Remember that we are looking at two things. First is the technical breadth of your app, what APIs does it use, how complex is it, how functional, how well tested. The second is the usability of your app. Can we reinitialize the app without quitting? Can you demo all of the functionality easily? In general, usability is less technically demanding, so it is a good idea to polish it, regardless of the technical scope of your app.

Make sure you have enough data for a sufficient demo. That might include location data, or multiple users, or enough data for interesting graphs. If you don't demo the functionality, you don't get credit for the functionality.

Here are some guidelines for scope. I think of the final project as larger than two homeworks. As you do more homeworks, that scope will become more clear.

I also like to say it should have about 3 major pieces of functionality, where functionality is something like an interactive chat, complex layout, integration with a "substantial" third-party library, control over a novel device/API like playing music, or a custom back end. Most projects use cloud authentication (which we cover in an FC). Your app does NOT need to be original. You can copy your favorite app.

A final guideline I like to give is that your app should have mutable shared state. That means state shared among users that gets written. I think a chat is my canonical example, which is very similar to the FireNote demo with different users and real-time updates. The idea though is that managing different users who want to do something "at the same time" is a classic programming problem you will encounter out there, so let's get some practice now.

You will do a final explanation and demo for the instructor, TA, and possibly fellow students toward the end of the semester. That will also be posted on the class schedule. The masters class will do a video demo.