To demonstrate the functionality that your team has implemented during each development iteration, your team must create a demo video of your app.
In addition to creating the video, your team must fill out an accompanying video report that includes a who-did-what report that lists who built each of the demoed features. The video report must be entered into the mX-video spreadsheet (where X is the number of the milestone the video is for).
A key goal for each team member is to have their work completed in time to make it into the video.
The demo video and video-report spreadsheet must meet the following grading criteria.
All the new features. Include all the latest features in the demo. Don’t leave any out. A big point of this exercise is to demonstrate all the wonderful progress that the team has made. Note that this criterion does not mean that you should skip re-demoing old features. It just means you shouldn’t skip the new ones. However, you should not include old work in the who-did-what report.
Backend too. Although UI features are a high priority, you may also demonstrate that backend functionality is working, even if it’s not yet connected to the frontend. The key thing is to prove that the code runs and works! Along those lines, you may demo automated tests.
Story form. Any demonstration of UI must take place in the context of a cohesive story. That is, the presenter must describe one or more characters (with names, like Alice and/or Bob) and relate a story about the character using the software. The presenter must stick to this story format. The story and accompanying demo must be well thought out, and not leave the audience with the impression that the presenter is making it up as he/she goes along. Use realistic names for things and not made-up placeholders, like “foo” and “slafjsd”.
UI first. Since the UI is generally most interesting, you should lead with that.
General audience. Don’t forget that not everyone is as familiar with your project as you are. To be on the safe side, explain it as if you are talking to someone who has never seen it before.
No special effects or fancy editing. The video should clearly show a user (or users) interacting with your web app. Don’t add special effects or sound effects, which distract or detract from the authenticity of the interaction.
Time limit. The video must be no more than 10 minutes long.
Video format. The video must be shared via YouTube.
Note that the creators of the demo video and accompanying video report are eligible for A&B points.
Scored out of 20 possible points. If the deductions below exceed 20 points, a score of 0 will be given.