Way Beyond Powerpoint: XML-driven SVG for Presentations

Microsoft PowerPoint is ubiquitous, and therefore controversial. Most critiques, both of the software and of its widespread adoption in educational settings, express concerns that are not particular to PowerPoint alone, but apply to “slideware” presentations generally. The reliance on sequences and hierarchies of bullet points (a poor means of presenting some kinds of complex information), the foregrounding of visual gimmicks over content, the displacement of attention from the speaker and her message onto summary arguments presented dumbly on screen: far from being necessary features of presentation technology, these (according to the critics) prove to be shortcomings that interfere with, rather than enhance, a presenter's ability to communicate.

This paper presents an alternative to slideware, in the form of SVG graphics used for presentation. Why SVG? It meets all our functional requirements of a presentations technology; but even more importantly, as an XML-based format, Scalable Vector Graphics is well-suited to an XML-based production framework. Going far beyond sequences of bullet points, SVG supports open-ended, innovative uses of visual media in presentation. This becomes practical because the complexities of SVG coding can be relegated to a processing layer, following the classic design pattern of XML publishing:

XML source + XSLT stylesheet => formatted result

Commonly the formatted result of the process will be HTML or PDF; in this case it is SVG. Here too, this layered architecture provides great advantages: since the logic of its composition can be managed in the XSLT transformation, the XML source can be an abstracted model designed specifically for this purpose, allowing an author to work without concern for the details of SVG coding. So an author may code 12 lines of simple XML, which is rendered by a stylesheet into 52 lines of complex SVG. The XSLT transform does the heavy lifting, calculating relative sizes and positions of SVG elements and managing the code and links that provide for dynamic behaviors on screen.

A small number of pre-coded "presentation primitives" can thus be combined, and mixed with arbitrary SVG, to create a dynamic and interactive screen or set of screens, which the lecturer can navigate at will, traversing to or zooming into and out from particular visuals or points of interest. The style of presentation this encourages is much different from the usual rote rehearsal of bullet points: instead of an argument or exposition, the screen presents contextual information and evidence, both in text and visuals. Where slideware is linear and focuses attention on itself, an SVG presentation can be spatial and content-oriented, providing background and support to the presenter. Dynamic features such as customized menus and event-driven animation, rather than making for mere visual gimmicks without relation to the content, become functionally useful. And because SVG is also a general-purpose graphics format, the visual possibilities go far beyond what slideware can do unassisted.

The presentation will include a demonstration of at least one example (more if time permits) developed for and used in a real-world educational setting.

1. Slideware and its critics

What makes the best technology for “presentations” can be a delicate and politically sensitive question. It even receives occasional attention in the media, as a fun but fairly innocuous “hot-button” issue. Not too long ago (May 2003), the currently-dominant technology for presentations, Microsoft PowerPoint, was singled out for scrutiny by the guru of visual information design, Edward Tufte[1]. His diatribe, The Cognitive Style of PowerPoint[Tufte-2003].[2] is directed specifically at PowerPoint, but is largely applicable to presentations software in general.

PowerPoint is controversial because it is ubiquitous: If PowerPoint is a fashionable object of contempt in some circles, this is less an indicator of the worthiness of this particular product among “slideware” offerings, so much as the inevitable reaction that comes as entire worlds (including primary/secondary and higher education, government, and the commercial sector) have seemingly come to be dominated by a single product, with whatever predispositions, quirks and limitations it happens to have. More even than other computer media, presentations packages seem to promise easy “dazzle” — a seduction we can all recognize. But as its users know (and as Tufte details), PowerPoint comes with weaknesses and shortcomings as well as strengths. Some of these are particular to PowerPoint itself, features of its design it does not share with other software. (As a piece of slideware production software, however, it should be admitted that its functionality improves over time.)

