This document proposes an Android application to serve as an educational tool for visualizing algorithms and testing user knowledge. The application would have three main components: 1) A learning mode that visually demonstrates algorithms step-by-step; 2) A testing mode that allows users to manipulate data structures and verify their understanding; 3) Statistics on user errors to help instructors. The project aims to help students learn algorithms on mobile devices. It will focus on graph algorithms like Kruskal's minimum spanning tree and use randomly generated graphs for testing. The application will be developed in four stages: requirements gathering, design, infrastructure implementation, and user interface development.

1. CS512 Project: Android Application as an
Educational Tool for Algorithm Visualization and
User Knowledge Testing
Hristiyan Kourtev, Anwar Jameel, Aditya Ambadipudi Venkata
Rutgers University, Piscataway, NJ, USA
Emails: hkourtev@ruccs.rutgers.edu, aj528@scarletmail.rutgers.edu, vsa17@scarletmail.rutgers.edu
RUIDs: 102009662, 166009833, 167000877
Abstract— In order to understand the algorithm, however simple
it may be, we often employ some kind of visualization (drawing on
paper, image, video etc.). Anyone who has studied algorithms knows
how helpful a visualizer can be to understand how an algorithm
works. By seeing how the algorithm works step-by-step we can often
understand it with just a glance, while going through the pseudo
code and other written explanations and trying to imagine what is
going on, can be time consuming, confusing and frustration. There
is a wide variety of algorithm visualizers for different algorithms
and representations, however what we haven’t been able to find
however was a tool that allows user to visually manipulate the data
and data structure, in a way the algorithm would and check each
step to make sure user is doing exactly what the algorithm would
have done. Our application does exactly that, while also collecting
statistical information about errors made by the user, which can help
instructors and students to identify problematic areas/steps and work
on improving them.
I. PROJECT DESCRIPTION
Our goal is to build an Android application, which will serve
as a teaching and learning tool with 3 major components:
• Learning mode, providing step-by-step visualization of
graph-based algorithms, such as Kruskal/Primm’s Mini-
mum Spanning Tree algorithm.
• Testing mode, providing a visual interface for manip-
ulating data and data structures to duplicate the steps
performed by the specific algorithm, an excellent way
for users to test their understanding. Each step will be
verified against the algorithm and feedback will be pro-
vided in real time. This latter capability is something we
have been unable to find in any other mobile/touchscreen
application for algorithm visualization available at the
moment.
• Statistics, providing an overview of the number and
frequency of each type of mistake made and the step
in the algorithm at which they occurred. Such statistics
can be very useful to an instructor, who can use them to
identify problematic areas and work on providing better
explanation.
We believe our project will help many students to test and
improve their knowledge of algorithms. Being an application
for a mobile platform it is something which students can do
on the move, while waiting for the bus, for example.
Our main hurdle will be to find a streamlined visual inter-
face which provides all necessary information, allows the user
to modify the data and data structure involved in the algorithm,
while being easy and intuitive to use. We will also build the
system with expandability in mind, so that it can be extended
with additional algorithms without too much difficulty.
The project has four stages: Gathering, Design, Infrastruc-
ture Implementation, and User Interface.
A. Stage1 - Requirement Gathering Stage.
Before commencing any project it is important to clearly
define, objectives, users, requirements, a realistic timeline and
ways to fairly and efficiently divide work within the team.
• Types of users: A wide variety of users can use our app,
for example students, teachers and people who are just
curious about algorithms.
• User interaction modes:
– Learning mode, where the algorithm operations will
be demonstrated step by step on a random set of
data, while each step is narrated in detail as well
– Testing mode, where the user will be presented with
input data and the necessary data structure building
blocks and will be asked to perform all the steps
the algorithm would perform in order to produce the
correct final output.
– Statistics mode, which allows users to view statis-
tical information about the type and frequencies of
mistakes they have made.
• Real World Scenario 1 - Student learning how to use
Kruskal’s algorithm to produce the Minimum Spanning
Tree of a given graph:
Students and other curious individuals can use the appli-
cation to get a visual representation of how a particular
algorithm works, step by step, together with detailed
explanations.
Once students are familiar with the process and data
structures used they can switch to test mode and test their
knowledge by trying to replicate the algorithm’s steps
on a new randomly generated graph. At each step the
system will verify their actions and will not allow them
to proceed until they perform the right action or until they
make 3 incorrect choices in a row, at which step the step
will be skipped and the user can continue.

