When assigning lesson difficulty, it is useful to consider: how much prerequisite knowledge is expected; whether and how specialist or technical terms are used and defined; the relative complexity of install and set-up; whether trouble-shooting steps are included, outlined, or referenced; where and how knowledge beyond the lesson's scope can be learned (in existing Programming Historian lessons and other written documentation, or is applied experience necessary?).

• Prerequisite knowledge
• Handling of specialist/technical terms
• Complexity of install and set-up
• Support for troubleshooting
• Guidance for further learning (towards or beyond the lesson)

difficulty: 1 Beginner

• No prior knowledge required
• All steps are clearly defined
• Specialist or technical terms are defined
• Software packages are easy to install (no “known issues”)
• Challenges that readers might encounter are anticipated, and clear trouble-shooting steps are included
• Further Programming Historian lessons (or external resources) for advancing new skills may be referenced

difficulty: 2 Intermediate

• Some prior knowledge is required
• Existing Programming Historian lessons (or external resources) to empower less experienced readers to gain that knowledge are identified
• Key steps are defined, all steps are outlined
• Specialist or technical terms established by beginner lessons are used in context, while any new terms are defined
• Software install and set-up may be subject to “known issues”
• Challenges that readers might encounter are anticipated, and trouble-shooting steps are outlined

difficulty: 3 Advanced

• Significant prior knowledge and applied experience required
• Confident ability to infer intermediate-level steps expected
• Specialist or technical terms are used throughout, new concepts are explained
• Software and packages may be known for their complexity to install and set-up
• Challenges that readers might encounter are anticipated, and trouble-shooting steps are referenced

Whether beginner or advanced, all lessons must be usable, sustainable, accessible and inclusive:

Usability

• Summarise learning outcomes in an opening paragraph
• Structure logically, use section headings for clear and meaningful signposting
• Keep within the word limit: 8,000 words (including code)

Sustainability

• Cite software versions, specify technical dependencies
• Encourage general methodological narratives over screenshots and GUI-specific instructions
• Anticipate challenges, support trouble-shooting

Accessibility

• Caption images concisely, and ensure they are well-described with alt-text
• Provide cut-and-pasteable code, rather than showing it in screenshots
• Keep accessibility in mind when choosing data, case studies, and software

Inclusivity

• Utilise open formats, open programming languages and free software
• Consider implicit bias in algorithms and tools
• Identify multi-lingual external resources and software documentation wherever possible
• Be explicit if recommending learning content that is not available in the lesson's native language