Designing Effective Algorithm Visualizations

1
Designing Effective Algorithm Visualizations

• Sami Khuri
• Department of Mathematics
• and Computer Science
• San José State University
• www.mathcs.sjsu.edu/faculty/khuri

2
Outline

• Definition
• History
• Design process
• Analysis phase
• Design phase
• Evaluation
• Concluding remarks

3
1. Definition

• Algorithm Visualization
• is the process of abstracting a programs data,
  operations, and semantics, and creating dynamic
  views of those abstractions.
• is a depiction of an algorithm using an
  integrated set of multimedia tools, such as
  graphics, text, color, sound, code, animation and
  video.

4
2. History

• 1980s
• Visualizations can serve as
• effective learning aid for students.
• Balsa (Marc Brown, 1988)
• Zeus (Marc Brown, 1991)
• Tango (John Stasko, 1990), Xtango, Polka
• Later Leonardo (Crescenzi et al., 1997)

5
History

• 1990s
• Empirical studies Do algorithm animations
  really help?
• Results are unsatisfactory...
• Badre (1991)
• Hundhausen (1997)
• Stasko (1998)

6
History

• Today
• Algorithm visualizations do enhance learning,
• if existing visualizations are effectively used
• Naps (2000)
• Faltin (1999)
• Stasko and Lawrence (1998)
• if new visualizations are better designed
• Hansen, Narayanan, Schrimpsher

7
3. Design Process

• Good algorithm visualization is not simply a
  matter of mimicking paper-based tasks or doing
  what is technically easy.
• Even simple tools can improve algorithm
  understanding, if they are the right ones.
• A lot of time and effort can be wasted
  implementing a system that is not needed or is
  unusable.

8
Design Process

• We advocate
• a user-centered approach
• (What do we NEED to show?), instead of
• a designer-centered approach
• (What CAN we show?)
• Start with an analysis of the users, their needs,
  tasks, information, and resources.

9
3.1. Analysis Phase

• Users analysis
• Needs analysis
• Task analysis
• Information analysis
• Domain analysis
• Resources analysis

10
3.1.1. Users Analysis

• Who are they?
• No algorithm visualization will be universally
  superior across all kinds of users.
• Understanding who the users are allows us to
  determine content, organization, depth, breadth,
  interaction and presentation methods.

11
Users Analysis

• Algorithm visualization system might be
• used by
• Students
• Teaching Staff
• Researchers
• Visualization developers

12
Users Analysis

• Students
• Will watch and interact with algorithm
  visualizations.
• Will need a lot of help information.
• Will need a system that is forgiving to their
  invalid input.
• Will need facilities for setting up desired speed
  and detail level, and for reversing actions.

13
Users Analysis

• Another possible approach is to
• divide users into
• Novice users
• Expert users

14
Users Analysis

• Novice users
• Need a system that is very easy to use.
• For example, if the algorithm visualization
  system requires the user to annotate his/her
  program to call animation routines, the novice
  might not have the skills to do so.
• Need clear and detailed help files.
• Do not need a system displaying many different
  views of an algorithm.

15
Users Analysis

• Expert users
• Need a system that complements and supplements
  their thinking, rather than mimics internal
  representations.
• Need a very flexible system allowing to see
  different levels of details
• if they try to improve performance of an
  algorithm, for example.

16
3.1.2. Needs Analysis

• Do the users need algorithm
• visualization?
• An assessment should be made as to whether
  presenting an algorithm by visualizing it is the
  most effective way to do so.
• For example, instructors can use a phonebook to
  illustrate binary search.
• If instructors do not have access to the WWW in
  class, they cannot use a web-based visualization
  system.

17
3.1.3. Task Analysis

• What will the users do with the algorithm
• visualization tool?
• Create new animations.
• Interact with existing visualization to
  understand the behavior of an algorithm.
• Debug their program.
• Each task demands a different kind of
  visualization tool. It is difficult to build a
  system that satisfies them all.

18
Task Analysis

