Overfloater

While browsing the internet I got to the Guardian’s Datablog, a blog that gathers interesting information and datasets to explore and make visualizations. Latest post was about Every Doctor Who villain since 1963. There’s information about each villain’s first and last year of appearance, their motivation/evil plan, the name of the actors who played the role of Doctor Who while that villain was making an appearance, the title of the stories where that villain was in, etc.

I created a “dynamic” TreeMap visualization with that data. Here’s a short screencast I made explaining the TreeMap functionalities (I have a horrible english accent… I know). You can also play with the demo here.

The Code

For this example I used a special build of the Toolkit which is currently hosted at GitHub. The TreeMap example code looks just like the TreeMap demos code but I also added an onBeforeCompute callback that checks for the Doctor Actor Name and Villain Motivation filters to fade nodes respectively:

onBeforeCompute: function() {
  tm.graph.eachNode(function(n) {
    var prev = false;
    if(n.data.motivations) {
      prev = true;
      if(motivation != 'All'
        && n.data.motivations.indexOf(motivation) == -1) {
        n.setData('alpha', 0, 'end');
        n.ignore = true;
      } else {
        n.setData('alpha', 1, 'end');
        delete n.ignore;
      }
    }
    if(n.data.doctorActorNames) {
      if(doctorName != 'All'
        && n.data.doctorActorNames.indexOf(doctorName) == -1) {
        n.setData('alpha', 0, 'end');
        n.ignore = true;
      } else if(!prev) {
        n.setData('alpha', 1, 'end');
        delete n.ignore;
      }
    }
  });
},

The anchor click callbacks set the current selected value to the doctorName and motivation variables and also perform an animation by fading nodes and repositioning the remaining visible nodes:

anchors.addEvent('click', function(e) {
  doctorName = this.innerHTML;
  tm.compute('end');
  tm.fx.animate({
    modes: {
      position: 'linear',
      'node-property': ['alpha', 'width', 'height']
    },
    duration: 1000,
    fps: 50,
    transition: $jit.Trans.Quart.easeInOut
  });
});

The tm.compute(‘end’); call will trigger the onBeforeCompute callback that will set correct alpha values for the nodes. Then we perform an animation of node positions and node alpha, width and height properties.

I hope you have fun with the demo!

After more than a year of hard work I’m proud to announce the release of the JavaScript InfoVis Toolkit 2.0!

What’s the JavaScript InfoVis Toolkit?

The JavaScript InfoVis Toolkit provides web standard based tools to create interactive data visualizations for the Web.

What’s new in this version?

This version introduces radical new features, an API redesign and new visualizations. If you don’t want to read the whole article and just want to play with the examples you can go to the demos page.

New Visualizations

With this version of the Toolkit the number of available visualizations has doubled. Some of the new visualizations are the AreaChart, BarChart and PieChart, which were described in more detail in this article. I’ve also added Sunburst and Force-Directed visualizations. I wrote about these visualizations before here and here. I also want to thank Pablo Flouret, who contributed most of the code for the Icicle visualization, also a new addition to the toolkit.

You can play now with these visualizations at the demos page!

Features common to all visualizations

I’ve also enhanced all visualizations with new configuration options that enable new features. These features are:

• Panning and zooming across all visualizations.
• A new event system that enables you to attach events to DOM elements or to native canvas nodes and also add support for touch events, drag and drop, etc.
• Complex animations have the ability to animate any style property of a node, edge or label. There is also support for animating canvas specific properties like shadowBlur, shadowColor, fillStyle, etc.

A new TreeMap visualization

The underlying rendering functions in the TreeMap visualization have changed. While in prior versions of the Toolkit the TreeMap was DOM-based, this new version renders the TreeMap entirely in Canvas. This enables you to add custom nodes of any shape or nature you like (can be images, circles, polygons) and also to take advantage of the new animation engine of the toolkit to add smooth transitions for the drill-down. These new things can be tested at the TreeMap section in the demos page.

API Redesign

The old API was too low level. Before creating any visualization you had to manually create a Canvas widget and pass it as parameter to the visualization class. Also, many other parameters like width and height of the canvas were required. For Background canvases the API had a couple of flaws, and it wasn’t clear how to use it either. Many of these things have been solved with the new API design. The Canvas class became an inner class implicitly created when making a new visualization. Width and height of the canvas are set to the container’s offsetWidth and offsetHeight if they’re not provided, and background canvases are easier to attach to the visualization.
Most of all, there is now a single global object in the library: $jit. This declares the namespace for the library and makes sure you won’t have conflicts with any other JavaScript library.

