Collections of slideshows

[Oscar Levin]

I'm working on revamping the CLI template for a "course", now having used PreTeXt for (almost) all of my course materials this semester.  While I don't use slides to teach from, I know there are plenty of folks who do, and I was going to include a slideshow as one of the course components.

This got me thinking about how these should be embedded within a course.  Currently, all the other student-facing materials can be put into a "book", divided in chapters corresponding to different types of materials.  I have a chapter of "course documents" (mostly just a syllabus), notes, worksheets, homework sets, etc.  Thus all my materials for a single course are in a single repository, and there is a single target that builds all of them as a single pretext document.

Slide shows are different though.  For one, you can't include a slideshow as a section in a book (although perhaps you should be able to??).  So from the CLI perspective, each of these will be a separate target, with a separate entry in the project.ptx manifest.  If you use a different slide deck for each day of a class, you might have as many as 60 targets that are slideshows!!

While I am pretty sure it doesn't work yet, it would not be too difficult to allow the CLI to build a "standalone" target with format slideshow.  That would take care of the excessive targets in the manifest, although would require typing the path to the ptx file when compiling.

Alternatively, the CLI could always build all slideshows that exist in a particular folder, and create a landing page that points to each.  More work for me, but if it is useful, I'm happy to explore this.

I haven't thought too much about a (core) PreTeXt way to manage this, but that is also an option.  What happens if you include a slideshow element inside a book?  PreTeXt could generate that slideshow and add a link in the place in source it is included.  Or maybe there is a more general "collection" target that does something like that.  I could definitely see an advantage to being able to xref to particular slides.

Just throwing out some ideas while they are on my mind.  Not necessarily looking to work on this in the next month (but who knows?).

[Barbara Ericson]

When we integrate LearningClude into Runestone it would be helpful to have access to the slides as well. LearningClues can ingest instructional material and then answer student questions based on the materials with links to the answer/topics materials.  

Dr. Barbara Ericson

Associate Professor, School of Information

University of Michigan

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/4c74bee2-6c6b-455f-a623-f1b616fce5c6n%40googlegroups.com.

[Mitch Keller]

This question has good timing, as I’m preparing to hand off a giant collection of materials we developed (in PreTeXt) for our large lecture discrete math for CS course last spring to the instructors teaching the course this spring. I currently have a file for each chapter with root element #slideshow. I also, as detailed in my MathTech.org post, I actually have two build targets for each chapter so that I can build both the annotated and unannotated versions. Would not be a huge shift to have one file per class meeting rather than one file per chapter in my structure, but I’m wondering if you could find a reasonable way to incorporate versions. I guess maybe a way to specify the publication file to use and where to output things? Then I could call the CLI pointed at a directory where each file’s root is #slideshow, specify my “blank” pubfile, and specify an output directory for the blank slides and then call it again in a similar manner specifying a different pub file and output directory? 

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/4c74bee2-6c6b-455f-a623-f1b616fce5c6n%40googlegroups.com.

-- 
Mitch Keller
mi...@rellek.net

http://www.rellek.net/

[Sean Fitzpatrick]

When I've used slides in class, it was a single slideshow, structured by sections. 

Each section was a class, and within each section were the slides for the class. For HTML slides, this produces a 2D layout: navigate left-right by date, and up-down by class. 

This was easier for me to manage, and it meant I only needed to provide a single link to students. I hosted on GitHub and used pretext deploy to update before each class.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/53946A0F-6FE1-409D-9EA3-7443E0F5D8F5%40rellek.net.

[kcri...@gmail.com]

When I've used slides in class, it was a single slideshow, structured by sections. 

Each section was a class, and within each section were the slides for the class. For HTML slides, this produces a 2D layout: navigate left-right by date, and up-down by class. 

This was easier for me to manage, and it meant I only needed to provide a single link to students.

I also did this, very similar.  

I hosted on GitHub and used pretext deploy to update before each class.

Except I uploaded the output inc. images/js to a local server hosted on campus. 

I found two downsides to this workflow, though I still prefer it and think it has more advantages:

* Making pdfs (which some students appreciate) takes a lot longer, and/or was not possible due to memory issues with the solution I used (probably decktape) due to the very large number of slides.  But next time I do it I will try to do this on a daily basis rather than of the whole thing.

* Students found it hard to navigate to the section they wanted - lots of left-right until they got there, and they had to try to remember what happened on what date, even with the (I hope) helpful titles for each date.

Anyway, potentially having a tool that allows both approaches, perhaps depending on some flag, would be helpful.

[Rob Beezer]

Some targeted comments.

* You could have multiple #slideshow live alongside a #book, as children of #pretext and use versions to control what actually gets processed. That would allow recycling things like LaTeX macros, and publisher file settings. Though that might also be accomplished by xi:include'ing common parts. No #xref to and from.

* Not sure about the wisdom of a #slideshow as an actual element of a #book.

* #slideshow is not really meant to convert to lots of output formats, like EPUB. But I did once produce one in braille for a blind member of an audience.

* I believe we support #slideshow in the conversion to LaTeX (but can't check right now). I prefer decktape for archiving a talk, but maybe a PreTeXt PDF would be helpful for this classroom scenario. This is certainly a place where improvements and contributions would be welcome.

* Just like previous point - convert a #slideshow to "straight" HTML, as an accessible version?

Rob