Day 12 (or so) - 30 Day Learning Challenge

How to Visualize Program Execution/Step Debugging

So this post was trigger by looking at TurtleJS by Walter Bender.  In playing with TurtleJS (which by the way has a rather nice interface design to support both mouse, touch, large screen and iphone size screens) I made a comment that

... would also be nice to have a "Step" button/icon.  Where kids could step through the scripts.  I often do this when kids don't understand a bug in there code.  Allowing them to step through one tile at a time (and ideally having them narrate what they think should be happening) often helps them debug without me really doing anything other than getting them to slow down and observe what each tile actually does.

So I started to think about different ways this could be implemented in TurtleJS and I prototyped some in Etoys.   Below is the current visualization:

What is hard to see in this image is that the block is highlighted in both scripts.  Here not only is the executing block "highlighted" (actually the block color is lightened to indicate executing), but also the blocks (as the execution is within each repeat) and the block which is waiting for "return" from .

So in effect this implementation is not only showing the "executing" block, but also the "call stack".  I wonder whether showing both the executing block and the "call stack" is a bit much visual/cognitive overload.

The following is my first attempt at prototyping a different visualization:

What I was trying to do here is make it more visually apparent which block is executing and what "script/block" called .   One thing I felt was missing was showing that we were in the loops so I tried the following:

I think I would have preffered to make the "repeat lines" dashes here and not really cray about the "calling arrow" from as I think it is a big.  The whole thing is also a bit too busy as the eye should be drawn to the action and the "main character" (suggested reading -

The Illusion of Life: Disney Animation: Ollie Johnston, Frank Thomas

great book on design).

So here is my last prototype for the day:

The point is to "gray out" the uniteresting parts to help the user's eye focus on the main action (watch some Disney animation and look at the "lighting").  I wound up "greying out" the "non executing" blocks and using a slighlty less grey mask for the blocks.  I would probably also do a light grey for the .


Last few notes:
1) I think it would be nice if the executing block's grew larger as they executed.  But the particular block library Walter is using apparently messes up layout when you do this.
2) The actions on stepping happen to fast. Ideally when stepping and there is a concrete execution of a block (ie: forward or turn vs. an arithemetic function) it might be good if the concrete action was slowed down so that the forward 100 did took a 1 sec instead of "instantly" (something similar to the way the scratch Glide tile works). Of course if you implemented a glide, that might need to glide slower and could mess up certain debugging cases that rely on timing.  Even if you didn't implement a glide block, someone could conceivably implement their own glide action.

The main problems I am trying to solve are:
1) Getting the students to slow down their thinking
2) Getting the students to pay attention to what they actually told the computer to do vs what they intended to/think they told the computer to do.
3) Providing a more concrete representation of code execution
4) Getting the kids to think about what's going on inside the computer (more on this when I describe how the online Python tutor tries to solve the step debugging problem).

Cheers,
Stephen