Some of these shortcomings are the inevitable ones for a piece of proprietary software in a monopoly position in its market — its relatively high cost to run (albeit buried in the “cost of doing business”), given the obtainable results, and its closed data format. Yet without always distinguishing between PowerPoint and its competitors, critics including Tufte justifiably lament slideware's reliance on sequences and hierarchies of bullet points (a poor means of presenting some kinds of complex information), the foregrounding of visual gimmicks over content, and the displacement of attention from the speaker and his or her message onto summary arguments presented dumbly on screen. Far from being necessary features of presentation technology, these (according to the critics) are more like vices, tending to interfere with, rather than enhance, a presenter's ability to communicate. (Sometimes it is admitted that these shortcomings are not necessarily the software package's fault; yet since no one wants to blame passive and bewildered users, the software is again blamed for its “tendencies”.)

There exist several options if one wants to forsake PowerPoint or one of its analogues (OpenOffice.org, WordPerfect Presentations, the new Keynote for the Macintosh, etc.) for sequences of HTML pages, which (especially with the help of CSS) can also make perfectly respectable “slides” for presentation; this approach works at least as well as the proprietary packages in some situations (generally those at a different scale from the “one-off”), and in some respects better, especially when such pages are generated from tagging optimized for authoring.[3] But an extremely tempting — ultimately, it would seem, the ideal — target format takes us away from bullet points altogether: SVG.

Scalable Vector Graphics, a W3C Recommendation[4] is a general-purpose tag set specifically designed for describing graphics as vectors (that is, in a declarative mode, by describing lines, shapes and colors rather than simply mapping colored pixels). As a format not only very lean (files often come in at a fraction of the size of comparable rasters), but also versatile and scalable (that is, it can be well rendered at any size and resolution), it has already made an impact in both interactive viewers, and print. It is also happens to be well-suited for projection and classroom group-interactive work.

Several XML to SVG presentations packages exist, the handiwork of various XML pioneers. A discursive series of lists of bullet points is actually a fairly challenging target for SVG, which is not designed to provide for typographic layout features such as line spacing or word wrapping.[5] Nonetheless, by means of various workarounds these problems can be dealt with, and these packages demonstrate how even rudimentary XML can be used effectively to get quite tasteful results [Mulberry-2002].

But if bullet points are everything that is wanted, CSS-controlled HTML is better; SVG's main advantage is that as a native graphics format — and, not incidentally, one specifically engineered to scale graphics — it also has the potential to take us far, far beyond PowerPoint.

2. So much more than bullets: SVG

One such application is being used in a professional context by Mr Jim Surkamp,whose lectures on the United States Constitutional Convention of 1787 (presented at the US Government's Eastern Management Development Center[6] ) have provided an occasion for the development and application of a truly dynamic classroom use. The aim here was to provide visuals which should be supporting players, not the center or “star” of the lecture.[7] Any projected visuals could be drawn in to provide context; but they should not have to encapsulate the presentation's content — on the contrary, if we assume the lecturer knows the material, to repeat it on screen would be redundant at best, at worst an interference. In Surkamp's case, the hour and a half (or sometimes more) is conducted in a role-playing mode, with participants assuming the task of representing to themselves and each other the interests of the different States at the Convention. Attention is focused not on Surkamp, nor even on the participants themselves, but on the issues faced by the Delegates of 1787.

In this context, visuals must be supportive but subdued, working fluidly, not imposing a schedule or sequence; and they should degrade gracefully, allowing for tangents and distractions, or even for the presenter to set them aside and do completely without them.

These goals were achieved by a single SVG image. (A photograph of Mr Surkamp in front of the display appears in Figure 1. That there is only a single image here — used in a presentation that goes well into a second hour — does not mean that it is simple or that little information is conveyed by it.) Scripting was added in order to provide pre-set zoom positions to show, in detail, a set of images that can be traversed as the presenter chooses. A simple “one-click” user interface allows the presenter to bring in or hide content, zooming in and out at will, using the dynamic capabilities of the digital medium to serve directly the purposes of focusing attention and capturing the viewers' imaginations — rather than being merely gratuitous and distracting, like PowerPoint's “fly-ins”. A great stress is placed on the detail of images that scale on the screen, so inset images may be scrutinized more closely than would be possible using the limited graphics support of typical presentations packages.

3. An XML-based production architecture

There is nothing new about the XML architecture used to produce these media; in fact it's nothing but the classic XML/XSLT architecture applied to SVG[8], with the special circumstance that as a declarative layer providing an authoring interface to SVG, but having no other application in mind, the source tag language used here need not be defined exclusively as a separate entity from the target. That is, it can superset SVG itself, thus providing certain conveniences for production); also, again since it exists only to simplify the production of this particular output, it does not even have to be fully specified or even validated in and of itself. That is, its “validation”, such as it is, can be “in the browser”, just as might be said of HTML.

<cameo who="mason" cast="left" xOffset="360" yOffset="300">
  <shot source="#vamason"/>
  <label>Mason</label>
  <tablet>
     <name>George Mason</name>
     <state>Virginia</state>
     <line>&ldquo;The General</line>
     <line>Gov't should</line>
     <line>have the power</line>
     <line>to prevent the</line>
     <line>increase of slavery.&rdquo;</line>
     <line>&mdash; Aug. 22nd</line>
  </tablet>
</cameo>

The author only needs to worry about coding this. A simple XML format specifies a unique ID (the who attribute), what direction to draw in (either left- or right-facing), x and y placement, a label and a text. With a state element, this one is tailored for this application: but more and less general configurations can be designed.

Figure 3: Code sample: XML source

<xsl:template match="cameo">
  <xsl:variable name="src" select="translate(shot/@source,'#','')"/>
  <xsl:if test="not($images[@id=$src])">
    <xsl:message>Warning: image "<xsl:value-of select="$src"/>
      <xsl:text/>" not found...</xsl:message>
  </xsl:if>
  <g transform="translate({@xOffset - 4} {@yOffset - 6})"
     id="{@who}-cameo" style="visibility: visible">
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="runningview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="visible" begin="startview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="{@who}-cameo.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="visible" begin="{@who}-tablet.click" fill="freeze"/>
    <xsl:call-template name="portrait">
      <xsl:with-param name="width" select="54"/>
      <xsl:with-param name="height" select="72"/>
    </xsl:call-template>
    <xsl:variable name="captionoffset">
      <xsl:choose>
        <xsl:when test="@cast='left'">0</xsl:when>
        <xsl:otherwise>
          <xsl:value-of select="54"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <g transform="translate({$captionoffset} 36)">
      <xsl:apply-templates select="label" mode="caption"/>
    </g>
  </g>
  <g transform="translate({@xOffset + 5} {@yOffset + 7.5})"
     id="{@who}-medal" style="visibility: hidden">
    <set attributeName="visibility" attributeType="CSS"
         to="visible" begin="runningview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="startview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="{@who}-medal.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="visible" begin="{@who}-cameo.click" fill="freeze"/>
    <xsl:call-template name="portrait">
      <xsl:with-param name="width" select="30"/>
      <xsl:with-param name="height" select="40"/>
      <xsl:with-param name="flag" select="'medal'"/>
    </xsl:call-template>
  </g>
  <g transform="translate({@xOffset} {@yOffset})"
     id="{@who}-tablet" style="visibility: hidden">
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="runningview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="startview.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="hidden" begin="{@who}-tablet.click" fill="freeze"/>
    <set attributeName="visibility" attributeType="CSS"
         to="visible" begin="{@who}-medal.click" fill="freeze"/>
    <xsl:call-template name="tablet-box"/>
    <xsl:call-template name="portrait">
      <xsl:with-param name="width" select="45"/>
      <xsl:with-param name="height" select="60"/>
      <xsl:with-param name="flag" select="'tablet'"/>
    </xsl:call-template>
    <xsl:call-template name="tablet-text"/>
  </g>
</xsl:template>

Code from the XSLT transformation that generates the SVG for a cameo. In order to resolve the graphic image, a lookup has been performed in a small catalog. Additionally, some of the code is provided by named templates called from this one (not shown).

Figure 5: Code sample: XSLT template

4. Tour-de-force or expedient hack?

One interesting critique comes from Syd Bauman.[9] On viewing this application, his response was (I paraphrase) “this is all very cool, but I have to admit, it strikes me a bit like programming in Postscript”. And while XML/XSLT may not be quite as arcane as Postscript, the analogy is apt because in both cases (designing a production line for a graphics display format; hacking directly into the printer code) what is happening is a strategic intervention into the common application scenario for producing either print, or a presentation: namely, composition in a user interface. Here, PowerPoint is forsaken as an authoring and production tool much in the way that a production line programmed in Postscript could bypass a word processor or desk-top publishing application, the usual way of creating Postscript.

Accordingly, in general it may seem gratuitously over-sophisticated to code XSLT transformations over custom XML for the creation of sophisticated screen display (leveraging the fact we have a convenient XML-based format for doing so, SVG), when one could “just use PowerPoint”. Yet even to ask this question is revealing of when, and why, it may actually be a worthwhile endeavor. And thereby, it points indirectly to one of the main advantages of XML-based technologies in general (not just XSLT/SVG) over other approaches to accomplish the same general kinds of media production. Here, just as in other XML-based production pipelines, the entire point is that production is oriented to local goals and needs, not poured into the mold of off-the-shelf one-size-fits-all solutions. This is possible because custom solutions are now feasible at a fraction of the cost they would have incurred in the past.

Whereas, in 1995 (say), sophisticated and disciplined users could already make respectable presentations in PowerPoint (and the strength of slideware packages when used well is precisely that a single individual can pull off the entire production), if one wanted or needed to go beyond what the commercial product offered, much more serious coding was called for. The greatest presenters, of course, have done without slides altogether. Yet if we don't take this step, we may as well go as far in the opposite direction (taking the digital media for all they are worth) as possible. Indeed, one might code something in Postscript. It hardly needs stressing that this is beyond the reach of most small-shop operations.

XML, however, changes this. There are non-trivial design problems in developing compelling presentations. A wide range of talents and skills are called for, that are generally not to be found in even the most accomplished single individual. (The awkwardness of the author's own attempts at graphic design are sufficient evidence of this.) The architecture outlined here, in which the requirements for the user interface (the user experience) are outlined in detail and then implemented, allows us to break the problem area into two: the design of the graphics and content, and the design and delivery of the user interface itself (in this case, by way of targetting SVG and even a particular SVG viewer). Intead of working in a WYWSIWYG editor, in XML the author works “closer to the metal” — which may seem challenging in some respects. (Yet HTML, if nothing else, has demonstrated that an immediate “browser refresh” or the equivalent can be a perfectly effective way of authoring content when only a single medium is targetted.) These experiments demonstrate that in principle, closeness to the code need not be a prohibitive factor — in fact, shifting to plain-text or XML editing can itself introduce new efficiencies, if the tools and tags are well designed. In fact, not everyone must become an expert in XML/XSLT to be able to take advantage of such systems: one or a few developers can serve quite large numbers of users. But more importantly, in this production model the author can and should have a more direct influence on design — and not only on the design of content of any particular presentation (though that must be the heart of everything), but also on the functional design, the mechanics and features of the application itself. That is, feature extensions become relatively very easy, when instead of a shrink-wrapped software package for authoring, the author has a transformation specialist (and/or an SVG presentations specialist) directly available to explore and execute new ideas.

This in turn is suggestive because it is potentially a feature of XML technologies in general, not just of the particular pathway (custom XML via XSLT to SVG) described in this paper. Even a single XML/XSLT expert may seem to be beyond the resources of many. But for many others, particularly in organizations in which such a specialist's abilities could also be applied in other ways, what was out of reach because it required an entire IT or engineering division, now becomes thinkable. By providing a standard infrastructure that works consistently across platforms and even applications, XML dramatically lowers the barriers to entry for creating custom applications of all kinds, but particularly of media-oriented applications. It does not bring those costs to zero. But it does shift the boundary, so that high-value media productions are no longer the exclusive preserve of Fortune 500 companies (who themselves are nonetheless benefitting from the same network effects of expertise at even greater scales). In the right organization, a single talented staff member could implement a system like this, even without having to give up other responsibilities in a more ordinary information production pipeline.

Of course, the level of resources required for this development is not warranted for just any kind of production for which “slideware” is useful: plenty of presentations are not worth this level of investment in media. Nor is the investment likely to be worthwhile to just any kind of organization. But for certain kinds of presentations, and certain kinds of organization (in education, for example), the results would apparently seem to be worth the trouble.

The author has produced visuals for several talks and presentations using these techniques. Experience suggests that a great deal can be done with just a few templates: for the most part, we need nothing even as complex as the cameo, getting the most leverage from a single feature of SVG, its scalability, which allows us to zoom in and around an image at will (once it is assembled by whatever means). Accordingly, this may be a sophisticated application of XSLT, but it is not generally a particularly difficult one. The SVG design, on the other hand, can be as complex as the designer can make it.

Figure 7: Other examples by the author

Way Beyond Powerpoint: XML-driven SVG for Presentations

Abstract

Table of Contents

1. Slideware and its critics

2. So much more than bullets: SVG

3. An XML-based production architecture

4. Tour-de-force or expedient hack?

Bibliography

Footnotes