A new Website

Last but not least, I worked on a website redesign, taking advantage of the new HTML5/CSS3 features supported by major browsers. There’s also a detailed documentation page to get you started.

It’s alpha

Finally I’d like to say that this is an alpha version. There are lots of known bugs and I’m counting on you to report bugs, send fixes, and collaborate in any aspect of the toolkit.

Thanks

To Pablo Flouret for contributing code to the toolkit, and to my wife, Luz Caballero for making me happy.

Now go get the Toolkit!

We’re not that far. Not at all. I was actually going to write some completion percentage, but I think I’ll just leave that as a mystery and surprise you when the time comes. But until then… some videos from the 2.0 world!

Animated TreeMaps

In order to show some of the new features I’ve been writing a simple example with TreeMap animations. TreeMap animations are integrated into the built-in classes of the Toolkit, but you can also create your own animations by altering either built-in Node/Edge params, or also canvas specific styles like shadows.

Here’s a short video of an Animated TreeMap, it also has animations when switching layouts. I think it’s better seen in fullscreen.

Zooming and Panning

The new Event system allows many customizations, such as Dragging and Dropping nodes, (right)clicking native Canvas nodes, etc. This will be the subject of a longer post, since there is a lot of machinery involving Native Canvas, SVG and HTML events, event delegation, etc. I’ve also been working in making a modular Canvas class enabling canvas background extensions.

Some of these changes had some desirable effects, such as enabling Panning and Zooming in a generic way, across all visualizations, as can be seen in this video:

A Force Directed Example

These features can be combined into useful and interesting examples. This Force Directed example uses the new Event system, zooming, panning and animations to make a complete graph editing tool. These are some of the graph interactions that can be made with the JavaScript InfoVis Toolkit (also better seen in fullscreen):

I hope you liked it. I know I’m having a great time working in this project.

I’ll be back with more updates.

Update: I made a video showing the Photo Mosaic process + zoomable Canvas here:

Today, I started working at Exalead on a photo mosaic service that could take advantage of Exalead’s Search Engine. The service contains a bunch of indexed images from different sources. These images are categorized by color just like the images in our public search service, allowing us to easily find pictures by approximating colors.

I decided to run the web application into some browser logos to see what the results were. You can click the images to enlarge.

Chrome

IE

Firefox

Opera

Safari

Safari was kind of complicated because the logo has more details than the others. I also made a close up of the logo:

Which one do you like the most?

Today I’d like to announce the addition of three new components in the next version of the JavaScript InfoVis Toolkit: Area Charts, Bar Charts and Pie Charts. I hope these components will be widely used among the JIT user community.

All components support a simpler JSON format that I’ll describe later in this post. These components are easy-to-use, yet very powerful: they support live data updates and multi valued data as we will see next.

Area Charts

The Area Chart is a useful component to track the evolution of a bunch of categories at the same time. In addition, the aggregation of the values of all these categories is also presented in a meaningful way. This component supports live updates (as you’ll see in the first seconds of the video), filtering/restoring categories, tooltips and a legend. As usual this is all JavaScript:

The visualization is instanciated this way:

var areaChart = new $jit.AreaChart({
    //id of the container
    injectInto: 'infovis',
    //set animations
    animate: true,
    //visualization 'padding'
    offset: 5,
    //labels 'margin'
    labelOffset:10,
    //show aggregated values
    showAggregates:true,
    //show labels
    showLabels:true,
    //use gradients for rendering
    type:'stacked:gradient',
    //label styling
    Label: {
      size: 13,
      family: 'Arial',
      color: 'white'
    },
    //enable tips
    Tips: {
      enable: true,
      onShow: function(tip, elem) {
         tip.innerHTML = "" + elem.name + ": " + elem.value;
      }
    },
    //add leftclick handler
    filterOnClick: true,
    //add rightclick handler
    restoreOnRightClick:true
});

Additionally this visualization allows programmatic category filtering, JSON updating, selecting you own colors, etc.

Bar Charts

Bar Charts are similar to Area Charts, but they support additional styling and positioning. You can use vertical or horizontal Bar Charts. Here’s an example:

This object is created the same way you create an AreaChart:

