Live In-Class Demo

• Instructions
• Grading Rubric

Instructions

During the live in-class demo session, each team must operate a demo booth. One member of your team must run the booth, providing visitors with a live interactive demo of your team’s app. The remaining members of your team will circulate about the other booths, acting as visitors.

• Content:
  • 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.
  • 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.
  • Realistic Data. Use only realistic data values in the demo and not made-up placeholders, like “blah” and “slafjsd”.
  • Only the Most Interesting User Goals and Features. For the live demo, the time will be very limited. Focus the demo on only the most interesting features of the app. It is NOT necessary for every team member’s code contributions to the app to be displayed in the live demo.
• Length:
  • 6-Minute Limit. The demo must be no more than 6 minutes long.
  • Fill the Time. Carefully plan the demo to fill the 6 minutes well.
• Tips:
  • 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. Prepare seed data. Prepare what will be said. Plan any data to be entered into the app during the demo. Rehearse! Rehearse! Rehearse!
  • Sign In Users Ahead of Time. User sign-in, sign-up, and sign-out features are not interesting. Avoid wasting time with them by signing in users prior to the start of the demo.
  • Multiple Browsers for Multiple Users. For parts of the demo that involve multiple users interacting via your team’s app, use a different browser for each user. Do NOT sign out and sign in every time the demo’s focus switches from one user to the other.
  • Reset before Each Demo. The presenter must deliver the demo over and over. To ensure that each demo runs smoothly, it is a good idea for the presenter to have a protocol for resetting the app prior to the start of each demo.

Grading Rubric

• High-Pass:
  • 3/6 of criteria graded as H.
  • None graded as F.
• Low-Pass: No more than 1 criterion graded as F.
• Fail: Fails to meet requirements for Low-Pass.

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.
• Well Planned and Smoothly Delivered. The demo focuses on only the most interesting features and uses the presentation time efficiently.
  • H: No excessive focus or time spent on uninteresting features or user activities, like signing in and out of the app.
  • L: The H criteria is mostly met, with only a few violations.
• Appropriate Length. The demo meets the length requirements.
  • H: The demo is no longer than 6 minutes.
  • L: The demo had to be cut off abruptly after 6 and was clearly meant to go longer.
• 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.