M1 Demo Video and Report

• Instructions
• Grading Rubric

Instructions

To demonstrate the functionality that your team has implemented for Milestone M1, your team must create a video demo of your team’s app.

Make It into the Video! A key goal for each team member should be to have their coding tasks for Milestone M1 completed in time to appear in the video. Don’t forget to allow time for the code review, bug fixing, etc.!

Display the Team’s Work in the Best Possible Light:

• User-Goal Focus. Structure the demonstration around goals that a user wants to fulfill using the app. Before showing the features in action, the presenter must always first make it clear what the user wants to do and why. The presenter may optionally use a story-telling approach in which the presenter introduces imaginary characters (e.g., Alice and Bob) and narrates as the characters use the app.
• Prepare ahead of Time! The demo must be well thought out and not leave the audience with the impression that the presenter is making it up as they go along.
• Realistic Data. Use only realistic data values in the demo and not made-up placeholders, like “foo” and “slafjsd”.
• UI First. Since the UI is generally most interesting, the presenter should lead with that.
• Gentle Introduction for a General Audience. Don’t forget that not everyone is as familiar with your project as you are. To be on the safe side, presenter must provide a gentle introduction to the app that explains it as if talking to someone who has never heard of the app before.
• No Special Effects or Fancy Editing. The video should clearly show a user (or users) interacting with your team’s app. Don’t add special effects or sound effects, which distract or detract from the authenticity of the interaction.

Demonstrate the Team’s Progress:

• All the New Features. Include all the latest features created for M1 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.
• Differentiate New and Old Features. In the course of demonstrating the new features, it may be necessary to also demonstrate some old features. The presenter should always make it clear which features being demonstrated are new and which are old.
• Backend and Automated Tests Too. Although the user-facing features are the highest priority, the presenter 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, the presenter may also demo automated tests.

Length and Format Constraints:

• 10-Minute Limit. The video must be no more than 10 minutes long.
• Submit via YouTube. The video must be shared via YouTube. The YouTube video’s visibility can be set to Unlisted, so only users with the video’s URL can access them.

Video-Demo Report. 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:

• Reporting Document. The video report must be entered into the m1_video_report.docx document.
• New Work Only. Although you may demo features from previous iterations in the video, the who-did-what report should only mention features/work that are new for Milestone M1.

Grading Rubric

Grading Criteria: Each of the following grading criteria is marked as H/L/F. In all cases, an F is received if the L criteria are not met.

• Gentle Introduction. Provides a gentle introduction that addresses a general audience.
  • H: Introduction is clear and prepares audience well to understand tasks to be demonstrated.
  • L: Introduction is given, but is somewhat unclear and/or leaves audience somewhat unprepared to understand tasks to be demonstrated.
• User-Oriented Story. Tells a user-task oriented cohesive story.
  • H: For each task demonstrated, the user’s motivation and goal for the task are clearly articulated before the task is performed.
  • L: The H criteria is mostly met, with only a few violations.
• Realistic Data. The demo uses realistic data, giving the audience a sense of what using the app is actually like.
  • H: All data displayed or entered into the app during the demonstration is realistic and germane to the app and tasks being performed with it.
  • L: The H criteria is mostly met, with only a few violations.
• All New Work Demoed. All required features are demoed.
  • H: For all tasks reported as complete or partially complete for the iteration, the work is demonstrated.
  • L: Only a couple minor tasks are not demonstrated.
• Differentiate New and Old Work. The presenter clearly differentiates old and new features.
  • H: The presenter consistently mentions which features being demonstrated are new for the iteration and which were implemented in a previous iteration.
  • L: For a few features being demonstrated, it is not made clear whether the feature is old or new.
• Appropriate Length. The demo meets the length requirements.
  • H: The video is no longer than 10 minutes.
  • L: The video exceeds 10 minutes by no more than 3 minutes.
• Bug Free. No bugs are apparent in the demo.
  • H: The app does not crash or significantly malfunction during the demonstration. If a feature is incomplete, it can be mentioned by the presenter, but such features should not be demoed in such a way that they crash or produce error messages.
  • L: One or two minor errors are evident.
• Video Demo Report. An accompanying video demo report document must be provided with all fields filled in appropriately.
  • H: Video report is present, with all fields completed correctly.
  • L: Video report is present, with only a couple minor defects.

Grade Requirements. Minimum requirements to earn each grade:

• High-Pass:
  • 4/8 of criteria graded as H, none graded as F.
• Low-Pass:
  • No more than 1 criterion graded as F, and the video demo report must receive a passing grade.
• Fail:
  • Fails to meet requirements for Low-Pass.