Introduction

Founded and maintained by John Mortensen, Open Coding Society (OCS) is an open educational and software ecosystem built around student learning, collaboration, and community impact.

OCS Pages began as a project to support students studying computer science. It provides team-taught lessons, coding challenges and runners ("hacks"), and educational blogs ("tech talks"). As the work expanded into community outreach and projects with nonprofits, local communities, and businesses, a new need emerged: making the software, resources, and teaching practices reusable by other educators and organizations. That need led to OCS-in-a-Kit.

Educators and students can customize this GitHub Pages repository to support computer science learning through pathways using JavaScript, Python/Flask, and Java/Spring. It supports coursework in Computer Science and Software Engineering (CSSE), AP Computer Science Principles (APCSP or CSP), AP Computer Science A (APCSA or CSA), and Computer Science Honors (CSH).

Educational Model

OCS's instructional model is grounded in connectivism: learning happens through networks of people, platforms, and AI. The project continues to refine its instructional practices by drawing on Merrill's instructional principles, Fink's approach to significant learning, and Universal Design for Learning (UDL).

Agile and design-thinking ceremonies provide structure for classroom collaboration, while Gagné's instructional events help organize individual class sessions. Together, these approaches support a learning environment in which students build, explain, review, and improve authentic work.

OCS-in-a-Kit: Education and Community

OCS-in-a-Kit is an emerging initiative to make OCS's software, educational resources, and teaching practices accessible to other schools, educators, nonprofits, and community organizations.

The goal is not simply to distribute a curriculum. It is to provide a foundation others can adopt, customize, and extend to serve their own learners and communities.

This work spans two connected areas:

• OCS Education: Learning pathways, lessons, coding challenges, instructional practices, student collaboration, and assessment.
• OCS Business: Community-facing projects, technical solutions, and opportunities to connect education with nonprofits, businesses, and other organizations.

Community partners can contribute technical expertise, mentorship, documentation, adoption opportunities, and authentic project needs. Students remain central to the educational mission: they learn by creating work that can be useful beyond the classroom.

OCS welcomes these contributions without requiring exclusive partnerships or transferring control of the project to any single organization.

Student Requirements and Participation

High school students have opportunities to create and maintain personal GitHub Pages repositories as they progress through their coursework.

Students and instructors generally use OCS Pages to build lessons, complete classroom hacks and challenges, and explore technical concepts. Work can move between OCS and personal or team repositories in several ways:

1. Share individual files. Copy or download a file, such as a Jupyter Notebook, from its raw GitHub URL.
2. Create a template. Use this repository as a starting point for an independent project.
3. Fork the repository. Create a separate copy for individual or team development, with the option to contribute improvements back to OCS Pages through pull requests.

This model becomes even more powerful as students use OCS to build community projects. Projects can share ideas, reusable components, lessons, and improvements while maintaining their own goals and direction.

A common architecture and contribution workflow make it easier to share useful ideas across projects without requiring every project to be identical. This creates a continuing cycle of learning, building, reuse, and contribution.

The goal is a win-win model: students develop transferable skills, community organizations gain useful work, and future learners benefit from what earlier contributors have created.

---

History

This project is in its fifth major revision, known as version 5.0.

OCS Pages was initially inspired by Fastpages. Over time, the project evolved into an independent system as its educational goals and technical requirements diverged from the original foundation. The deprecation of Fastpages by its original authors also contributed to the decision to move forward independently.

The current implementation has substantially different architecture and build tooling, reflecting years of teacher and student development. Although the project began with GitHub Pages and the Minima theme, its presentation layer has evolved toward a custom Sass implementation using a grammar-based UI system. The long-term direction is to remove the remaining Minima dependencies.

We remain grateful to Fastpages for its early inspiration. OCS continues to build on that starting point while developing its own approach to open educational software, classroom collaboration, and community participation.

License and Attribution

Years of teacher and student work have gone into OCS Pages. The current code, lessons, tools, and instructional practices have evolved substantially from their original foundations through contributions from educators, students, and AI-assisted development.

