2.7 Giving a presentation


As a software engineer you can expect to have to give two kinds of presentations. First there are presentations in which you might discuss the concept, specification, and design of your program. These days, presentations of this sort are almost universally made into a series of PowerPoint slides. Second, there are the presentations in which you show a live, running demonstration of your program in its current state.

The two most important rules for either kind of presentation are these.

  • Face the audience. Resist the tendency to turn your back to the audience and stare at the screen. This is a particular risk when you're presenting a software demo. For software demos you really need one person to be at the computer running the demo while another person talks.

  • Speak loudly, clearly, and not too fast. Speaking loud to a group can be psychologically difficult if you've never done it before. It's said that fear of having to speak to a group is one of the most widespread phobias. Practice with your family or friends in advance if you get a chance. And when you make your presentation, try and think of the group as not being hostile or judgmental. Think of them as friends.

PowerPoint

Here are a few basic rules to remember about a PowerPoint style demonstration.

  • Content, not graphics. You can be sure that your audience has seen PowerPoint presentations before. What is going to impress them is the content of your material, not the fancy themes or colors that you use. Work the content out first, and think about the graphics frills second “ or not at all.

  • Make the slides have good contrast. Yes, black text on white background seems boring when there are so many other possibilities. But the person in the last row is going to be unable to read your slides if they're green on beige or some such. PowerPoint is simply a medium for getting your words across. Don't let it get in the way. If you'd rather be different and use white text on black background, that's okay, but you'll need to make the font a bit larger, as this color -scheme is slightly harder to read.

  • Use a big font. You shouldn't try to squeeze more than three or four lines of text onto a slide. Even if the font is still readable, too much information on a slide loses your audience. When necessary, split a thought into two or three subthoughts, start with a 'contents' slide listing the two or three thoughts you're about to discuss, show a slide for each thought, and when you're done come back to the contents slide to summarize.

  • Supplement with paper handouts. It's often not possible to fit a complicated UML diagram onto a slide and still have it legible. You can break the UML up into small pieces or, if this doesn't seem to communicate the pattern properly, you can print out copies of the full UML and hand it out. People like getting a few paper handouts at presentations. It gives them something to make notes on, and it reminds them of what you said.

Software demo

Software engineers refer to something called the 'demo effect'. This is a weird force which sometimes makes your wonderful program turn into a buggy piece of junk in front of a large audience. Here's a little law, gleaned from some years of experience:

The strength of the demo effect is directly proportional to the size of the audience times the importance of the demo to your career.

The ideal method is to bring your demo on a laptop, but sometimes you won't be allowed to do this. In a course using this book, it's reasonable to require the students to use a classroom machine which is hooked up to the classroom computer projector. If you build your project on an individual self-study basis, you might eventually take it to a friendly gamers' group and show it on a projector there.

If you have to bring your demo in portable form, there is the issue of getting it to fit onto a disk. Floppy disks have a 1.44 Meg maximum size. If your game includes a lot of bitmaps, it may well be larger than this size. But if the exe itself is less than 1.44 Meg, put it alone on a floppy and put any support files like *.hlp or parameter files or sample source code on another disk.

If you can't fit your exe on a floppy, you can consider using a compress utility like WinZip, or burning a CD or even DVD with your game on it.

Theoretically you can use the old-style DOS Backup utility to back a file up onto two disks, but it can be tricky to get the command prompts for this right, especially in a stressed situation. There are also other backup utilities that one can download from various software sites on the internet, but they're not much easier to use. Forget backup utilities.

A typical sequence on demo day in a classroom might be that the students bring their disks up, the professor gets all the executables copied or unzipped from the floppies (or other types of disks), and puts them all into a directory on a network drive, and then the students come up in teams and run the executables on the classroom machine. If you're doing a demo at a conference or a meeting, it's more likely that you yourself would be responsible for plugging in your own laptop or for copying your software to the demo machine.

Here's a list of tips for avoiding the demo effect, starting with our two principles of scale and speed independence.

  • Write your program so its behavior is independent of the resolution of the display.

  • Write your program so its behavior is independent of the speed of the machine.

  • Bring your program on your laptop if you can. But do keep in mind that there's a real chance that for some reason you won't be able to use your laptop; it's not uncommon for people to have a problem in connecting their laptop to a computer projector. Any task can become surprisingly hard in a stressed situation with people watching you and giving you advice. If at all possible, test your laptop with the projector during a break before your demo.

  • Understand that your demo machine may well be a randomly configured rental machine with no Internet hookup that was delivered to completely non-technical people (who are likely as not Windows-hating Mac-lovers) five minutes before you go on.

  • Before the demo be sure and test your program on a variety of machines. Carry a disk with your *.exe around and try to run it other machines. If you're running it on someone else's machine, you should ask permission and, if possible, run the program from your floppy rather than cluttering up their hard drive. Note by the way that WinZip actually lets you double-click on a zipped executable and run it without formally unzipping the file.

  • Bring your program to the demo in more than one medium: laptop, floppy disk, CD ROM, on the Web for download, etc. For a really challenging event “ like if you are flying to another country to do your demo “ give yourself some insurance by bringing transparencies of some sample screens. If all else fails you can show the slides with an old-fashioned overhead projector.

  • If you bring your program on a floppy disk, bring an extra copy of the floppy in case the floppy goes bad. All floppies die, sooner or later. On the same theme, use a new floppy for your big demo.

  • If you do bring your program in compressed *.zip form, bring a disk with an unzipping utility program on it, just in case you need to install the utility on the spot. If the demo is important enough, the demo machine (a) will not have an unzip utility and (b) will not have an Internet hookup that would let you download one.

  • If it's at all possible, get a half an hour of 'quality time' alone with the demo machine and projector so you can properly install your program.

  • Remember that what you see on the screen is not necessarily the same as what goes over the computer projector. Projectors often don't like high resolutions . You can set the demo machine to a lower screen resolution by right-clicking on the desktop and going to Properties Settings .

  • In the case of a Pop Framework program, remember that, as a last measure, there is a File Run Speed... dialog that might possibly help if your demo machine goes too slow or too fast.

  • Imagine the most horrible scenarios you can conceive, and then expect something worse !

  • Don't cry or lose your temper. How you look and act and talk is as important as anything your audience sees, or doesn't see, on the screen.



Software Engineering and Computer Games
Software Engineering and Computer Games
ISBN: B00406LVDU
EAN: N/A
Year: 2002
Pages: 272

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net