Ever wondered whether a treemap must necessarily be a tree? I don't know ... this might be plain obvious to you but it isn't to me. Only recently I started thinking that a treemap must not necessarily represent hierarchical data but simply a plain n-dimensional dataset or, in other words, a map without a tree structure. And I'm surprised how few interest it has been devoted to this aspect.

After all, there are not so many other layout algorithms that permit to fill the whole screen (that is, without any empty space between items) with meaningful data and still use additional visual dimensions such as color, size, texture, etc.

In this respect, ordered treemaps are of particular interest. They employ some kind of algorithms that: "create rectangles in a visual order that matches the input to the treemap algorithm". Because the objects' placement depends on the order in which they are presented, their position is fixed and carries some additional useful information.

Initial attempts to improve treemaps involve rather the "squarification" of rectangles, that is, find clever strategies to make rectangles as close as possible to squares to improve their readability. Ordered treemaps retain this initial idea and add the constrain of presenting data with an order. In a 2001 paper, Bederson, Sheiderman, and Wattenberg proposed and compared various strategies (e.g., slice and dice, squarified, pivot, strip, etc.) and evaluated them by means of quality metrics:

• aspect ratio: how "squarified" the treemap is
• change: how much change is involved in a data update
• readability: how hard is to visually scan the tree in the input order

However, not much emphasis is put on the fact that this kind of treemaps can nicely present non hierarchical data. Nonetheless, some nice examples exist:

One notable domain where these features are useful is network security, where information must be visually scanned in real time to cope with potentially dangerous network events.

Maintaining the input order means, for example, that in the specific case where rectangles represent network hosts, if they are presented to the algorithm in a network IP order , the elements under the same network will fall in similar positions. The stability of the layout is even more important in this case. Because data change often and thus the position of the elements can change, having a stable layout means that an observer can easily track items' position when data is refreshed.

One interesting application of treemaps in network security (with some additional geographical constraints) is Hierarchical Network Maps where network aggregates such as autonomous systems (backbones) are represented by rectangles whose size represent number of hosts and color traffic volume. Here is a screen shot.

I couldn't find however an example where rectangles' size (and thus position) changes with time. In HNM the authors claim it is not a good idea because layout stability is of primary importance. Nonetheless, I think that having the objects requiring attention represented as the biggest items on the screen could really improve the analyst's job.

I think there are many ways to elaborate over this idea in the future. After all, when the constrain of having a containment/recursive visual structure is relaxed, there might be tens of other clever criteria to arrange items on the screen.