OCS recognizes that open projects grow through the work of many people. Attribution should reflect actual contributions, including original student work, software development, educational resources, documentation, mentorship, and community adoption.

Reuse and redistribution are governed by the applicable licenses and copyright terms of each repository and its materials. Contributors and adopters should consult the relevant license and preserve required notices.

OCS welcomes contributions from individuals and organizations without requiring exclusivity. Acknowledgment recognizes contributions; it does not, by itself, confer ownership or control over OCS or prevent others from contributing.

Open Collaboration and Acknowledgment

Open Coding Society is designed to be reused, adapted, and extended by students, educators, nonprofits, businesses, and other contributors.

• Open participation: Individuals and organizations are welcome to contribute without becoming exclusive partners or acquiring ownership of OCS.
• Student recognition: Student authors should receive appropriate credit for their original work and contributions, consistent with applicable ownership and licensing terms.
• Contributor acknowledgment: Meaningful contributions may be recognized in project documentation, presentations, release notes, and other relevant materials.
• Accurate and nonexclusive credit: Acknowledgments should reflect contributions actually made. Recognizing one contributor does not prevent OCS from recognizing others or collaborating with other organizations.
• Open-ended collaboration: OCS may evolve through new contributors, partnerships, and adoption opportunities. Recognition should support this growth rather than create an exclusive or permanent claim over the project's identity.

OCS aims to make its work useful beyond any single classroom, institution, or partnership. Its long-term value comes from open participation, transparent contributions, and the ability of others to build upon what already exists.

---

Emerging Technology and Applied Computer Science

OCS provides a foundation for students to explore emerging technologies by building real applications, integrating systems, testing ideas, and working with users beyond the classroom. Projects connect foundational computer science to current developments in AI, connected devices, software infrastructure, accessibility, and community technology.

AI and Open Intelligence

Students explore large language models (LLMs), AI-assisted development and assessment, intelligent search, chatbots, and AI-enabled applications. OCS Intelligence investigates hosting open-weight language models on locally available GPU hardware, making AI coding assistance more accessible without requiring every student to purchase a separate subscription.

OCS's AI initiatives have also benefited from mentorship and technical discussions with Eduardo Revollo, Founder/CEO of Prometheus. OCS welcomes continued collaboration with industry practitioners as students explore open intelligence, AI infrastructure, and practical applications of emerging technology.

Connected Classrooms and Intelligent Systems

Projects explore how software can connect physical devices, classroom environments, and digital services. Examples include RFID-based classroom presence prototypes, QR-based workflows, computer vision, object detection, and systems that combine sensor events with application data and dashboards.

Full-Stack Engineering and Infrastructure

Students build beyond isolated programs and frontend demonstrations. Their work includes JavaScript interfaces, Python/Flask services, Java/Spring applications, SQL databases, APIs, authentication, deployment, monitoring, and security. They also develop the administrative, communication, assessment, and analytics systems needed to operate a shared educational platform.

Interactive Experiences and Accessibility

Game engines, multiplayer experiences, interactive learning modules, accessible game creation, and alternative input methods give students opportunities to explore user interaction, software design, and inclusive technology. Projects connect programming concepts with the experience of the people who will use the resulting systems.

Community Technology and Applied Research

Through capstone projects, students work with nonprofits, community organizations, and real-world problem statements. Projects include community websites and service platforms, volunteer coordination, educational tools, emergency preparedness, and other applications intended to make information and services more useful to their audiences.

OCS encourages students to treat these projects as engineering work: define a problem, investigate possible solutions, build a prototype, test assumptions, evaluate results, document decisions, and improve the system.

The OCS Development Ecosystem

OCS Pages supports the instructional and development workflows that make this work possible:

