Superficially, a popular public demo is every technologist’s dream. It’s the one opportunity that one gets to show off one’s work to the public at-large, get praise, feel one’s work is important to the world… all of that.

Scratch that surface and you’ll see why demos can be tiring, frustrating events with very low RoI unless they are handled well (Sidenote: RoI is return on investment: working for Microsoft has bestowed on me a deep affection for three-letter acronyms).

Last week, I was demo-ing at TechVista, a Microsoft Research event here in Bangalore. The event was remarkably well organized, and wonderfully crowded– work we put in over the last few months was finally seeing the light of day! While I’m happy with our demos in general, the experience taught me a lot about how to handle crowded demos, and I’m hoping to share and learn more through this blog.

I must clarify this post is NOT about how to give great demos, but about avoiding common demo problems (my ultimate goal is to become the next Pranav Mistry — but I’m so far away from that goal!)

In this discussion, I’ll use “SmokeAndMirrors” as the name of a fictitious project  you’re demo-ing. Below, I talk about potential problems we’ll face demoing SmokeAndMirrors, and ways I’ve thought of to mitigate them. Please add your own suggestions in the comments.

Crowds

The number one problem with public demos are the crowds. Frequently, the demoer is mobbed. What’s worse is that people don’t arrive all at once– they keep trickling in. The traditional model of a talk falls flat: you can’t repeat since the folks who’d arrived before are bored, you can’t continue since the folks who were “late” don’t get the context you set up at the beginning of your talk.

The solution I have is to stay in a constant recap mode, briefly summarizing the talk every 15 seconds (approx): “As I mentioned to you earlier, the idea of SmokeAndMirrors is to…”.

Another help is a putting up a poster that explains SmokeAndMirrors so visitors get in context.

A related problem is that researchers (and other folks in technology) are trained to listen. This means that everytime someone in the crowd starts talking, the demo-er begins to listen, losing the flow of the practised talk, and generally making room for confusion. Should this happen often enough, the demo booth would be left with a babbling crowd of visitors discussing Microsoft-vs-Apple (or something similarly inane and irrelevant.)

In my demo, I tried to encourage people to ask questions at the end, but man, it’s hard to interrupt people when they are speaking, and harder still to listen to a question and not answer it right away.

Low attention spans

A crowd’s attention span seems to be determined by that of its most impatient member. These are the folks who will interrupt and ask  ”How does SmokeAndMirrors compare to Adobe Photoshop?” regardless of whether or not SmokeAndMirrors is related to photos. Hate them you might, but these guys aren’t an endangered species.

I think the best way to combat this is to keep the basic demo to less than an “impatience threshold”. Let me hand-waive and say this limit is around 30 seconds. 1 minute tops.

Anything more you should answer through your Q&A session at the end. Keeping the demo short also helps with the “trickling crowd” problem above.

The colors aren’t important!

This one hurts. You enthusiastically show a demo of your super-cool SmokeAndMirrors project and people get fixated on something minor and irrelevant– like, you know, the color scheme you picked, or something that bounces as you move it across the screen.

And then they’ll get distracted.  And they won’t pay attention to your demo. What’s one to do? My way is to repeatedly remind people to not focus on colors or bouncing shapes or whatever is likely to distract them. I like this method, though it makes the job tiresome, because I want my demo to look good. (Alternatively, you could make your interfaces really boring, devoid of color etc, but…so ugly!)

Visitors getting distracted is also a hint that the demo pitch is weak and needs to become crisper.

When will it be released?

If your demo is well-loved, someone will definitely ask this. Sadly for the interested visitor, you’ll rarely know the answer. I hate questions I can’t answer :X

Grin and bear it.

OMG, is it going to crash?

My greatest fear. Unfortunately, when your demo crashes; your visitors get distracted, and until you get the demo up-and-running again, have time to ask (often irrelevant) questions (e.g. your opinions on Windows 7 stability).

Why squander time? Next time, I will have a backup spiel for when the demo crashes (and crash it will: if it didn’t, we could ship it already). My idea is to use this time to make meta-points about the demo, painting the bigger picture that might be missed in the demo otherwise.

Is it worth it?

Trust me, it is. Besides providing great feedback, demos are a great opportunity to make your work understandable to the public at-large and convince them that yours is an idea who’s time has come (sorry, couldn’t resist ending the post by vandalizing a Victor Hugo quote– On résiste à l’invasion des armées; on ne résiste pas à l’invasion des idées– here is one thing stronger than all the armies in the world, and that is an idea whose time has come).

PS: The project we demo’ed at Techvista is called Digital Heritage.