Ali Raza
04Algorithms · Visualization · 2026

Algorify

See the algorithm. Understand the motion. — an event-driven sorting laboratory built with Python, Dash, and Plotly.

Status
Complete — deployed guides included
Year
2026
Role
Algorithm engine, event model, visualization, playback system, and product design.
GitHub ↗

01Context

Algorify is an event-driven sorting laboratory: a real algorithm runs once, emits a complete trace of events, and the interface replays that trace so every comparison, swap, and pivot can be inspected step by step.

The editorial landing page, interactive canvas instrument, and light/dark laboratory are designed as one product — built for Data Structures and Python Programming study.

Genuine bubble, selection, insertion, Lomuto quick, and merge sort — not animations that pretend to sort.

02Problem

Sorting is usually taught as code you read, not a process you watch with full control — most visualizations play too fast, skip detail, or fake the algorithm with scripted animations.

Students need to pause mid-decision, step backward, read the exact operands and pseudocode line, and see honest counters — not a decorative bar dance.

03Approach

Compute the full trace once: Python validates input, runs the genuine algorithm, and emits independent JSON event snapshots stored in a browser-local Dash store.

Replay, never recompute: a synchronous clientside playback reducer advances the precomputed trace — sorting logic never reruns on timer ticks.

Treat the interface as an instrument: custom Plotly vertical bars with active-index indicators, final-position diamonds, pivot reference lines, exchange arrows, region boundaries, and insertion holes.

Make state inspectable: exact comparison/swap/operation counters, event history, an execution DNA view of the last 180 events, live explanations, and highlighted pseudocode update together.

04Architecture

Trace pipeline — compute once, replay many

  1. Python input validation

    Random or manual arrays, 1–48 values

  2. Genuine sorting algorithm

    Computed once per input/algorithm

  3. JSON event snapshots

    Independent events in a browser-local store

  4. Clientside playback reducer

    Synchronous — no recompute on ticks

  5. Plotly figure + metrics + trace

    Bars, counters, pseudocode, state

05Stack

  • Python 3.10+
  • Dash
  • Plotly
  • Clientside JavaScript
  • Pure-Python algorithm engine
  • WSGI deployment

06Features

  • 01Genuine bubble, selection, insertion, Lomuto quick, and merge sort.
  • 02Play/pause, single step, step backward, replay, reset, and a seekable execution timeline.
  • 03Playback speeds 0.25×, 0.5×, 1×, 2×, 4× — at 1× each event lasts 360 ms and no events are skipped.
  • 04Random arrays of 8, 16, 24, 32, or 48 values (default 32), plus validated manual input of 1–48 integers from −999 to 999 including duplicates, zeros, and negatives.
  • 05Exact comparison, swap, and operation counters; event history; last-180-event execution DNA; live explanations; highlighted pseudocode.
  • 06Custom Plotly bars with active-index indicators, final-position diamonds, pivot reference lines, exchange arrows, region boundaries, and insertion holes.
  • 07Keyboard controls, focus indicators, descriptive graph text, mobile layouts, and reduced-motion support.

07Engineering decisions

  1. D01

    Compute once, replay forever

    The algorithm runs a single time per input and emits a complete event trace. Playback never re-executes sorting logic — so playback is deterministic, seekable, and cheap.

  2. D02

    Pure algorithm engine

    algorithm_engine.py has no Dash dependency: each invocation owns its counters, workspace, and event list. The engine is testable independently of the UI framework.

  3. D03

    Clientside synchronous playback

    A single clientside callback advances the trace and updates every dependent visual together — avoiding server round-trips that would make stepping feel laggy.

  4. D04

    Reset returns to the original array

    Replay studies the same data honestly; a new array is always an explicit action, so algorithm comparisons on identical input stay possible.

08Challenges

  1. C01

    Stepping backward

    Reverse navigation required designing the event model around immutable snapshots — every step must be reconstructable without re-running the algorithm.

  2. C02

    Merge sort buffers

    Merge operations read buffered operands that source bars may have already overwritten — the visualization had to track actual buffered values separately from bar positions.

  3. C03

    Hidden tabs and timers

    Timer ticks must not advance event positions when a tab is hidden, and invalid manual input must preserve the previous trace and pause any run.

09Result

  • A working laboratory: five genuine algorithms with playback, seeking, exact metrics, execution history, and pseudocode — self-contained with no database, API, or credentials.
  • Deployment paths documented for PythonAnywhere, Render, and Railway with a full verification checklist.
  • Browser tests that check mobile overflow, catch console errors, and generate screenshots of home and lab views.

10What I learned

  • “An event-snapshot model separates computation from presentation — and makes "step backward" possible at all.”
  • “Exact counters turn Big-O from a formula into something you can watch happen.”
  • “Building the algorithm yourself (Lomuto partition, merge buffers) is how the details stop being memorized and start being understood.”