Critique of a 3D animation of Linux source code development



Critique of a 3D animation of Linux source code development

[pic] [pic]

Linux 1.2.0 (beginning screenshot) Linux 2.4.1 (ending screenshot)

Video and description at .

Description

This 46-second animation depicts the changes of the Linux kernel source code between Linux 1.2.0 and Linux 2.4.1. Each color in the graph is mapped to an aspect of the Linux source code which the author could extract automatically from versions of Linux source code itself. Close to 200 Linux versions were included in the animation, though it is difficult to determine an exact number.

Each node in the graph is a file, highlighted by a faint grey box that flashes yellow, green, or red for several frames of the animation if the file is modified, moved, or created, respectively. These nodes are connected by green lines (the directory structure), blue lines (functional dependencies), and red lines (variable dependencies). Blue and red links are weighted according to use. The data displayed is nominal. Some textual data are also displayed: the Linux version number is printed in the upper-left corner of the visualization, and filenames occasionally appear in the three-dimensional space around the graph.

The nodes are laid out automatically using “trivial spring-based techniques” (in the author’s words) that use link weight to determine node placement. The node position does not hold any intrinsic meaning. The camera circles around the graph as it changes, and zooms into the center of the Linux 2.4.1 mapping at the end. The grey skeleton of a bounding cube is also rendered.

The author’s purpose in creating the visualization is not clear from his description, but the way that the page explains the animation suggests that it is meant to help others see the changes that the Linux kernel has undergone. The backlinks found by Google show that the visualization made its rounds on Slashdot and among bloggers and self-proclaimed “geeks” in the summer of 2003, many of whom commended the author on making a nice visualization. All this suggests that the visualization’s primary use was to provide a timeline of early Linux kernel development to Linux programmers, Linux users, and others knowledgeable about Linux and software development.

Critique and Suggesting Improvements

The visualization is good at giving a qualitative sense of the development of the Linux kernel over time, and the movement, flashes, and black background make the animation visually exciting. The use of animation to add the time dimension to such a spatially-rich data set is useful: it doesn’t overload the static representation and it maps naturally to the changes in the Linux kernel over time. The red, green, and yellow flashes – especially the yellow, which is particularly common in the animation – effectively highlight the general quantity of changes made to individual files, and at times a whole set of proximate files flash yellow, suggesting an overhaul of the corresponding module. The variable link width and the node layout mechanism make graph hubs – files that are very important in the Linux kernel – apparent.

However, the graph does have a number of visualization issues that interfere with its implied goal of providing a visualization of Linux kernel development to Linux programmers and enthusiasts. Below I describe these issues, roughly in order of importance, and suggest solutions.

1. The circling camera gives the viewer an impression of the three-dimensionality of the graph, but it also obfuscates the data, making it difficult to pay attention to one part of the graph and giving the illusion of more change than is actually happening. The camera could be kept in one place instead.

2. Related to the point above, the three-dimensionality of the data, while visually exciting, actually hinders comprehension of the full graph structure. The graph could be flattened to two dimensions.

3. The grey bounding cube was probably intended to help viewers understand the rotation of the three-dimensional dataset, but its thick lines are distracting. The rotation of the graph itself would likely be obvious enough that it could be removed entirely.

4. The names of some files sometimes appear for a few frames in a shell around the graph. The purpose of these flashes is not clear, and it adds a lot of visual clutter to the graph, as well as giving the impression of more change than is actually happening. While the effect is visually exciting, the author would improve his audience’s chances at accurately seeing changes in the graph if he did not do this.

5. Nodes move around as the animation progresses and more files are added, making it difficult to track the changes of one particular file. Node placement could be fixed from the beginning to make it easier for viewers to track the changes on a particular file.

6. The grey nodes are faint, some links are also very faint, and everything is rendered semi-transparent, so some less-used files fade away completely even though they still exist. Because of this, it’s impossible to see a complete snapshot of a particular version of the Linux kernel. The transparency could be lessened or eliminated (especially if the graph was flattened to two dimensions) so that rarely-used nodes don’t fade away.

7. The animation is not interactive. There is no way to drill down to any numbers, to step between versions one at a time, or to direct attention to a particular file or group of files, which are all functions that a Linux programmer might want to do. Even the version numbers are difficult to read: they change so quickly that I had to count fast to arrive at my estimate of 200 versions of Linux. Viewers should be able to pause, jump to a particular Linux version, step frames, and zoom.

8. The nodes are unlabeled. Even a viewer familiar with the Linux directory structure and how it has changed over time can’t actually tell which boxes correspond to which files. Continuing the interactivity suggestion from the last point, node labeling could be added as an interactive feature: viewers could place a cursor on a node to determine its name, and perhaps addition information such as the size, last date of change, and author(s). Links could be similarly labeled.

9. Viewers have no sense of the amount of development time represented by the visualization as a whole, or of the amount of time spent developing a particular version. The animation speed could be scaled to correspond to development time, and release dates could be added to each version number in the top left corner of the screen.

10. Files seem to have different-sized boxes associated with them, suggesting that the size of the box is related to the size of the file or some other characteristic. However, the variable box size is never explained, and could be caused by the three-dimensionality and rotation. Varying the size of the boxes with the size of the file would be a nice way of visualizing file size, but the mapping should be clarified in the visualization description.

11. The use of color to differentiate between graph elements does make the graph easier to read. However, the colors used to represent files, file changes, and links are arbitrary, and green is used twice to show two different variables (directory structure and file moves). Perhaps the colors could be better chosen and better labeled in the graph itself.

12. The layout algorithm enabled the viewer to easily see clusters of related files, and the use of color intensity to show greater dependencies between two files is fairly natural. However, many of the long links between two more distant files were too visually salient in the graph, making it difficult to see clusters and other features of the graph. These could be toned down or nodes could be better highlighted to enable viewers to see the graph structure.

In summary, the visualization could be made more effective if it were flattened to two dimensions, had a fixed camera location and no gratuitous visual elements, provided features that let the viewer interact with the data and discover more details, and made better use of color, link length, and animation timing to encode appropriate information.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download