visual-presentation

Topics in the source

• Visual Presentation
• Purpose
• When to use
• The static-slide core
• The motion decision (make it before any animation is designed)
• How to animate (when the decision is "animated")
• Platform notes
• Quality gate

A deck or a stepped web page is an argument delivered over time. This skill owns two things: the static-slide core (every slide makes a claim and defends it) and the motion decision (whether anything should move, and if so how). The motion evidence is mostly negative, so the skill's core is knowing when not to animate. Building, outlining, rewriting or critiquing slides, titles, subtitles or speaker notes. Any question of builds, transitions, Morph, Magic Move, or "should this animate". An animated chart for a talk, a data video, a scrollytelling or stepped explainer page. visual-intent handed off with a medium of deckprojected, deckreadahead, or an animated or scroll-driven web page. Not for: a static figure for a paper or report, a dashboard, a poster or wall display, data art (route to visual-intent, visual-beautiful, or scientific-visualization). A chart that sits on a slide still gets its encoding from visual-encoding; this skill decides how the slide and its steps carry it. Read /dev/MandrakeWorkflows/skills/visual-presentation/references/slides.md for every deck. Its rules came over unchanged from technical-presentation: title = the takeaway, subtitle = what the slide holds;

This is an excerpt. Refer to the complete source and its current requirements.