Your spoken paper cannot be the same as your written paper, both because time is too short and because written papers are often extremely boring to listen to when they are read out. Remember, your audience will be able to read the full conference Proceedings online prior to your presentation, and to refer to afterwards. Use your face-time with them to highlight your best points, and your original contribution to the field.
What Not to Show!
All MW attendees have access to the Web and can visit your Web site by themselves. DO NOT conduct a general tour. If you’re giving a paper or mini-workshop, it’s because you’ve got an idea or issue to explore. If you’re giving a Demonstration, think about a quick path through some relevant sections to highlight your achievements.
What to Show?
On the other hand, your colleagues DO want to see the concrete implementation on-line that is the focus of your paper. Showing them, rather than telling them, will be much more interesting and will help them appreciate what you have done. If in doubt – NEVER tell something with a bullet if you could be showing it in action. MW is a conference about connected technologies and the communities they serve – you will have fast connectivity, and if you want you can cache your content to make it even faster. Especially when describing interactives or processes, show how the network actually makes it work.
Exploring Novel Ideas
Your written paper probably has a section establishing the background – telling the audience about your museum, about your funding, about the team working on your project. Please DO NOT use your time at the podium to tell the audience these things. They are all fellow professionals who have come to MW to hear what you have to say – they can read the background for themselves.
Reference Other Work
This isn’t just show and tell. Help your audience by positioning your work in the context of others. What did you build on? Where did you depart? What’s your unique contribution? Make it clear that you are aware of the contributions made elsewhere, and that you didn’t just “re-invent the wheel.”
Your colleagues are fairly technical people, but no one can easily listen to large amounts of technical detail and absorb it. This will be easier for them to get from the published paper. What they do need to hear is often best presented with diagrams. In spoken presentations, data in tables can be understood more easily as charts – architectural diagrams and high-level flow charts are better than code. If the point of your paper is itself highly technical, try to explain WHY it is different from other approaches and WHAT RESULT to expect. Leave the listener wanting to find out HOW to achieve it by reading your paper later.