Metalinguistic Abstraction

Computer Languages, Programming, and Free Software

DeckWiki: Proposed Collaborative Presentation Creation

with one comment

This is something I have been turning over in my head for at least six or seven months as I discovered the prevalence of Microsoft PowerPoint™ in business settings. There are a number of shortcomings:

  • Big binary files exchanged by email[0]
  • Relatively weak version control/merging capabilities
  • Out of date borrowed slides[1]
  • Lobotomizing an old set of slides just to get the same style in an integrated Microsoft PowerPoint™ file
  • Having to reprocess slides manually to get them to conform to some new style
  • Weak metadata/commenting capabilities, leading to bad slides
  • Lack of visual support for “off the rails” discussion, leading to unnecessary hand waving
  • Almost no serious collaboration support whatsoever[2]
  • Doesn’t facilitate location of useful, other slides available in the organization

This is kind of a solved problem, if you could get everyone to accept using something like Prosper and a bunch of TeX files on some sort of version control plus a few scripts. But that’s not going to happen. Even I will admit that it would probably be a little painful.

So let’s discuss something viable.

Many people at this point are pretty familiar with the idea of a Wiki…reading one, at least. Instead of some heavy-handed new tool that has to convince everyone its way is the One True Way and takes no prisoners[3], I suggest using a wiki package or writing something employing the wiki model to facilitate authorship of slides for presentations. Most professionals in technology sort of understand the idea of a wiki, even if in practice they never use them or contribute to them, but at least it’s not completely alien and probably not too scary to new users. I think. Let’s start with that premise. Let’s also presume the Wiki has a notion of “Presentations,” or a path through a series of presentations, including the empty presentation (no pages) and automatic singleton presentations (consisting of one page, every slide is a presentation). This is an important recurrence relation, because I will henceforth never organize things in terms of slides except when referring to the current way of doing things: in this model all presentations will be formed by composing presentations.

Let’s consider how we can address the issues raised above:

  1. Big binary files exchanged by email
    If the presentations are held in a wiki, each presentation can be maintained independently and there will be a common place to view and download presentations. Hopefully this will prevent attaching big files and sending them around all the time. By exploiting page versions it is possible to make sure that a given presentation will remain with the same content for all-time.
  2. Relatively weak version control/merging capabilities
    Since each presentation is tracked and worked on independently, one would only need to be concerned about clashing of the revision of single atom of content. The definition of an “atom” is most obviously at least on the per-page-level, but could be as fine as the word/paragraph level by using diffing/patching, although this gets more complicated. This also doesn’t seem to present a humongous problem on Wikipedia, even on the busiest pages. They still seem to get contributed to and updated.
  3. Out of date borrowed slides
    One can easily obtain a list of updated sub-presentations for any or all presentations and accept or reject changes. The result is a new, unique presentation; old presentations are never lost, so reverting is easy.
  4. Lobotomizing an old set of slides just to get the same style in an integrated Microsoft PowerPoint™ file
    Styles should only be loosely connected to a presentation. One should be able to paint a new style over any presentation unit, so absolute conformity is an option.
  5. Having to reprocess slides manually to get them to conform to some new style
    Simply apply a new style to the presentation
  6. Weak metadata/commenting capabilities, leading to bad slides
    Right now presentation slides are meant as much to be distributed and read as much as they are meant to be shown in person. The results are slides with entirely too much text and visual noise, distracting the viewers during presentations. Cutting out some detail upsets some stakeholders because then the slides no longer communicate everything that was said during the presentation in person. The relatively wimpy commenting facilities seen in most presentation packages doesn’t seem to please anyone, but an up-to-date nicely-formatted cross-referenced wiki-page associated with each presentation may be better. This idea is not new at all[4], although its proper implementation may be tricky.
  7. Lack of visual support for “off the rails” discussion, leading to unnecessary hand waving
    If a presentation goes off the rails — and this is not always a bad thing — one is often left without visual aids must do blackboarding and waving of hands. It’d be better to have a big list of short presentations that one is at least moderately familiar with so that if discussion wavers to another engaging topic that deserves more through discussion one can pull up more appropriate presentations and documentation. Another way to use this is to include “see-also” sub-presentations that one can visit and then jump back from the aside back to the main presentation. In this way a presentation flow resembles a NDFA.
  8. Almost no serious collaboration support whatsoever
    All this version tracking buys us a nice, fluid system that allows for synchronized updating of artifacts with a number of authors that far exceed two (as is, in my experience, the limit with more traditional methods). Wikipedia is an empirical example of this model working.
  9. Doesn’t facilitate location of useful, other slides available in the organization
    This is an exciting one. With all this graph connectivity information searching and finding more information may be a lot easier. One can also tell roughly how much a presentation is being used elsewhere. There are many potential uses for this.

