How to reuse lectures across courses without rebuilding your slide deck

The problem: Teaching the same idea in multiple courses

Here's a scenario I bet most college teachers have faced: you've been assigned courses that cover slightly overlapping subjects. In my field (Technical Communication and Rhetoric), I often lecture on closely related fundamentals. For example, I may introduce an idea like designing information for accessibility in our 300-level Technical Writing class and then cover it in much greater depth in our 400-level Accessible Information Design course. Some of the basic concepts could feed into lecture components for both classes, if only I could find those individual concepts and rearrange them into some sort of new output format. But finding and reusing those topics is not as simple as it sounds.

The first cause: Organization (or lack thereof)

My old system was essentially a non-system. I kept lecture notes in Word documents associated with each course. Every term I'd update and tweak those documents, and I generally had a sense of what topics I might find in a given course. Problems with this system quickly accumulate. From year to year topics would drift: I might try something new one year that didn't work very well, remember that it didn't work the next time I taught the class, and then go poking through multiple iterations of multiple Word documents, hoping to find the specific topic that actually did work a year (or was it two years? three years?) ago.

Or I might think that I covered the topic nicely in an intro class, and wouldn't it be nice to use that as a refresher for the students in the advanced class. But which term did we cover that? Which week? Which day? As you can see from all these rhetorical question marks, finding the right topic quickly became like finding a needle in a haystack, only the needle and the hay all looked more or less identical.

The first solution: Think in topics, not documents

In my advanced technical writing class, I teach topic-based authoring. The basic idea is to move away from documents as the basic unit of content storage. Documents are great when it comes to delivering a complete set of ideas. For example, proposals, reports, and presentations all make sense as documents. But documents are terrible as a method of storing ideas and even worse when it comes to retrieving and reusing them.

Technical writers have done this for years, but the systems they use are expensive, complex, or both. Authoring programs like MadCap Flare cost nearly $3,000 per user per year, and setting up a system like MkDocs or Jekyll requires you to install and understand programs like git and be comfortable working in a command line terminal. All of this creates a barrier for those of us who just want to pull a few topics together into a set of notes or a slide deck before class.

I have spent hours and hours trawling the Internet for an affordable topic-based authoring system, and until now I have never found one. Making topic-based authoring more accessible to non-specialists was my primary inspiration for building this system. This part is conceptually easy, but surprisingly difficult to implement. And it still doesn't solve an equally difficult barrier to entry: word processor lock-in. And so the secondary inspiration arose from the realization that all of my ideas were being held prisoner by word processors.

The second cause: Existing content is trapped in Word

There is another factor that makes it difficult to move to a topic-based approach to developing course materials: Word itself. Because Word stores your writing in a binary format, it's actually quite difficult to know what's in a Word file without opening it up and reading it. That's why you might have five or six Word docs open looking for that one great nugget of information you want to present in class tomorrow.

The goal would be to switch to plain-text formats like Markdown, and this is the way that much of the technical writing world takes to the problem. Markdown stores your content in plain text, which makes it much easier to find with basic, fast search tools.

But for those of us with years or even decades of course materials already stored in Word, "switching to Markdown" is not as simple as it seems. The options are to either copy and paste content from Word into a text editor, or use another command line program like Pandoc to convert batches of Word documents to Markdown systematically. Copying and pasting could get us to the topics we want, but batch conversion will still leave us with multiple topics trapped in a mess of documents (albeit more transparent ones).

The second solution: An LLM assist

Dealing with the second part of this problem was the inspiration for Sheetbend. Sheetbend converts your Word documents to text and then uses a finely tuned prompt that tells Claude to find the topics in the document and return them as individual Markdown files. Those files are then stored as individual topics and (for paid users) saved in a folder as Markdown files. You can then search those topics and add them to new arrangements (which we call maps). Exporting maps to PDF, Word, PowerPoint, or Markdown is as easy as clicking a button.

Start by breaking a single lecture into topics

For me, the workflow starts by looking at a single lecture that I know covers multiple topics. In most cases, I have these saved in a separate "Lectures" folder for each term that I teach a class. Then each file is named by the week and day that I used the last time I taught the class. So the first day is called "Week_1_Day_1.docx" and so on. I've already described the many ways this system can break, but the biggest problem is visibility. I really have no idea what's in that file until I open it.

So to start gaining insight into my content, I first run it through Sheetbend, which uses Claude to read the file and suggest where the topic boundaries are. A good example might be two different content topics, where I discuss general concepts from the course readings, followed by an in-class activity topic. Sheetbend will also try to classify the topics by type and suggest tags to help with retrieval later. The prompt is tuned to suggest topic names, but to try to defer to the original. And it is instructed not to change the wording of the topic itself. This is important because I don't want AI to write my materials for me. (I figure I'm pretty good at that part.)

At the end of the extraction process, I will have individual topics stored in a database. For free users, that content is all stored locally in browser storage. Paid users can select a folder on their hard drive and save it there. All of the content is stored in plain text, and all users can export their libraries whenever they want, so that the work they put into Sheetbend is always portable.

Then remix those topics into different lectures and output formats

Once you have a library of topics, you can start remixing them into new sets of lecture notes. As a recent example: I teach problem statements similarly in my Rhetoric for Professional Writers class and in my Business Writing class. By treating the lecture overview and the in-class activities as topics instead of documents, I could easily mix both into lectures suited to each class individually, while maintaining a consistency that helps me be an effective teacher. And I know that the next time I teach problem statements, I can start with an easily found and modified topic map, rather than digging through folders and Word files trying to find that "one that worked so well" two years ago.

You can also easily take the same material and push it to different output formats. Naturally this takes a little advance planning, but doing so can be a real time saver. All you have to do is plan slide-deck-friendly topics. Every topic heading will be the title of a new slide, and as long as you keep the body of the topic fairly short, it will usually fit pretty well on the slide itself. Choose the PowerPoint export option to generate your slide deck, and then export the same map to Word or PDF, and you have a printer-friendly copy you can share with your students. (Exporting back to Markdown would let you do more complex conversions, but that's a subject for a later blog post.)

What this approach doesn't solve yet

Sheetbend's biggest gap is what happens when a topic library gets too big to manage comfortably. Right now all topics live at the same level. You can search, sort, and filter, which helps with keeping topics discoverable, but you could quickly accumulate hundreds of topics, and I'm not sure how well the system will help manage that much information. I have investigated implementing an AI-assisted search system for paid users, but so far haven't found a satisfactory solution.

If you want to give it a try

You can sign up and use the full functionality described here for free. Users on the free tier are limited to 50 topics in the library at any given moment, but they use the same LLM-assisted topic extraction and flexible map creation tools as paid users. Upgrading to paid unlocks unlimited topic libraries and the ability to save your topics and maps to a folder on your computer (the free tier keeps everything in a database stored in your browser, which can be lost if that database is cleared).

Try it out and let me know what you think!