• Lessons and coding challenges: Interactive lessons, Jupyter Notebooks, code examples, and hands-on hacks.
• Collaborative development: GitHub repositories, forks, templates, team projects, pull requests, and reusable resources.
• Teaching and assessment: Student Teaching, assignment tracking, live reviews, AI-assisted grading, and feedback workflows.
• Communication and analytics: Tools for discussion, announcements, collaboration, progress tracking, and educational reflection.
• Local development and deployment: Makefiles, development scripts, GitHub Actions, and integration with web services and databases.
• OCS-in-a-Kit: An evolving effort to package software, resources, and teaching practices so other educators and organizations can adopt and adapt the ecosystem.

The project portfolio is available at OCS Capstone. It provides examples of student teams, technical investigations, and community-facing projects as the ecosystem evolves.

---

GitHub Pages setup

The absolutes in setup up...

Activate GitHub Pages Actions: This step involves enabling GitHub Pages Actions for your project. By doing so, your project will be automatically deployed using GitHub Pages Actions, ensuring that your project is always up to date with the latest changes you push to your repository.

• On the GitHub website for the repository go to the menu: Settings -> Pages ->Build
• Under the Deployment location on the page, select "GitHub Actions".

Update _config.yml: You need to modify the _config.yml file to reflect your repository's name. This configuration is crucial because it ensures that your project's styling is correctly applied, making your deployed site look as intended rather than unstyled or broken.

github_repo: "pages" 
baseurl: "/pages"

Set Repository Name in Makefile: Adjust the REPO_NAME variable in your Makefile to match your GitHub repository's name. This action facilitates the automatic updating of posts and notebooks on your local development server, improving the development process.

# Configuration, override port with usage: make PORT=4200
PORT ?= 4500
REPO_NAME ?= pages
LOG_FILE = /tmp/jekyll$(PORT).log

Tool requirements

All GitHub Pages websites are managed on GitHub infrastructure and use GitHub version control. Each time we change files in GitHub it initiates a GitHub Action, a continuous integration and development toolset, that rebuilds and publishes the site with Jekyll.

• GitHub uses Jekyll to transform your markdown and HTML content into static websites and blogs. Jekyll.
• A Linux shell is required to work with this project integration with GitHub Pages, GitHub and VSCode. Ubuntu is the preferred shell, though MacOS shell is supported as well. There will be some key setup scripts that follow in the README.
• Visual Studio Code is the Pages author's preferred code editor and extensible development environment. VSCode has a rich ecosystem of developer extensions that ease working with GitHub Pages, GitHub, and many programming languages. Setting up VSCode and extensions will be elaborated upon in this document.
• An anatomy section in this README will describe GitHub Pages and conventions that are used to organize content and files. This includes file names, key coding files, metadata tagging of blogs, styling tooling for blogs, etc.

Development Environment Setup

Comprehensive start. A topic-by-topic guide to getting this project running is published here.

Quick start. A quick start below is a reminder, but is dependent on your knowledge. Only follow this instruction if you need a refresher. Always default to the comprehensive start if any problem occurs.

Create From Template, Then Clone

Use GitHub "Use this template" on this repository and create your own repository named pages. Keeping the repository name as pages avoids site.baseurl mismatch problems.

Then clone your own repository and enter the project root (not the scripts folder):

git clone https://github.com/<your-username>/pages.git
cd pages

Add Open Coding Society as an upstream remote once, then periodically merge updates. This help you keep up with dynamic character of a portfolio project.

#  In your repository, do this once
git remote add upstream https://github.com/open-coding-society/pages.git
git remote -v # verify sucess

# first sync for template-created repos (run once if you see unrelated histories)
git fetch upstream
# if fetch fails, remove and try again with correct location: get remote remove upstream

# this part is the downstream update, work through best option
git merge upstream/main
git merge upstream/main --allow-unrelated-histories
git merge upstream/main --allow-unrelated-histories -X theirs # destructive resolve

# resolve conflicts, for instance VSCode will have them in Version Control secton with Continue button 

Windows WSL and/or Ubuntu or Kali Users

• Execute the script: ./scripts/activate_ubuntu.sh or ./scripts/activate_kali.sh
• Then run ./scripts/verifyTools.sh to confirm your setup.

macOS Users

• Execute the script: ./scripts/activate_macos.sh
• Then run ./scripts/verifyTools.sh to confirm your setup.

