Project

You will design and carry out a quarter-long project where you will write an iOS app (done in teams). I hope that these projects will lead apps in the App Store. The timeline for the projects is as follows:

  • 11/5: Inform me of your group's membership and few sentence description of the app you plan to build. Groups should generally consist of three or four people. Your project partners will have a substantial effect on your experience in this course, so choose carefully.
  • 11/13: Milestone 1. This milestone includes preliminary designs with how you plan to decompose your app, descriptions of libraries you plan to use, what you plan to do for server support, and a timeline of when we can expect tasks to be done and who is going to do them. We'll set your Professor's Challenge in your Milestone 1 meeting.
  • 11/20: Milestone 2 due. Milestone 2 will be set during your "Milestone 1" meeting with me and the TA.
  • 12/5: Live demos. You will demo your app to the rest of the class during the lecture period.
  • 12/5: Final project due.

Project groups should be 3-4 members. Any other group size needs explicit approval by the professor.

This quarter I am not going to give out project ideas. You are responsible for coming up with an app idea by yourself, but I encourage you to start this process early and to solicit feedback from me.

Project Details

Want an A+?

Put your app in the App Store and get 250 daily active users, and you'll get an A+ in the class independent of the rest of your graded materials. Above all I love impact, so if you can show that people are getting value from your app this quarter I will give you full credit for the class. The requirements for this are:

  • You need to have 250 daily active users by the day that the project is due
  • Students from this class can count towards your 150 daily active users. In fact, I want students to help each other out by using your apps and giving feedback
  • You can't pay people to use your app
  • If you want to try this, you need to have a written agreement with Professor King about how you define and measure daily active users
  • Your app needs to be created this quarter as a part of this class. You can't bring in past projects that you've worked on and get credit

Project proposal

Write a few sentences describing the app that you plan to build. It doesn't have to be detailed, we're only want to get a general idea of what direction you're thinking about going to make sure that your project is appropriate for this class.

Please email us before the due date to inform us about group membership because we need to create your groups manually in Canvas.

After we create your group, you should be able to submit a single proposal for the entire group using Canvas' group feature.

Milestone 1

The key activities for Milestone 1 are around planning and getting setup to execute on your app. I do expect that you've started programming when Milestone 1 is due, but I won't grade you on that. Here's what you will need to turn in:

  • Designs for all of the screens you plan to have. These designs do not need to be pixel perfect, and in fact they shouldn't be. Use a whiteboard and take pictures, or better yet use a tool like Balsamiq that lets you draw sketch / wireframe designs easily.
  • A listing of all third party libraries you plan to use
  • Server support for your app. If you plan to roll your own server support, a full listing of the APIs you plan to build
  • A listing of all of the models you plan to include in your app
  • A listing of all ViewControllers you will implement. Please include how you plan to navigate to / from each ViewController and any protocols / delegates / variables you plan to use for ViewController / ViewController communication
  • A list of approximately week long tasks and a timeline of when each of them will be done
  • A trello board that includes all of the tasks and their state (up next, in progress, blocked, done). These tasks need to include an owner from the start, but the owner can change during the quarter as needed
  • A github classroom project that includes all of this documentation. The Readme in your project needs to include a link to your Trello board and pictures of each of the team members with their name and github handle
  • A testing plan. A good app should get feedback from potential users early and often. List here what you plan to get other people to test out. Having your friends or classmates from other groups help you with testing is acceptable (and encouraged). You should have at least one aspect that you measure with each test. Measurements can be quantitative (e.g., how long does it take for them to signup for a new account) or based on survey data (e.g., answers to "from a scale of 1-5 how easy was it to signup?")
Please note that this is not a contract -- I fully expect this all to change as the quarter progresses and you write software. Please do keep all of it consistent with the state of your app as you make progress though.

Milestone 2

The goal of milestone 2 is to make sure that you're making sufficient progress towards finishing your final project. By milestone 2 we should see significant code at either broad progress across the entire app or deep progress on one or more areas. At this point you should have experience with all of the third parties you plan to use, and you should have picked your "magical" experience or advanced feature that we talked about during your Milestone 1 meeting.

Some groups got explicit instructions to email me about something during your Milestone 1 meeting, we'll follow up on that during our Milestone 2 meeting so please do make sure that you've taken action before you meet with us.

Here's what you need to turn in:

  • a link to your most recent sprint planning document
We're not going to grade it twice, but we will use it to get a sense of where you are for our in person meeting.

Sprint planning, standups, and Trello

