The Joy of Flex

Note: this list is mainly for my own future reference. I assume anyone who has much speaking experience knows all this stuff.

Here are a few things I learned as a result of giving my Buzzword talk at 360|Flex.

Be animated. Stand and walk around as much as possible. Vary your voice to keep people engaged and remind them to listen. Catch your audience’s attention over and over again.

Be spontaneous. As the speaker, you have a unique vantage point from which to see what’s going on in the room and make it better. So pay attention to what’s going on in the room. Are people getting bored? Do something different. Is a conversation breaking out among audience members? Facilitate it, don’t shut it down (unless it’s off-topic or uncivil). Are there empty seats up front and people standing in the back? Invite them to come in and sit down. Be willing to put your material on pause for a few moments and go off on a tangent.

Don’t read your slides. A slide deck is a very useful tool. The slides remind you of the points you wanted to hit. They let your audience get behind and then catch up. They facilitate note-taking. And if they are available for download later, they relieve the audience of the need to take notes at all. But if all you do is read them aloud, you’re not adding value. Instead, glance at each slide as it comes up, read it to yourself quickly, and then look at your audience and talk. If you forget to say something on the slide, don’t worry about it — your audience saw it on the slide and if they want you to talk about it, they’ll ask. It’s more important to say what the slides don’t say.

Repeat yourself. Assume that most people in the audience are only listening about half the time, maybe less if they are all on their laptops. Repeat your important points a couple of times and then come back to them some more, later in the talk.

Use a remote control. I used a MacBook with PowerPoint for the slides and Sofa Control to enable the Apple Remote to drive the slides. It’s distracting to your audience to have to watch you run back to your laptop to advance each slide, and the alternative of sitting at your laptop and talking from there makes for a much less visually engaging talk.

Practice your demos. It’s hard to speak clearly in complete sentences while operating a computer. The more times you practice your demos, the more smoothly you’ll be able to talk, mouse, and type at the same time, and the less likely you’ll be to make a time-consuming and embarrassing mistake in front of a roomful of people.

Try to have more material than time. This is hard to do until you actually give the talk for the first time. I had no idea whether I had twice as much material as time or vice versa, and I would have thought either was equally likely. It’s especially hard if your talk has demos in it where you go off the slides for a while, because then it’s harder to use the number of slides to estimate. For my 80-minute talk, I prepared six in-depth topics for which we were going to demo the feature, discuss the design of the feature, and then look at code. We only had time to talk about four of those topics, and only went into the code for two of those.

Ask lots of questions. If you want people to ask you questions, you should ask them questions and set an interactive tone, especially toward the beginning of the talk. Questions of the form “raise your hand if you…” are easy. Asking technical puzzlers is good, but make them relatively easy; it’s fine if half the room shouts out the answer, but if they are too hard and no one knows the answer, it kind of falls flat.

Answer lots of questions. Unless you are truly a presentation Jedi master, your audience is at least as likely as you, or more likely, to know what they want to learn. So the more time you can spend answering their questions, the more likely they are to go away feeling like the talk was of value to them. I found it very helpful to insert slides throughout the talk that read “Questions?” in big bold letters. I think it encouraged people to think about what they wanted to learn.

Ask someone to write down the questions that are asked. That way, you can go back and review whether some of that material should be covered in future versions of the talk, and at the very least think about how to answer them the next time they come up.

Here are the questions that were asked at my talk:

1. What’s a “run” – Document Internals slide
2. How did you come to the concept of a run? (binary tree primitives)
3. How long has this project been in development?
4. Are you using a flyweight pattern for managing runs?
5. How big is the app?
6. What has been your experience with managing memory/profiling?
7. What are “hips”?
8. Printing?
9. What is that icon? (comment icon)
10. What information do you care about in the (test) snapshots? (document and layout)
11. How are you running your tests? How do you enforce them in the dev process?
12. Do tests need to be retrained when changes are made to the API?
13. Do the command script generators (test framework) need to be updated when the API is changed?
14. How is undo handled? (you mentioned coalescing)
15. Do you “undo” text selection? (yes)
16. Can you show us a command and how it emits its own test code?
17. How do you handle updating the cached swf files (modules)?
18. Do you test backwards compatibility when pushing new modules?
19. Does the browser accumulate past versions of the swf modules?
20. Can you talk about the project structure (in flex builder)?
21. How are you communicating with the backend?
22. How much chatter is going on behind the scenes while the user is working?
23. Can you discuss issues you had with fonts?
24. Localization?
25. Do you have a dedicated designer?
26. Where did you have to write your own ActionScript to improve performance? (effects, renderer caching)
27. How much logging of user activity do you do?

Technorati Tags: 360Flex, puppy