Setup connection to GitHub

• Execute the script: ./scripts/activate.sh
• Then run ./scripts/verifyTools.sh to confirm your setup.

Prep project to serve on localhost

• Execute the script: ./scripts/venv.sh
• Source the virtual environment: source venv/bin/activate
• Build localhost server: make
• Look for and click on server line output, perhaps Server address: http://localhost:4500/portfolio/. The Port and baseurl may change.```

Verify Your Environment

Run this after cloning and before starting any sprint work:

./scripts/verifyTools.sh

It auto-detects your repo location, checks required tools (git, ruby, bundler, python, pip), validates _config.yml and venv/ setup, and confirms Jekyll can run. Its Markdown report lists each check as PASS, WARN (non-blocking, e.g. optional tools like Jupyter/Java), or FAIL with a remediation hint. Exit code 0 means there are no failures; exit code 1 means at least one check failed. The full report is written to verifyTools.md in the repo root.

To print every check and its remediation directly in the terminal without creating a Markdown report, run:

bash scripts/verifyToolsTerminal.sh

macOS Terminal Setup Helper (optional)

On macOS, you can opt into a live terminal companion that watches setup commands (brew, xcode-select, java, git, python3, pip3, code, ...) as you run them and prints an inline fix the moment one fails. It's local-only — no network calls, no browser/game integration, and it never runs for commands outside that list. Add one line to ~/.zshrc to enable it:

source /absolute/path/to/pages/scripts/mac_setup_agent.zsh

Run mac_agent_pause / mac_agent_resume in a shell to temporarily turn it off/on.

