hive plot status, 2012.0318

[Rich Morin]

About a week ago, Manish Sood suggested that I look into Martin
Krzywinski's Hive Plots. After a few days of hacking, I had a
working (if minimal) D3 demo. This produced some enthusiastic
chatter (and hacking activity), as seen on the D3 mailing list.

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

[Rich Morin]

I've spent an entirely unreasonable amount of time playing with
Mike's hive plot example, but I think the results are starting
to look pretty interesting:

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.

[Rich Morin]

The page now has two independent hive plots, generated by mostly
the same code. This required some CSS and HTML rework, as well
as some closure magic in main.js.

I also played a bit more with the geometry (eg, axis angles).

http://bl.ocks.org/d/2117857/
https://gist.github.com/2117857

[Mike Bostock]

I like the sidebar that lists the dependencies on mouseover!

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

[Rich Morin]

On Mar 25, 2012, at 09:22, Mike Bostock wrote:
> I like the sidebar that lists the dependencies on mouseover!

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...

[Darrick Wiebe]

I was thinking a little bit about hive plots today and how much better I like them than any other graph visualization I've encountered before, and a couple of questions or ideas struck me.

First was simply whether the original team at BCGSC.ca has moved beyond what we see on their poster (Mike's earlier email) in any way. Has anyone in the group been in contact with them?

Secondly I realized that there really seem to be a few key insights that are combined here that make the visualization so useful: 1) strict organization of vertices in rows (improved by Mike's grouping); 2) allowing entire rows of vertices to be duplicated to prevent interlinking within a single row; 3) preventing edges from passing over/under vertices that they don't actually connect to; 4) treating different edge types as independent layers that are visualized separately, greatly simplifying each view.

In addition to those, the option they present of giving vertices and edges a width on their row allows even more data to be expressed which is very cool. Unfortunately though, here I think the design runs into problems because no matter what you are expressing, data nearer the outer edge of the hive is going to get a lot more "data ink" than the same data if it were nearer the centre. At that point I realized that nothing about these visualizations requires the awkward circular, almost pie-like rendering.

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. It would look a lot like a parallel coordinates chart, and in fact it would be exactly that, but extended to support graph data and much more useful for that. To be able to create a hybrid of a parallel coordinates graph and this graph would yield one of pretty incredible power and readability!

The other idea that I had today is that while it's kind of cool to see a set of several views of the same data side by side as it is on that poster, it's exciting that with d3 it will be possible to compare or even combine layers (in less dense graphs at least) in place. I'm really looking forward to exploring the potential there.

Then, if we consider giving edges area again, and combine the above ideas, we end up with something potentially similar to a streamgraph...on graph data... I don't know about others here, but this stuff really excites me!

Thanks for the great work so far.

Darrick

[Rich Morin]

On Mar 26, 2012, at 00:21, Darrick Wiebe wrote:
> Has anyone in the group been in contact with them?

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!

[Kai Chang]

Like parallel coordinates and scatterplot matrix, these visualizations
will do well with rapid interaction. Also consider the design of small
hive plots to be used in a hive panel/matrix:

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.

[Max De Marzi Jr.]

Thanks for the hard work guys, I just wanted to contribute a blog post on this http://maxdemarzi.com/2012/03/26/visualizing-a-set-of-hiveplots-with-neo4j/   

... and 9 hiveplots in a 3x3 matrix.

http://hiveplot.herokuapp.com/index.html

[Martin Krzywinski]

The egweb.bcgsc.ca link may be broken. The hive panel poster is at

http://www.hiveplot.com/conference/ismb2011/netbiosig/hivepanel-human-dip-poster.png

On Mar 26, 6:24 am, Kai Chang <kai.s.ch...@gmail.com> wrote:
> Like parallel coordinates and scatterplot matrix, these visualizations
> will do well with rapid interaction. Also consider the design of smallhiveplots to be used in ahivepanel/matrix:
>

> http://egweb.bcgsc.ca/conference/ismb2011/netbiosig/hivepanel-human-d...
>
> It'd be nice to use thehiveplot'saxis 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. 6hiveplots could provide

> feedback for 18+ dimensions that aren't filterable on the main

> parallel coordinates. Perhaps clicking ahiveplotwould add

> dimensions to the parallel coordinates.
>
>
>
>
>
>
>
> On Mon, Mar 26, 2012 at 1:01 AM, Rich Morin <r...@cfcl.com> wrote:
> > On Mar 26, 2012, at 00:21, Darrick Wiebe wrote:
> >> Has anyone in the group been in contact with them?
>
> > 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 modifyhttps://gist.github.com/2117857as a set of

[Martin Krzywinski]

> He even mentioned them on his web page:http://egweb.bcgsc.ca/

The egweb link is likely broken. Please use

http://mkweb.bcgsc.ca

I will make more prominent links from this location - my home page.

Links to this discussion and Rich's code are already on hiveplot.com

I've added a link to Mike's d3.js+hive article from my rotating
mastheads.

http://www.hiveplot.com/img/masthead.png

Martin

[Musho Genshin]

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.

Thank you all so much.

Mushogenshin.

[Kai Chang]

I guess that was a bump, but I did want to post this example by Sara Quigley:

http://bl.ocks.org/saraquigley/raw/2346962/

Great edge highlighting and labeling on hover. The most readable hive
plot I've seen so far.

On Fri, Mar 1, 2013 at 2:23 PM, ASM Liton Chowdhury
<asmliton...@gmail.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups
> "d3-js" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to d3-js+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>