• How will the algorithm visualization fit
• into the existing curricula?
• Classroom demos
• Assignments
• Hands-on laboratories
• Self-directed work outside of class
• Office hours
• Distance learning

19
Task Analysis

• Classroom demos
• Algorithm visualizations should function well as
  demonstrations.
• They will not need a lot of written explanations.
• They need a facility for adjusting the speed and
  reversing previous steps.
• They should run smoothly to avoid unpleasant
  situations where they freeze
• Web-based tools are not always the best for this
  task.

20
Task Analysis

• Homework assignments
• Algorithm visualizations have to run smoothly on
  different platforms for everyone.
• Better to create Java applications, not applets
• Web-based Java execution is unpredictable at this
  point.
• One has to test all the applications on the
  actual equipment (under different environments)
  ahead of time. Impossible to do!
• They should be available for download
• running them on the web server can be too slow.

21
3.1.4. Information Analysis

• What are we trying to convey?
• Do we want to emphasize the data structures
  rather than the algorithm or vice-versa?
• Create a profile of resource utilization.
• Search through an execution trace.
• Contrast two algorithms.

22
Information Analysis

• Which aspects of an algorithm should
• we illustrate?
• Source code
• Data
• Data structures
• Execution
• The trend is toward the ability to visualize all
  aspects of an algorithm.

23
Information Analysis

• Source code visualization
• View the source code through a flowchart.
• View the code by displaying the pseudocode and
  highlighting lines currently being executed.
• Present currently executing portion of the code
  in a window.
• Data visualization
• Extract and display only scalar variables such as
  values held in an array.

24
Information Analysis

• How should information be represented?
• Direct representation
• Structural representation
• Synthesized representation
• Analytical representation
• Explanatory representation

25
Information Analysis

• Direct representation
• At any given instant, the data structure could be
  constructed from the display, and the display
  could be constructed from the data structure.

26
Information Analysis

• Structural representation
• Only the important aspects are represented.
• For example, a computation running on a network
  of processes, where each process is either
  active or inactive. All other attributes of
  the processes are concealed since they are not
  relevant to the viewer.

27
Information Analysis

• Do we display current information or
• illustrate history of what has
• happened?
• Displaying history
• helps explain the algorithm like a textbook
  example,
• lets users become familiar with the algorithms
  dynamic behavior at their own speed.

28
Information Analysis

• How will we move from one display to
• the next one?
• Incremental transition
• Discrete transition
• There is no pedagogical advantage of either
• technique.

29
Information Analysis

• Incremental transition
• Transition occurs smoothly.
• It is effective when users (especially novice)
  are examining an algorithm running on a small set
  of data.
• This type of transition is difficult and tedious
  to implement.
• Developers need to decide how slow or fast the
  transition should occur.

30
Information Analysis

• What is the largest data set the
• algorithm visualization should be able
• to handle?
• Limit the size of input data.
• Large input files are allowed.

31
Information Analysis

• Limit the size of input data
• If visualizations are used to explain steps of
  algorithms.
• For example, viewing visualizations of large
  trees will require scrolling to see the entire
  tree and might confuse more than educate.
• If visualizations are used by novice users.
• If visualizations are used in homework
  assignments.

32
Information Analysis

• Very large size of input data
• Is useful for researchers or instructors in
  classroom when comparing running times and
  behavior of different algorithms.
• Cluttering the screen with information is not a
  problem.
• Data items should be presented in the simplest
  form, dots, for example.

33
3.1.5. Domain Analysis

• What is the scope of the algorithm
• visualization?
• General-purpose algorithm visualization system
• Specialized algorithm visualization system
• Single-purpose algorithm visualizations

34
Domain Analysis

• General-purpose algorithm
• visualization systems
• Systems that can (ideally) animate any algorithm.
  
• These type of systems should provide a large set
  of ready-made pieces of visualizations and
  general tools to create them.
• The greater the number of algorithms that can be
  animated, the more desirable the result.

35
Domain Analysis

• General-purpose algorithm
• visualization systems
• Some of the general-purpose systems are BALSA,
  TANGO and XTango, Zeus.