Here’s a conceptual sketch of a more formal treatment[5]:

presentation -> {id: Id, presentation: [From], presentation: [To], page: P, 

This slideshow could not be started. Try refreshing the page or viewing it in another browser.

: Ancestry} presentation -> Nil id -> UniqueIdentifier (probably 64 bit integer) page -> {Version, Data} (A version and some payload)

A presentation from Nil to Nil is the empty presentation. If From is Nil, then this presentation is the head of a presentation, if the To is Nil, then it’s the terminating point of a presentation. The Ancestry variable allows for tracking of the evolution of presentations over time by showing what presentations derived the current one[6].

Another interesting idea is to break free of stack-based thought and use continuation-style thought in order to model presentation traversal, but I suspect that will break the minds of many people. That way you may not jump back to the datum you started at, but somewhere else entirely…possibly never to return, or perhaps carrying all your exit continuations along with you for possible use. In any case, the ‘presentation’ datatype can support this since it has an ‘environment’ (the page and version) and a ‘label’ (the From and To nodes). In fact, all standard linear presentations are similar to invoking a continuation that never calls a return. This is another way to think about this. It’s certainly all within reach if presentations are simply recursively connected to presentations and should you define a ‘page’ datatype an adequate ‘environment’ and the presentation datatype (which includes the page) the ‘code.’ In any case, thinking of it of a NDFA (as mentioned above) is probably easier to understand and a less-stretched analogy, but the idea of carrying multiple exits is an intriguing one that deserves at least cursory attention. An NDFA analogy would also suggest a simple and well known form of visualization.

I have changed my type definitions somewhat to give more indication of the many-entrance many-exit nature of presentations by listifying To and From, although the same thing could have been accomplished by a large number of presentation type instances. I think this is more like what an actual implementation might look like. It may make ancestry tracking less hairy, too. My original goal was to define as little as possible to get things done, but then I decided this was silly and I should be spending a few more characters to more adequately carry the idea.


[0]: Now slightly less-binary with the new Microsoft Office™ 2007 XML format. If anyone can hope to actually understand it in a reasonable amount of time.

[1]: Common scenario: “HR says we’re at X employees…oh, that’s old, we’re actually at X + N, let’s move on…” In isolation this is really not so bad except N is sometimes wrong due to misremembering and with enough such errata it is distracting. There’s no obvious reason why it has to be so hard to stay up to date.

[2]: Especially with over two people. The track edit feature is useful, but did you ever try giving slides out to five people and merging the changes?

[3]: Sound familiar? It’s Lisp vs UNIX again

[4]: Possibly a variant of Knuth’s notion of Literate Programming

[5]: This is hand-wavy amalgam of syntax/semantics borrowed from Prolog, ML, Erlang, Lisp (for Nil only, really) and/or Haskell. If anyone complains I’ll provide something more rigorous. My variables start with capital letters, my types start with lower case and when describing a variable use a colon, and lists are denoted with […], so

This slideshow could not be started. Try refreshing the page or viewing it in another browser.

is a list filled with “presentation”-typed things. -> is my reduction symbol. Braces denote tuples. Comments are in parentheses

[6]: One of the interesting problems presented here is that Wikis generally attempt to converge on an authoritative page that everyone sees as opposed to branching and derivative works, which itself can create a mess of cross-generational merging. The problem can be seen as the same one that plagues the distributed vs centralized version control camps. As merging is still a problem that seems to not have been solved to everyone’s satisfaction, implementors would do well to pay attention to the subtle issues engaged by both camps in that community in an attempt to make an informed decision.


Written by fdr

June 29, 2007 at 12:05 am

Posted in projects

One Response

Subscribe to comments with RSS.

  1. I highly recommend reading the work of Edward Tufte on Powerpoint for more inspiration on this worthwhile subject

    grant czerepak

    July 4, 2007 at 9:46 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: