Learning objectives
You can:
- Build a slide from the six shape types that carry the overwhelming majority of real work, and state for any seventh shape what it adds beyond what those six already do.
- Manage a crowded slide with the selection pane, using grouping, naming, hiding and z-order to take a 47-object slide to 9 top-level entries without changing what a reader sees.
- Decide when a diagram tool helps and when it traps you, naming the three failure cases (the autofit that sizes type from the longest node, the layout that asserts a relationship you do not mean, and the block that cannot sit on the grid).
- Set a table so it can be read, choosing a table over a chart on the three stated grounds, and cutting a full grid of 13 rule lines to the 4 that do work.
- Size an image correctly, computing effective resolution from pixels and placed width, choosing the export target from the destination, and stating the licence position before the image goes on a slide.
- Apply the icon consistency rule, diagnosing a mixed set by grid, stroke weight and corner radius, and computing what a 24 px icon's 1.5 px stroke becomes when it is placed at 40 px.
- Cut animation to what carries meaning, distinguishing the three effects that do work from the ones that only cost time, and defending a build against the all-at-once alternative with a comprehension argument rather than a taste argument.
- Build a reveal that matches the narration, computing the audience's reading time against the speaker's talking time and showing that the slide never holds information the speaker has not reached.
- Run the accessibility pass, fixing reading order, writing or waiving alt text on every object, and measuring contrast against the 4.5:1, 3:1 and 3:1 thresholds for body text, large text and graphical objects.
- Ship the deck, exporting to the right target for each destination, predicting what breaks in a PDF and on a printer, and filling the eight-item checklist so that a deck leaves your machine once rather than three times.
Prerequisites & connections
Builds on. Alignment, distribution, grids, the type scale and colour as a role, all of which the precision-and-type node teaches and none of which is rebuilt here. You should be able to put an object on a 12-column grid, set a four-level type scale, and say why an outer margin obeyed everywhere reads as competence. You also need a master and a set of layouts, because several fixes below are stored at the master level rather than on the slide, and a deck that fights its own master cannot be shipped cleanly. From the tool node you need the four views, the selection habits and file naming; the ship pass assumes you can already save, version and reopen a file without losing it.
Feeds forward. The chart-craft branch takes the object mechanics for granted and argues about form, colour and the action title. The diagramming node takes the shape vocabulary here and asks what a diagram should assert. The archetype nodes assume that a deck you hand over is already accessible, already the right size and already exported correctly, because a board pack that arrives as a 26.72 MB attachment is not a board pack. The capstone runs the whole sequence, and the ship checklist below is the last gate it applies before a submission counts.
Four neighbours own material that touches this one, and the boundaries are deliberate. PR3.01 owns diagram construction as visual thinking: which relationships a picture can assert, the concept, process, flow, framework and matrix forms, and the Gestalt grouping that makes a diagram legible; what is owned here is the mechanics of the objects a diagram is made from. PR1.02 owns alignment, distribution, grids and typography, so the geometry below is applied rather than taught. PR0.02 owns the file as a file: naming, versioning, autosave, recovery, opening someone else's deck and the difference between a theme and a template; what is owned here is the export pass, which asks a different question, namely what happens to this file's contents at the destination. PR2.02 owns colour and decluttering as data-visualisation craft, so the contrast arithmetic below is treated as an accessibility threshold rather than as a palette design method.