User talk:Aps/GSoC 2014
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Pluggable Rendering Engines? | 3 | 13:38, 20 March 2014 |
| Slide navigation | 1 | 18:05, 18 March 2014 |
| Import from OpenOffice? | 1 | 18:01, 18 March 2014 |
| Reveal.js | 7 | 16:23, 18 March 2014 |
Would it be practical to allow more than one slide rendering engine? (html5slides, reveal, shower, impress, etc.)
It is possible to use more than one slide rendering engine, but what would be the advantages of that?
Flexibility is the obvious advantage. It would allow the author to choose their favorite rendering. A particular use case might be an institution that always used impress.js or Flowtime, this would allow a consistent look for slideshows in the wiki.
There should be a generic way of dividing wikitext pages into slides on section boundaries (and failing that, on div boundaries), then each of those "slides" would be rendered as a sequence within the specified engine.
For slides with synchronized audio tracks it must be possible to:
- advance the slides and have the audio skip to the correct location
- scrub the audio position, and have the slides resync to the new position
Would it be practical to include a way to import an existing slide presentation? Providing at least a "rough draft" import from an open file format (like Open Office) might provide a good authoring starting point for educators that already have presentations in other formats.
I'm curious why you picked Reveal.js for the slide framework.
I've never used Reveal. Does it already have support for an audio track? (And if so, can you advance slides either by clicking the slide or by "scrubbing" the audio position?)
Reveal.js has a wide range of useful features which include
- nested slides
- nice slide tansition customization
- markdown contents
- PDF export
- speaker notes(useful if author is giving a live presentation)
- a nice API to do things easily
It does have automatic slide transitions at specific interval of time. For linking it with audio position, I'd be using Popcorn.js similar to way its being done in the prototype, but with easy authoring of course.
Markdown could actually be a disadvantage, since WikiEducator authors are familiar with wikitext.
Wiki authors don't need to write/read markdown. They would just be using the UI. Reveal.js would be storing the content in markdown format in sub-pages.
If it is in Markdown format, it won't render correctly on the subpages.
