I gave my talk at PyCon this year on HTML processing in Python. It seemed to be well received, but I did see some comments on the web from people who wanted more technical content. The presentation I ended up giving was really more about HTML and its place and advantages compared with XML and XHTML. Basically I decided to talk about why you want to process HTML, instead of getting too much into how. I talked a little bit about how, but if you had hoped to hear much technical substance then certainly it would have been disappointing. (As to the slide question, I will get them up, but I want to assemble at least a little of the material that motivated it, since slides alone aren’t that useful.)
I’m not sure what to do for talks like these. In 30 minutes it is hard to go into much depth about a subject. And I’m not sure what the purpose would be. If you want to learn to use a tool you should read the documentation, sit down with a computer, and give it a try. You certainly shouldn’t come to a talk. So I’ve tried to avoid the technical details, and instead try to make people want to learn the "how" on their own. This was the goal of my WSGI talk last year as well.
That said, the whole talk format was unsatisfying to me at PyCon. Lightning Talks are great (or at least, can be great — and I thought on Sunday when all the sponsors were gone, they were great). But 30 minute is too much time for just presenting an idea, and too little time (and a poor format) for presenting advanced content. And that slides are built into the format just makes it worse.
I wish the Open Spaces had been more functional at PyCon. I couldn’t find the ones I wanted and felt conflicted between them and talks (in retrospect of course there shouldn’t have been conflict). I didn’t have a single successful Open Space experience this year, despite trying a couple times.
While the organization of Open Spaces could be improved, I don’t think Just In Time Planning is going to work at PyCon. And I don’t think Open Spaces have to be JIT. What makes them most interesting isn’t that they are totally ad hoc, but that they aren’t just one person talking to a bunch of other people. I’d have been very happy to lead some more extensive "talk" about HTML and XML processing in Python, probably starting out with 10-15 minutes of introduction and survey and then going completely to discussion, Q/A, or wherever the attendees wanted to take it. I would expect a smaller group of people (I guess), as it would be a larger time commitment and attendance would feel less casual than just showing up at a normal talk. Maybe it could be clearly setup so that it was something like 10-15 minutes of introduction, 30-35 minutes of talking, and then a clearly planned structure for people to stop talking (moving on to another topic) or stick around to talk more in a smaller and more intimate space and group. Figuring out where to continue the discussion should not be left until the moment everyone has to choose whether to stay or leave. You’d have to be careful not to let it degenerate into people just asking questions of only personal interest. I’m pretty comfortable generalizing people’s overly specific questions. People who are less comfortable doing that might benefit from a moderator to help them guide the discussion.
This format seems like much less work for me as a speaker (and the stress of speaking greatly infringes on my enjoyment of the conference), it seems more likely to fit the interests of the attendees, and I think it can provide benefit for a much wider range of interests and experience levels.
Anyway, an idea. I’m not sure how things should be structured at PyCon next year, but I’m pretty sure the current talk format isn’t it. A few talks, sure: The State Of X talks can work well, as do talks about ideas and experience instead of talks about tools and libraries. But I think one track could be sufficient.
No related posts.
I did a 30-minute talk about the Python.NET module. Since Python.NET is not a well-known module, I focused more on why people might want to use it, rather than how to use it. I think this is a good strategy: Use the talk to give the introduction and motivation for your topic, including some small demos/examples, and of course allow for a few questions. Then schedule an Open Space sometime after the talk for the people who want more technical details.
However, I think this strategy works well only if you schedule the Open Space before the start of the conference. I scheduled it about a week beforehand to make sure that I could get a decent room. Also, I was able to use this time to contact presenters who were talking about related subjects, so that we could do the Open Space together (Q&A works better when there’s more than one expert in the room). The other presenters and I created a wiki page for our Open Space and wrote out a list of possible things to discuss. We promoted the Open Space on our respective mailing lists. I wanted to make sure that people who attended my talk were aware of the Open Space, so my third slide contained the full details for it.
Because of our preparation, we had a fairly productive Open Space. My only regret is that I didn’t reserve a projector. With the number of people who showed up, we could easily have gone through a short round of lightning talks.
Ian, you make an interesting point about talks that motivate interest vs. talks that dive deep technically. I think one of the points of friction that causes discontent with Pycon talks is that the talk abstracts often sound like the second kind even though the content ends up being the first. For example, the abstract for your talk is a little ambiguous, and there are plenty of people at Pycon who already know they want to consume HTML.
On the other hand, there were other talks that immediately jumped to technical details without giving me any sense of why I should care.
Looking over the pycon speakers’ tips: http://us.pycon.org/2008/conference/helpforspeakers/ , there’s very little guidance on these points.
BTW Ian, good job handling the heckler during your talk. It came up again in the comments on my Pycon notes blog post!
“If you want to learn to use a tool you should read the documentation, sit down with a computer, and give it a try. You certainly shouldn’t come to a talk.”
Spot on! However, when you don’t know which tool to pick and study for a particular task, a talk could give you an idea.
Lots of people have mentioned the heckler. While it caught me a bit off guard, I actually was happy to get a little push-back — made the talk seem a little more exciting ;)
I agree that 30 minutes is too short to actually teach anything – it is about right to give an overview but little more (I enjoyed your talk by the way).
Most of the other conferences I go to schedule talks for an hour. I think mixing it up a bit for talks at PyCon would help.
I thought the lightning talks on Saturday were ok – even some of the sponsor ones. ;-)
Ian, again, I had the same issue… how much to focus on code versus the motivation and overview. I believe the same complaint about the code might have been directed at my presentation. I didn’t hit code until around the 10 minutes to go mark either. And really, it was for a similar reason, I wasn’t going to have time to teach something… I was encouraging the use of something (the django admin interface in my case) for a variety of different problems. What code I did show was to give a flavor for how little was required to get up and going… just to back up my earlier points rather than to teach… and I referred them to my big honking paper which essentially spoon fed them the “how”.
As for your talk, I enjoyed it. I got what I needed out of it. I knew I wasn’t going to learn all the nuts and bolts but that I would get pointed in the right direction with plenty of backup as to why to go in that direction and why it was okay to bother with it all. Very practical and useful to me. If someone was expecting to be taught all the ABC’s for doing something from beginning to end… they must grossly underestimate the complexity of everything in life.
I too was wondering what might make a better talk format for PyCon next year. The only conclusion I’ve come to is that 4 tracks are way too many — even last year’s 3 tracks seemed easier to handle. Also, I agree that open spaces and/or sprints seem the most useful, although I didn’t have enough time to make the most of them this year. As for talks that teach you or introduce you to a tool, I find that often I want to read the documentation for a tool but for whatever reason never get around to it. For example, I’ve always been curious about pyglet and Richard Jones’ talk on it this year was amazing. It didn’t fully explain how to use it of course but gave enough “cool stuff” to get me interested and also enough technical details to answer the question “why pyglet?” (like, how all the bindings are mainly done with native OS components for efficiency). I probably could have gotten this all from reading the docs and viewing demos but I feel my experience justified the talk.
AFAIK, there are two primary values in conferences: 1) Networking 2) Presentations that quickly help you decide what to invest more time researching (and what to skip!)
You can’t hope to teach in short talk. Instead help the audience understand that the topic really is/really is not valuable to them and tell them where to go for more info if they want it. If that is “all” you managed to do then Bravo!