You are responsible for meeting with your group three times a week. Twice a week your meetings can be quick standups where you briefly talk about (1) what you're up to over the next few days (2) what you did over the previous few days and (3) anything your stuck on. If you're spending more than 10 minutes on these meetings, then you're spending too much time on them. Having standups over Slack or another online tool is fine as long as everyone is logged in at the same time to provide feedback.

Each week you should have a longer sprint planning meeting that should last for about one hour and needs to be in person. In this meeting you will also talk about (1) what you did (2) what you plan to do and (3) any issues you're having, but it will be for the entire week, not just a few days. You must take notes in this meeting about (1), (2), and (3) and submit these notes via Github to get credit. Include links to all PRs / commits in Github that correspond to tasks. Please create a Markdown document in Github to record your notes for your sprint planning meeting and make sure to include:

  • A 2-3 sentence summary of your project
  • A link to your up-to-date trello board
  • Notes that includes what people have done, what they plan to do, etc for each individual in the group
  • Links to all commits that correspond to the tasks that people have done
  • If you did a task that didn't require any code (e.g., test out API foo to see if it works), put a description of the task instead of a link to a commit
To get credit for sprint planning, you must submit a URL that links to your markdown document via Canvas

To track work, you will use Trello. In Trello, you will maintain four lists: up next, in progress, blocked, done. Each task in your Trello board should take about one week of work and You are required to keep your Trello board up-to-date at all times. The main idea behind Trello is to make your committments explicit and to provide visibility as to what you're doing at any given time.

On a personal note, pure "agile development" borders on being rediculous and teams that work on difficult problems don't use it. You should identify the most important things that need to be worked on and work on them, and you should be thoughtful about diagnosing issues when things don't go as expected, but story points and weekly retrospectives are counterproductive and impractical. In this class we'll use what I think are the good parts of agile development, but this is something I encourage you to form an opinion about yourselves.

A more healthy approach is to focus your conversations on impact and quantitative metrics, but that will be difficult in this class as you are building out the product itself -- the focus on impact usually comes after you actually have a product.

Agile development is very good at fostering communication, providing visibility into what you're working on, and identifying any issues that might come up early, so we're focusing our use of Agile development on these facets.

Demo

During the last lecture of the class you will have the opportunity to demo your app to your peers. Everyone will setup in an area of the classroom and then people will roam around the room to checkout what people have done. During this period, Zhiyi and I will go from group to group and you will have a chance to show off your app. For your demo grade, here's what we're going to be looking at (roughly equal weight for each item):

  • You will explain what problem you're solving, why it's important, and how your solution is different.
  • Show us the "magical" experience in your app.
  • Show us the one smooth and polished flow in your app.

Final project

For your final project, the main artifact you need to submit is your code. We will be compiling your app using Xcode 11 so please make sure that your app compiles. For your grade, we will be looking at (roughly equal weight):

  • The basics and documentation. Does it compile, is the code organized in a reasonable way, etc. The only bit of documentation we need beyond what we're expecting for sprint plannint notes is a short decription of what each project member did.
  • API Usage. Are you using APIs in a reasonably efficient way, handle basic errors, etc.
  • App completeness. Your app needs to be complete (e.g., no dead ends when using it). This may mean cutting scope for the final version of your app, but the parts that you turn in need to be complete.
  • UI / UX. Appropriate and logical flows in the app, the app should be usable by a new user without reading instructions outside of the app.
  • Code quality. Your code should be easy to read and understand and it should appear to have been written by a single person.
  • App quality. Does your app provide at least one experience that is compelling for users and is there potential to extend it into something more.

Peer grading

A portion of your final project grade will be set by your project partners. If you get full credit I expect the sprint planning documentation to reflect a project partner who is contributing to the project, and if you don't get full credit then I expect to see some early warning signs in your sprint planning documents.

Your peer grade will be the average of the grades that your project partners give you. My hope is that if there are any issues that you'll talk about it openly as a group early when there is still time for any project members to improve.

What does your app do?

One important aspect of this class is being able to explain to other people what it is that you're building. As a first step, you'll need to explain to me what you're building in a way that makes sense.

We suggest that you use the Y Combinator guidance on how to answer the question of "What do you do?". Please make sure to see their suggestions for how to forumlate your answer and look at the end of the blog post for guidance on improving your answer.

The first thing I'm going to ask you in all of our face-to-face meetings is "what does your app do?" so please make sure that you're prepared to answer that question and work on improving it as the quarter goes on.