To check your whole Mac setup at once (Xcode tools, Homebrew, Git and its name/email, Python/pip/venv, Ruby/Bundler, Java, VS Code's code command, this repo and its venv), run from the repo folder:

python3 scripts/mac_setup_agent.py --check

It only reads versions and settings; nothing is installed or changed. It prints a report with a fix for each failed check and exits 0 (all passed), 1 (something to fix), or 2 (not a Mac).

In the CS Pathway game, the Set up & check my Mac button in Toolchain Trail (shown when macOS is selected) walks students through these commands in their own Terminal: source scripts/mac_setup_agent.zsh (agent on), bash scripts/activate_macos.sh (install), source ~/.zshrc, then bash scripts/verifyToolsTerminal.sh (verify). They paste the verifier's output back and the page shows what passed and the next steps. The agent also watches the install script, so a failed install gets a fix tip. Scripts are run with bash because they are committed without the execute bit. Tests: python3 -m unittest discover -s scripts -p 'test_mac_setup_agent.py' and node --test tests/test_verify_tools_report.mjs.

Jupyter Kernels

To run many of the IPYNB files you will need to install Jupyter kernels for the languages you want to use. Here are the most common and recommended kernels:

Recommended Kernels

• Python3 (ipykernel): For Python code cells and most data science workflows.
• Java (IJava or jbang-ijava): For Java code cells and Java notebooks.
• JavaScript (tslab): For JavaScript code cells and JavaScript notebooks.

Installing tslab

First, Install tslab

npm install -g tslab

Second, confirm it's installed

tslab install --version

Finally, register it to your Jupyter environment

tslab install

Installing IJava or JBang

macOS (Homebrew):

# For Java kernel (IJava)
brew install coursier
cs install --channel=https://github.com/SpencerPark/IJava/releases/latest/download/channel.json ijava
# Or for jbang-ijava
brew install jbang
jbang app install ijava

Ubuntu/Linux (apt):

# For Java kernel (IJava)
sudo apt install coursier
cs install --channel=https://github.com/SpencerPark/IJava/releases/latest/download/channel.json ijava

# Or for jbang-ijava
sudo apt install jbang
# or sudo snap install jbang --classic
jbang app install ijava

List your installed kernels

(venv) username@machine path % jupyter kernelspec list
Available kernels:
  python3        /Users/username/Library/Jupyter/kernels/python3
  java           /Users/username/Library/Jupyter/kernels/java
  jbang-ijava    /Users/username/Library/Jupyter/kernels/jbang-ijava
  jslab          /Users/username/Library/Jupyter/kernels/jslab
  tslab          /Users/username/Library/Jupyter/kernels/tslab

Recommended Kernels

Start the Server

This requires running terminal commands make, make stop, make clean, or make convert to manage the running server. Logging of details will appear in the terminal. A Makefile has been created in the project to support commands and start processes.

Start the server, this is the best choice for initial and iterative development. Note. after the initial make, you should see files automatically refresh in the terminal on VSCode save.

make

For easier build failure logging, run:

python _projects/make-helper/run_make.py

Load web application into the Browser

Start the preview server in the terminal, The terminal output from make shows the server address. "Cmd" or "Ctl" click the http location to open the preview server in a browser. Here is an example Server address message, click on the Server address to load:...

http://0.0.0.0:4500/pages/

Regeneration of web application

Save on ".ipynb" or ".md" file activiates "regeneration". An example terminal message is below. Refresh the browser to see updates after the message displays.

Regenerating: 1 file(s) changed at 2023-07-31 06:54:32
    _notebooks/2024-01-04-cockpit-setup.ipynb

Other "make" commands

Terminal messages are generated from background processes. At any time, click return or enter in a terminal window to obtain a prompt. Once you have the prompt you can use the terminal as needed for other tasks. Always return to the root of project cd ~/open/pages for all "make" actions.

Stop the preview server

Stopping the server ends the web server applications running process. However, it leaves constructed files in the project in a ready state for the next time you run make.

make stop

Clean the local web application environment

This command will top the server and "clean" all previously constructed files (ie .ipynb -> .md). This is the best choice when renaming files has created duplicates that are visible when previewing work.

make clean

Observe build errors

Test Jupyter Notebook conversions (ie .ipynb -> .md), this is the best choice to see if an IPYNB conversion error is occurring.

make convert

Notebook conversion is incremental. Registered projects publish directly from _projects/<category>/<project>/ to _posts/projects/<project>/; they no longer stage notebook copies under _notebooks/projects/. Existing filenames, lesson permalinks, and runner markup are retained.

# Publish changed notebooks in one project
make -C _projects/lessons/java build

# Convert one project or legacy source
make convert-single NOTEBOOK_FILE=_projects/lessons/java/notebooks/2025-09-21-3.1.ipynb

# Force legacy notebook conversion, or reduce conversion workers
make convert CONVERT_FLAGS=--force CONVERT_JOBS=1

Project builds use one Python batch with up to four workers. Unchanged notebooks are skipped using .notebook-conversion-cache/; editing the source or converter, or deleting/modifying the output, causes reconversion. Identical Markdown is not rewritten. make convert scans legacy notebook sources only; registered-project build targets handle project sources. make split-courses still publishes multi-course variants from generated posts.

make dev now retains generated output and performs one incremental build of the selected projects instead of cleaning and converting them twice. Use make clean explicitly when a fresh start is needed. Generated project Makefiles are refreshed by registered builds or make generate-makefiles, while tracked overrides are preserved. After changing the pipeline, restart existing watchers so they use the new recipes.

Converter regression tests: venv/bin/python -m unittest discover -s tests -p test_convert_notebooks.py.

---

Development Support

File Names in "_posts", "_notebooks"

There are two primary directories for creating blogs. The "_posts" directory is for authoring in markdown only. The "_notebooks" allows for markdown, pythons, javascript and more.

To name a file, use the following structure (If dates are in the future, review your config.yml setting if you want them to be viewed). Review these naming conventions.

• For markdown files in _posts:

  • year-month-day-fileName.md
    • GOOD EXAMPLE: 2021-08-02-First-Day.md
    • BAD EXAMPLE: 2021-8-2-first-day.md
    • BAD EXAMPLE: first-day.md
    • BAD EXAMPLE: 2069-12-31-First-Day.md

• For Jupyter notebooks in _notebooks:

  • year-month-day-fileName.ipynb
    • GOOD EXAMPLE: 2021-08-02-First-Day.ipynb
    • BAD EXAMPLE: 2021-8-2-first-day.ipynb
    • BAD EXAMPLE: first-day.ipynb
    • BAD EXAMPLE: 2069-12-31-First-Day.ipynb

Tags

Tags are used to organize pages by their tag the way to add tags is to add the following to your front matter such as the example seen here categories: [Tools] Each item in the same category will be lumped together to be seen easily on the search page.

Search

All pages can be searched for using the built-in search bar. This search bar will search for any word in the title of a page or in the page itself. This allows for easily finding pages and information that you are looking for. However, sometimes this may not be desirable so to hide a page from the search you need to add search_exclude: true to the front matter of the page. This will hide the page from appearing when the viewer uses search.

Navigation Bar

To add pages to the top navigation bar use _config.yml to order and determine which menus you want and how to order them. Review the_config.yml in this project for an example.

Blog Page

There is a blog page that has options for images and a description of the page. This page can help the viewer understand what the page is about and what they can expect to find on the page. The way to add images to a page is to have the following front matter image: /images/file.jpg and then the name of the image that you want to use. The image must be in the images folder. Furthermore, if you would like the file to not show up on the blog page hide: true can be added to the front matter.

SASS support

Pages supports a variety of different themes that are each overlaid on top of minima. To use each theme, go to the "_sass/minima/custom-styles.scss" file and simply comment or uncomment the theme you want to use.

To learn about the minima themes search for "GitHub Pages minima" and review the README.

To find a new theme search for "GitHub Pages Themes".

Includes

• Pages uses liquid syntax to import many common page elements that are present throughout the repository. These common elements are imported from the _includes directory. If you want to add one of these common elements, use liquid syntax to import the desired element to your file. Here’s an example of the liquid syntax used to import: {%- include post_list.html -%} Note that the liquid syntax is surrounded by curly braces and percent signs. This can be used anywhere in the repository.

Layouts

• To use or create a custom page layout, make an HTML page inside the _layouts directory, and when you want to use that layout in a file, use the following front matter layout: [your layout here]. All layouts will be written in liquid to define the structure of the page.

Metadata

Metadata, also known as "front matter", is a set of key-value pairs that can provide additional information to GitHub Pages about .md and .ipynb files. This can and probably will be used in other file types (ie doc, pdf) if we add them to the system.

In the front matter, you can also define things like a title and description for the page. Additional front matter is defined to place content on the "Computer Science Lab Notebook" page. The courses: key will place data on a specific page with the nested week: placing data on a specific row on the page. The type: key in "front matter" will place the blog under the plans, hacks(ToDo), and tangibles columns.

• In our files, the front matter is defined at the top of the page or the first markdown cell.

  • First, open one of the .md or .ipynb files already included in either your _posts|_notebooks folder.

  • In the .md file, you should notice something similar to this at the top of the page. To see this in your .ipynb files you will need to double-click the markdown cell at the top of the file.

  ---
  toc: true
  comments: true
  layout: post
  title: Jupyter Python Sample
  description: Example Blog!!!  This shows code and notes from hacks.
  type: ccc
  courses: { csa: {week: 5} }
  ---

• The front matter will always have '---' at the top and bottom to distinguish it and each key-value pair will be separated by a ':'.

• Here we can modify things like the title and description.

• The type value will tell us which column this is going to appear under the time box supported pages. The "ccc" stands for Code, Code, Code.

• The courses will tell us which menu item it will be under, in this case, the csa menu, and the week tells it what row (week) it will appear under that menu.

Open Coding Society: Instructional Framework

A flexible, inclusive, and modern teaching model grounded in Connectivism, with structured learning through Merrill, Fink, UDL, Agile, and select Gagné elements. This framework prepares learners to thrive in collaborative, networked, AI-augmented environments.

---

Guiding Philosophy: Connectivism

“Learning is a process of connecting specialized nodes or information sources.” – George Siemens

OCS is grounded in a Connectivist philosophy, recognizing that:

• Knowledge is distributed across people, platforms, and digital tools
• Students learn by building and navigating networks — with peers, mentors, experts, and AI
• Internet and AI are not just resources but learning partners
• Decision-making (what to learn, when to seek help, what tools to use) is a critical skill
• Diverse collaboration and community contribution are essential for relevant, authentic learning

Connectivist Practices in OCS education

• Promote open collaboration via GitHub, blogs, scrum-team projects and cross-class projects
• Encourage learners to curate, remix, and build upon knowledge from global networks
• Teach students to evaluate digital sources, verify code, and contribute to public knowledge
• Incorporate AI tools for coding, writing, design, reflection, and peer modeling

✅ Connectivism provides the underlying philosophy that unifies Merrill’s structure, Fink’s depth, UDL’s accessibility, and Agile’s team-based iteration — all in a digital, networked world.

---

Instructional Core: Merrill’s First Principles of Instruction

“Make instruction Effective, Efficient, Engaging.”

• Problem (Anchor): Begin with a real-world task or problem that students must solve, pages is considered launch point project.
• Activation: Connect to prior knowledge or personal experience, GitHub OCS contains projects from many years of instruction.
• Demonstration: Show examples or models — how it’s done, pages has blogs and OCS has many projects to build upon.
• Application: Provide practice — guided then independent, OCS learning uses sprints to practice and iterate.
• Integration: Encourage students to reflect, share, or transfer skills to new contexts, students are encouraged to add to OCS.

---

Learning Depth: Fink’s Significant Learning

Emphasize holistic, transformative learning. These words and associated actions help learners become assets to the Connectivist landscape.

• Foundational Knowledge – Core facts, tools, syntax, concepts
• Application – Use of knowledge in projects, analysis, creation
• Integration – Connect coding with design, ethics, community
• Human Dimension – Team roles, collaboration, self-discovery
• Caring – Projects that matter to learners
• Metacognition – Learning how to learn, reflect, self-evaluate
• Intersection – True learning happens when all areas overlap

---

Access & Inclusion: Universal Design for Learning (UDL)

Proactively reduce barriers and support diverse learners. OCS maintains social and coding platforms that support UDL thinking (GitHub, YouTube, LinkedIn, X)

• Multiple Means of Engagement – Interests, choices, autonomy
• Multiple Means of Representation – Videos, code, diagrams, demos
• Multiple Means of Action & Expression – Presentations, repos, recordings, blogs

UDL is not a method but a design lens to make learning accessible and meaningful for all.

---

Structure & Ceremonies: Agile + Design Thinking + Gagné (selective)

Use classroom ceremonies for rhythm, reflection, and real-world alignment.

Gagné Elements (selective use)

• Gain Attention – Start with prompts, demos, tech news, or student input
• Set Objectives – Clarify sprint, lesson, or project goals
• Reflection – Use reflections and live reviews at the end of lessons/sprints

Agile & Design Thinking Ceremonies

• Empathy – Interviews, personas, build "Point of View" and “How Might We…” prompts
• Ideation – Brainstorms, sticky notes, sketches, synthesize
• Planning – User stories, task boards (Kanban, GitHub Issues)
• Sprints – Iterative cycles with visible progress
• Standups/PinUps – Feedback-oriented checkpoints
• Burndown Charts – Track group/team/individual progress
• In-Sprint Checkpoints – Product Owner reviews, Demo products or features, receive feedback, plan iterations
• Close-Sprint Assessment - Rubric close out, learning and competency demonstrations
• Retrospectives – Reflect on process and teamwork, next steps

---

Summary of Learning Philosophies

Layer	Model	Role
Philosophy	Connectivism	Foundation – learning is networked, shared, tech-augmented
Core Instruction	Merrill	Scaffolded, problem-first instruction
Depth & Growth	Fink	Human, affective, reflective development
Access & Design	UDL	Inclusive and flexible access to all learners
Workflow & Rhythm	Agile + Design Thinking + Gagné	Iteration, planning, feedback, reflection ceremonies