For faculty and instructional staff

Interactive Canvas Plugins

Small, self-contained web tools that drop into a Canvas course and give students something to do rather than something to read. Every example below is working software you can open right now, use as-is, or adapt. If the one your course needs is not here, the last section is how to ask for it.

What a "plugin" means here

A single HTML file. No account, no install, no server, no data collection. A student opens it from a module, works in it, and exports what they made as a PDF, a pasted summary, or a save file they can bring back next week.

The pedagogical bet is narrow and specific: a worksheet asks a student to write down an answer, while a tool computes something from what they wrote and hands the result back while they can still change it. A student who types "get better at project management" into a goal field and immediately sees not counted next to four of five criteria has learned something that a rubric printed underneath the assignment would not have taught them.

Two honest limits. These tools do not talk to the Canvas gradebook on their own — students submit an export, or the tool gets wrapped as an LTI app (see Putting one in Canvas). And they store nothing about the student anywhere but that student's own browser, which is a privacy feature and an analytics limitation at the same time. If you need completion data, say so in the request and it changes the build.

What every one of them does

These are build standards, not features of one tool. Anything requested gets them too.

Shared behavior across the plugin set
CapabilityWhat it means in practice
Runs anywhere, offlineOne HTML file, no dependencies, no CDN, no network calls. It works on a phone in a basement lab and it works in five years when the framework it was not built with is dead.
Nothing leaves the deviceWork is kept in the student's own browser. No accounts, no tracking, no third-party processor, nothing for a privacy review to escalate.
WCAG 2.2 AAFull keyboard operation with no drag-and-drop anywhere, visible focus, 44-pixel targets, live-region announcements, colour never the only signal, and reduced-motion honored.
Four ways to submitPrint/Save as PDF with a layout designed for print, copy a plain-text summary to paste into a Canvas submission, download a JSON save file, and reopen that save file later.
Survives the LMS iframeCanvas frames can block browser storage. Each tool detects this and tells the student to use the save file instead of silently losing their work.
A worked example built inOne button loads a realistic completed case, so a student who does not know what "good" looks like can see it before starting.
Feedback, not scoringThe tools respond to what a student entered with specific observations. They do not assign points, so they never become something to game.
A reflection promptEvery tool ends with a question the computation cannot answer — which is where the actual learning gets written down.

What else could be built

The eleven above happen to be about managing work. The same pattern — student input in, computed response back, exportable artifact out — fits most disciplines. A sample of what has been asked for, or would work well:

Plugin types by purpose, with concrete examples
TypeExamples
Practice with real feedback Problem sets that respond to the specific wrong answer rather than marking it wrong; misconception-targeted question banks; spaced-recall decks students keep across a term; step-checkers that catch the algebra error rather than the final number.
Data and analysis Dataset explorers loaded with the course's own data; a statistics sandbox where students see what changing n does to a confidence interval; chart builders where the student annotates what the chart shows and gets asked what it does not.
Simulation and models Parameter sliders for anything with a model behind it — budget, dosage, population, circuit, epidemic curve, cash flow; branching decision scenarios that report what a choice cost three steps later.
Writing and argument A thesis stress-tester that asks what evidence would falsify the claim; source-evaluation walkthroughs; outline builders that check whether each section actually advances the argument; peer-review guides that convert a rubric into questions.
Professional and clinical practice Case-triage simulators; SBAR and handoff builders; calculation tools with deliberate error-flagging for teaching; IEP or care-plan goal writers with the same specificity checks as the SMART tool above; interview and consultation rehearsal scripts.
Studio, lab, and design Critique protocols that structure what feedback has to include; project scoping tools; lab notebook templates with completeness checks; safety pre-flight checklists that will not print until answered.
Metacognition and reflection Exam wrappers that compare predicted to actual performance; learning logs; self-assessment against the rubric before submission, with the gap shown; study-strategy audits.
Group work Team charters; contribution trackers; conflict protocols; peer-evaluation forms that require evidence rather than a rating.
Instructor-side tools Rubric builders that flag criteria two graders would score differently; assignment-prompt checkers; accessibility checkers for your own course materials; grade-distribution explorers.

Not on this list is fine. The list is a prompt, not a menu.

Putting one in your Canvas course

Read this before you try pasting one into a Page. The Canvas Rich Content Editor strips <script> tags and inline event handlers for security. Paste a tool's source into a Page and you will get the layout with none of the behavior. These are the three routes that actually work.

Route 1 — Upload the file to Course Files simplest

  1. Go to Files in your course and upload the .html file.
  2. Make sure the file is published (the green circle), not restricted to instructors.
  3. Add it to a Module, or link it from a Page or an Assignment using the RCE's Course Documents link tool.
  4. Tell students it opens in a new tab and that their work stays on their own device.

Depending on your institution's Canvas settings, HTML files may open with a "download" interstitial. If that annoys you or your students, use Route 2.

Route 2 — Host it and embed it in an iframe

  1. Put the file anywhere that serves HTTPS: institutional web space, a department server, GitHub Pages, or a hosting account.
  2. On a Canvas Page, switch to the HTML editor and add an <iframe> pointing at it, with a title attribute and a generous height.
  3. Canvas allows iframes in Pages, so the tool renders inline inside the course.

One tradeoff worth knowing: browsers increasingly block storage inside cross-origin iframes, so autosave may not work in this mode. Every tool detects that and directs students to the save file instead — but it is why Route 1 gives a smoother student experience.

Route 3 — Wrap it as an LTI app gradebook

  1. Needed only when you want completion or scores to flow into the Canvas gradebook automatically.
  2. This requires your Canvas admin to add the app, and it changes the privacy picture — student work now passes through a server.
  3. Say so in your request and the build accounts for it from the start rather than being retrofitted.

Collecting the work

Without LTI, the cleanest setup is an Assignment with Text Entry or File Upload enabled. Students press Copy summary to clipboard and paste, or press Print / Save as PDF and upload. The plain-text summaries are deliberately readable and skimmable — you can grade a stack of them quickly, and they contain the tool's own observations alongside the student's answers.

Request a plugin

Nothing here has to fit your course. If you can describe what students get stuck on, that is enough to start — the design conversation figures out the rest. Fill this in, press the button, and it becomes a formatted request you can send.

What makes a request easy to build from
  • Name the stuck point, not the tool. "Students can't tell a claim from evidence" is more useful than "I want a quiz." The second one presumes an answer; the first one leaves the design open.
  • Say what the student should walk away holding. A completed plan, a calibrated number, an annotated chart, a defensible thesis statement. The artifact drives everything else.
  • Bring an example of the good version and the bad version. Two student submissions, one that worked and one that did not, are worth an hour of specification.
  • Be honest about the deadline. A rough working version in ten days is a different build from a polished one in a semester, and both are fine.
You and the course
The problem
Shape of the tool
Closest type — tick any that apply
Anything that changes the build

Fill in what you can — nothing is required, and a half-filled request is still a good starting point.

Nothing is submitted from this page. The buttons above copy the text or hand it to your own mail client — you stay in control of what gets sent.

Prefer to just email? Send the same information in whatever form suits you to akesha@gmail.com. A paragraph describing the stuck point is a perfectly good request.

What happens next

  1. A short conversation. Twenty minutes, usually enough. Most of it is spent on what students actually do wrong, because that is what the tool has to respond to.
  2. A rough version to react to. Faster than a specification and much more honest — you will know within a minute of using it whether the shape is right.
  3. Revision against real use. Ideally after a handful of students have touched it. The feedback text is usually what changes, not the mechanics.
  4. Handover. You get the file, and it is yours: no licence, no dependency, no one to renew with. It will still work when this page does not.