R Markdown slides: plan four bullet checkpoints

Pressing Next should not reveal a recommendation before the audience has seen its supporting facts. Set content boundaries and bullet order before polishing an R Markdown briefing.

This briefing has two content slides and four bullet checkpoints. Ten drawings need places; one rack holds six. Two racks provide twelve places, leaving two empty. The HTML generates complete Rmd source and lets you inspect the planned reading sequence; an actual ioslides render must be rehearsed separately.

R Markdown slides: plan four bullet checkpoints
R Markdown slides: plan four bullet checkpoints
Open the full example ↗

Work through the example

Select Next checkpoint to move from the first fact to the second, then to the recommendation. Four drawings would remain unplaced with one rack; that is different from the two empty places available with two racks. The Rmd source uses title Practice Club Briefing, section Decision, headings Current facts and Recommendation, and incremental: true. Copy that source to briefing.Rmd and render it in your R environment.

Before rehearsing, write the intended audience sequence beside the two headings. Require both facts before leaving Current facts and both recommendation bullets before leaving Recommendation. Count content slides separately from title and section pages. In the native render, record the actual action that reveals a bullet and the action that changes the slide; the reading preview cannot establish those controls.

Keep the briefing small enough to check

Use the title Practice Club Briefing, one section called Decision, and two content slides:

Content heading First bullet Second bullet
Current facts Ten drawings need places now One rack holds six
Recommendation Two racks offer twelve places Four drawings would remain unplaced with one rack

These are original illustrative facts, not observations from an actual club. They describe capacity only. They do not establish a price, available floor space, rack stability, or permission to buy anything.

Check the arithmetic before treating the recommendation as settled. One rack has six places for ten drawings: four drawings would be unplaced. Two racks offer twelve places: after placing ten drawings, two places would be empty. Four unplaced drawings with one rack and two empty places with two racks describe different situations. Adding a claim about four spare places would contradict the example.

The second recommendation bullet describes the one-rack alternative. Keep “drawings” and “unplaced” in that bullet so listeners can distinguish the shortfall from the two empty places with two racks.

Map the source structure to the audience sequence

The R Markdown guide documents ioslides_presentation, heading-based sections and slides, and the incremental: true setting for staged bullets. A horizontal rule can also introduce a slide. Use the heading structure here without extra separators. R Markdown: ioslides presentation

Use the generated source named briefing.Rmd. Its YAML metadata has the title above and an output mapping with ioslides_presentation containing incremental: true. The body has # Decision, followed by ## Current facts and its two list items, then ## Recommendation and its two list items. The example needs no R chunks, equations, images, or external assets authored into the source. That does not establish that every generated dependency will work offline.

Count two content slides, rather than promising a two-slide deck. Title and section transition pages belong in a separate count after rendering. An extra page is not automatically an error; an unexpected content boundary is something to investigate.

Write the intended audience sequence before inspecting the output:

Content slide Intended sequence within that slide Condition before leaving
Current facts Ten drawings, then capacity of one rack Both bullets have been seen
Recommendation Capacity of two racks, then the one-rack shortfall Both bullets have been seen

During rehearsal in the rendered deck, note whether the first bullet is initially visible and which advance action reveals the next item or changes slides.

Recreate this example

Build one self-contained responsive HTML example titled “R Markdown slides: plan four bullet checkpoints” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.

Generate complete Rmd source for Practice Club Briefing, section Decision, ioslides_presentation with incremental: true. Current facts has Ten drawings need places now and One rack holds six. Recommendation has Two racks offer twelve places and Four drawings would remain unplaced with one rack. Provide Next checkpoint and Reset controls for four planned reading checkpoints, retaining checkpoint four at the end. Show one-rack shortfall four and two-rack spare capacity two. Keep native page count and observed key behavior not tested.

Use a dark slide rehearsal desk with numbered checkpoints and a complete source panel design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.

Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.

The page generates Rmd source and a planned preview; it does not run R, Pandoc or ioslides. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.

Review the prepared copy in NOS

When a colleague questions the one-rack comparison, review its wording beside the four checkpoints. A prepared HTML explanation can be rendered in NOS, where eligible static presenter instructions can be revised visually without AI regeneration. Apply any content change to briefing.Rmd and render the deck again before presenting.

Keep reading