9 comments

[ 3.6 ms ] story [ 34.2 ms ] thread
Lately I’ve been working on discovering what NetworkX can do. I learned it is a powerful and useful Python tool, but I also noticed challenges most NetworkX users are facing. Read more about it at my blog post. If you have any questions just let me know.
My (limited) experience with building network analysis tools is that the biggest difficulty is representing the data in a way that people (especially non-experts) can actually understand and draw insights from. So many network graphs are a colourful sea of nodes and edges that looks amazing in a demo but as soon as a non-expert customer tries to actually use the thing they’re just confused.

What’s the state of the art / good practice in presenting network data? My gut feeling is that even though it’s a graph, it’s often not best rendered as one, and many times a collection of more familiar chart types or tables would be more useful.

Would love to hear people’s thoughts on this.

I have a feeling like people like to render large graphs just for visualizations. I yet didn't encounter a use case where someone would look at a graph of a million visualized nodes and said: "Oh I see, this is what's happening!" or some other information. But then again, you don't do that at all when dealing with relational databases as well

But I guess the biggest advantage lies in shallow hop visualizations (up to 10), where there is a smaller number of nodes, let's say a 100, but you can clearly understand what's happening because you can process all of the connections at first glance.

And even in the real life use cases, such as fraud detection, it's never going to be a million person organization that steals you money and resources, but a group of people closely tied together, which you can quickly inspect and look at, whereas looking at tabular data does not connect the dots.

You can draw a parallel when detectives marked the maps with needles and strings to connect the murder cases. Of course they didn't put a million needles on the wall, but a 100 of them was sufficient for inference.

Presenting the data and results of analytics is certainly not an easy task and it definitely depends on who is the audience. So, yeah, I agree with you about that. Regarding graph representation, I talked with a bunch of people on the conferences regarding this, and they liked the form of a graph, because that's how they are thinking about the problem from the start. If they want to put it on a paper, they are actually drawing graphs, and that's why it's intuitive to them. It's important to make it simple, to make node size fit the results properly, and I would say, not to exaggerate with the colors :') Charts are out there for a long time, so I think that sometimes a combination of graphs and charts can be useful, depending on the solution you are trying to present.
How to these tools compare to something like Gephi?
I didn't compare it, since I haven't used Gephi, but I heard it's useful for large graphs. I don't like the user interface. It looks a bit outdated. I guess it's a good visualization tool, but I am not sure what it offers regarding the data import options and storage. If I need data persistency, I would rather choose a graph database which offers visualization tool. But if I only want to visualize my data, I would probably turn to tools such as Gephi.