A Program Visualization Tool
The long-term goal of this project is to create a visualization tool for
computer programs. Something like Jeliot
(http://www.cs.joensuu.fi/jeliot/index.php), but obviously
During the Summer of Code program, the goal is to write, in Python, a functional
program visualization tool that can visualize Python code.
With the visualization tool, one can write a program and see the execution
visualized to help understanding how the program works. This is especially
useful to assist students learning how to program.
Why this project?
Teaching is very close to my heart and I'm constantly looking for ways to
improve the learning experience in different situations. Visualizing computer
programs is a good aid for many people when they learn how to write software.
Jeliot is seen as representing the cutting edge research of visualization, but
this project should be able to build on it and do a bit better. Some differences
With these changes, the project would deliver a good tool for both educators and
self-learners, bringing the advantages of visualization in learning programming
to the reach of the masses. In addition, the project would try to ease the five
major impediments (see ) for instructors regarding the use of visualization,
using some advice given in .
Jeliot is licensed under the GPL, but it's slow-moving and oriented more towards
research than real-life usage. Also, Jeliot developers seem to have no plans to
support other languages than Java. I have not been able to find other similar
tools of reasonable quality as Free Software, so this would be a chance to fill
this interesting niche.
- Visualize Python instead of Java and aim to support other languages in the future
- Clearer and prettier visualizations with better timing
- Better editor with syntax highlighting (by embedding an existing component)
- Ability to select what to visualize (e.g. not every recursive call when recursion is already understood - a major nuisance with Jeliot)
- Also, ability to visualize on different levels, like having modules as a "black box"
- Better support for self-learners not using the tool on a lecture
What will the project deliver during SoC?
The goals that should be met before the deadline are:
- Ability to write programs in Python with the tool and visualizing the
changes to the program's variables during it's execution while
simultaneously visualizing where in the code the execution is at any given
- Just in case, only promising to deliver the above for simple Python
programs. Defining "simple" will be done together with the mentor if
- Showing the output of each stage of the program
- Using an existing component as the editor and the standard Python
interpreter for code execution
- Ability to skip the visualization of defined lines and handling defined
modules as "black boxes" from the point of view of the visualization
More detailed description of the project
The tool would be built using existing technologies where possible. The
execution of the program should be done using the standard Python interpreter,
with the option of using other interpreters - like Logo, Ruby or Perl - in the
future. The editor used in the tool should also be an embedded component
designed for writing code and supporting visualization-facilitating features
like syntax and line highlighting (I haven't evaluated alternatives yet, but if
none are viable, an existing component can most likely be enhanced to do what's
The UI will be similar to Jeliot's
(example) with a code
area, visualization area, control panel and output area. The layout and look will
be honed during the development.
When the code is executed, the tool will track the line where the execution is
at any given moment, highlighting it in the code are. Variable states are shown
in the visualization area and changes to them are animated. When an output is
produced, it is also moved to the output area with an animation.
The user will have control over the way visualization is done and it's speed,
similar to Jeliot. The program can be executed in steps or with a constant speed
defined by the user. Lines or modules of code can be tagged in the editor to
have them skipped when showing a visualization in the visualization area. At any
moment, the visualization can be stopped and continued with same or changed
As longer term goals that are not aimed for during Summer of Code, one could see
using themes to make more attractive or depicting visualizations and having a
backlog to enable going back in the program execution.
What will I get from this project?
In addition to my profound interest in the subject, I see myself as the right
person for this project since I have done some research into visualization
software at the university. A presentation I held on this topic for a Computer
Science Education course is attached. During my research, I - and others on
the course - could think of several improvements to the current systems that I'd
now have a chance to realize. This is also an excellent chance for digging
deeper into the current research.
For me, this project could also pave a way for my B.Sc paper, which I might do
on the tool resulting from this project. And perhaps this could even provide a
topic for my M.Sc paper later on.
Of course, I'm also looking to meet my personal goals for Summer of Code as
described in my biography.
Please note that one of my main personal goals for participating in Summer of
Code is to learn how to write software better. I have no experience in things
like unit tests nor do I really know how much time should be given to the design
in real world. These are the kind of things I hope to learn with the help of the
mentor(s) and thus the schedule will likely be among the first things to review
and polish together.
June: Further research on the topic, discussions with the mentor to refine the
plans, first design drafts.
Early July: improve the design and document it, decide upon the external code to
use, begin writing code.
Late July: Focus on producing more code to implement the key features, start
creating visual elements, keep revising the design and other plans if needed,
Early August: Finish implementing key features and visual elements, confirm that
the design has been implemented, finish the documentation content-wise.
Late August: Stabilization period, implement missing pieces of the design if
any, freeze the code for Google/mentor review, polish the documentation.
Early September: Wait eagerly for judgement, create one's own Post Mortem.
After results: Open the project for all interested, lead development to new
interesting directions :)
 Naps, T.L., Roessling, G. et al. Exploring the Role of Visualization and
Engagement in Computer Science Education. ACM SIGCSE Bulletin v.35 n.2,
(June 2003), 131-152
 Naps, T.L., Roessling, G. et al. Evaluating the Educational Impact of
Visualization. ACM SIGCSE Bulletin, v.35 n.4, (December 2003), 124-136
 My presentation on SV and Jeliot: