In response to yesterday's entry (and this week's column) on web-based presentations, several folks have mentioned Eric Meyer's S5, which I pointed to from the column but not the corresponding blog item. Today Michael Smick adds:
Some wonderful soul integrated s5 slideshow into my favorite wiki, PmWiki. Here is the "cookbook" script, a php extension for the main PmWiki install.
http://www.pmwiki.org/wiki/Cookbook/SlideShow
here are two demos
http:\//wiki.cyaneus.net/teste/index.php?n=Main.SlideShow&action=slideshow
http://scripsit.org/index.php/Main/SlideShow?action=slideshow
What's cool about this one, is the normal wiki page comes up, and gives you a link for the slideshow, and the slideshow is just another <variable?> accessible from the address bar. So for those who complain that online slideshows are annoying, they get both without even unhooking the default style sheet in the browser.
Here's another web presentation / screen sharing service. Saw it a couple months ago.
http://www.teamslide.com/
Clearly the use of wiki markup is a great way to simplify the authoring of HTML slideshows. Integration with a server-based wiki does, however, sacrifice the convenience of serverless deployment. In general, S3 or HTML Slidy shows work the same way from a file: source or an http: source, and that's extremely handy. I wonder if anyone has combined S5 or HTML Slidy with a standalone (aka single-page) wiki such as TiddlyWiki?
Another observation: in these examples, the URL-line does not update as the slides advance, so slides are not invidually linkable and bookmarkable. Note, by the way, that while HTML Slidy does update the URL-line, it's only a partial solution. An URL like http:\//www.w3.org/Talks/Tools/Slidy/#(4) relies on JavaScript code to render slide 4 only. Vanilla HTTP clients -- e.g., search engine crawlers -- won't see a sequence of individual pages.
On the question of permalinks, I don't how it's possible to dynamically modify the URL-line and retain all expected behaviors. I've written before about AJAX and deep linking [1, 2, 3], but I hadn't thought this through from the perspective of search engines until I made my first HTML Slidy show. There's an option in HTML Slidy to make each slide's title the HTML doctitle, and of course I turned that on because I'm always looking for ways to make my stuff more coherent and useful in search results contexts. But to no avail. Search engines don't contain JavaScript processors, so they cannot construct and therefore do not see those per-slide titles.
In an AJAX era, could search robots and other crawlers use JavaScript processors to reproduce the effects happening inside browsers? Should they? Might the ability to do so become a competitive advantage?
In response to yesterday's entry (and this week's column) on web-based presentations, several folks have mentioned Eric Meyer's S5, which I pointed to from the column but not the corresponding blog item. Today Michael Smick adds:
Some wonderful soul integrated s5 slideshow into my favorite wiki, PmWiki. Here is the "cookbook" script, a php extension for the main PmWiki install.
http://www.pmwiki.org/wiki/Cookbook/SlideShow
here are two demos
http:\//wiki.cyaneus.net/teste/index.php?n=Main.SlideShow&action=slideshow
http://scripsit.org/index.php/Main/SlideShow?action=slideshow
What's cool about this one, is the normal wiki page comes up, and gives you a link for the slideshow, and the slideshow is just another <variable?> accessible from the address bar. So for those who complain that online slideshows are annoying, they get both without even unhooking the default style sheet in the browser.
Here's another web presentation / screen sharing service. Saw it a couple months ago.
http://www.teamslide.com/
Clearly the use of wiki markup is a great way to simplify the authoring of HTML slideshows. Integration with a server-based wiki does, however, sacrifice the convenience of serverless deployment. In general, S3 or HTML Slidy shows work the same way from a file: source or an http: source, and that's extremely handy. I wonder if anyone has combined S5 or HTML Slidy with a standalone (aka single-page) wiki such as TiddlyWiki?
Another observation: in these examples, the URL-line does not update as the slides advance, so slides are not invidually linkable and bookmarkable. Note, by the way, that while HTML Slidy does update the URL-line, it's only a partial solution. An URL like http:\//www.w3.org/Talks/Tools/Slidy/#(4) relies on JavaScript code to render slide 4 only. Vanilla HTTP clients -- e.g., search engine crawlers -- won't see a sequence of individual pages.
On the question of permalinks, I don't how it's possible to dynamically modify the URL-line and retain all expected behaviors. I've written before about AJAX and deep linking [1, 2, 3], but I hadn't thought this through from the perspective of search engines until I made my first HTML Slidy show. There's an option in HTML Slidy to make each slide's title the HTML doctitle, and of course I turned that on because I'm always looking for ways to make my stuff more coherent and useful in search results contexts. But to no avail. Search engines don't contain JavaScript processors, so they cannot construct and therefore do not see those per-slide titles.
In an AJAX era, could search robots and other crawlers use JavaScript processors to reproduce the effects happening inside browsers? Should they? Might the ability to do so become a competitive advantage?
Updates:
Clint Checketts wrote to say that he's collaborated with Paulo Soares on a slide-show plugin for TiddlyWiki, seen in use here
Peter Sefton has integrated Slidy into the University of Southern Queensland's ICE courseware system. ICE, by the way, is a noteworthy example of how wordprocessor stylesheets -- for OpenOffice.org and MS Word -- can provide the integration glue for single-source and multi-output content management.
Former URL: http://weblog.infoworld.com/udell/2006/05/23.html#a1453