Interactify Beta

View saved version →

---
name: accessible-interactive-design
description: Write content for Interactify's H5P activities so they're usable by people with visual, motor, cognitive, or language-related access needs - not through code changes (H5P's own runtime already handles keyboard navigation and screen reader labeling), but through the actual wording and answer-matching choices made when generating content.
---

H5P's runtime libraries already provide real accessibility infrastructure - keyboard
navigation, ARIA labeling, screen-reader announcements - without any extra effort on your
part. This skill is about the part that infrastructure *can't* fix: the actual words and
answer logic chosen when generating content. Getting that wrong creates a real barrier even
though the underlying player is fully accessible.

## Accept reasonable answer variation, not just one exact phrasing

Requiring a single exact spelling or phrasing is a real access barrier - for dyslexic
learners, English language learners, and anyone using assistive input, not just a
convenience issue.

- **Fill in the Blanks**: use the `/` syntax to accept genuine alternate spellings or
  phrasings for the same blank, e.g. `*colour/color*` or `*labour/labor*`, whenever more
  than one answer is legitimately correct - not just for regional spelling, but for any
  blank where a learner could reasonably phrase the right answer more than one way.
- Don't use this to make genuinely different answers "equivalent" - only phrasings of the
  *same* correct answer.

## Write stems and labels that stand on their own

Someone using a screen reader hears card text and question stems read aloud, often without
the surrounding visual layout for context. Every question, card front, clue, and label
needs to make sense read in isolation:

- Don't write a stem that depends on seeing an image, color, or spatial position ("the one
  on the left," "the green option") - none of these content types in practice rely on
  images for the correct answer, but avoid introducing that dependency in wording even
  incidentally.
- Keep sentences direct. A screen reader user re-parsing a long, clause-heavy stem to find
  the actual question is a real tax that sighted skimming doesn't impose.
- Spell out what an abbreviation means on first use if the activity itself is what
  introduces it - don't assume context the learner doesn't have yet.

## Match reading level to who's actually using this

A teacher building a quiz for their students needs the *students'* reading level reflected
in the questions, not the teacher's. If the source content's audience is implied (a grade
level, "my beginners," a specific course), write at that level - simpler sentence structure
and more common vocabulary isn't dumbing content down, it's removing a barrier that has
nothing to do with whether someone understands the actual subject.

## Be honest about what's outside Interactify's control

**Interactive Video takes a YouTube URL as input - Interactify has no influence over
whether that source video has captions.** If accessibility of the video itself matters to
the person asking (and for an educational use case, it usually does), say so plainly rather
than implying the activity is fully accessible end-to-end: "the questions and interactions
I'm adding are accessible, but captions on the video itself depend on what's available on
YouTube for this specific video - worth checking before using this with students who need
them."

## What you don't need to worry about

H5P.Crossword's own runtime already offers a non-grid input mode (Tab-navigable fields,
styled like Fill in the Blanks) for people who can't or don't want to use the visual grid -
this is a real, already-built feature of the library, not something that needs to be
designed around. Likewise, keyboard operability and screen-reader labeling for every content
type here come from the vendored H5P runtime itself, not from anything in the content you
generate - focus on the wording and answer-matching guidance above, since that's the part
actually within reach.

View saved version →

---
name: choosing-the-right-h5p-content-type
description: Decide which of Interactify's 9 H5P content types actually fits a given learning goal, before calling any create_h5p_* tool - start from what the learner needs to do, not from which tool sounds closest to what the user asked for, and recognize when more than one activity (or none of these) is the honest answer.
---

Start from the learning goal, not the request's surface wording. Someone asking to "test my
students on this chapter" might mean recall of facts (Dialog Cards), checking they followed
the chapter's logic (Interactive Book with checkpoints), or a formal graded assessment
(Quiz) - these call for different tools even though the request sounds similar. If the goal
isn't clear from context, it's worth a quick clarifying question rather than guessing.

## Decision guide

**The learner needs to recall a fact, term, or definition on demand**
→ Dialog Cards (self-paced review, flip to check) or Fill in the Blanks (production,
not just recognition - stronger retrieval practice than picking from options).

**The learner needs to recognize and recall vocabulary in context**
→ Drag the Words (the sentence gives context the word has to fit) or Crossword (the clue
forces recall from a definition rather than just pattern-matching a word shape). Crossword
specifically rewards words that share letters with each other (thematically related sets
work better than a random grab-bag) - mention this if the chosen words look unrelated.

**The learner needs to check their understanding of one specific idea, with one correct
answer among a few options**
→ Single Choice Set for a quick sequence of individually low-stakes checks, or standalone
multiple-choice questions inside a Quiz if it's part of a larger graded set.