• Although general-purpose algorithm visualization
  systems are becoming more powerful, the task of
  using these tools to create visualizations of
  algorithms still involves a lot of work.

36
Domain Analysis

• Specialized algorithm visualization
• systems
• Systems that specialize in visualizing algorithms
  from a certain field of computer science, such as
  computational geometry.
• Restricting algorithm visualization system to one
  field only eases the process of creating
  visualizations, since graphical representation of
  data structures will be implemented once only.

37
Domain Analysis

• Single-purpose algorithm visualizations
• Programs that visualize one algorithm or a group
  of related algorithms in detail.
• They are coded from scratch for each algorithm.
• They are easier to create, understand and
  maintain.

38
Domain Analysis

• Is there a potential for the domain to
• enlarge over time?
• Design for growth.
• Use object-oriented design.
• Provide extensive documentation.

39
3.1.6. Resources Analysis

• Given the above information, do we
• have the necessary resources to
• create the algorithm visualization?
• Time.
• Human resources.
• Computer resources.

40
Resources Analysis

• Time
• Designing and implementing algorithm
  visualizations takes longer than expected.
• Human resources
• Need a team of developers with skills in context,
  graphical design, networks, etc.

41
Resources Analysis

• Computer resources
• CPU speed, RAM, monitor size and resolution,
  audio/video input and output, color display panel
  and projection.
• If the prepared visualization will be available
  over the internet, it might need large amounts of
  storage space, and more importantly, high-speed
  connection to the net.

42
3.2. Design Phase

• Choosing specification method.
• Choosing techniques for visual representation of
  information.

43
3.2.1. Specification Methods

• Choices available to the developers
• Predefinition (hand-coded visualization)
• Annotation
• Declaration (animation by demonstration)

44
3.2.1. Specification Methods

• Predefinition (hand-coded visualization)
• Mainly used in application-specific
  visualization.
• Fixed or highly constrained mapping of the steps
  of the algorithm to the graphical views.
• The information and its representation cannot be
  changed after the implementation.
• The main advantage is the execution speed.
• Can be easily distributed.
• Can be very interactive and visually attractive.

45
Specification Methods

• Annotation
• Important steps of an algorithm are annotated
  with interesting events.
• These events call graphical operations from an
  existing library.
• For example, move rectangles, change colors, etc.
• The main advantage of this approach is the
  animators ability to define events at any
  suitable level.

46
Specification Methods

• Annotation
• The most significant shortcoming of this method,
  is the need to access and modify the code of the
  program.
• The first major system with interesting events
  was BALSA by Brown.
• Other examples Zeus and Tango.

47
Specification Methods

• Declaration
• The developer defines mappings from program
  states to graphical objects.
• During program execution, changes in the program
  state trigger updates to the graphical view of
  the program.
• This paradigm is instantiated in the Pavane
  animation system by Roman, Cox, Wilcox and Plun.

48
3.2.2. Techniques

• Some techniques for visual
• representation of information about
• algorithms.
• Selection of default visualizations.
• Screen design and multiple views.
• Color and Sound.
• 3-Dimension.
• Interaction .

49
Selection of Default Visualization

• Design appropriate default
• visualizations
• How much complexity does the user of algorithm
  visualization need?
• The complexity of visual presentations is
  generally proportional to the amount of
  information being conveyed.
• Start with relatively small problem instances and
  gradually introduce larger ones for the users who
  begin to understand the meaning of the visual
  patterns.

50
Selection of Default Visualization

• Design appropriate default
• visualizations
• For pedagogical purposes, the following input
  data should be provided as default
  visualizations
• Pathological input data
• Cooked input data

51
Screen Design

• The screen on which the visualization occurs can
  easily get cluttered with the many visual
  representations of control constructs or data
  items.
• The user may get lost in the details and not see
  the overall picture.

52
Screen Design

• The solution to reducing the graphical
• overload is abstraction
• Condense complicated parts of the scene into
  simpler items.
• Omit several phases of an algorithm and present
  only the final result of several program steps.
