April 2, 2009

Bulk view

Remote presentations that rock: Challenges and opportunities of remote presentations

How are remote presentations different from in-person ones, and how can you make the most of those differences?

Plan for different channels and attention levels

Unlike at in-person conferences, you don’t have a lot of control over how people experience your presentation. Some people will be connected to the phone conference, but won’t be able to view your slides. Some people will be part of the phone conference, but not the Web conference, so they’ll need to change slides themselves. Some people will read your slides in order to catch up on parts they missed. Some people will listen to the recording after your session. Some people will just read your slides.

As much as possible, plan your talk so that you can make the most of the different ways people will receive your message.

To accommodate people on the phone, do not rely too much on visual aids, and explain important points out loud. Indicate when you’re moving to the next slide. Include the slide number on all pages of your presentation.

To accommodate people who may drift in and out of your presentation, verbally and visually emphasize important points, repeating as necessary.

To accommodate people who are reviewing the slides or recording, write an article or blog post with a more coherent version of your presentation.

Build interactivity into your presentation

At first glance, remote presentations may seem less interactive than real-life ones. You can’t see body language, and it’s difficult for people to interrupt during a conference call. However, you can still build interactivity into your session, and you should. Here are some reasons why and some tips for doing so.

  • Both real-life and virtual presentations benefit from the increased engagement and energy of interactivity. Your session is competing for attention against e-mail, instant messages, and other distractions, and interactivity gives your session an extra punch.
  • You don’t have body language cues to tell when people are interested or bored, and it’s not as easy for people to interrupt with a question. Interactivity gives you a way to check the pulse. Ask questions, conduct polls, and get people to share their stories.
  • Different opportunities for interaction open up with a remote presentation. You can ask people to share their thoughts and questions during the presentation instead of waiting for the end, and they can answer each other’s questions or discuss topics themselves, too. On some web-conferencing systems like Centra, you can even ask people to annotate the slides, or to break out into groups and discuss things there.

Don’t be afraid of a little silence on the line. What seems like an uncomfortablely long silence to you gives people time to think about what they want to say, and eventually pushes other people to say something.

When asking people to interact, I find that it’s often helpful to encourage people to use the text chat. That way, more people can share their thoughts without trying to figure out whose turn it is to speak, and this also brings in shyer people. If your phone or web conference allows people to raise their hands, you can use that to queue people for speaking as well.

As you become more comfortable with building interactivity into your remote presentations, you’ll find that you’ll learn as much from the participants as you share with them.

Talk one-on-one

In a session called “Presentation Secrets of Comedians and Stage Performers to Keep Audience Attention” at last year’s IBM Technical Leadership Exchange, Barclay Brown shared a story about watching a presenter make the mistake of wrapping with “Thanks, you’ve
been a great audience.” He explained that although speakers might see themselves speaking to an audience, listeners think of themselves as individuals, not a group. Good speakers make that one-on-one connection even with hundreds or thousands of people in the room.

In a virtual presentation, the perception of being an individual is even stronger. Your audience members don’t see the other participants. Pay attention to the words you use so that you can make the most of that one-on-one connection. Use sentences like “Have you ever experienced this?” instead of “Has anyone here experienced this?” You can still summarize group results, but keep that one-on-one mindset as you go through the rest of your talk.

Provide next actions

Think of things people may want to learn more about or do after your presentation, and take advantage of the fact that most of your participants will already be on a computer. Give them a URL where they can find out more, take the first step, or even fill out a survey about the session.

Hope that helps! Feel free to ask me questions – I’ll come up with more tips that way. =)

Lessons learned from this phase of our Drupal project

Not only has my sleep cycle been thrown out of whack, but I’ve also broken out in pimples.

Clearly, we can get better at managing the crunch time around deployment.

The last time we deployed, there were a few tense moments, but our rigorous test-everything-from-a-production-install process helped us do it smoothly. This time, not so much. Here are a few reasons why, and here’s what I can do to make things better.

  • I had set $access_check to FALSE because I wasn’t sure if we could get in to update the system. The IT architect logged in as a super administrator and ran upgrade.php. However, since $access_check was FALSE, it apparently didn’t check at all if the user was logged in as a super administrator, and so we ran into bugs that assumed account 1 was running the update (related to node saving). Symptom: The updates ran, but some updates didn’t get fully applied. We only detected this the day after (the perils of doing an evening deployment when you’re tired). I thought that just reloading the database backup and reapplying the changes (properly, this time!) would’ve been a cleaner way to do it, but my other team members voted for manually fixing things. So that was stressful.

    The problem occurred a couple of times during QA testing, which is how I realized that update.php was misbehaving. I wrote about it, but I didn’t review the other developers’ code for potential issues, and I didn’t emphasize the potential pitfalls during our meeting.

    To do this better next time, we can come up with a more formal and regular code review process, and I can communicate more explicitly. We could try to always run update.php with $access_check = TRUE, but it may need to be false in some case in the future, and it’s better to be aware of potential problems.

  • After we deployed, we found out that a subdomain we were using hadn’t been set up in DNS. We were no longer in control of the domain record because we had turned that over to the nonprofit partner who was supposed to be managing the site.

    To do this better next time, we should make sure our QA and production setups are as close as possible (we had been using wildcards for QA), and we should test new domains.

  • I had been in crunch mode for 10 days (since the weekend before). It’s difficult to maintain sprint-like energy and focus for that long, and I was feeling physically fatigued after I stayed up relatively late to finish the deployment.

    To do this better next time, I need to insist on taking breaks, even if it doesn’t seem to be being much like a team player. Also, I need to reset my sleep cycle as quickly as possible.

During deployment, I also learned to:

  • Give people feedback and send them patches instead of just fixing the code for them. I don’t get fazed when code changes underneath me. I’ve worked with too much open source, I guess. I just try to figure out what changed, why, and how to work with the new structure. Other people can feel alienated from their code, though, and they lose that feeling of ownership. Better to hand things over to other people, perhaps with a few tips, even if it means it won’t be finished as quickly.
  • Communicate changes more often and more explicitly. I liked having a Sametime group chat running. I don’t like sending lots of e-mail, and having the chat made it easier for me to keep others in the loop.
  • Make sure tests are up to date, and run them regularly. There were a few bugs I missed because I hadn’t run the test suite, and I hadn’t run it because it takes a lot of time on my system. I should make the time to do that (using it as break time if necessary), and I can also set up a testing environment so that other people can run the tests easily. Speaking of that – I spent nearly a day tracking down failures due to other people’s changes because they didn’t verify their work against our test suite. I need to figure out how to build more common ownership of our test suite, and how to get them to run the tests themselves. The SimpleTest web interface is okay, but it’s still not as convenient as Drush. Maybe a line item in our administration interface… Hmm… Next time, I could also set up regular tests that e-mail us the results.
  • Build little tools to help. Instead of analyzing the source code by hand in order to come up with the number of lines we changed (needed this for IBM Legal), I wrote a tool that analyzed our source code based on the Subversion history. It was pretty cool. It took me about 30 minutes to write, and we ended up running it twice. I expect it would’ve taken us three hours to do that all by hand. Yay! =)

So my key things for next time are:

  • Make sure developers know about the gotchas we encountered.
  • Set up an automated test environment and make sure other developers take ownership of the results.
  • Keep a group chat running. I participate in that quite a lot. E-mail, not so much.
  • Take more breaks.

Becoming a better developer, one step at a time…