Tag Archives: presentation

TED Talks: The Official TED guide to public speaking

Over the years my job has required me to do varying amounts of public speaking. A few years ago I was doing it weekly to audiences ranging from a handful of people to dozens. I’ve done less recently but it’s something I wanted to get back into, hence this book. TED talks are slickly produced and the speakers almost always appear to be, at the very least, competent, and usually much better than that. That made “TED Talks” a good place to start.

While reading the book I ended up speaking at a conference and I was able to put some of the lessons into practice. Of course I’d only read half of it so I did make some avoidable mistakes. However, it also showed some practical limitations of the book: naturally it’s about the kind of talks given at TED, but most people rarely do that.

My talks are often given at fairly short notice, frequently with a “standard” slide deck that you’re not supposed to edit significantly. The last talk I gave was written entirely by someone else and I only had the time to adjust the slides to work with my delivery style better.

Other than the logistics, the subject matter also differs. If you gave a presentation about your companies product roadmap in the style of a TED talk you’d get laughed out of the room! (That doesn’t stop so many companies trying to ape Steve Jobs, but those are usually also seen as inauthentic.)

And, perhaps unlike at TED, at most places you don’t get to choose how the stage looks. I like to walk around a little. This, I feel, makes the presentation look more dynamic but also means that I can’t look at my notes all the time and I have to engage with that audience; double win! But you can’t always do that. Maybe the stage is too small; perhaps they’re recording and they don’t like you moving out of shot continually; maybe the microphone is attached to the lectern.

What I’m saying is, while the advice is probably great for when you give your TED Talk, you’re going to have to allow for a much greater degree of outside control for most presentations you have to give.

But overall, the advice is good. It covers everything from how to structure the talk, to preparation (including your slides, and whether you should even use any), stage presence, voice and how to work best with your strengths and weaknesses.

Where it lost me, though, are the last few chapters (“Reflection”). After talking about how to give a great talk only at the end does it discuss why it’s important and why you should do it. The little bit of TED history is quite interesting but the book probably could have done without it — presumably if you’re reading the book you’re already convinced — or maybe put it at the beginning as a form of motivation for reading the rest.

Ironically, people who don’t want to ever give a talk are the very people that the last section is really aimed at, unfortunately they’re never going to read it.

Of course, that’s mostly a quibble in an otherwise decent guide. Not everyone is going to want to give talk, but if you do it’s worth a look.

What you forgot from your Computer Science Degree

Last night I did a short presentation about my WSLHTMLEntities open source project at the London iOS Developer Group meeting. You can see the slides here:

Since last time I did a talk there people snickered because I built the slides using PowerPoint, this time I decided to use the latest Apple technology: Keynote in iCloud. Unfortunately this was a bit too new for the Mac Pro they use in the Apple Store, so we ended up downloading a copy in PowerPoint format and loading that into the local copy of Keynote. Nothing is ever simple.

One question I got at the end that I was unable to answer is how well it performs compared to other solutions.

This afternoon I ran a few quick tests.

Firstly I added two further methods of performing the HTML entity replacement:

The last option, while built-in and easy to implement, is not something you’d want to consider if you had any performance requirements. First, it has to run on the main thread. Second, it’s memory footprint is way higher than either of the other two solutions. And, finally, it’s slow. In my tests I did a loop of 10,000 iterations. Because of the memory problem I only ran 1000 iterations of the NSAttributedString solution, but it was still about 15 times slower than my version when doing the full 10,000 records (i.e., over 150 times slower overall).

So I’ve not included it in the charts below.

HTMLEntityChart

I ran eight simple tests with each of the parsers.

There is no clear winner.

As I speculated, WSLHTMLEntities is much more consistent than the other two. Google’s varies a lot depending on where in the mapping list the “solution” lies. Replacing ◊ (near the end of the list) takes 50% longer than & (near the beginning) for example.

Still, you’d have to be pretty obsessive to pick one of these solutions for performance reasons alone. Interesting to find out, though!

Familiarity Breeds Contempt

This week I did a presentation at the London iPhone Developer Group meeting. Given my experience with using lots of APIs, I thought it might be a good, if dry, topic. I tried to spice it up by complaining about lots of them and trying to condense that negativity into some useful lessons to take away.

Most of the other discussions of this subject that I’ve seen focus on designing libraries but I thought the same lessons could be applied to all kinds of interfaces, from Objective C libraries to REST API’s for connecting to web services. (I don’t mean to suggest that the focus of the two articles I link to is wrong. They’re both very much worth reading.)

You can see a PDF of the slides here (though they might not make much sense without what I was saying at the time), but the gist is as follows:

  • Design your APIs around use-cases. Many appear to be designed around “how can I made the data I have available.” This is the wrong way round
  • Clients need to access data in a predictable, reliable way. Being clever accepting any old junk and trying to do the right thing is often not the right thing to do
  • Communicate how it works and how it’s going to change clearly. Examples and sample code are always useful
  • Think about error cases. “Something went wrong” is not a good error message
  • Think about the devices that people are likely to be accessing your service from. Mobile apps have latency, bandwidth and CPU constraints that desktop computers and other servers do not. The iPad 4 has more resources to throw at a problem than an iPhone 3GS. Your code might need to work on both
  • Be consistent. Make your API look like other, similar APIs and use the patterns of the technology you’re using. That means delegates and return codes for Objective C, inheritance and exceptions for C#
  • And, most importantly, use your own API. Don’t keep special “secret sauce” for your self. How else are you going to know whether it works than by actually using it?

Ideally I’d end a presentation (or blog post) with salient advice on the best way to do something. This is an exception. I don’t think there’s a one-size-fits-all solution and I’m generally weary of Best Practice guides.

So I’ll end by noting that poor APIs result in poor applications. It’s worth investing the time and energy in doing it well. Your users and your future self will thank you.

My delicious.com bookmarks for March 13th through March 14th