- AV Catalog
- Field Reports
- For Developers
- OpenDSA Project
- Getting Started
- Newsletter #1
Submitted by ajalon on 29 March 2010 - 10:29am
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 ﬁelds, 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 difﬁcult to navigate and complicate the learning process.
An AV should aways ﬁt 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 ﬁt 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 simpliﬁed 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 beneﬁt 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.