2. – Input Data Types:
A graph G with V vertices and E edges where every
edge has a weight.
– System Data Output:
Visualization and explanation of each and every step
of Kruskal’s algorithm for finding the Minimum
Spanning Tree of a graph G. A Minimum Spanning
Tree of G.
– Output Data Types:
A list of the steps involved in computing Minimum
Spanning Tree of a given graph G, using Kruskal’s
algorithm and a list of any errors made by the user.
• Real World Scenario 2 - A teacher teaching Minimum
Spanning Tree Algorithms and testing students’ knowl-
edge of Kruskal’s Minimum Spanning Tree Algorithm:
A teacher in a digital classroom equipped with electronic
tablets can teach the algorithm by demonstrating the step
by step visualization of the algorithm using this mobile
application.
The teacher can then use the application as a testing
platform with automatic scoring and can use the statistical
data collected to identify potential problems with their
description of certain steps of the algorithm and work on
generating better descriptions, if necessary.
– Input Data Types:
A graph G with V vertices and E edges where every
edge has a weight.
– System Data Output:
Visualization and explanation of each and every step
of Kruskal’s algorithm for finding the Minimum
Spanning Tree of a graph G. A Minimum Spanning
Tree of G.
– Output Data Types for Scenario2:
A Minimum Spanning Tree of G.
• Project Time-line
– Stage 1 - Requirement gathering stage: Submit
project proposal. (Due October 28, 2015)
– Stage 2 - Design stage: Choose algorithms to be
included in the application, define general categories
and group algorithms based on similarities of data
structures used, methodology and visual represen-
tation, identify visual and structural items needed
to implement the algorithms in each category. (Due
November 3, 2015)
– Stage 3 - Implementation stage: Program visual and
back-end items. Debugging and preliminary testing.
Usability testing with real users. (Due November 24,
2015)
– Stage 4 - Presentation: Prepare project highlights and
final presentation. (Due December 3, 2015)
• Division of Labor.
– Hristiyan: User Interface design and implementation
– Anwar: Database and Back-End design and imple-
mentation
– Aditya: User Experience design and implementation,
usability testing
B. Stage2 - Design Stage.
• Short Textual Project Description.
The application being designed contains 4 activi-
ties (activity in android is every screen that user
can see and interact with) namely Main Activity,
Learn Activity and Test Activity. Main Activity is
the activity which gets invoked with the application
launch by the user. Main Activity provides the user
with options to enter into Learning mode (Learn
Activity), Testing Mode (Test Activity), Statistics
Mode (Statistics Activity) or Exit the application.
Learning Mode (Learn Activity) comes into the
foreground when user selects Learning mode in Main
Activity. Learn Activity runs the services (service
in android is a background process) to generate the
graph, run algorithm on the generated graph, store
the algorithm steps to database and visualize the
stored steps in an orderly manner.
Testing Mode (Test Activity) comes into the fore-
ground when user selects Test mode in Main Activ-
ity. Test Activity runs the services to generate the
graph, run algorithm on the generated graph, store
and retrieve the algorithm steps to and from database,
draw the graph on screen, check the user steps to
trace an algorithm and display the statistics of test.
• Flow Diagram. Flow Diagram is shown in Fig. 1
• High Level Pseudo Code System Description. Please
insert high level pseudo-code describing the major system
modules as per your flow diagram.
• Algorithms and Data Structures.
– Graph Generation Algorithm (Description)
In order for the app to provide a better educational
experience and to give users the ability to test
themselves on the same algorithm multiple times, we
decided that it is necessary for us to use randomly
generated graphs. This means that every time the
user reloads the application they will see a different
graph. Using randomly generated graphs will ensure
that the users get to see how the algorithm operates
on a variety of different graphs and will prevent them
from remembering a solution, so that every time they
test themselves on one of the provided algorithms,
they will actually need to solve a completely different
problem. This required us to solve the problem of
random graph generation. Our research revealed that
random graph generation is a very complex prob-
lem with a multitude of parameters and constraints,
depending on the purpose and type of graph. Our
time constraint prevents us from performing detailed
research on the subject, so we looked for a simple

3. Fig. 1. App Flow Diagram
(even though imperfect) method, which would be
easy to implement. We initially planned on using an
algorithm called ”The Configuration Model” and in
particular, ”The Erased Configuration Model”. The
algorithm’s inputs are n - number of vertices and d -
average vertex degree desired. It proceeds by creating
n vertices and a standard probability distribution for
the vertex degree F with median d. It then iterates
over the list of vertices and for each one generates
d stubs (stubs are edges for now just connected to
the current vertex v). d is picked randomly based
on the probability distribution F. Then it loops over
the stubs and joins each randomly selected pair.
The resulting graph may not always be simple and
there could be multiple edges between vertices. To
solve this problem the algorithm inspects all edges
of the graph and collapses any multiple edges into
a single one. Despite the relative simplicity of this
algorithm it solves one problem and creates many
more. Having a truly random graph requires a good
universal graph visualization algorithm and that is
yet another very broad research area which we will
be unable to properly explore in the limited time that
we have. In addition to the time constraints we are
also restricted by a relatively small workspace (e.g.
a cell phone screen) and the need for a clean and
unambiguous visual representation, where all nodes
and edges are clearly visible, not overlapping and
of a size that is easy to select and manipulate with
a finger. All of these restrictions and the fact that
the purpose of this project is algorithm visualization,
not in-depth research on graph generation and visu-
alization algorithms, forced us to come up with an
alternative semi-random graph generation algorithm,
which would solve both problems (generation and
visualization) with one stroke. We begin with a
predefined matrix-like graph of 4 x 3 vertices with
each node having an undirected edge to each of
its neighbors (see Fig. 2). Each node can have the
following types of edges E, NE, N, NW, W, SW, S,
SE, where E, W, N, S represent East, West, North
and South respectively.
We then randomly pick X (X will probably = 3)
nodes to be removed. When removing a node we
check to see if there are opposing edges (e.g. N
and S, or SW and NE). If such pairs exist, they
are replaced with a single edge that spans the entire
distance between the 2 neighbors of the node that is
being removed.

4. Fig. 2. Initial default graph with nodes marked for deletion
Fig. 3. Nodes removed
Finally we loop over all edges and assign them ran-
dom weights from a pre-specified range. If the graph
needs to be directed, we replace each undirected edge
(u,v) with a random choice of either 1 directed edge
(u, v), 1 directed edge (v, u) or 2 directed edges (u,
v) and (v, u) - i.e. a loop (See Fig. 4).
Even though quite simple this algorithm can still
generate, a wide variety of graphs, sufficient for our
needs and greatly simplifies the graph visualization
problem, allowing us to spend more time on the user
interface and experience.
– Graph Generation Algorithm (Data Structures)
Please note that since a lot of the data structures we
use are shared between modules, we will only list
their names and for more information you can refer
to the comprehensive list of data structures at the
end of this section.
Pseudocode:
Fig. 4. Cross edges removed. Directed graph.
function generate graph(height, width)
input height: the height of the base graph which
will prune, the width of the base graph which will
prune
output: A random graph
begin
graph base = generate empty graph(height,
width)
for i := 0 to height
for j := width
boolean node lives = gener-
ate random number(0, 1) > 0.5 ? true : false;
if(node lives)
base[i][j].valid = true;
foreach (node1, node2) in base
boolean edge lives = gener-
ate random number(0, 1) > 0.5 ? true : false;
if(edge lives)
node1.connects(node2)
return base;
end
Data structures used for graph generation: Graph,
Node, Edge
– Visualize Steps (Description)
In order to be able to visualize (in learn mode)
and verify (in test mode) steps, we store the steps
that the selected algorithm takes during its execution
and store them in an ordered list. Each step can be
comprised of 1 or more actions. Here’s an example
of a step with multiple actions: selectEdge(u, v),
relaxNode(u, v, w); During visualization we begin
by drawing the original graph. We then loop over
the list of steps, executing each one and redrawing

