What’s holding back presentation software?

I can’t think of one thing I do with presentation software today other than creating PDFs that I didn’t do ten years ago.

We have Microsoft PowerPoint, we have OpenOffice.org Impress, and IBM’s Symphony. Over on the Mac we have Keynote. Toss in a few others such as KOffice and we have the office productivity market.

These all have value to their users though if though don’t support ODF, the Open Document Format, in a first class way, I don’t care too much about them. On a regular basis I use Symphony and to a much lesser extent OpenOffice.org and Keynote.

I don’t view presentations on the web as a matter of course, though I do look at SlideShare occasionally. I probably get a dozen presentations a day for work. Unless I’m going to edit them, I want them in PDF format. Otherwise I expect ODF.

The software for creating and deploying presentations have changed very little in the sense that we create blank slides, use templates and predefined layouts, add text and images, and fiddle with fonts and colors. Depending on the application you choose, this is more or less easy.

If you were to create a new desktop presentation application from scratch, what features would you put into it? What would you do differently compared with the apps above?

I’ve addressed some of these ideas before in “Presentations: Still too hard to mix and match” and “Presentations: The death of complexity”.

Here’s an idea of what I would do. Note my usual disclaimer that these are my own opinions and not those of any IBM product group.

• Forget backward compatibility with the Microsoft formats. I understand that for some of you this is a non-starter, but this is my app and I’m starting with a clean slate. I have no interest in supporting the huge number of features that minorities of users need. I also don’t want to support all the failed formats contained in OOXML. Therefore it all goes.
• I would support ODF natively, but look at understanding the subset, if possible, that I would need.
• Excellent PDF export is necessary.
• Like applications such as Firefox and WordPress, I would have a well defined and documented architecture for extensions and hooks. The goal is to keep the core small, tight, and well understood. From there we would drive a third-party market for tools that extend the core. These could include input format filters and export plugins.
• I would use Python as the macro language in the presentation editor.
• While I would target the desktop, the architecture must facilitate multi-touch interfaces such as the iPad and the upcoming Android tablets.
• I would not prioritize support for devices as small as a smartphone.
• The display engine would be cleanly separated from the core components. For the desktop, I would start with a Linux port, then do the Mac, and finally Windows.
• Themes and presentation documents need more metadata to make it simple to switch themes easily and accurately. That text box at the top of a slide in a big font is not assumed to be a title, it is known to be a title because of the information associated with it. This also allows me to create and manipulate presentations programmatically, even on servers. No guessing about slide structure is allowed.
• I need to be able to manage groups of one or more slides for reuse, with versioning. It is still far too difficult to create libraries of slides and then put them together when necessary into new presentations. Slides and groups of slides need tags. For extra credit, slide groups might have suggested dependencies so you know, say, that you should not include these 4 slides without showing those other 2 first. Similarly, one group of slides might be indicated as being the in-depth expansion of another group.

What am I missing? What would you do differently?