Why I Built 12 AI Interactives as Plain, Offline HTML

Logan M. Dixon — Tue, 11 Aug 2026 20:29:43 +0000

When I started teaching an introductory artificial intelligence course, I kept running into a gap between two common ways of presenting AI.

At one end, students could read about an algorithm: a diagram of A* search, an equation for Bayesian updating, or a description of how k-nearest neighbors classifies a point.

At the other end, they could implement the algorithm in code.

Both are useful. But there is a useful middle layer between them: changing the variables yourself and watching the mechanism respond.

That is what I built AI Playgrounds for.

Open the full-resolution 15-second demo

It is a collection of 12 browser-based interactives covering foundational AI concepts:

search and pathfinding
hill climbing and simulated annealing
Wumpus World
CNF and SAT solving
naïve Bayes
Bayesian networks
k-nearest neighbors
overfitting
neural networks
k-means clustering
convolution
Q-learning

The project is open source and available here:

AI Playgrounds

The basic interaction is deliberately simple

The recurring pattern is:

predict → manipulate → observe → explain

Instead of beginning with implementation, a learner can first ask what they expect an algorithm to do.

Then they change something.

Move a point. Change a probability. Adjust a parameter. Add an obstacle. Alter a learning rate.

Then they inspect what actually changes.

The goal is not to replace mathematics or programming. It is to make the behavior underneath them easier to interrogate.

For example, k-nearest neighbors is straightforward to define:

measure the distance from a query point to the existing examples,
choose the nearest k,
classify according to those neighbors.

But several questions become much more concrete when the data can be moved directly:

What happens near a decision boundary?
Why can changing k change the prediction?
What happens when classes overlap?
How much does one unusual training point matter?

The visualization creates a small environment where those questions can be tested rather than merely described.

Why plain HTML?

I deliberately kept the deployment model unusually simple.

Each playground can run as a self-contained HTML file.

That means:

no installation,
no account,
no backend,
no student data sent to a server,
and no development environment required just to explore the concept.

A teacher can download a playground, put it on a local machine, LMS, USB drive, or shared folder, and open it in a browser.

That constraint matters more in classrooms than it might in a normal software project.

Every dependency added to an educational tool creates another possible failure point: school filtering, authentication, package installation, unreliable internet, browser restrictions, or simply the time required to get thirty students into the same environment.

Reducing that friction became part of the design.

Offline capability changes the architecture

It would have been easier to build the project around a framework, package manager, API, database, and hosted service.

Instead, portability became a design constraint.

Most of the computation therefore happens directly in the browser.

The algorithms are not screenshots or prerecorded animations. They execute as the learner interacts with them.

That also makes the implementation inspectable. Someone interested in how a playground works can open the source rather than treating the visualization as a black box.

For an educational project about artificial intelligence, that seemed important.

Bilingual interfaces were another constraint

The original classroom context was multilingual, so the playgrounds support both English and Simplified Chinese.

This introduced a less obvious software-design problem.

Translation cannot just be added to a handful of buttons at the end. Dynamic text, explanations, status messages, examples, teaching notes, and generated output all need to remain synchronized with the language state.

Building bilingual behavior into the interface from the beginning produced a cleaner system than treating localization as decoration.

It also reinforced another design principle: the visualization should carry as much explanatory weight as possible.

A visualization can also mislead

Interactive demonstrations have their own failure mode.

A clean visualization may make an algorithm look more universal, deterministic, or simple than it really is.

So each playground includes teacher-facing information about the abstraction being presented and what has been simplified.

That distinction matters.

A small neural-network playground is not TensorFlow.

A gridworld is not the full reinforcement-learning problem.

A two-dimensional classifier is not representative of every classification task.

The point is to isolate a mechanism without pretending that the isolated mechanism is the whole field.

The teacher layer became as important as the visualization

As the project developed, I added classroom-oriented material around the interactives:

teacher guidance,
student lab structures,
classroom activity sequences,
a curriculum map,
predict–run–explain prompts,
accessibility/state descriptions,
and explicit notes about common misconceptions.

The result is therefore closer to a small open educational resource than a gallery of demos.

A visualization by itself answers:

What happens when I change this?

A classroom resource also needs to help answer:

What should the learner notice?

and:

What should they be able to explain afterward?

Testing the software is not the same as testing the pedagogy

This distinction has been important throughout the project.

The repository includes automated checks and browser-level verification intended to catch software regressions and confirm deterministic behavior.

Those tests can tell me whether the implementation behaves as specified.

They cannot tell me whether students learn better because they used it.

Those are different claims requiring different evidence.

So I treat the verification suite as software-quality evidence, not educational-efficacy evidence.

The project is currently offered as an open design and teaching resource. Questions about learning effects require a different study.

Why build all 12 instead of one?

One playground could easily become an isolated demo.

A suite makes it possible to test whether the same interaction philosophy survives across very different AI paradigms.

Search behaves differently from probability.

Probability behaves differently from clustering.

Clustering behaves differently from reinforcement learning.

Yet the same basic design pattern can still work:

isolate one mechanism,
expose a small number of meaningful variables,
let the learner predict,
let them change something,
make the resulting state visible,
ask them to explain what happened,
disclose what the model simplifies.

That pattern is probably the part of the project I find most reusable.

Try it

AI Playgrounds is MIT-licensed and currently contains 12 interactives, teacher resources, classroom materials, and English/Simplified Chinese interfaces.

Live project: AI Playgrounds

Source: GitHub repository

Watch the full-resolution 15-second demo

If you teach AI, computer science, mathematics, or related subjects, I would be particularly interested in which abstractions you think work well visually, and which ones you think should remain primarily mathematical or code-based.

DEV Community: Logan M. Dixon