create new tag
, view all tags

TWiki Replacing Powerpoint

TWiki is a very flexible information tool. This is one of it's greatest strengths and also an opportunity for enhancement. Here's an idea for an application that could change the playing field for TWiki adoption in some companies.

Problem: Even within companies where much data is stored using TWiki, traditional oral presentations using visual slides are a key method of conveying information at an executive level. I believe most executives today use Microsoft Powerpoint to present their data. Powerpoint data files are the results of extensive data collection often from many people and data sources. Powerpoint is used because it has very targeted features and ease of use. However this data is not "usable" or "linkable" in any way other than downloading the ppt and running Powerpoint. Sometimes folks go to the trouble of exporting the slides to HTML, but not often.

Data in these Powerpoint presentations is a distillation of the core of what a company does. There is high value here that is unable to be leveraged because the data is in a form that it can not easily be shared and used. More effective use of this data can provide real and immediate value.

Solution: Use TWiki itself to create and present data during executive meetings. TWiki pages and forms can be configured (herein lies the magic) to mimic much of the standard functionality of Powerpoint. As WWW adoption has increased, web pages are becoming more acceptable rather than Microsoft Powerpoint.

I realize that some special features of Mozilla and Internet Explorer (or other browsers) might also be required to make it as "easy" and attractive for executives when actually giving a presentation. I hope this topic will elicit comments and suggestions from those that have either done this already or know of specific features that would enable this to become a reality.

Result: This is beneficial in supporting deeper linking of data, in supporting those that missed the meeting and in providing notes to attendees to refer to after the meeting. Decisions made using better supported data have a greater chance of success. The pace of meeting schedules and attendee's abilities to focus during meetings are not what they once were. If presentations are posted this can only help in the inevitable situations where meetings are missed or when attendee's focus is on other matters. More effective use of the data that is created for the executive teams of companies can only improve the organization's competitiveness.

I feel this appliction would be compelling and provide extremely high value.

-- GrantBow - 29 Oct 2002

This sound realy interesting... but what about portability?

