Week 12 [Nov 4] - Tutorial

Demo Duration

• Strictly 18 minutes for a 5-person team, 15 minutes for a 4-person team, 21 minutes for a 6-person team. Exceeding this limit will be penalized.
• An additional 5 minutes will be given to set up i.e., you will be given access to the demo station 5 minutes before your allocated start time.

Demo Target audience

• Assume you are giving a demo to a higher-level manager of your company, to brief him/her on the current capabilities of the product. This is the first time they are seeing the new product you developed but they are familiar with the AddressBook-level3 (AB3) product. The actual audience are the evaluators (the team supervisor and another tutor).

Demo Scope

• Start by giving an overview of the product so that the evaluators get a sense of the full picture early. Include the following:
  • What is it? e.g., FooBar is a product to ensure the user takes frequent standing-breaks while working.
  • Who is it for? e.g., It is for someone who works at a PC, prefers typing, and wants to avoid prolonged periods of sitting.
  • How does it help? Give an overview of how the product's features help to solve the target problem for the target user

Hi, welcome to the demo of our product FooBar. It is a product to ensure the user takes
frequent standing-breaks while working.
It is for someone who works at a PC, prefers typing, and wants to avoid prolonged periods
of sitting.
The user first sets the parameters such as frequency and targets, and then enters a
command to record the start of the sitting time, ... The app shows the length of the
sitting periods, and alerts the user if ...
...

• There is no need to introduce team members or explain who did what. Reason: to save time.
• Each person should do a fair share of the demo. However, it's OK for one member to do all the typing.
• There is no need for you to demo your own work.
• Present the features in a reasonable order: Organize the demo to present a cohesive picture of the product as a whole, presented in a logical order.
• No need to cover design/implementation details as the manager is not interested in those details.
• No need to demo features inherited from AB3 unless they are needed to explain your new features. Reason: existing features will not earn you marks, and the audience is already familiar with AB3 features.

Demo Structure

• Demo the product using the same executable you submitted, on your own laptop, using the TV.
• It can be a sitting down demo. You'll be demonstrating the features using the TV while sitting down. But you may stand around the TV if you prefer that way.
• It will be an uninterrupted demo. The audience members will not interrupt you during the demo. That means you should finish within the given time.
• Use a sufficient amount of realistic demo data. e.g at least 20 contacts. Trying to demo a product using just 1-2 sample data creates a bad impression.
• Dress code: The level of formality is up to you, but it is recommended that the whole team dress at the same level.

Demo Tips

• Plan the demo to be in sync with the impression you want to create. For example, if you are trying to convince that the product is easy to use, show the easiest way to perform a task before you show the full command with all the bells and whistles.
• Spend as much time as possible on demonstrating the actual product. Not recommended to use slides (if you do, use them sparingly) or videos or lengthy narrations. Avoid skits, re-enactments, dramatizations etc. This is not a sales pitch or an informercial. While you need to show how a user use the product to get value, but you don’t need to act like an imaginary user. For example,
  [Instead of this] Jim get’s a call from boss. "Ring ring", "hello", "oh hi Jim, can we postpone the meeting?" "Sure". Jim hang up and curses the boss under his breath. Now he starts typing ..etc.
  [do this] If Jim needs to postpone the meeting, he can type …
  It’s not that dramatization is bad or we don’t like it. We simply don’t have enough time for it. Note that CS2101 demo requirements may differ. Different context → Different requirements.
• Showcase how the feature improves the user’s life rather than simply describe each feature.
• Rehearse the steps well and ensure you can do a smooth demo. Find a golden path and stick to it. Poor quality demos can affect your grade.
• Don’t waste time repeating things the target audience already knows. e.g. no need to say things like "We are students from NUS, SoC".
• No need to introduce next presenter at the end of your part Reason: to save time.

Demo Special circumstances

• If a significant feature was not merged on time: inform the tutor and get permission to show the unmerged feature using your own version of the code. Obviously, unmerged features earn much less marks than a merged equivalent but something is better than nothing.
• If you are unable to come to the demo due to a valid reason, submit the evidence of your excuse e.g., MC to prof. The demo is part of module grading and absence without a valid reason will cause you to lose marks.