• Use semantic zooming.
• Use step-wise refinement.

53
Screen Design

• Stepwise Refinement
• Give the basic idea first and then progressively
  add more detail.
• How many details do we want to display?
• Too many levels can have a counterproductive
  effect and difficulty to the learning task.
• A rule of thumb a given line of pseudocode
  should be expandable to a maximum of three
  levels.
• The fully expanded pseudocode should fit on one
  screen without scrolling.

54
Screen Design

• Some recommendations
• Divide the screen into functional areas, each
  containing a different type of information.
• Consistently display each type of information in
  its assigned area.
• Place important information near the top and to
  the left.
• Eye-motion studies show that our gaze goes to the
  upper left of a rectangular display first and
  then moves clockwise.

55
Screen Design

• Recommendations for designing user
• interface
• Dont make the user guess where to click to
  perform an action.
• For example, unlabeled graphics as controls
  (buttons, links, etc.) are confusing.
• Try not to have two or more buttons that perform
  the same action.
• Keep the interface uniform. Have the same
  controls perform the same action everywhere.

56
Multiple Views

• Multiple views
• Each view displays only a few aspects of the
  algorithm.
• Each view must be easy to comprehend in
  isolation.
• They are conceptually simpler and easier to
  implement than monolithic views.
• They eliminate the possibility of forcing the
  viewer to remember algorithm states no longer on
  display.

57
Multiple Views
58
Multiple Views

• Multiple views
• The important design question is how to
  synchronize the views. Some possibilities are
• Display related objects in different views in the
  same color.
• Display related objects in different views using
  the same shape (circle, triangle, etc.).
• Display related objects in different views in the
  same size.

59
Multiple Views

• Segmentation is a useful extension of
• the multiple views idea
• If the user selects a physical region in one of
  the views, the display would immediately
  highlight the corresponding values in other views.

60
Multiple Views
61
Multiple Views

• Some recommendations
• If multiple views are needed to visualize a
  concept, allow the users to page them so that
  only one or the other can be seen at a time.

62
Color

• Color offers the following advantages
• It calls attention to specific data or
  information.
• It identifies elements of structures and
  processes.
• It can portray time.
• It increases appeal, believability, memorability,
  and comprehensibility.
• It reduces errors of legibility and
  interpretation.

63
Color

• Advantages of using color
• It allows denser presentation of information
• fewer pixels are needed to make a color change
  visible than to make a change in the shape of an
  object visible.
• It increases the number of dimensions for coding
  data
• one can encode information in both the shape and
  the color of objects.

64
Color

• Drawbacks or disadvantages
• It requires more expensive and complicated design
  equipment.
• It may not account for color deficiency among
  some users
• about eight percent of Caucasian males.
• It can cause visual fatigue and afterimages
  induced by strong colors.

65
Color

• Drawbacks or disadvantages
• It can invoke negative cultural associations to
  some or all colors.
• Establishing general rules or specifications for
  color use is very difficult
• We still lack some important understanding of
  color vision.
• Color is subjective
• Different users have different preferences.

66
Color

• Color can be used
• To draw attention,
• through highlighting, for example.
• To communicate organization.
• To indicate status.
• To establish relationships,
• in multiple views, for example.
• To increase user satisfaction.

67
Color

• To draw attention
• temporarily paint a small region of interest with
  a transparent, contrasting color
• The highlight color should be transparent.
• It should not interact visually with the data
  elements on the screen, but simply draw the eye
  to them.
• Highlight must be temporarily and should be
  removed quickly when the scene changes. Think
  about double-buffering in Java to avoid
  flickering.

68
Color
69
Color

• Some recommendations for using
• color
• It is better to be conservative.
• Use a maximum of five, plus or minus two colors.
• This allows extra room for short-term memory
  (about 20 seconds) which can store five words or
  shapes, six letters, seven colors and eight
  digits.
• For novice viewers, four distinct colors are
  appropriate.

70
Color

• Use fovea (center) and peripheral colors
  appropriately.
