Contents
Introduction
Algorithm Visualizations vs. Presentations
Why create an algorithm visualization? There is a lot of information that can be conveyed in presentation mode using static images and text. An algorithm visualization has two major advantages over a static presentation:
- An algorithm visualization (or an animation) can get across a dynamic process.
- An algorithm visualization can proactively involve the learner.
Thus, your visualizations should attempt to take advantage of these key differences from static visualizations. Make them as dynamic and proactive as you possibly can.
Purpose of your Visualization
Algorithm visualizations can be created for one or more specific purposes. When designing your visualization, you should keep in mind what you intend it to be used for. Typical uses are:
- Used by an instructor as part of a lecture or presentation
- Supplement to a textbook or other static presentation
- Primary learning source for concepts
- Primary learning source for algorithm or data structure operational details
- Validator for another implementation (input data and see the correct result)
Tools of the Trade
When you sit down to write an AV, you will face a number of important decisions: Write in Java , some other language, or one of the numerous Toolkits? Web-based or executable? Do you even want to make a visualization? Maybe a presentation would actually be better for your purpose.
The choices you make will impact the ease of implementation, your ability to maintain the project, and perhaps most importantly, the educational value of your visualization. We've combed through many existing visualizations and have tried to identify features which assist the developer, the educator, or the learner (with focus on the latter two). This list represents our attempt to distill these features into design principles for creating "good" visualizations, starting with the most important and working towards the "nice to have".
Reduce Complexity
The number one goal an AV developer should work toward is reducing complexity. This can be accomplished in three ways: simple user interface, hidden implementation details, and animated complex operations.
Simple User Interface
A number of visualizations presently available have scads of features, but learners can't penetrate the masses of buttons, menus, and options. Browsing through our Catalog of topics, in general the better AVs are the ones with simpler user interfaces. Extraneous operations should not be included in the presentation just because you know how to implement them; stick to the basic operations of an algorithm or data structure. Avoid menus if possible; try to limit your UI to buttons, text fields, and labels on the window. You're trying to simplify the topic under consideration, not expose every possible bit of functionality.
One exception to this guideline is if you are building a toolkit to support the creation of other AVs; any integrated development environment will necessarily support a great deal of functionality and have a more complicated user interface. However, there are AV environments which attempt to package lots of visualizations into one application and are not IDEs; these jam-packed applications are difficult to navigate and complicate the learning process.
Size Considerations
An AV should aways fit on the screen in its entirety, without requiring scrolling around to see all of its components. [Note that the AV might itself have a scrolling pane, such as for a log of text, that is a different issue.] If the AV is implemented as an applet, that means it should fit within a typical browser window on the screen, which slightly reduces the available space. One should always design with the assumption that the user is limited to 1024x768 resolution. In practice, this means that the applet should not require more than 1000x700 pixels. The reason is that many AVs are going to be used in classroom presentations by instructors, and typical projectors are limited to 1024x768 resolution. And small notebooks with relatively limited screen space are popular.
Hidden Implementation Details
Besides a simple user interface, the best thing you can provide to educators and learners is a simplified model of the topic under consideration. Obviously this is not an absolute (since in some cases, you explicitly want to model the inherent complexity of a topic), but in general, the more you can leave out, the better the remaining functionality will be. For instance, in a demonstration of HuffmanCodingTrees, there is really no need to introduce hash tables or other extra data structures as would be used in a real Huffman coding implementation. Instead, stick to the conceptual model, where the decoder walks through the tree (branching on each bit) in order to arrive at the leaf node holding the appropriate symbol.
Animated Complex Operations
Certain complex operations such as rebalancing AvlTrees may benefit from animation. That is, don't simply throw text on the screen explaining which branches move where; instead, visibly show each branch being reconnected in its new location. This way, the learner can use his or her spatial awareness to follow along with the conceptual steps without becoming disoriented.
Data Sets
A major factor in the success of your visualization is how test data will be input. Fundamentally, there are three approaches: supply built-in data sets, generate a random data set, or let the user supply the data. There are pros and cons to each approach.
User-provided Data Sets
Under the constructivist theory of learning, should be encouraged to provide their own test data to use when studying a given algorithm or data structure. This allows them to focus on key aspects that they are interested in, or have difficulty understanding. This gives them a measure of control and a stake in their learning. Entering data can be done with a simple input box in which the users type numbers or whatever else is appropriate. This is a feature provided by most algorithm visualizations.
If you intend for the visualization to be used by an instructor giving a presentation, then there needs to be an easy mechanism by which the instructor can enter a relatively complex "canned" data set. For example, if the instructor wants to show insertion or deletion in a complex tree structure, the instructor needs a fast and easy way to build up the tree with a meaningful set of input data, and then he or she needs a way to invoke the desired insert or delete command on that built-up tree. A good way to do this might be to allow the user to create a data file, and read that file in or cut/paste it into the visualization's data entry box as a whole.
This also opens up a new use for your visualization: debugging. If a learner has implemented something and wants to check his or her results, he or she can turn to your visualization as a reference implementation. He or she could also compare the output of a debugger with the steps taken by your visualization to understand where errors lie.
Random Data Sets
This can be a good way to give the user control over certain aspects of the data set, such as its size, without making them manage all of the details of providing the complete set. For example, the user might want to control the number of records to be sorted, and perhaps a few other key parameters such as the data distribution, or whether the data is pre-sorted or reverse sorted. The user might not care about the exact values being sorted, and might not want to provide, for example, 100 values. On the other hand, using random data could be a problem if it means that the user cannot reproduce previous runs of the visualization.
Good Built-in Data Sets
While constructivist learning theory indicates that allowing users to input data is the ideal, it is also well known that introductory computer science students are poor testors and debuggers. Thus, they will likely benefit from being provided with good test data sets that will appropriately exercise the key features of the algorithm or data structure being visualized. For instance, if you are demonstrating one of the sorting algorithms, it's normally best to use a uniform random data set of sufficient size (unless you are specifically trying to show the algorithm's performance under a different a class of input). Feeding in "10, 20, 30, 50, 40" to MergeSort and BubbleSort would give learners a misguided idea of the algorithms' respective performances.
Operation
There are some operational features you might consider implementing: stepwise or continuous control, speed control, and undo/redo.
Speed Control
The fundamental operation of an AV is to display a series of events. Depending on how long and involved the series is, and how much the user has to understand, the user might need more or less control over the pacing. For example, if the "event" is just the movement of an object from one position to another, this might be conveyed by a smooth animation. Such "small scale" animations should be controlled by a speed control so that the user can make the animation go fast or slow. Learners can slow down the difficult parts; educators making a presentation can scale the speed to their speech. Everyone gets bored with watching the same thing over and over if goes too slow.
Stepwise vs. Continuous Operation
When a longer series of events is presented, particularly if they contain key content that the user is meant to understand, then it become important to give the user control over the pacing of the presentation. The most extreme case is when the "series of events" is the entire algorithm or operation. Many AVs today are essentially movies, which give the user no interaction or control other than the speed of the interaction. In general, the potential of AVs is best realized when users are more engaged, and in control of the information flow. User studies (see Saraiya 2004) show that there is a significant improvement in learning outcome when an animation is broken into pieces by providing a "next" button" to let the user move from step to step at their pace.
Undo/Redo
As with all human-computer interactions, undo and redo are nice features to include where appropriate. Especially if you allow user-entered data, at least one level of undo would be ideal.
AV Architecture
A major concern in AV implementation is the interaction between the algorithm itself, and the interface that allows users to control pacing through and interaction with the algorithm. See the discussion on this topic.
How NOT To Make An AV
In addition to the positive design principles above, there are some design pitfalls to avoid. Similar to the above list, we begin with the major "don't"s and work towards the smaller issues.
Negation of Good Principles
First and foremost, failure to at least think about the issues above is a poor decision. You may not agree with all our recommendations, but at least reason about the issues yourself and make a decision.
Excessive Documentation Required
If your tool requires more explanation to operate than a textbook chapter on the topic you're trying to illustrate, something has gone wrong. This is not to say that users (especially educators) are off-the-hook with regards to reading READMEs, but other principles (like user-centered design) agree with our perspective that the interface should not require major documentation just to operate at a simple level.
Bugs
So many visualizations out there have known and/or unknown bugs which really detract from their use as educational tools. For example, if a balanced binary tree cannot be balanced in the visualization tool, use of that tool has no educational value (and in fact may decrease understanding!).
Missing Features
Nearly as bad as bugs, missing features detract from a tool's usefulness as well. If a stack visualization can only push but never pop, it's not really a stack visualization at all. In reality, most missing features are not as egregious as that example; they tend to be more esoteric features. Nevertheless, it's important to get complete coverage of a topic in order to make your ADSV as useful as possible.
Lack of a Design Goal
When a user (educator, learner, or researcher) is unable to determine what you intended to do with your visualization, chances are it doesn't do that thing very well. If your AV is intended as an in-lecture presentation maker, make that apparent. Similarly, if it's intended as an exploration tool for learners to use on their own, make that apparent as well. See our list of what visualizations are GoodFor to get an idea of the types of design goals we (and hopefully the community) envision.
Make it Hard to get Started
AVs that are directly available in web pages will typically get more attention from potential users, since they need not go through the additional step of downloading and unpacking an AV or AV system.
Implementing a Common Topic
Lastly, if there are already 100 visualizations for your topic, are you sure you want to spend time implementing it again? Check existing visualizations to make sure that someone else hasn't already done it. If you still want to stick to your original topic, certainly no one will stop you. However, it would be more useful to the community (educators, researchers) if you would implement a topic that has few or no examples (SkipLists, anyone?!?).
Good Examples
Although we have not yet evaluated all of its characteristics, the DijkstrasAlgorithm applet located at http://carbon.cudenver.edu/~hgreenbe/sessions/dijkstra/DijkstraApplet.html appears to be a good example to follow. It has a simple UI, consisting of just a few buttons and one menu, and it has a good built-in data set plus the capability to define your own. It has stepwise and continuous operation modes and hides some of the complexity of implementing Dijkstra's algorithm (for instance, it keeps no table; instead, it keeps all the data directly on the graph). Its only missing feature is speed control for the continuous mode, but there are no obvious bugs and this is not the most common of topics.
Are there other really good examples out there?