Project Update Videos

For this class, you have a semester project. Now that you are somewhat familiar with the class, and have been working on a project, it is time to present your work to the class. This page explains what is expected of the project updates in a general way. There may be further instructions for your specific classs, which have precedence. That is, if anything on this page conflicts with specific instructions, you should follow the specific instructions.

The project update is like a first draft of your final semester presentation. One purpose is to make sure your group plans to do an appropriate amount of work. That is, it should not be too easy nor too ambitious. The project update should contain the following:

• Introduction
  • Names of your group members. You need to identify who will be on your team. It may be possible to work by yourself under certain circumstances; see the professor for permission. Teams typically have 2 or 3 members. No matter how many people are on your team (even if you work by yourself), you should be prepared to justify the number. Explain any specialized roles. Teams should include only graduate students, or only undergraduates, unless given permission. People will be leaving feedback for you, so make sure that your name is clearly shown.
  • Other info. Include class name, professor's name, and due date of the project update. You do not need to read this to us if it is clearly visible. If you named your project, include that.
  • Overview and motivation. Express what your project is doing and what it will do. This should be a brief (not too technical) overview. What is your motivation?
  • If not apparent: relation to the class. The project should be appropriate for the class, and if there is doubt, you should explain how it connects.
• Background
  • Tasks. Give details about what you plan to do. Break the project up into smaller sub-projects, and identify the steps that will accomplish each one. Set realistic goals.
  • If relevant: Equipment needed. List any special hardware or software that you need to do the project. Do not assume that our department will purchase equipment! If you choose to use your own equipment, you do so at your own risk.
  • Supporting material. Include any graphs, equations, pictures, etc. to convey the idea of what you are trying to do. For a video, you can be creative in how you communicate the information. As always, cite where any material comes from if you did not create it yourself. This means including the reference in a caption, like "Figure 1 - Example system configuration [1]."
  • If relevant: Similarities and Differences. There are other projects like yours (e.g. YouTube videos, Make Magazine articles, previous class projects, etc.). What are they? How are they similar? How is yours going to be different? Talk about them in relation to your plan.
• Project Mock-up
  • To illustrate your idea for your project, you should include a "mock-up". A mock-up is a specification of how things should look. Imagine that is the end of this semester, and you are presenting your final project to the class. What does your project look like? What sort of interface does it have? What buttons are there? What does it do? How does it respond to user input? How does its output look? These are the sorts of things that the mock-up should include.
  • Your group makes a simple model/version of your project. This can include hand-drawn illustrations of the interface screens, cardboard stand-ins for components, knobs that you turn in place of motors, etc. It can be made at a much smaller/larger scale, as appropriate. The mock-up allows you to talk about the project, giving the audience something to look at while you talk.
  • This does not need to be a high-tech mock-up, in fact, creativity is good, and low tech solutions are encouraged. It can look like you're putting together your project from materials on hand, possibly from your recycling bin, with the scissors, string, tape, glue, paper, and markers from a junk drawer. Instead of a GUI interface, put sticky notes on a rectangle of cardboard. It should convey the idea. If appropriate, such as for a game, show how things interact. For example, you can hold representative objects in front of the camera, move the objects accordingly, and explain what happens, such as when they collide.
  • The mock-up is an important part of your project update. It is not the only part. The final video might not include it, unless you want to do a "before and after" type of segment.
• Progress
  • Work done so far. Make sure to show us what you have accomplished so far. You should have some documentation, things you tried, and what worked. Project updates are about what you are already working on, and you should have several weeks of solid work done. A common problem is that people wait too long to get started on their project.
  • Milestones. Include specific things to accomplish. These are unique to your project, and are not likely to be things that other projects do. You can include these with a timeline, but be sure to identify them. For example, "identify and review additional research papers" might be appropriate for the timeline, but this is not specific to your project, and is not a milestone. "Milestone 4: Get the green LED on the Duemilanove Arduino board to blink one, two, or three times within a 2 second interval when the user presses button one, two, or three, respectively" is specific to a project. Calling it "milestone 4" identifies that it is a milestone.
• End Credits
  • References. Include the resources you plan to use. This should include books and papers that deal with the subject. Graduate theses and dissertations can count as books. A URL is *NOT* a reference and if you want to use one, include as much additional information as possible: who created it, what the title is, what company or organization published it, when, where, etc. URLs change all the time, and you should provide enough information that we can find it when the link no longer works.
  • Credits. You didn't make this by yourself. Thank the people who have helped you, e.g. your roommate who recorded video of you speaking. If your video includes music or video from other sources, clearly identify it, and add the information here.

The title (project name, team members, class, etc.) should be on a scene by itself. The other items above do not necessarily need to be on separate scenes - just use your best judgment.

Make your work professional, such as typing or drawing things on a computer. However, you can and should use your own style and creativity. For example, one project video used a flip-book style animation, that looked like it was drawn in ink on a stack of papers, then flipped through rapidly. Previous groups have used skits to illustrate their motivation.

5 minutes

The video should be about 5 minutes: no shorter than 4, no longer than 6, and it should have a good pace. Good pace actually means more than the time shown; an over-length video that is well done will score well, a video exactly on time that drags will lose points.

It is a good idea to have at least one minute that highlights your work. Suppose that you are in a group with 4 people total. If each of you provides a minute-long segment, when you put it together, and add to the beginning and end, you have a 5 minute video that everyone can be proud of.

Everyone is responsible for the video. Some groups have appointed one person as the "editor," only to have him/her drop the course, stop showing up for meetings, quit answering e-mails, quit responding to text messages, etc. You are responsible for the video whether your team-mate(s) deliver on their promises or not. (In a worst-case scenario, a short video highlighting your work is much, much better than no video at all.)

Remember that we are looking for quality, not necessarily quantity.

Use .mp4 for the video format

Every team is responsible for one video for the project update. This is a team effort, and it is up to you to make sure that the work is fairly distributed across your team. The professor reserves the right to replace team members if needed (e.g. if a team member fails to show up for team meetings, he may be replaced by someone who will). There are going to be group dynamics to consider, which is one of the reasons why this is a team project (and a valuable experience). For example, one member may be a strong programmer, but does not communicate well. Another person may be a good leader, while inept with hardware. Learning to overcome individual difficulties and challenges in building your team is an important part of the semester project.

The professor will let you know if your project needs to be revised*. Go ahead with the project as planned unless you hear otherwise. If you find you need to change something major (e.g. you cannot obtain the software in time, so instead you want to solve a different problem), be sure to inform the professor.