• Use blue for large areas, such as background, not
  for text, thin lines or small shapes.
• Blue-sensitive cones are the least numerous of
  the color receptors in the retina, and the eyes
  central focusing area, the fovea, contains
  relatively few of these blue-sensitive cones.
• Use red and green in the center of the visual
  field, not in the periphery.
• The edges of retina are not particularly
  sensitive to these colors.
• If red or green are used at the periphery, some
  signal to the viewer must be given to capture
  attention (size change, blinking, etc.)

71
Color

• Some recommendations for using
• color
• Do not use high-chroma, spectrally extreme colors
  simultaneously.
• Strong contrasts of red/green, blue/yellow,
  green/blue, and red/blue create vibrations,
  illusions of shadows and afterimages.

72
Color

• Some recommendations for using
• color
• Use familiar, consistent color coding with
  appropriate references. Some common Western
  denotations are the following
• Red refers to stop, danger, hot, fire.
• Yellow refers to caution, slow, test.
• Green refers to O.K., clear.
• Blue refers to cold, water.
• Gray and white refer to neutrality.

73
Color

• Some recommendations for using
• color
• Carefully select colors that will be displayed
  across media with different techniques for
  generating color.
• Note, that CRT display screens use additive color
  mixtures which combine into white, while most
  hard copy devices use subtractive color mixtures
  which combine into black.

74
Color

• Some recommendations for using
• color
• Use color to enhance black and white information.
  
• With respect to learning and comprehension, color
  is superior to black and white in terms of
  viewers emotional reactions.
• There is no difference in the viewers ability to
  interpret information. People do not learn more
  from a color display, although they may say they
  do.
• The crucial factor is that color is more
  enjoyable and color information is easier to
  remember.

75
Color

• Some recommendations for using
• color
• Keep in mind that many people are color blind.
• Any time color is used to convey information, the
  secondary cues should also be used.
• Secondary cues can consist of anything from the
  subtlety of gray scale differentiation to having
  a different graphic or different text label
  associated with each color presented.

76
Sound

• Why use sound in algorithm
• visualizations?
• Sound has the potential to convey information
  that is difficult or awkward to display
  graphically.
• Sound can help reduce the visual clutter of
  current graphic interfaces.
• Sound can be redundant with visual information to
  reinforce the concepts.

77
Sound

• Some problems when using sound
• Sound is more difficult to use than color.
• Most people do not have the same level of
  sophistication and training aurally as they do
  visually.
• What happens when more than one computer is using
  audio in the same room?
• What happens when more than one view uses
  audio?
• What if there are no audio output?

78
Sound

• Some problems when using sound
• Sound is difficult to master
• frequency
• volume
• attack and decay rates
• duration
• timbre
• Poor use of sound is less forgiving than poor use
  of color or 3-D.

79
Sound

• Some problems when using sound
• Many aspects of sound perception are not yet well
  understood. More research is needed to determine
  the best sonic representation of data.
• There is no standard sound hardware and software
  platform.

80
Sound

• Some recommendations for using
• sound in algorithm visualization
• Carefully consider the number of sounds.
• Use only a few sounds for the most important or
  difficult events/commands.
• The threshold for learning and remembering sounds
  is between 7 and 9 different sounds.

81
Sound

• Some recommendations for using
• sound in algorithm visualization
• Test your algorithm visualization with a range of
  users to ensure that the selected sounds are
  effective.
• Graphical display results should be synchronized
  with the audio.

82
3-D

• Do not use 3D for enhancing the beauty of a
  picture that is easily shown in 2D.
• Use 3D displays to
• represent the 3-dimensional data some algorithms
  manipulate
• provide an extra dimension to represent more
  information about two-dimensional data.

83
3-D

• 3-D can give us one more dimension

2-D Display 3-D Display direct visual
comparison of the elements
84
3-D

• Some techniques that may be used in
• crafting 3-dimensional visualizations
• Rotation
• Transparency
• Navigation
• Exploration of objects

85
3-D