5. the graph. In addition to specifying what actions
to take in each step, actions are also described in
plain English and captions of each step are displayed,
wherever applicable, each time the graph is redrawn.
– Visualize Steps (Data Structures)
Data structures used: Exercise, Graph, Node, Edge,
SolutionStep, Action
– Verify Steps (Description)
The verification process is very similar to the step
visualization process. After the original graph is
displayed we wait for user input. We then wait for
user input. When the user has made the same number
of actions as the number of actions we have in the
current step, we display a ”Confirm Step” button to
the user. The user has the choice to make changes to
the steps they have made or confirm. The total time
taken by the user to execute this step is recorded for
statistical purposes.
Upon confirmation we compare the actions that the
user made in the current step, with the actions we
expect. Actions do not need to be in the same order,
so for each user action we search the entire list of
actions comprising the current step.
If all steps match, the user is given positive feedback
(ding sound) and is allowed to continue. If the user
has made a mistake he is given negative feedback
(buzzer sound) and is allowed to retry. If the user
makes 3 mistakes the correct step is executed and
visualized and the user is allowed to continue.
– Verify Steps (Data Structures)
Data structures used: Exercise, Graph, Node, Edge,
SolutionStep, Action, Mistake, DBHandler
– Draw Graph (Description)
The graph generation algorithm provides us with a
list of nodes and edges and has an inherently neat
rectangular shape overall, so displaying the graph is
quite trivial.
We begin by first drawing the nodes. We know the
screen size and node size relative to the screen size,
margins and padding, as well as the number of rows
and columns of nodes so it is easy to calculate the
spacing between nodes. The edges of each node are
also labeled using geographic directions so we know
where each node needs to be positioned relative
to others. Once the node positions for the current
screen size are calculated (Fig. 4), we add some
random jitter to their positions, in order to make the
graph look more random and less rectangular. The
jitter is a small translation in a random direction.
The resulting graph now looks a lot more random
and less artificial (Fig. 5).
Pseudo code
Function draw graph(nodes[row][col], edges,
width, height)
Fig. 5. Cross edges removed. Directed graph.
input: nodes[row][col], edges, screen width, screen
height
begin
node radius = min( (height - 100)/row, (width -
50)/col );
for i := 0 to row,
for j := 0 to col,
if(nodes[row][col] is set to show):
X = 25 + col * (node radius +
node padding);
Y = 50 + row * (node radius +
node padding);
draw circle(node radius, X, Y);
for each edge E,
Nodes start = E.start
Nodes end = E.end
draw line(start.coordinates, end.coordinates)
end
– Verify Steps (Data Structures)
Data structures used: Graph, Node, Edge
– Display Statistics
Upon completion of the exercise we loop through
all the steps taken by the user and calculate the total
number of mistakes made and time taken to complete
the exercise.
– Data Structures (Detailed Outline)
Node (properties)
∗ label
∗ value
∗ color
∗ size
∗ border thickness
∗ position
∗ edges (E, NE, N, NW, W, SW, S, SE, Other)

