Why STEM needs its own authoring habits
Science, technology, engineering and math content has features that ordinary prose does not. It contains equations, symbols, units, diagrams, graphs, code and data. Each of these can fail in a specific way: an equation saved as a picture cannot be read by a screen reader, a unit left out can make a number meaningless, and a code snippet with one typo teaches the wrong thing. Open resources add a further demand, because other people will edit and reuse your work, so every piece needs to be editable at the source.
Equations and symbols
The most important choice is to store math as text, not as images. Common options include:
- LaTeX, a long-established notation for typesetting math, which many authoring tools can render. It is compact and editable, and it is a good source format.
- MathML, a web standard for describing math in a page, which assistive technology can interpret.
- Plain Unicode for simple cases, such as x² or 3 × 10⁴, which work in almost any text environment.
Whatever you choose, test the result in the formats you publish. Math that looks fine in a PDF may break in an e-reader, and some systems render LaTeX differently. Check, too, that a screen reader can read at least the simple equations sensibly. If a complex formula cannot be read well, add a short sentence describing what it expresses in words.
Worked examples
In technical subjects, worked examples are among the most useful things you can write. A solid pattern is to show a complete solution with each step explained, then a similar problem with some steps left for the learner, then a problem to solve alone with an answer provided. This gradual removal of support is widely used in teaching, although how well it works depends on the learner and the topic.
Because errors are costly, check every calculation yourself, and ideally have a second person re-do it. Here is a small illustration of the level of care needed. Suppose a car travels 150 km in 2.5 hours at a constant speed. Speed equals distance divided by time, so 150 ÷ 2.5 = 60 km/h. Writing the unit at each stage and checking that the answer is sensible are habits worth modeling in every example. Cover unit conversion explicitly where your readers may be shaky.
Simulations and interactives
Simulations let learners change a variable and see what happens, which is hard to do on paper. When creating or including them:
- Check the license for the code and for any art or sound assets inside it; they may differ.
- Say what the model simplifies. A simulation of motion without air resistance is a useful teaching model, and learners should be told it is not the full picture.
- Provide a non-interactive alternative, such as a short description or a set of screenshots with explanations, for learners who cannot use the interactive version.
- Avoid depending on technology that stops working, and keep a downloadable version where possible.
- Make controls usable by keyboard.
Interactive items are more fragile than text. If you cannot maintain one, consider whether a clear diagram would do the job.
Open datasets
Real data makes STEM more engaging, and open data lets learners explore it themselves. Check carefully for the license and any conditions of use, since data is treated differently from text in many places and rights vary by jurisdiction. If you create your own dataset, publish it in a plain format such as CSV, include a short description of every column with units, state how and when it was collected, and note known limitations. Do not include anything that could identify real people.
When teaching with data, point out sources of uncertainty. Ideas such as measurement uncertainty and the difference between correlation and causation are important enough to show in the materials themselves.
Code in technical resources
If your resource contains programming examples, run every one before you publish and note the language version you used. Keep examples short, explain each step, and show the expected output. Include the license of the code itself, which may be different from the text. Tell learners what to do when something goes wrong, since a debugging mindset is part of learning to code. Where an example might be unsafe if misused, such as code that deletes files, say so clearly.
Diagrams and graphs
Make diagrams from editable sources, such as SVG or the drawing tool’s native file, and publish the source with the image. Add alternative text that conveys the point of the diagram, not just “a graph”. Label axes with quantities and units, and avoid using color alone to separate lines on a chart. Learners who are color-blind, or who print in black and white, will thank you.
Keep science accurate and current
Stick to well-established facts, and mark clearly where something is a simplification, a convention or still debated. Date the material and name your sources so that others can check them. Fields move quickly, and an old explanation that was once standard may no longer be.
A short review routine
Before release:
- Recalculate every worked example and answer from scratch.
- Run every code sample in a fresh environment.
- Check units, signs and significant figures.
- Render the text in each output format and look at the equations.
- Check that each image, simulation and dataset has a license and a credit.
- Ask someone from outside the subject to read the first section and tell you where they got lost.
No resource is free of mistakes, so give readers an easy way to report errors, and correct them in public with dated version notes.