var barChart = new $jit.BarChart({
    injectInto: 'infovis',
    animate: true,
    //set orientation vertical or horizontal
    orientation: 'horizontal',
    //bar separation
    barsOffset: 20,
    offset:10,
    labelOffset:5,
    type:'stacked:gradient',
    showAggregates:true,
    showLabels:true,
    Label: {
      size: 13,
      family: 'Arial',
      color: 'white'
    },
    Tips: {
      'enable': true,
      'onShow': function(tip, elem) {
         tip.innerHTML = "" + elem.name + ": " + elem.value;
      }
    }
});

Pie Charts / Rose Diagrams

Finally there’s the Pie Chart. But this is no regular Pie Chart. It can support simple data as well as more complex data. You can add multiple categories to this Pie Chart, combining them into something more like a Stacked Rose Diagram. They also support live updates as you’ll see in the first seconds of the video:

JSON Data Format

The JSON data format for these visualizations had to depict something like a contingency table, and so I decided to adopt something like this:

var json = {
    //category labels
    'label': ['label A', 'label B', 'label C', 'label D'],
    //each "stack" is described here
    'values': [
    {
      'label': 'date A',
      'values': [20, 40, 15, 5]
    },
    {
      'label': 'date B',
      'values': [30, 10, 45, 10]
    },
    {
      'label': 'date E',
      'values': [38, 20, 35, 17]
    },
    {
      'label': 'date F',
      'values': [58, 10, 35, 32]
    },
    {
      'label': 'date D',
      'values': [55, 60, 34, 38]
    },
    {
      'label': 'date C',
      'values': [26, 40, 25, 40]
    }]
};

I hope you find these visualizations useful, and if you can’t wait for the next version to come out to use these charts you can always build the project from GitHub. Here’s a wiki with some instructions on how to make your own build of the library while you’re waiting for an official release. If you ever find bugs please use the issue tracker at GitHub. If you need help or have any questions you can always go to the Google Group. Well, this got long enough.

Hope you enjoyed it!

I had the chance to play with the JavaScript InfoVis Toolkit lately. It’s nice to be able to use the Toolkit instead of developing it. The main reason I built the Toolkit in the first place was to create specific visualizations I was needing for MusicTrails. At the end I got to code lots of features but didn’t have the chance to play with them for a long time.

I hope these examples can demonstrate that the Toolkit was really built upon the concepts of Modularity, Extensibility and Composability.

Stacked Bar Charts

One of the things I wanted to do for some time now was to adapt the Spacetree visualization to show Bar Charts.
By watching this example we can already tell that the Spacetree can be used to represent something similar to a Bar Chart. For the next example I created a BarChart class that uses a Spacetree with some special node rendering function to plot bars for each node:

What’s also interesting about this widget is that the custom node implementation I made allows it to show stacked values:

Stacked Bar Charts are useful when aggregated results are as meaninful information as knowing the specific value of each analyzed element. The JQuery team used these kind of charts for measuring performance in different browsers for different versions of JQuery. As you can a see in the next picture, the overall performance comparison is as useful as the specific browser performance improvements data.

Implementation
In order to make Stacked Bar Charts I stored multivalued information into the nodes’ data property and then accessed it to render each node like this:

//Here we implement custom node rendering types for the ST
ST.Plot.NodeTypes.implement({
  'stacked': function(node, canvas) {
    var pos = node.pos.getc(true), nconfig = this.node, data = node.data;
    var cond = nconfig.overridable && data;
    var width  = cond && data.$width || nconfig.width;
    var height = cond && data.$height || nconfig.height;
    var algnPos = this.getAlignedPos(pos, width, height);
    var valueArray = data.valueArray;

    var ctx = canvas.getCtx();
    ctx.save();
    if(valueArray) {
     for(var i=0, l=valueArray.length, acum=0; i<l; i++) {
      var rgb = valueArray[i].color.hexToRgb(true);
      var rgbdark = rgb.map(function(e) { return (e * .3) >> 0; });

      var lgradient = ctx.createLinearGradient(algnPos.x, algnPos.y + acum,
        algnPos.x + width -1, algnPos.y + acum + (valueArray[i].hvalue || 0));

      lgradient.addColorStop(0, rgb.rgbToHex());
      lgradient.addColorStop(0.5, rgb.rgbToHex());
      lgradient.addColorStop(1, rgbdark.rgbToHex());

      ctx.fillStyle = lgradient;
      ctx.fillRect(algnPos.x, algnPos.y + acum, width, valueArray[i].hvalue || 0);
    }
    ctx.restore();
  }
});

That code also uses linear gradients to render nice gradients for each stacked bar.

Pie Charts + TreeMaps = Awesome TreeMaps

When lots of elements need to be compared the Stacked Bar Chart visualization can be confusing. This is due to the fact that each bar gets thinner and the aspect ratio for each bar tends to be very high. I wrote about the aspect ratio problem some time ago, and I also showed that it could be solved by using Squarified TreeMaps to show hierarchical structures in constrained space.
This is OK for replacing Bar Charts, but what about Stacked Bar Charts? Should we subdivide each TreeMap cell into the number of stacked elements? I didn’t find that solution very appealing: for each TreeMap node its subnodes would have the same color, same name, but different values. It seems like redundant information.
Instead, I opted to create Pie Charts inside each TreeMap node. Pie Charts are useful to compare values where the whole information also has a meaning.

Here’s an example I did with the same data collected from the second Stacked Bar Chart image (click on the image to enlarge):

Each TreeMap cell is proportional to the amount of aggregate information for each element. The Pie Chart compares the specific information of each element.
While the previous example isn’t too useful, this next example collects more data and thus makes this visualization more suitable (also click to enlarge):

Implementation
By taking a look at this example we can see that we can make Pie Charts by using RGraphs and adding a special node rendering function. We also know that we can make Squarified TreeMaps by looking at this example.

So how can we combine these two visualizations?

The TreeMap visualization accepts a controller method that is triggered on element creation. This means that for each created treemap node a callback is used that can post-process each TreeMap node. This method is called onCreateElement and I use it to append a pie chart for each TreeMap element like this:

onCreateElement: function(content, node, isLeaf, leaf) {
  if(isLeaf && node.data.valueArray) {
    var w = leaf.offsetWidth, h = leaf.offsetHeight;
    //create a canvas with unique id
    //and append it to the leaf TreeMap element
    var c = new Canvas("piechartcanvas_" + TMPieWidget.count++, {
      injectInto: leaf,
      width: w,
      height: h - 2*tm.config.titleHeight
    });
    //create a RGraph with nodepie node rendering
    //function
    var rg = new RGraph(c, {
        Node: {
            'overridable': true,
             'type': 'nodepie'
        },
        Edge: {
            'overridable': true
        },
        //Parent-children distance
        levelDistance: ((w > h? h : w) / 2) - 2*tm.config.titleHeight,  

        //Add styles to node labels on label creation
        onCreateLabel: function(domElement, node){
            domElement.innerHTML = '';//node.name;
            if(node.data.$aw)
                domElement.innerHTML += " " + node.data.$aw;
            var style = domElement.style;
            style.fontSize = "0.8em";
            style.color = "#fff";
        },
        //Add some offset to the labels when placed.
        onPlaceLabel: function(domElement, node){
            var r = rg.graph.getNode(rg.root);
            var style = domElement.style;
            var dw = domElement.offsetWidth;
            if(r.data.count == 1) {
              var dh = domElement.offsetHeight;
              style.left = (w/2 - dw / 2) + 'px';
              style.top = (h/2 - dh) + 'px';
            } else {
              var left = parseInt(style.left);
              style.left = (left - dw / 2) + 'px';
            }
        }
    });
    rg.loadJSON(that.createJSONPie(node));
    rg.refresh();
  }
}

And that’s it!

I hope these customizations inspired you enough to create your own wacky visualizations with the JavaScript InfoVis Toolkit. I honestly encourage all Toolkit users to try to extend the library with new crazy ideas and features; most of the library design was targeted at that!

PS: Some people posted a job offer at the JavaScript InfoVis Toolkit Google Group that you might find useful. To check or post about job offerings related to visualization or the JavaScript InfoVis Toolkit please join the group!

This is going to be the first of a couple of posts related to Voronoi Tessellations, Centroidal Voronoi Tessellations and Voronoi TreeMaps. In this post I’ll explain what a Voronoi Tessellation is, what can it be used for, and also I’ll describe an interesting algorithm for creating a Voronoi Tessellation given a set of points (or sites as I’ll call them from now on).

What is a Voronoi Tessellation?

Given a set P := {p1, …, pn} of sites, a Voronoi Tessellation is a subdivision of the space into n cells, one for each site in P, with the property that a point q lies in the cell corresponding to a site pi iff d(pi, q) < d(pj, q) for i distinct from j. The segments in a Voronoi Tessellation correspond to all points in the plane equidistant to the two nearest sites.
Voronoi Tessellations have applications in computer science, chemistry, etc. but I’m most interested in Voronoi Diagrams for constructing Voronoi TreeMaps (more on that in later posts).

How do I create a Voronoi Tessellation?

One algorithm for creating Voronoi Tessellations was discovered by Steven Fortune in 1986.

This algorithm is described as a plane sweep algorithm. Fortune’s Algorithm maintains both a sweep line (in red) and a beach line (in black) which move through the plane as the algorithm progresses.

The structures used in this algorithm are an EventQueue, EdgeList and a binary Tree that tracks the state of the beach line.

The EventQueue stores two distinct type of events that are related to changes in the beach line. These events happen when:

• A site s crosses the sweep line: in this case a new parabola with minimum at s is added to the beach line. A Voronoi Edge is born.
• A circle that touches three sites staying behind the sweep line is found and is tangent to the sweep line (see image below). A Voronoi Vertex is found.

At each of these stages the EdgeList is updated until the algorithm is completed.

Implementations

I haven’t found any interesting implementation of this algorithm in JavaScript. Actually, I didn’t find a working implementation of this algorithm in JavaScript. There’s this version of a JavaScript applet for making Voronoi Tessellations, but it doesn’t seem to work right (the corners of the image generally hold two or more sites in the same cell). Also, the code was based in a C# implementation and isn’t very pretty. Then there’s this blog that mentions the algorithm but there’s no visible implementation, just a JQuery demo that animates parabolas when a mouse crosses a site, but no Voronoi Diagram.

So I made my own implementation, which I tried to make as similar as possible to the original C implementation from Steven Fortune. If you click on the image you can see it in action. Just refresh the page for new Voronoi Tessellations of random positioned sites.

Any comments or advices about how to make this implementation better are welcomed!

I’ve been invited by Fanny Chevalier from the Microsoft-INRIA Joint Centre to the Parisian Seminar on Information Visualization and HCI.

I’ll be speaking about Using Web Standards to create Interactive Data Visualizations for the Web. Here’s the abstract:

What is the best way to render complex information on the Web? The Document metaphor has been used for years in Web Standards to define the best way to show information on the Web. Today, Web Documents are turning into full fledged Web Applications and a Web Standards revolution is taking place to provide richer ways to present complex data. HTML is covering new patterns as Drag and Drop and 2D graphics; CSS is now covering transforms and animations, and JavaScript just got 100% faster. Web Standards are important because they are built natively in Web Browsers providing common functionality guidelines, independence from third-party libraries, and high interoperability with other Web components. The JavaScript InfoVis Toolkit is a toolkit for Information Visualization built solely on Web Standards. This Toolkit provides many visualization techniques to seamlessly integrate Interactive Data Visualizations in Web Pages, turning them into Web Applications. In this talk I’d like to present an overview of the new features in Web Standards and also some concepts behind the making of the JavaScript InfoVis Toolkit, as well as some user applications..

You can find more information about this talk and how to get there here. Everyone’s invited!

In a previous post I showed the ForceDirected visualization I’m working on for version 1.2 of the JavaScript InfoVis Toolkit, today I’d like to talk about another visualization I’ve been working on, the Sunburst Visualization.

What’s the Sunburst Visualization?

I guess an example could help here:

A Sunburst visualization is a radial space-filling visualization technique for displaying tree like structures. There are other space-filling visualization methods that use other visual encodings for describing hierarchies. For example, the Treemap is a space-filling visualization that uses “containment” to show “parent-child” relationships.

There are a couple of subtle changes that can improve the way the information is communicated by this visualization.

• The “classic” Sunburst visualization uses horizontal labels for node names. One problem with this is that as I mentioned in a previous post labels can be occluded. One solution for this is to rotate labels in a way that they’re not occluded.
• A simple yet important thing to do when rotating labels is to rotate the labels in a way that they’re always facing up.
  In this example some labels are upside-down:

  

  A simple check could make labels more readable:

  
• Another interesting thing that can be used with the Canvas Text API is the maxWidth parameter. This is an optional parameter that can be used to try to force the text to fit some width. I use this parameter when plotting the Sunburst visualization:
  

Node Styling and Behavior

The visualization also implements events for hovering and clicking nodes. You can also provide any number of styles to be smoothly updated when hovering and clicking nodes. There’s also onClick and onHover callbacks that are called when a node is clicked or hovered respectively.
For example, this is the configuration I used in the previous example:

        NodeStyles: {
          attachToDOM: false,
          attachToCanvas: true,
          stylesHover: {
            'color': '#d33'
          },
          stylesClick: {
            'color': '#3dd'
          },
          onClick: function(node) {
            //build right column relations list
            buildRightColumnRelationsList(node);

            //hide tip
            sb.tips.tip.style.display = 'none';

            //rotate
            sb.rotate(node, 'animate', {
              'duration': 1500,
              'transition': Trans.Quart.easeInOut
            });
          }
        },

You can also add tool-tips as I did in the example. The configuration I used was:

        Tips: {
          allow: true,
          attachToDOM: false,
          attachToCanvas: true,
          onShow: function(tip, node, elem) {
            tip.innerHTML = node.name;
          }
        },

Node styling and tool-tips can be attached to DOM elements (like HTML or SVG labels) or they can also be attached to the Canvas. The latter method uses an internal MouseEventManager to calculate the position of the mouse event and determine which node of the graph is being hovered or clicked.

Collapsing and Expanding Subtrees

I’ve been also implementing animations for collpasing/expanding subtrees:

The collapsing process reduces the angle span occupied by a parent node and sets its children alpha value to zero. There’s also a visual mark set for collapsed nodes.

I hope you like this visualization. There’s still much work to do, mostly regarding browser compatibility. I’ll keep you up to date with the progress of this visualization and the next visualization I’ll be implementing in the next post

I’m currently working on three new visualizations for the JavaScript InfoVis Toolkit that will be added in version 1.2.

I started the development of these new visualizations a couple of weeks ago, and while trying to incorporate these new visualizations harmoniously into the Toolkit I’ve found myself considering new design and code abstractions I haven’t thought about before. That’s good for the Toolkit, and also good for my brain

One of the visualizations I’ll be incorporating in the next major release is a Force-Directed visualization. I first want to thank Marcus Cobden for donating a lot of code related to this algorithm that you can find here.

My code is based in his donation and also in a nice overview of Force-Directed layout algorithms that I’ve found here.

So what are Force-Directed Layout Algorithms?

Force-Directed Layout algorithms are graph drawing algorithms based only on information contained within the structure of the graph itself rather than relying on contextual information. The most straightforward Force-Directed algorithm uses repulsive forces between nodes and attractive forces between adjacent nodes. This physical model produces some local minima in which the graph, well, gets to a stable configuration and is drawn in an aesthetically pleasing way.

The main algorithm consists on a main loop that simulates the system for some iterations and then plots the graph. The system will consist on repulsive forces between all graph nodes and attractive forces between adjacent nodes. The force models considered correspond to Hooke’s law and Coulomb’s law.

Here’s an example with some JSON data I also use for other examples at the demos page:

There are lots of refinements and different methods for making Force-Directed Layouts. Some are just based on the model I described before, others are based on what’s called Graph Theoretic Distances: If for two adjacent nodes their ideal distance is set as d, then for nodes with shortest path distance of n their ideal layout distance should be n * d. Attractive and repulsive forces are used to make a graph system with random nodes positions get to a local minima based on these rules.

I implemented the first model I described. For each iteration the computePositionStep method is called to update all nodes positions based on attractive and repulsive forces. The formal parameters passed to the method are property which is an array of node properties which contain positions to be updated and opt which is an object containing layout options like generic repulsive and attractive force functions. $C creates a new Complex Number.

  computePositionStep: function(property, opt) {
    var graph = this.graph, GUtil = Graph.Util;
    var min = Math.min, max = Math.max;
    var dpos = $C(0, 0);
    //calculate repulsive forces
    GUtil.eachNode(graph, function(v) {
      //initialize disp
      $each(property, function(p) {
        v.disp[p].x = 0; v.disp[p].y = 0;
      });
      GUtil.eachNode(graph, function(u) {
        if(u.id != v.id) {
          $each(property, function(p) {
            var vp = v.getPos(p), up = u.getPos(p);
            dpos.x = vp.x - up.x;
            dpos.y = vp.y - up.y;
            var norm = dpos.norm() || 1;
            v.disp[p].$add(dpos
                .$scale(opt.nodef(norm) / norm));
          });
        }
      });
    });
    //calculate attractive forces
    var T = !!graph.getNode(this.root).visited;
    GUtil.eachNode(graph, function(node) {
      GUtil.eachAdjacency(node, function(adj) {
        var nodeTo = adj.nodeTo;
        if(!!nodeTo.visited === T) {
          $each(property, function(p) {
            var vp = node.getPos(p), up = nodeTo.getPos(p);
            dpos.x = vp.x - up.x;
            dpos.y = vp.y - up.y;
            var norm = dpos.norm() || 1;
            node.disp[p].$add(dpos.$scale(-opt.edgef(norm) / norm));
            nodeTo.disp[p].$add(dpos.$scale(-1));
          });
        }
      });
      node.visited = !T;
    });
    //arrange positions to fit the canvas
    var t = opt.t, w2 = opt.width / 2, h2 = opt.height / 2;
    GUtil.eachNode(graph, function(u) {
      $each(property, function(p) {
        var disp = u.disp[p];
        var norm = disp.norm() || 1;
        var p = u.getPos(p);
        p.$add($C(disp.x * min(Math.abs(disp.x), t) / norm,
            disp.y * min(Math.abs(disp.y), t) / norm));
        p.x = min(w2, max(-w2, p.x));
        p.y = min(h2, max(-h2, p.y));
      });
    });
  }

You can find more information about this algorithm in this overview of Force-Directed algorithms.
This method is called multiple times to provide a final layout, for example like this:

      for(var i=0; i < times; i++) {
        opt.t = opt.tstart * (1 - i/(times -1));
        this.computePositionStep(property, opt);
      }

Where times corresponds to the number of iterations of the simulation, and is generally > 50 and t can be thought as the global temperature of a system that gets cooler with each iteration.

Performance

Although there are a couple of methods to reduce the complexity of this algorithm, this implementation runs like O(V^3), which can be considered as really bad performance.

This is not desirable for real-time interactive visualizations, in which everlasting computation algorithms can lead to blocking browser popups like “This Script is Taking too long…” or things like that.

One way you can avoid these popups is by making incremental computations. This can be done by splitting the main algorithm that has for example 100 iterations into smaller pieces of 20 iterations each. The main iteration loop could then be changed into something like this:

  computePositions: function(property, opt, incremental) {
    var times = this.config.iterations, i = 0, that = this;
    if(incremental) {
      (function iter() {
        for(var total=incremental.iter, j=0; j<total; j++) {
          opt.t = opt.tstart * (1 - i++/(times -1));
          that.computePositionStep(property, opt);
          if(i >= times) {
            incremental.onComplete();
            return;
          }
        }
        incremental.onStep(Math.round(i / (times -1) * 100));
        setTimeout(iter, 1);
      })();
    } else {
      for(; i < times; i++) {
        opt.t = opt.tstart * (1 - i/(times -1));
        this.computePositionStep(property, opt);
      }
    }
  }

This method could be called for example like this:

    //compute positions incrementally and animate.
    fd.computePositions(property, opt, {
      iter: 20,
      onStep: function(perc) {
        Log.write(perc + '% loaded...');
      },
      onComplete: function() {
        Log.write('done');
       fd.animate();
      }
    });

And the main computation would be split into smaller parts calling on each step of the computation the onStep callback.

Graph Operations

For graph operations (Adding/Removing nodes and edges, Graph Sum and Graph Morphing) I make all iterations in the first layout and then only apply 20 iterations after some operation has been completed. Here's a video:

When (*not*) to use Force-Directed Layouts

Force-Directed Layouts can be a good choice when you're drawing general graphs and you don't have domain specific (or any other topological) information about them.
Tree structures however are a special case of graphs: this means that tree structures have more constrains and therefore there's more contextual information for drawing a Tree than for drawing a general graph.
Also, Trees are easier to grasp for the human eye than "general graphs". There's that intrinsic notion of hierarchy that can be used to draw aesthetically pleasing graph layouts. Think about the "general graph" layouts that start with the drawing of a spanning tree and then add the "extra edges" to complete the graph structure (for example here and here). The Multitrees method I mentioned a couple of posts ago was also developed to try to extract more contextual information about a graph and draw it based on a notion of partial hierarchy.

Because of this, in my opinion, it wouldn't be wise to plot Trees that have many nodes with this Force-Directed algorithm: this extra-information about trees isn't used in this layout. However, if you're planning on drawing general graphs and you don't have any other information about them, then this algorithm can detect interesting symmetries and make aesthetically pleasing drawings.

I'll keep you updated with the other visualizations I'm working on in the next posts.