6. Node (functions)
∗ create
∗ delete
∗ select
∗ move
∗ draw
∗ set value
∗ set color
∗ set thickness
∗ get degree
∗ get neighbors
∗ relax
Edge (properties)
∗ start node
∗ end node
∗ directed
∗ weight
∗ color
∗ thickness
∗ start point
∗ end point
Edge (functions)
∗ create
∗ remove
∗ draw
∗ select
∗ set color
∗ set weight
∗ set thickness
Graph (properties)
∗ nodes
∗ edges
∗ roots
∗ solution steps
Graph (functions)
∗ generate
∗ draw
∗ add edge
∗ remove edge
∗ solve (takes as input the algorithm to run)
SolutionStep (properties)
∗ actions (list)
∗ final (boolean)
∗ num tries
∗ time taken
SolutionStep (functions)
∗ add action
∗ remove action
∗ compare actions
Action (properties)
∗ action index (from a predefined list of actions)
∗ action parameters
∗ description
Action (functions)
∗ compare
Exercise (properties)
∗ original graph
∗ final graph
∗ algorithm
∗ solution steps
Exercise (functions)
∗ initialize
∗ generate solution steps
∗ visualization next step
∗ visualization previous step
∗ exercise wait for input
C. Stage3 - The Implementation Stage.
Our project is an Android Mobile Application, therefore,
we have used JAVA programming language and Android
Studio integrated development environment for our project.
The deliverables for this stage include the following items:
• Sample small data snippet.
– Fig6 shows the sample graph which is fed to the
algorithm for finding MST. This input graph is
generated randomly.
Fig. 6. Randomly Generated Input Graph
• Sample small output.
– Fig7 shows the step by step Minimum Spanning Tree
construction using Union by Rank and FindSet with
path compression operations.
• Working code.
– Working Code is submitted in a zip file.
• Demo and sample findings.
– Fig8 shows the Final Output i.e. Minimum Spanning
Tree
– System Memory Requirement for Application to run
is 512MB RAM
– User cannot manipulate with the graph during Learn-
ing Phase. Every time the user launches the activ-
ity, user is provided with the new graph which is
randomly generated in its size and the associated
weights for each edge. User is provided with a

7. Fig. 7. Minimum Spanning Tree under construction using a forest of
trees to represent disjoint sets
Fig. 8. Output Minimum Spanning Tree
Learning Method which displays the foundation of
an algorithm such as Union and FindSet operations.
D. Stage4 - User Interface.
The developed Android application provides user with a
user friendly interface to interact with the application. The
User Interface is designed in order to provide the user with
effective ways of learning. The HOME screen of application
appears when user starts the application by pressing the appli-
cation icon. The Home screen provides the user with an option
to Learn, Test, View Statistics and Exit. The activity on the
basis of user’s selection(learn, test etc.) will be launched next.
The Learn activity provides a step-by-step visualization of the
steps the algorithm makes in order to produce the final output.
The Test activity provides the user with a testing environment
where, using the touch screen, they can manipulate the data
and data structures in the same ways the algorithm does. Each
user action is verified by comparing it against the step that the
algorithm would perform. Appropriate confirmation and error
messages are displayed at each step, in addition to a pop-up
message and auditory feedback (good sound/bad sound). At
each step, in both Learn and Test activities, the user is able
to switch between Tree View (the default view; displays the
forest of trees that the algorithm uses) and Graph view (shows
the MST as it is being built, using the original graph topology).
Most figures in this section will display both views. Statistics
of user attempts are stored and can be retrieved by launching
Statistics activity.
• The HOME screen of application appears when user
launches the application and it looks like as follows:
Fig. 9. HOME Screen
• Learn Activity - Randomly Generated Input Graph (Fig.
10)
Fig. 10. Initial Learn Mode Screen - Input Graph
The user is only able to press ”NEXT”, so it is very
intuitive. After the first step the user can use the ”PRE-
VIOUS” button to go back and review a previous step if
they like. They can use the ”SWITCH VIEW” button to
switch between Tree and Graph views
• Learn Activity - Make Set operation (Fig. 11)
In tree view, nodes not yet in a set are displayed in the
column to the right, while the nodes produced by the
Make Set operation are arranged horizontally, with a rank
of 0 and red halo to denote that those nodes are roots The
notification box displays detailed information about this
step. Message format: ”Create set of 1 with root node u”,
where u is the label of the node.
• Learn Activity - Select Edge operation (Fig. 12)
The previously explored edges are colored in gray, un-
explored edges are colored in blue, just like the nodes