**The learner needs to work through a full document, chapter, or guide and check
understanding along the way**
→ Interactive Book, with checkpoint questions placed at natural section boundaries - ask how
often they want checks if they haven't said (every section vs. a few key spots vs. just a
wrap-up).

**The learner needs to engage with a specific video instead of watching it passively**
→ Interactive Video, with interactions timed to actual content beats in the video, not
evenly spaced by the clock.

**The person needs to organize or let someone browse reference material - a policy doc, an
FAQ, "find the part that's relevant to you"**
→ Accordion. This isn't really an assessment, and that's the right call when nothing needs
to be *tested*, just organized and made scannable.

**The person needs a real graded or summative assessment with an overall score and pass
mark**
→ Quiz. This is the one format built around an overall score, not Single Choice Set or
Fill in the Blanks, even though those also "ask questions."

**The request implies dragging visual elements onto an image, diagram, or map**
→ None of these fit well. Interactify's content generation is text-only (no image
pipeline) - say this plainly rather than forcing a text-only format to stand in for an
image-based interaction it wasn't built for.

## More than one activity can be the right answer

A single request sometimes genuinely calls for more than one content type - "turn my
onboarding guide into something interactive" might be best served by an Interactive Book
for the guide itself *and* a separate Dialog Cards deck for the glossary of internal terms
it introduces. Don't force everything into one activity when splitting it serves the
learning goal better; say so and offer both.

## When none of the nine fit

If what's being asked for is open-ended writing, peer discussion, live debate, or anything
that isn't reducible to a defined-answer interaction, none of these content types are a good
fit - that's a real limit of the current nine, not something to approximate with a
multiple-choice stand-in. Say so, and build the closest reasonable fit only if the user
still wants it with that limitation understood.

View saved version →

---
name: learning-design-for-interactives
description: Apply instructional-design judgment whenever building an H5P activity with Interactify - where to place checkpoints, how to write questions and distractors that actually test understanding, and how to give feedback that teaches. For which content type to use in the first place, see the choosing-the-right-h5p-content-type skill; for wording accessibility, see accessible-interactive-design.
---

This applies across all nine Interactify content types (Quiz, Interactive Book, Interactive
Video, Accordion, Dialog Cards, Fill in the Blanks, Drag the Words, Single Choice Set,
Crossword) - it's about the *quality* of what gets built, once the content type is already
chosen (see the choosing-the-right-h5p-content-type skill for that earlier decision).

## Where to place checkpoints and interactions

Spacing questions throughout content tests retention better than clustering them at the end
(the testing effect is strongest when retrieval happens close to when the relevant idea was
just introduced, not after unrelated material in between). For Book and Video specifically:

- Place a checkpoint right after the idea it tests, not after several unrelated ideas have
  gone by.
- Don't put one after every single paragraph or every few seconds either - that interrupts
  comprehension before there's anything substantial to check. A natural section or sub-topic
  boundary is usually the right unit.
- If the user hasn't said how often they want checkpoints, ask rather than guessing (Book's
  `checkpointFrequency` field exists for exactly this) - "every section," "a few key spots,"
  and "just a wrap-up at the end" imply different amounts of content to write questions for.

## Writing questions and distractors that actually test something

- Write plausible wrong answers, not throwaway ones. A distractor that's obviously silly
  doesn't test anything - it just makes the question easier by elimination. Good distractors
  reflect a real misunderstanding someone might actually have.
- Avoid "all of the above" / "none of the above" as a crutch - they're usually a sign the
  other options weren't hard to write, and they let someone get the right answer through
  elimination logic instead of knowing the content.
- Avoid negatively-phrased stems ("which of the following is NOT...") unless the negative
  is clearly, visibly marked - they're a common source of avoidable wrong answers that have
  nothing to do with understanding the material.
- Keep answer options parallel in length and structure. A correct answer that's noticeably
  longer or more specific than the distractors is a tell, independent of whether the person
  knows the content.
- Vary the cognitive level across a set of questions where the format allows it (Quiz,
  Single Choice Set) - not everything needs to be pure recall ("what is X called"). Where the
  source content supports it, include at least one question that requires applying or
  reasoning with the idea, not just recognizing a term.

## Feedback

Where a format shows per-answer feedback (Quiz's answer-level feedback, Drag the Words'
correct/incorrect text), write feedback that says *why*, not just "Correct!" / "Incorrect."
Generic feedback wastes the one moment the learner is most receptive to understanding their
mistake.

## Wording

Question stems and card text should be unambiguous on a first read - there's no author
present to clarify if something's confusing. See the accessible-interactive-design skill
for how this also matters specifically for screen reader users, language learners, and
cognitive accessibility, not just general clarity.