DITA for presentations, aka how to avoid PowerPoint
After a number of years using PowerPoint and OpenOffice/LibreOffice Impress to create slide decks, I’ve grown frustrated with the enforced separation of information in PowerPoint-like products.
There are slides, there are notes, and there are handouts, but there’s no way to integrate the three. Additionally—at least in LibreOffice—I found that printing handouts never worked the way I wanted; I always ended up printing the slides six-up, rather than using the “handouts” option.
One day the thought occurred to me: what if I could use DITA topics for my slides?
And how might the DITA tagging look? Most slides are sets of bullet points. If I could integrate the bullets for slides with additional notes for readers, I could generate two different types of output for different uses: a set of HTML files containing the bullet points for the slide deck, and a PDF containing integrated bullet points and notes as handouts.
This meant that I needed to develop a set of rules to distinguish between information intended for slides and information intended for notes. The easier the set of rules, the easier it would be to pour information into DITA topics without having to apply extra elements or attributes. Perhaps elements with an implied purpose flies in the face of semantic tagging. For now it will do. If I feel driven to it, I can always create a slide specialization that attaches more specific names to the elements.
Initially I considered using section elements for each bullet point (the title element would contain the bullet text; the rest of the section would contain the notes). However, the title element is fairly restrictive in its content. I could foresee being hamstrung by some of these limitations.
In the end, I decided to use a simple unordered list (ul element). But how to distinguish bullets from notes? Mixed content is a beast that can confuse writers and annoy transformation developers. I’ve tamed the beast more than once; now is the time to make it do my bidding. These are the rules I use:
- A basic slide topic contains a ul element with one or more list items (li element).
- The initial content in a list item is untagged text. The text is transformed into a bullet point when generating slide output.
- Any element inside the li element—except the paragraph (p) element—is used to create slide output. These include note, table, image, codeblock, and nested ol or ul elements.
- A p element inside a list item (li) is ignored by the slide transform. However, when using the pdf transform to generate handouts, these p elements are handled normally and display as notes on the bullet points.
- Nested lists behave in exactly the same way.
- Because there are always exceptions to rules, I allow two outputclass attribute values:
- If a p element has outputclass=”slides”, the element is output in the slides.
- If any element has outputclass=”notes”, the element is not output in the slides.
There are a number of advantages for encoding my slides this way:
- My notes are integrated with my bullet points, so I can edit them both at the same time.
- My notes allow me to create useful handouts that provide far more information for students than a simple set of bullet points.
- My content is no longer locked into a binary format. I can write transforms (or take advantage of existing transforms in the DITA Open Toolkit) to generate many different forms of output.
- If I want to change the appearance of our slides, I can make a small number of changes to the transform, rather than hassling with importing templates into slide decks.
- I can use the DITA filtering attributes to create slides that cover the same topic for more than one tool or platform. This is a really big win.
- Much as I hate to say it, LibreOffice Impress crashed on me once too often. While I rarely lost any content in these crashes, they were frustrating and time-consuming.
Slide decks often contain special “master pages” for the title slide, section slides, and slides that direct the students to work an exercise. An outputclass attribute on the topic element allows me to specify a master page. Most of these master page attributes are implemented in the CSS, so I can add new master page types by adding new selectors to the CSS.
As a finishing touch, the output HTML includes links to the previous and next slides as well as a link to a table of contents. To make presentation easier, the HTML slides respond to ENTER on the keyboard and keypad to advance to the next slide and Backspace and keypad minus (-) to return to the previous slide.
Of course, there are detractors from the whole idea of using slides in presentations; Edward Tufte has been decrying them for years. As today is the sesquicentennial-minus-one of Lincoln’s Gettysburg Address, this might serve as a fitting example of why: http://www.norvig.com/Gettysburg/index.htm
Have you considered generating slides from DITA? What advantages have you found?
I also did some small amount of work into XML based slides but I started with a simple format, not DITA. Basing your slides on DITA should be even better, I think.
Do you have any plans of opening your work in any way?
Hi George. That really depends on how much interest people show in it.
Great minds think alike. 🙂 I did something similar myself. I went a step further and specialized topics so that I wouldn’t have to remember outputclasses or get quite as tricky with my XPATH selection but I wound up with a slide that had an optional note section. I didn’t bother with an HTML transform because I found that I really only needed a PDF transform and set it up so that based on the outputclass on the map I could deliver slides or slides and notes complete with the appropriate background image.
I wound up using tables to handle slides with text and images on it which restricted the size of the image but allowed consistency in the textual presentation.
It was fun as a first specializtion. 😀
Hi Julio. I can see some strong advantages in creating a specialization, so you’re on the right path.
I am surprised that you went the PDF route for the slides. My longer-range view is that I might not necessarily be displaying my slides on my laptop, so I didn’t want to be locked into any particular page dimension. HTML gives me that advantage (and I can go to ePub fairly easily, should I need to).
Great idea, but it does make me think about something. The way you’ve set it up works great for a 1-man team where everything is controlled by you. But once you’ll want more people to use it, the sort of “magic” you introduce by hiding elements inside list items in the slide output will bite you.
You will have to communicate that additional logic to other people using your stylesheets, and every new rule you’re creating makes adoption harder because content authors should not only learn the tagset, but also your special (mis)usages of them.
Do you see the problem? Do you have any thoughts how to prevent this?
Oh, absolutely. That’s why I said I might eventually create a specialization to support slides. At that point, I might even drop the mixed content, so a “bullet” element would probably contain “bullet paragraph” and “bullet note” elements. (I’ll have to think through the actual naming.)
How would one include the animation effects authoring in DITA?
I developed a similar process. I chose to focus on a PDF output mainly so that if my team were asked to share the slides with another group in the company, we’d only need to share one file, not a set of files and images, etc. You wouldn’t think multiple files would trip folks up, but, well, yeah…. I did not specialize, but used @outputclass in various ways. Like you, I have a small but strict set of rules governing what elements can be used and how.
Rather irritatingly, some large tech comm conferences that make presentation content available to attendees afterward use software or services that are not compatible with any slide format other than PowerPoint. At least, that was the experience two/three years ago. Perhaps it’s changed.
I know, this is an old post, but if anyone stumbles around here looking for an answer, please have a look at this plugin https://github.com/doctales/org.doctales.reveal