Demo Guidelines

From Mw_writing
Jump to: navigation, search


If the result of your work or research is a software system, a demo may be required to explain to others how your system works, why it's interesting, and why it's worth researching. Demos can be rigidly scripted, where only the presenter uses the software and others watch the interaction, or they can be less formal where anyone who wants to can use the system. These different types of demos require some different preparation.

Contents

[edit] General demo advice

[edit] Know the software

You are demonstrating how the software you created works. You should feel quite comfortable using the software, and should be able to use it both slowly (to explain how the software works) and efficiently (to demonstrate how quickly it works).

[edit] Save working programs

You want your demo to be successful. It is a very good idea to keep backup copies of the executables for your demos, instead of relying on the cutting-edge code in your version control system working. If you rely on external data, it could be a good idea to save a working copy of this data. You don't want to need to delay your demo while waiting for a bugfix to compile.

[edit] Scripted demo advice

[edit] Have a detailed plan

You want to avoid improvising, since you might forget to mention something important, or may discuss important concepts out of order. You should know what you will be demonstrating in what order. Some people [1] encourage you to have a clear story for your demo, and to use that story to motivate the demonstrated features.

[edit] Practice, practice, practice

Demos have more ways to go wrong than talks, so you should arguably practice them even more thoroughly than a talk. You should feel comfortable using the software, and you should be able to answer reasonable questions. Additionally, you should try to answer common questions before they are asked. If in your practice talks, the audiences frequently ask the same questions, see if there is a way to clarify that point without the question being asked.

[edit] Streamline as much as possible

You want the focus of the demo to be your impressive software. For example, if you need to open files from inside your program, place them all in one location where they can be easily found.[2]


[edit] Interactive demo advice

[edit] Handle invalid input

When you're letting others use your software, your software should be essentially uncrashable. You might know how your software wants input to behave, but you should assume the user will not abide by these requirements.

[edit] Know how to reset

If your software has various modes in it, you should assume that the user could accidentally enable one of these modes and get stuck. You should be able to quickly identify this and switch the software back to a working mode.

Even if your software doesn't have modes, it's entirely possible that it could somehow get into a corrupted state and need to be restarted. You should know how to re-launch your program as quickly and easily as possible.

[edit] Practice explaining your software

When a new user is introduced to your software system, you should know how to explain the system to them. If multiple people are involved in presenting the demo, they should each know and agree who does the majority of the talking. If multiple people are trying to explain software at the same time, it can confuse the user and create a worse impression of your system.

[edit] Be ready to talk

Know how the program works, so when the users ask questions, you are able to answer intelligently. If you are unable to answer a question, it is far better to admit it than to try to stumble your way through an answer.

[edit] References

  1. Joel on Software: How to demo software
  2. How to Change the World: How to Be a Demo God
Personal tools