Most of presentations are shown using a PC not connected to a network (just a portable PC, sometimes connected to a video projector.

In my opinion the solution can gain diffusion if the Twiki system is easily operable in a "stand-alone" mode.

-- AndreaFanelli - 01 Nov 2002

My operating theory is that if we can make it work when connected via the network, we can sure copy some HTML pages locally for just giving the presentation.

Browser issues may need to be accomodated inidvidually, that's OK. I am hoping people will share their notes if they have ever tried to give a presentation with an HTML browser.

-- GrantBow - 03 Nov 2002

Technically, PDF offers most what you want; You can switch to fullscreen presentation mode. Even automatic slideshows with fancy effects work. And offline mode is no problem. HtmlDoc controls all these features, so in principle it's available for PrintUsingPDF.

For ease of use, we would need userfriendly ways to

  1. switch the template for a presentation vs book (or memo); this is needed to
    1. pump up the font size
    2. insert headings, fancy logos, backgrounds etc
  2. mark the beginning of slides - probably just pick up <h1> + <h2>?
  3. pass subtitles - maybe <h3>?

But the biggest problem: you will have a hard time, a very very hard time to overcome powerpoint culture.

-- PeterKlausner - 13 Nov 2002

Using the <link ... media="projection" ...> element in HTML to point to a special CSS stylesheet specifically designed for full screen viewing addresses each of PeterKlausner's points directly and easily.

See http://www.codestyle.org/css/media/projection-ProjectingYourStyle.shtml

-- MattWilkie - 13 Nov 2002

This is an intersting idea. At work we have more and more content in TWiki. Monthly reviews of the business units are done using PowerPoint. Slides frequently have links to details, usually in TWiki. As one exec said, "we dive into TWiki for details". The need to be online is no issue in this scenario.

Some time ago I did a presentation of TWiki at the Silicon Valley Webguild Technical Development SIG. I did this:

  • Created the slides in PowerPoint,
  • Saved the slides as a set of GIF files,
  • Attached them to a TWiki topic
  • Added some SpreadSheetPlugin formulas to "Next" and "Previous" links to show the presentation slide by slide, all in one TWiki topic.

This works well but has two disadvantages:

  • Performance: Each slide needs a trip back to the server
  • Links: No hot links are possible to link to related content

Another simple approach is to create a new SlideShowPlugin that mimics a slide show. The idea is as follows:

  • Have all slides in one TWiki topic
  • Each slide consists of a ---+ heading and some bullets, and some graphics if needed. Text contains links in the usual way. A slide should not occupy more then one screen height, e.g. split text into two slides if needed.
  • The Plugin would introduce a %SLIDE% variable that can be used as a delimiter for a new slide. This variable gets expanded to anchor jumps and navigation buttons: [^] [<<] [>>] for "Top", "Previous", "Next", respectively.
  • Clicking on a navigation button would just jump to an anchor on the same page, thus is fast.

Example topic text:

---+!! Bread Slicer 1.1
   * Presented by Indi Jones
   * 13 Nov 2002

---+!! Agenda

---+ Introduction
   * Blah blah
   * Blah blah
   * Blah blah

---+ Highlights
   * etc

The introduction slide would look like this:

TWiki home  Introduction 3 of 27 [^] [<<] [>>]

  • Blah blah
  • Blah blah
  • Blah blah

The Plugin would introduce extra vertical space for slides that have little content so that the next slide would not show up on the same screen. The navigation buttons could be done with button images.

This could be enhanced further, for example with a template design that can be defined in the Plugin settings.

You get the idea.

-- PeterThoeny - 14 Nov 2002

MattWilkie, thanks for sharing this capability and the URL! These are exactly the kind of technical solutions I am hoping others will volunteer, allowing web browsers to take on the Powerpoint role during a presentation.

PeterKlausner's idea sounds fine, but seems more appropriate for a topic named PDFReplacingPowerpoint. smile However I don't feel the "requirements" you outlined are the most important for a first implementation. For a Book/Memo printing feature for handouts I'm hoping that if the data is on TWiki handouts won't be necessary. I was thinking of using one TWiki topic per slide to make it easy to do a first implementation with refinements to be added later. I'm not sure what you mean by "pass subtitles."

In fact this ideas was generated from a discussion I had on the phone with PeterThoeny. The SlideShowPlugin idea sounds like a wonderful refinement once the capability seems reasonable. What I wanted to explore first is the available feature set of current browsers and usability in real life of using a web browser for a presentation - at least for simple slides. Fancy transitions and animation are clearly outside the scope of a first implementation. I'm thinking of what will be necessary to overcome the basic usability culture of Powerpoint. I'm also assuming a corporate culture of TWiki use. This should imply a willingness to use TWiki and instant value in the use of TWiki data. Given the technical feasability then enhancements such as the nicely proposed SlideShowPlugin will be wonderful indeed. Thanks for elaborating on this PeterThoeny.

I'm thinking of what a required feature set would be. A solid idea about the functional requirements is a good place to begin for any software development effort, though not often done in practice. A minimum set of requirements to me is that the browser buttons are not showing and there are perhaps a few shortcuts to move between slides via arrows instead of having to click on tiny little links in a corner of the slide. I feel these requirements are the most important for those using a web browser in creating and giving the new presentations. I don't yet know that a CSS2 media= implementation fits these two requirements and I don't see mention of Mozilla in that URL. It's worth exploring further.

-- GrantBow - 14 Nov 2002

For the navigation described above, NavbarPlugin would be doing the trick...

-- ThomasWeigert - 14 Nov 2002

OperaBrowser has a slideshow feature called Operashow that does pretty much what's discussed here using HTML and some CSS trickery. Worth a look, but I'm not sure how this would work in other browsers.

  • Update: In fact, the media="projection" CSS feature mentioned above by MattWilkie is a more standardised version of Operashow - ironically Opera is the only major browser that doesn't implement this, but of course a suitable TWiki plugin could detect the browser using AgentPlugin and then generate suitable markup.

One thing missing from a PDF/browser solution would be animation and builds. Also, more advanced presentations sometimes have hyperlinks off to another page and then back again - easy with HTML in concept, but would require sensible page names that don't change arbitrarily (or suitable anchors if all in one page).

-- RichardDonkin - 14 Nov 2002

Note that I toyed on the idea of providing both worlds with the NavbarPlugin : Have the plugin generate also a single page with all the pages concatenated, for viewing in projection mode. Thus each page is still a wiki single page for editing, but you can still have a presentation mode with longer initial delay but no delay between each page.

I have not completed it however as I was unable to forbid the next slide to show at the bottom if the previous one was short in the presentation mode. Anyone has a trick to do this?

-- ColasNahaboo - 15 Nov 2002

> ... idea sounds fine, but seems more appropriate for a topic named PDFReplacingPowerpoint. ..
Not so. I'm always thinking TWiki and %INCLUDE%. Slides. PDF. Includes. How does that relate?
I think the feature of Wikis is to have 1 topic = 1 page, instead of reiterating 1 topic in n documents, memos + slide shows again and again. Cf PPR:OnceAndOnlyOnceIsNotJustForCode
Now (I think) the feature of TWiki is %INCLUDE%. It allows you to re-massage your [chaotic] web of pages into something presentable. Be it print -- be it slides.

So instead of jumping right onto new %SLIDES...% whatever macros, how about leveraging existing semantics? I.e. put together a regular TWiki page with the intended content, then map this onto a slide show, e.g.:

HTML TWikiML Semantic for slide show
h1 ---+ title
h2 ---++ group of slides [sub-headings]
h3 ---+++ individual slide
Included pages don't have to be aware of any special slide markup; e.g. include a report of open issues, built from %SEARCH. This way, things make sense in the (regular) browser, in the slide show, in print.

HtmlDoc simply comes in, because it does a good job at HTML presentation. And its PDF output format solves a few extra problems:

  • Offline mode, e.g. you can attach it to an email leaving your intranet
  • Keyboard operation
  • Transition animations (whoever needs that)
  • Snapshot specific state in one file. You will want that, if you include popular reports e.g. from the XpTrackerPlugin. TWiki's RCS revisions are not sufficient for here, because they don't apply to %INCLUDEs and %SEARCHes

2 PeterKlausner 14 Nov 2002

Initial version of SlideShowPlugin is implemented, posted in the Plugins webs and also installed at TWiki.org. There is lots of room for improvements. I will give it a try on my next presentation at work. To see the Plugin in action, click on "Start presentation" in the Example section of SlideShowPlugin.

-- PeterThoeny - 17 Nov 2002

I'm working on using PublishWebPlugin to produce a nicely packaged presentation in HTML. Each slide is a full-screen DIV and navigation is controlled by buttons in a floating DIV. To go to the next slide, Javascript sets the current slide to class "notVisible" and then slide+1 to Visible. That gets rid of the nasty scrollbar. I was looking at prototype.js for Perl which has some nifty transitions--you can fade the divs into one another, etc. and it's all quite standardized. Anyway, the idea would be to use PublishWebPlugin to render it all in HTML/JS from the standard h1 h2 h3 layout used in the current plugins, but generate a page outside of TWiki. This solves performance problems using TWiki, allows you to just close the window to get back to TWiki, and it can be easily saved on disk to transport.

-- DaveCampbell - 01 Mar 2007

We've thrown out protoype.js because it caused serious crashes on some TWiki installations, and because it is not modular. Instead we now use Yahoo libs, distributed as YahooUserInterfaceContrib.

-- ArthurClemens - 01 Mar 2007

Dave, that looks interesting! Is this based on SlideShowPlugin and PublishWebPlugin, or just on PublishWebPlugin? Could you share this with the TWikiCommunity? Possibly attach to PublishWebPluginDev topic (or SlideShowPluginDev topic if based on that).

-- PeterThoeny - 02 Mar 2007

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2007-03-02 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.