8. Fig. 11. Making Sets
in the trees and graph and the currently selected edge
nodes are colored with 2 different colors in both the
list at the bottom and in the tree/graph as well. This
makes it easy for the user to visualize the sets/nodes we
are working with at all times. The notification box also
displays information about which set is currently selected.
Message format: ”Select edge (u,v)”, where u and v are
the labels of the nodes.
• Learn Activity - Union operation
Message format: ”Unite the sets that node u belongs to
(tree with root x) and v (tree with root y) by making node
u parent of node v”, where u and v are the nodes of the
currently selected edge and x and y are the roots of the
sets they belong to (can also be u and v, or just u or just
v).
• Learn Activity - IncreaseRank operation This operation
increments the rank of the parent set’s root and redraws
the graph. Message format: ”Since the root of the parent
tree (node u) has the same rank as the root of the tree
being appended (node v), we increase the rank of node
u”, where u and v are the roots of the sets that the nodes
of the currently selected edge belong to.
• Learn Activity - AddToMST operation This operation
adds an edge, that has had the Union operation performed
on it, to the list of MST edges, that will be used to
produce the MST. Message format: ”Adding edge (u,v)
Fig. 12. Union operation performed. Selected edge can be seen colored
in yellow/orange
to MST”, where u and v are the labels of the nodes of
the currently selected edge.
• Learn Activity - SkipEdge operation This operation skips
the current edge, since its nodes are already in the same
set. Message format: ”Nodes u and v belong to the same
set. Cannot unite. Skipping edge.”, where u and v are the
labels of the nodes in the currently selected edge.
• Learn Activity - Final Product (Fig. 13)
The MST is complete. We can see both the final tree
produced by the union of sets as well as the actual MST.
Message format: ”All edges explored. Minimum Weight
Spanning Tree complete. Weight: X. Press QUIT to go
back”
• Test Activity - Randomly Generated Input Graph
The user is only able to press ”START”, so it is very
intuitive what to do.
• Test Activity - START The user has at their disposal
2 actions/buttons - GET NEXT EDGE and UNION.
The user begins with the MakeSet operations and Sort-
Edges operation already completed. This is done since
the operations are trivial and time consuming if done
manually one by one. Initially those actions were manual,
however automating them greatly improved the user
experience, without having a detrimental effect on the
learning experience. The user is clearly informed of this

9. Fig. 13. Final product - MST complete
Fig. 14. Initial Test Mode Screen
and is prompted to begin by getting an edge from the
queue. Message format: ”NOTE: All MakeSet operations
and the SortEdges operation have already been executed
automatically, as they are trivial. Please begin by getting
an edge from the list.”
• Test Activity - GetEdge operation (Fig. 15)
The ”GET NEXT EDGE” button combines 2 different
operations - GetEdge and SkipEdge. A separate button
for SkipEdge was initially created, however Simplifying
by combining both of these operations under the same
button (since they are very similar) resulted in a more
fluid user experience. Getting an edge colors its nodes so
they can be easier to identify. In case of this being the
correct step there are 2 cases
Fig. 15. Test Mode - Get Edge operation
– Case 1 - The nodes on the edge belong to the same
set so the user would like to skip this edge and
get the next one. Success Message format: ”STEP
CORRECT! Nodes u and v belong to the same set.
Cannot unite. Skipping edge”; ”Select edge (u,v)”
The user also received positive auditory feedback
(ding)
– Case 2 - The nodes on the edge have already been
united, so the user would like to get the next edge.
Success Message format: ”STEP CORRECT! Select
edge (u,v)” The user also receives positive auditory
feedback (ding)
In the case that this is the incorrect step, the user is given
the proper feedback (See Fig. 17) Error Message format:
”Error: Wrong action selected. Try again. of errors until
step is skipped: X” Popup message contains the same
text. It automatically disappears after a couple of seconds.
The user also receives negative auditory feedback (errr)
• Test Activity - FindSet operation (implicit) This operation
is one of the major parts that are peformed by the user.
They have to do a visual search and figure out for the
node in question, which set it belongs to.
• Test Activity - Union operation (Fig. 16)
Pressing the UNION button prompts the user to make
the right selection. They need to select the sets that the
2 nodes belong to by touching the roots of those sets.
The tricky part here is the order in which the set roots

