It also inspired Mike Bostock to create, in short order, two
simple demos and a blog entry containing a _really_ nice demo:
http://bost.ocks.org/mike/hive
Visualizing Networks with Hive Plots
When I first saw the demo, my reaction was that it was very pretty
and looked quite detailed. I then ran the mouse over the edges,
noting the red highlighting and the dynamically changing text above.
The demo is an excellent showcase for D3, Hive Plots, and their
excellent synergy. D3's detailed graphics and highly interactive
feedback make hive plots "come to life", showing off their defined
and predictable diagram layout, as well as their high data density.
Folks, I think we have a winner!
Although there is still a lot to be done, it is clearly time to work
on defining an API, building a hive plot library, etc. Ideally, the
API should be as compatible as possible with the other D3 layouts,
while handling the specific capabilities and needs of hive plots.
We should also look into extending the code's capabilities, eg:
* handling of aggregate relationships
http://bl.ocks.org/2066421 - D3 Hive Plot (Areas)
* adjustable, hierarchical bundling of edges
http://mbostock.github.com/d3/talk/20111116/bundle.html
* "inspector" windows for selected edges, nodes, rules, etc.
http://en.wikipedia.org/wiki/Inspector_window
The presentation of graph-based information is (IMHO) an important
and interesting area of research. If you agree, I encourage you
to get involved. But first, wander over to Hacker News and vote
up the topic: http://news.ycombinator.com/item?id=3720684
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Software system design, development, and documentation
http://bl.ocks.org/d/2117857/
https://gist.github.com/2117857
Much of the time was spent on refactoring - Mike's example was
a bit too monolithic for me to comprehend, let alone edit. So,
I broke it up into several files, named a number of previously
anonymous functions, etc. In the process, I added some support
for namespaces, to let the code handle multiple plots, etc.
Although the result isn't an exemplar of modularity, I can find
my way around it and I'm hopeful that others will be able to do
so, as well. Let me know if you run into any problems...
I also fiddled with some of the appearance and behavior, eg:
* rotated the axes and adjusted their spacing, making
them less "tuned" to the flare data set
* changed the highlighting, making "imports" links green
and "imported by" links blue
* added a sidebar that gives a more detailed summary of
the highlighted edges and nodes
* changed the nodes from circles to ovals, etc.
Kai hopes to adapt the code, in order to support the Les Miz
data set. This should reveal most of the dependencies the
code has on the flare data set (eg, connectivity, format).
I'm still hoping to play with aggregate relationships, edge
bundling, and inspector windows, among other possibilities.
I also played a bit more with the geometry (eg, axis angles).
http://bl.ocks.org/d/2117857/
https://gist.github.com/2117857
One improvement that would be nice would be to highlight the cloned
node when mousing over nodes that have both incoming and outgoing
links. That way, the sidebar's list of imports and imported-bys would
match the highlighted links.
For green vs. blue, you need to recolor the links dynamically if you
want to indicate directionality. For example, if I mouseover the
SortOperator class (the top node on the source axis), I see a number
of green links, which is correct. However, if I follow one of those
links and mouseover the Operator class, the link back to the
SortOperator class is still shown green, even though the relationship
goes the other way: Operator is imported by SortOperator.
Fortunately, the design of the hive plot doesn't require coloring to
indicate directionality: the layout itself is sufficient.
> * rotated the axes and adjusted their spacing, making
> them less "tuned" to the flare data set
FWIW, the original placement was intentional, matching Krzywinski's
convention. You can see it described in detail here:
http://www.hiveplot.com/conference/vizbi2011/poster/krzywinski-hiveplot-poster.png
The 12 o'clock axis is for sources (nodes with only outgoing links),
the bottom-left axis is for targets (or "sinks", in the poster, nodes
with only incoming links), and the bottom-right axes are for nodes
that are both, "cloned to show relationships between nodes of the same
type".
In any case, my hive plot example needs labels or a legend to indicate
which axis is which. But I think it's critical that the cloned axes
for source-targets have gestalt grouping; otherwise, it may not be
obvious that the nodes are duplicated.
Mike
Cool. FWIW, that's sort of my first step towards an "inspector".
> One improvement that would be nice would be to highlight the cloned
> node when mousing over nodes that have both incoming and outgoing ...
+1 - done; see below.
> FWIW, the original placement was intentional, matching Krzywinski's
> convention. You can see it described in detail here:
>
> http://www.hiveplot.com/conference/vizbi2011/poster/krzywinski-hiveplot-poster.png
Thanks; I hadn't seen that poster. I have mixed feelings about the placement
issue. Following conventions is a Good Thing, but I'd also like to make the
best use of the space. So, I've set up the code to allow experimentation
(for details, see "format" in get_info() in main.js).
> In any case, my hive plot example needs labels or a legend to indicate
> which axis is which.
Agreed. I'd prefer some small, horizontally-oriented labels (eg, SO, ST, TO)
just past the outer ends of the axes. However, I have currently left that on
the back burner due to a lack of clues about how to do it. Hints?
> I think it's critical that the cloned axes for source-targets have gestalt
> grouping; otherwise, it may not be obvious that the nodes are duplicated.
The duplication should definitely be indicated in some manner. We also need
a way (see below) to indicate source/target relationships, etc.
More generally, I don't think hive plots are ever going to be as "obvious"
as conventional (ie, separate node and edge) layout. On the other hand,
this may not be a fatal flaw for an interested audience: many visualization
techniques require (and reward) close, thoughtful examination.
> For green vs. blue, you need to recolor the links dynamically ...
> Fortunately, the design of the hive plot doesn't require coloring to
> indicate directionality: the layout itself is sufficient.
I've been thinking about this quite a bit; my take is that the coloring
for any link or node should tell the user about its connectivity. So:
* Mousing over a link should cause:
- the link to light up red
- the nodes that it imports to light up green
- the nodes that import it to light up blue
* Mousing over a node should cause:
- the node to light up red
- the links and nodes that it imports to light up green
- the links and nodes that import it to light up blue
* The sidebar color and text should match the diagram.
* Clones of lighted nodes should also light up.
See what you think of my decisions (and implementation), in action:
http://bl.ocks.org/d/2117857/
https://gist.github.com/2117857
I think the test diagram looks pretty good, but I'm less pleased by
the real (flare) diagram). COmments and suggestions welcome...
Martin Krzywinski has been following our efforts with great interest.
He even mentioned them on his web page: http://egweb.bcgsc.ca/
> Secondly I realized that there really seem to be a few key insights ...
That may not be the entire list, but it's a good start (:-).
> Why not just render the chart in a straight line? A simple set of connected
> stacks of vertices, beautifully organized and easy to read, with (if circularity
> is required) the first stack duplicated again as the last one.
I discussed this notion with a friend just the other day. It would look a bit
like a DOT-style layout (in Graphviz), but with far more data density. I think
it would be pretty simple to modify https://gist.github.com/2117857 as a set of
parallel axes. Most of the relevant code should be in main.js and lib_plot.js.
It sounds like you have a lot of interesting ideas. Come on out and play!
http://egweb.bcgsc.ca/conference/ismb2011/netbiosig/hivepanel-human-dip-poster.png
It'd be nice to use the hive plot's axis placement with parallel
coordinates polylines.
For example, in the nutrition dataset, there are many interesting
dynamics between food groups and 3-5 dimensions. Vegetables have
interesting vitamins, oils have interesting fats, fast food has
interesting water/sodium/calories, etc. 6 hive plots could provide
feedback for 18+ dimensions that aren't filterable on the main
parallel coordinates. Perhaps clicking a hive plot would add
dimensions to the parallel coordinates.
Hi everyone,
Please pardon me, I'm complelely a newbie here.
I'm working on a small hive plot (tweaked from Rich Morin and Mike's demo) and don't know how to add an extra axis (or axes) as well as how to cling additional data onto that new axis.
I would very appreciate if someone could help me figure this out a bit.