Content Development Guidelines

Guidelines about the tone, style, design and format for Mathigon’s courses.

1. Storytelling

Every course should have an engaging, continuous narrative – for example, based on real-life applications (“predicting the weather”), historical events (“measuring the height of Mount Everest”), a mathematical puzzle (“which shapes tessellate”) or even fictional characters. After starting with some general exposition, we should arrive at a new problem that students can’t solve, and then develop new mathematics that’s required. There could even be some suspense: students don’t initially know where the story might lead, and are later surprised with a powerful mathematics result. At every point, students should understand the reason for what they are learning.

2. Exploration and Open Play

Whenever possible, a new topic should be introduced with a open-ended environment where students can explore, discover some initial concepts,

3. User Interactions

Every Mathigon course is divided into small steps. Usually, these should not be longer than 2-3 paragraphs of text, and at every step, there needs to be something to do for the user.

4. Questions

Avoid asking students direct questions (“What is the sum of 3 and 4?”) and instead write a statement that students have to complete (“The sum of 3 and 4 is ___.”).

5. Tone and Pronouns

Overall, the tone should be kept as neutral and factual as possible. Rather than referring directly to the author (“I”) or student (“you”), assume that you are working together (“we” or “let’s”). This allows students to feel more

6. Illustrations and Graphics

As you are scrolling though a course, the browser viewport should always contain some colour like illustrations or diagrams (excluding very small screens like phones). Diagram style (not hand-drawn, etc.)

6. Inline Elements

TODO - Links between text and graphics, highlights in text

7. Use of Colours

TODO - text/diagrams match

8. Questions and Clanks

TODO - simple, number, range, etc.

9. List and Table Data

TODO - Structured data should never be represented in a long sentence: use tables or bullet lists instead.

10. Writing Style

TODO - Lots of small paragraphs, short sentences, etc.