SortLab: teaching the decisions inside 18 sorting algorithms
Most sorting visualizers make colorful bars move. That is satisfying, but it can leave the most useful question unanswered: why did the algorithm make that move?
I built SortLab as an exploratory learning environment for that missing layer. It covers 18 algorithms across six families, from Bubble Sort and Merge Sort to Smoothsort, Introsort, Bogo Sort, and Sleep Sort. The goal is not to memorize choreography. It is to build a mental model you can test.
Start with a decision, not a definition
Every lesson opens with the same three ways to engage:
- Guided explains a trace one decision at a time. The bars, plain-language narration, pseudocode highlight, live variables, and operation counters all describe the same moment.
- Practice pauses the trace and asks what the algorithm will do next. Feedback explains the local rule, not just whether the answer was right.
- Explore gives direct control over the data, playback, input pattern, and experiments.
That progression matters. A learner can first borrow the interface's explanation, then predict with support, and finally investigate independently.
One trace powers the whole lesson
The central design decision was to represent an algorithm run as a deterministic sequence of semantic events. A step is not merely “frame 42.” It records what was compared, written, swapped, selected, or finalized, plus the variables and source line that explain the action.
That shared trace drives:
- reversible step-by-step playback;
- synchronized narration and pseudocode;
- exact comparison, write, and swap counts;
- contextual practice questions;
- keyboard controls and screen-reader announcements; and
- the completed-run evidence used by the mastery model.
Because every surface reads from the same event, the explanation cannot quietly drift away from the animation. Moving backward is also real state restoration, not an approximation.
Turn “it depends” into an experiment
Big-O notation is essential, but it is easy to flatten into a flash card. SortLab pairs the formal complexity table with experiments that expose the conditions behind it.
Learners can generate random, nearly sorted, reversed, few-unique, or all-equal inputs, then enter their own integers. A hypothesis lab asks them to predict which input shape will help or hurt before running it. An empirical growth lab changes the input size and reports operation counts. The comparison workspace runs up to three algorithms against the same data so the result is a controlled comparison.
I intentionally count algorithmic operations instead of wall-clock milliseconds. Browser timing is noisy and implementation-dependent; comparisons, writes, and swaps are the quantities the lesson is actually trying to explain.
Tagged duplicate values make stability visible too. Equal values retain their identities, so “stable” becomes something a learner can observe rather than a word beneath a complexity table.
Make progress mean understanding
A green checkmark should represent more than reaching the end of an animation. A SortLab lesson is mastered after the learner:
- completes a full trace;
- finishes the contextual practice set; and
- answers at least two of three review questions correctly.
Progress stays in the browser, alongside theme and lesson preferences. There is no account wall between curiosity and the first experiment.
Keep the unusual algorithms
Bogo Sort and Sleep Sort are not included because they are sensible production choices. They are useful boundary cases. They make assumptions, randomness, scheduling, and the difference between “eventually produces ordered output” and “good sorting algorithm” much easier to discuss.
The same principle shaped the comparison language. SortLab distinguishes comparison sorts from non-comparison sorts and avoids pretending that one ranking works for every data distribution, memory constraint, or key type.
Verify the teaching model
Educational software can be polished and still teach the wrong thing. The test suite generates 355 representative traces, then checks that every result is sorted, preserves the input multiset, keeps metrics monotonic, and maintains equal-value order for stable algorithms. It also exercises boundary inputs, route integrity, practice data, custom-input safeguards, and key accessibility hooks.
The application is deliberately framework-free: semantic HTML, CSS, and JavaScript, with no runtime dependency between a learner and a lesson. That kept the deployment simple and forced the trace model—not a component library—to carry the product.
What I learned
The biggest shift was treating visualization as evidence, not decoration. Once a learner can ask “what happens next?”, change the input, reverse a decision, compare the same data, and explain the result, the animation becomes a laboratory.
That is the version of algorithm education I wanted to build: rigorous enough to be honest, approachable enough to invite tinkering, and structured enough to turn curiosity into a durable mental model.