• Attention should be paid to choosing
• the axis of rotation,
• the speed of rotation.
• The orientation and rotation speed should be
• saved each time there is a pause in animation.

86
3-D

• Transparency
• Very complicated 3D objects may be best
  understood if the user can interact with them and
  inspect their contents.
• Make the object transparent.
• Use transparency with care, otherwise, there may
  be too much detail.

87
3-D

• Transparency
• To avoid overload, make only selected portions of
  an object transparent. We can draw the viewers
  attention only to the important parts of an
  object.
• An ideal interface will allow the user to look
  inside an object by
• cutting it open
• slicing it along a selected plane
• breaking it apart at natural boundaries and
  separating pieces for further examination.

88
Interaction

• Visualizations are more effective when the user
  can steer them in appropriate directions.
• Algorithm visualizations should allow for
  interactive controls.
• Users should be forced to interact with the
  system at least every 45 seconds.

89
Interaction

• Some of the varieties of interaction an
• algorithm visualization system can utilize
• Allowing the user to step through the execution
  or set its speed,
• Allowing the user to design input data for the
  algorithm
• tools for inputting data should be simple so as
  not to overwhelm the user,
• input tools should do error checking and report
  any invalid input to the user.

90
Interaction

• Other forms of interaction
• Allowing the user to control the presentation and
  amount of information
• Facility to hide one or more of the multiple
  views.
• Facilities to zoom in and out.
• Means for changing the data while the algorithm
  runs, e.g., by dragging a data point to a
  different location and watching the effect of
  this change,
• not suitable for some algorithms, e.g. sort
  algorithms

91
Interaction

• Other forms of interaction
• Allowing the user to simultaneously run several
  algorithms to compare and contrast them.
• This capability is useful for comparing the
  execution times of two algorithms by running a
  race.
• Note, that modern windowing environments and
  operating systems will allow almost any
  window-based visualization system to be run in
  parallel.
• Running two versions of algorithm visualization
  in different windows would not qualify under this
  category because there is no centralized control
  or synchronization between both running
  visualizations.

92
Interaction

• Other forms of interaction
• Allowing the user to step back in the algorithm
  visualization.
• Allowing the user to design his/her own
  visualizations.

93
Interaction

• Other forms of interaction
• Allowing the user to check his/her understanding
  by answering stop-and-think questions
• if the feedback from the interaction is sluggish
  such that users actions and their feedback
  become unrelated, then this type of interaction
  fails.

94
4. Evaluation

• Over one hundred different algorithm
• visualization tools have been built in the last
• twenty years, yet very few of these were
• systematically evaluated.

95
Evaluation

• There are some difficulties which arise
• when performing a formal evaluation
• study
• Obviously, evaluation takes time.
• Which visualization should we use for testing?
• How do we measure program understanding?
• Which criteria should we use?
• How do we properly and fairly conduct the study?

96
Conclusion

• So far, we have only informal evidence that
  applications of algorithm visualizations are
  useful - we need controlled studies
• need to conduct formal studies of applications in
  classroom settings and use the result to
  influence the next generation of tools.

97
Conclusion

• Creating good educational algorithm
  visualizations is time consuming and generally
  requires a team of developers with different
  skills.
• Think about distribution and maintenance of your
  new algorithm visualization system.

98
Conclusion

• Distribution issues
• Make it possible for other educators to try your
  tool.
• Put the tool on the web.
• Educational algorithm visualizations are shifting
  toward web-based design
• It simplifies installation and platform
  compatibility.
• It provides immediacy of access.
• It allows them to be incorporated into electronic
  textbooks.

99
Conclusion

• Maintenance issues
• There is increasing demand for more functionality
  in algorithm visualizations which results in
  larger programs.
• Turnover in the development and support community
  is great development tools become obsolete
  source code is even lost.
• All this makes maintenance very difficult and
  important.

100
Conclusion

• Color, sound, and 3-D graphics do not merely
  enhance the beauty of presentation they can be
  used to give fundamental information.
• Designing effective dynamic algorithm
  visualizations is a craft, not a science.

101

• Kiitos!