A Blog for Graymad

Think Cooking Demonstration...

Start with File...New...

Do while not complete

- Add a thing or two here and there...

- Close that project and open a new one with a few busywork steps already done. Run it to show what's been done behind the curtain.

Loop

This works best for complex examples.

I would like to see two people building a demo project at the same time (on separate laptops). That way while one person typing away, the other can either explain what the person is doing and even test their code, or also be coding. One person does the UI, the other does the backend.

Dylan,

Thanks for the feedback, I'll keep that in mind. I also like the idea of a tag-team programming demo, but that one's going to have to wait, as Jeff and I are each doing two separate presentations during the pre-con day. Jeff and I aren't anywhere near each other geographically, so trying to co-ordinate rehearsing for combined presentations would've been logistically challenging to say the least. The good part is that I get to see Jeff's presentations, which I'm sure are going to be excellent.

Don's Law:

Don't show any code you don't write on stage.

Rob & Scott's Corollary:
Sometime copy & paste is a good thing -- but explain why.

No help, I know
TTFN - Kent

As you give us ample opportunity to ask for the "perfect" format, here goes my 2 cents:

- A minimum of slides, with diagrams or graphics showing things like architecture, purpose and relationships. No bulleted text if at all possible.

- Small examples created live showing that basic concepts are really simple to use.

- One sophisticated example where we can see how the whole thing works in a realistic scenario and how you are supposed to use the new feature together with things like exceptions, logging, etc.

I know this is probably too much to ask for (especially the last point) but if you do it I will certainly blog about it!.

Scott Cate told be the best way to do it was to put your code snippets in the VS.NET toolbox in order and drag them onto the page. It's pretty quick and gets the job done.

I hate seeing the presenter futz around writing code. If you're going to do it "on the fly" make sure it is simple enough that you can type it out quickly, and without error. I went to a presentation a while back that was given by a guy from developmentor (sorry, can't remember the name). Not only did he do all his code demos all "on the fly" but in notepad, compiling with the command line tools. I think everything he wrote compiled and ran without error the first time (except maybe once where he forgot a ; or }). I don't think he even intended to do it that way, but he had some problem with VS.NET at the start of the talk, and just "dropped back to command mode". His code samples were all short, and it was a really good presentation.

Joseph,

You describe the classic DM style - that style is slowly but surely becoming the MSFT style - most Indigo talks will go that way and I know that at least ChrisAn has the bug.

My work here will be done when the exec keynotes all work that way. So far I know of one that is heavily leaning...

DB

I think it varies by the material. I generally prefer the minimal slides and heavy writing code type of talks. The problem is that I've seen some people not prepare adequately for this, or maybe its just that they keep adding stuff at the last minute that isn't up to par. On the other hand, there is nothing wrong with some of the talks that are oriented around tips, with alternating slides and pre-built code. I think there tends to be too many of these though, i.e. some of the tips aren't that special. Either way, don't try to cover every imaginable feature or tip that you think you can fit into a talk, since it just won't happen without rushing right past your listeners. And my biggest pet peeve (already said, but) -- prepare prepare prepate and don't add stuff at the last minute -- presenters look like idiots when they can't get their stuff to work and no one learns anything from such frustrating talks.

Wow! Thanks, everyone, for the great feedback...keep it coming!

I should be clear that my demos are already done for the most part, so at best I'll be tweaking based on the advice given here.

It does seem so far that there's a pretty wide variety of opinions on this subject.

I'm in agreement with Joseph that watching someone "futz" with code can be annoying, but that when someone's good at writing code on the fly, it can be fun to watch. My concern with trying this style myself is that I'm a fairly crappy typist, so I'd hate to put people through watching me hit the backspace key repeatedly. :-)

I am thinking about refactoring some of the demos to remove boilerplate code to a separate business class in order to boil the individual examples to more of what's specifically relevant. This would also make it easier to write those examples on the fly. Does that sound like it would be useful?

Here's some more comments:

1) Real-world demos. Don't make a Media Player. We already have one, and most of us don't need to make our business applications play videos or MP3s.

2) Use real Internet servers. Don't set up a fake Bookstore.com. Use Amazon. Or Google. Or Slashdot.

3) Use non-Microsoft software. Build a web page using Macromedia MX. Get data from Oracle Apps Server. Show the web page in Mozilla.

4) Have somebody else on stage playing the part of the audience and ask you questions when he thinks you went too fast for the audience to understand what you are doing.

5) Remember that some people in the audience are Visual Studio .NET experts and some have never used anything besides JBuilder.

6) Explaining a demo to our boss is as interesting as watching powerpoint slides. Make sure we can show our bosses the demos, either live sites or WMV9 files hosted on MSDN and/or your blog.

6) I won't be able to make it to the PDC, but I am in the target demographic. Make people like me can find, view, and comment about the demos.