Learning through Visualization

A textbook does one thing well and one thing badly. It holds a precise definition still on the page for as long as you need it, and it asks you to build a moving picture in your head out of words alone.

This began as a question about that trade. Where does seeing a concept beat reading about it, where does it not, and what should someone building a learning tool do about the difference? I surveyed 55 students at USF, interviewed three computer science professors, and read the meta-analyses that already exist comparing block-based and text-based programming.

What the students said

Six statements, rated one to five.

The strongest result was also the least surprising. Visual materials make new concepts easier to understand scored 4.67, with 96 percent agreeing or strongly agreeing. Motivation followed at 4.26. Preferring a textbook to an interactive tool came last at 2.30, where only 13 percent agreed.

Two other results were worth more than the ones that confirmed the hypothesis.

Retention scored 4.21, and it is the number I trust least in my own study. It measures what students believe about their retention rather than their retention. The literature has been asking for longitudinal work on exactly this point for years, and a one-off survey cannot supply it.

Then the flattest number of the six. Text is better for advanced content landed at 3.00, dead centre, with the responses piled on the midpoint. I had expected agreement. The open responses showed why it did not come: students do not treat this as a question about difficulty at all.

Where text won, in their words

They reached for text when they needed exactness. Formal definitions. Bayes' theorem. API documentation. One respondent described debugging assembly and going straight to the RISC-V instruction set reference, because they needed exact opcode semantics, register conventions and edge cases, and no diagram of a datapath carries any of those.

That is not text winning on difficulty. It is text winning on precision, which is a different axis, and it is why the 3.00 sits where it does.

The other two cases were writing-heavy courses, where the text is the content rather than a description of it, and detailed procedural work where the exact mechanics matter as much as the shape of the thing.

The interview that changed the question

Two of the three professors said roughly what I expected, with useful sharpening. The first named instructor time as the real constraint: he could see the value of good visual tools and could not build them inside a normal teaching load. The second drew a line between animation that simplifies and animation that decorates, and defended only the first. A call stack building downward earns its motion. A wall of text, in her words, is universally bad.

The third disagreed with the framing. Engagement is the wrong thing to optimise, he argued. What students struggle with is debugging and reasoning systematically, and the test for any visual tool should be whether it builds that habit. On his account the motivation score is a weak result wearing the costume of a strong one.

He is right that it reframes the question, so the prototype is built around his objection rather than around the 96 percent.

What came out of it

The clearest agreement in the whole study came from the open responses about an ideal tool, and it matched where the literature already pointed: a hybrid, with the ability to switch between a visual and the text for the same thing.

The prototype takes that literally. Every lesson is a list of steps, and the visual mode and the text mode are two renderers over the same step index. Switching modes re-renders the step you are standing on, so the two views cannot drift into describing different moments. That constraint is the design.

Seven lessons run across five fields, which was deliberate: if the effect is real it should not stop at computer science. Binary search, recursion and hash tables, then solving an equation on a balance, projectile motion, a base-rate problem worked over a hundred people, and building a major scale on a keyboard.

The third professor's objection shows up as the checkpoint engine. At the steps that matter you cannot advance by watching. The lesson stops and asks you to pick the legal algebra move, or predict the velocity, or work out how many of those hundred people test positive once you account for the false ones. A wrong answer keeps you there. It turns the mode switch from something a learner does passively into something the app can measure.

The whole app is one HTML file with an inline script, plus a service worker so it runs offline. No build step and nothing fetched from a CDN. 83 logic tests cover the step machinery and the checkpoint validators against a fake DOM.

What this does not show

One institution, and a sample three quarters of which is computer science, so it says little about how any of this lands elsewhere. Fifty-five students is enough to describe and not enough to generalise. Three professors is rich and not representative. Every measure is self-reported, which is the sharpest limit of the four, because the claim people most want from this work is about retention, and retention is the claim a survey is least able to make.

The prototype has not been run as a study yet. It is instrumented for one: it records which mode a learner picked, how often they switched, and what they say helped once the lesson ends. Those logs are the point of the next phase.