Discussion questions from CS 7390 lecture

Date: 2/7/96

Presented by: John Stasko

Topic: Algorithm Animation Systems 2

• How extensible is Tango? How easy is it to add new functionality such as support for 3D or VR animations?
• If Dance allows you to generate Tango code, are there any instances where you must use Tango? Are there any things you cannot do in Dance?
• Direct manipulation seems like an intuitve and interesting solution to animating algorithms. However, more complex views, such as a pie chart that constantly changes pie cuts, would be much easier to describe parametrically in a program. How does Dance support this type of animation?
• Tango has similarity to the Smalltalk system in that it has annotations and promoies smooth transitions where Balsa takes discrete steps and the algorithm sits in the Balsa system. Why is Tango uniquye in comparison to the Smalltalk system and what does the Balsa system lose out on?
• In the framework for Tango and its data type operations, what do you need to modify (if any) to work in a 3D space?
• Tango is different from other systems, like Balsa, in that you don't have to break youir code and include it in the animation software. In which other ways is it different?
• What limitations does the programmer have if they use Dance rather than directly using Tango?
• Balsa discussed the issue of handling timing (length & speed of animations). How does Dance/Tango handle this?
• When using direct manipulation, can we use some algorithm to smooth the trajectory?
• In Tango, when an operation requires 2 scenes, how are these 2 scenes used? One after another?
• Dance is what I would consider a "visual language." Is there a reason why visual languages haven't come to the mainstream?
• The Tango paper mentions it uses a graphical debugger. I would consider Tango an algorithm animator while programs have more complex data structures. Would an integration of Tango and the earlier data structure display systems consist of a next-generation debugger?
• By specifying the animation through direct manipulation in Dance, are there situations where this may limit your ability to react to varying situations with variances in the animations?
• How are the components of the program which get animated identified? Could this process or mapping and the overhead associated with it be avoided in some situations?
• In Dance, the animation routines are based on run-time information of the program performing the algoriothm. Does this mean whenever the input data set for an algorithm is changed, the animation scenario has to be modified to work with the new data set?
• Both papers discussed the path-transition paradigm upon which Tango is built. What is gained from this as opposed to a simpler state-based paradigm, other than the obvious gain of being able to do smooth transitions between states?
• Are the geometric operations provided by tango such as object location, orientation, scaling, etc., generally extensible to 3D?
• Can an animation designer use Dance to design paths other than those for geometric location, i.e., a color change?
• In the Tango paper you say that algorithm aniamtion helps with developing new programs. Given that alogorithm animations basically have to be hand-crafted, and seem to always be done after an algorithm has been coded, how much do they really help with this? You could make the point that an algorithm animation of one version of an algorithm might inspire a new variation, but how often does this happen, in practice? Don't you already have to understand the algorithm pretty well in order to animate it?
• What sort of changes would need to be made to Tango/Dance in order to visualize parallel/concurrent programs? By generating a trace and then using that to generate Tango calls, one could animate parallel/concurrent algorithms but it might be hard to synchronize events correctly and to wait the correct amount of time between events.