10. Fig. 16. Test Mode - Union operation
need to be selected, as the first selected root is to be the
parent of the second. If both roots have the same rank,
the order obviously doesn’t matter, however otherwise it
is mandatory that the user selects the root with the higher
rank first. Again in order to streamline the user experi-
ence, the Union operation in Test mode combines 3 steps
- Union, IncreaseRank and AddEdgeToMST. Message
format: ”Action UNION selected. Select the roots of the
2 sets that should be united” After selecting one node,
the user is provided with additional feedback: Message
format: ”You have successfully selected node (u). Please
select 1 more node or press CANCEL” Upon selecting
the second node, the step is automatically verified. And
the user is given the proper feedback: Success Message
format: ”STEP CORRECT! Unite the sets that node u
belongs to (tree with root x) and v (tree with root y)
by making node u parent of node v”; ”Since the root
of the parent tree (node u) has the same rank as the
root of the tree being appended (node v), we increase
the rank of node u”; ”Adding edge (u,v) to MST” The
user also receives positive auditory feedback (ding) If the
step is incorrect, there are 2 possible reasons: the user
was not supposed to do a Union, or they selected the
wrong sets (See Fig. 17). Error Message format: ”Error:
Wrong action selected. Try again. of errors until step
is skipped: X” Popup message contains the same text.
It automatically disappears after a couple of seconds.
The user also receives negative auditory feedback (errr)
Error Message format: ”Error: Correct action selected but
wrong parameters provided. Try again. of errors until
step is skipped: X” Popup message contains the same
text. It automatically disappears after a couple of seconds.
The user also receives negative auditory feedback (errr)
• Test Activity - Final Product The MST is complete. We
can see both the final tree produced by the union of sets
as well as the actual MST bu switching views, just like
in the Learn Activity (See Fig. 13)
• Test Activity - More About Errors As mentioned above
the user is provided negative feedback in 3 ways - the
notification box (See Fig. 17), a toast message (popup)
(See Fig. 18) and via auditory (an ”errr” sound).
Fig. 17. Error Messages
Fig. 18. Wrong action
After 3 wrong attempts in TEST mode, an error message
appears and user is advanced to the next step as shown
in the Figure 19:
• Statistics Activity:
for every TEST trial by the user is saved and displayed
when user launches Statistics Activity from Home Screen.
Statistics are shown in Figure 20:
• Future Work: There are 2 major ways in which we believe
the app can be improved:

11. Fig. 19. User is advancing to next step automatically
Fig. 20. User Test Trials Statistics.
– Extendability and Usability: Add more algorithms
and further improve the user experience. Currently
in order to extend the app capabilities by adding an
additional algorithm, the programmer would need to
create a Java class with the algorithm implementa-
tion, as well as create activities for the Learn and
Test modes, where they implement a button for each
possible algorithm action. This process is not easy to
automate but it is possible to create a standardized
way of doing this (e.g. a plugin architecture), so that
algorithms can be added without the need to code in
Java.
– Global Statistics: Currently the statistics are stored
in a SQLite3 database on each individual machine,
so the data collected is for the users of that particular
device only. The data can easily be stored in an
online database. This improvement would allow a
teacher to easily get statistics about multiple students
at once.
REFERENCES
[1] Roberto Tamassia, Handbook of Graph Drawing and Visualization -
https://cs.brown.edu/∼rt/gdhandbook/
[2] Force-Directed Graph Drawing Approach - https://en.wikipedia.org/
wiki/Force-directed graph drawing
[3] Force-Directed Graph Drawing Approach - https://www.youtube.com/
watch?v=VxiKoT I P4
[4] JUNG - Java Universal Network/Graph Framework - http://jung.
sourceforge.net/
[5] Flowchart Shape and What They Mean - http://www.rff.com/flowchart
shapes.htm
[6] 10 Tips and Tricks for Making Flowcharts - http://www.breezetree.com/
article generalflowcharting1.htm