Best flow to represent, browse and edit complex graph network

Question

It seems that more and more, data is going to be network-based. A graph with related nodes.

Something like http://bl.ocks.org/mbostock/950642 , or pick one from a gallery here: http://christopheviau.com/d3list/gallery.html#visualizationType=network

So how can we let the user focus on what he wants from this network. I can't seem to find any current implementation that cares for other than pretty colours.

There is nothing that focuses on actually understanding the data and being able to edit or remix it, reorder it.

A zoom may be? Some sort of a out-of-the-way menu for filtering? What could aid the user?

Answer 1

Context

It's really going to depend on what the data is, what the nodes and edges are representing and what the objective of the visualization is. As with most UX questions, context is king.

I've been working on a graph-based application for some years now, and so my answer's going to be based on my experience with that... so this answer won't fit everywhere. Here's some details about my situation:

• Very large, very complex graphs (hundreds of thousands of nodes of varying types, with relationships having both type and direction)
• Different users and use cases requiring different views of different subsets of the graphs for multiple different contexts
• Graph used for both interrogation (answering specific questions) and exploration (determining questions to ask)

Where those are the case, I've found that you always need to know the following before even starting to work out the interaction:

• Context - what is the user trying to do - your interaction model will likely be different for interrogation than it will be for exploration. If you need both then you need to at least be aware that the two are likely to be different flows through the same piece of UI.
• Scope - how much of the graph does the user need to see to be useful. In my work, I've found that the types of nodes and relationships to display can often be limited based on the user and the context they are viewing in. Sometimes the scope will be "as far as the graph goes by continuing along the types of relationships the user is interested in", whilst other times there will only be benefit in showing only the immediate neighbourhood (say, one or two hops) from the point (or points) they started from. For exploration, I've found that the scope needs to be larger than for interrogation.
• Minimum useful data for the context - how much data can you leave out in the initial view and still be useful - this usually provides a good start point without overwhelming the user, especially if they're then able to selectively reveal more of the graph.

What to show

Start off by showing the nodes and relationships that are within scope and within context for the task the user is trying to achieve, and also within the minimum useful data... then afford access to show more.

How to show it / interact with it

When you've got those questions answered and know what you need to show, you can then start to think about how to let the user browse and manipulate that display - dragging and dropping of nodes is pretty much expected now... and for a lot of situations you'll also need to afford the means to edit, which is also more complex than it could be.

Typically, your users will need to be able to interact with three types of things within a displayed graph (nodes, relationships, canvas), so it's worth thinking about each separately to break things down a bit.

Breaking down the interactions

Nodes

You'll usually need to be able to interact with individual nodes to view, edit or delete them (at least), and potentially create new related nodes (which means creating a new relationship, too) or duplicating a node (with or without its relationships).

Relationships

you need to be able to interact with these too - add a relationship from one node to new node (which means creating a new node too), add relationships between existing nodes, edit properties of a given relationship, change the nodes a relationship is between, delete a relationship (type, direction, other properties)

Graph "Canvas"

If the user wants to add nodes to the graph which are not yet related to anything in the graph, they'll need some means to do so. I usually do this either by affordances outside the graph or with a context menu on the canvas the graph is displayed on. (not referring to HTML5 canvas - just the concept of a canvas for the visualization.)

After breaking things down from one complex thing (a graph) to several simple ones (nodes, relationships, canvas) it's a much simpler thing to work out an interaction model for each thing... which you can then prioritize and design your UI around.

Choosing appropriate affordances / components

For the work I've done, I've ended up with context menus on each type of thing (nodes, relationships, canvas) that afford access to behaviours directly or launch appropriate UI elements for each action - usually modal dialogues. That's not going to be appropriate for every use case, but it's worked for me.

Hope that's helpful!

Answer 2

There is nothing that focuses on actually understanding the data and being able to edit or remix it, reorder it.

I think this is the key to the question: it needs more of an IA approach before treating it visually and is also very content specific. There isn't a catchall solution for displaying every type of data in a hub and spoke visualization.

Example 1

Just for a thought experiment, let's take for example a hub and spoke visualization of someone's Facebook social network and the goal for the user is to get from him/herself to Kevin Bacon in the smallest number of clicks possible (let's put aside privacy issues and assume you have access to every friend of friend of friend and so on -- and that Kevin Bacon is in fact on Facebook and has friends). Furthermore, there is no quantum computing available that will automagically show you the best path based on some kind of algorithm.

Given that someone's social network could range drastically (let's say from 20 friends to 1000+), there will definitely need to be some kind of filtering mechanism to limit the connected nodes to a manageable data set (let's say 10). Furthermore the path the user takes and the data that is shown is dependent on which nodes are selected so there will have to be a method of selection and the dataset will change upon that selection.

Given the above, an acceptable UI would need to incorporate some kind of filtering mechanism or multiple filtering mechanisms on top of the hub and spoke node selection. Some natural options would be gender radio buttons (male/female/none), and age range slider, and keyword search filter that links to a user's Likes in their profile.

You can see that this dataset requires a lot of filtering as well as trial and error on the user's end. Let's compare this to another example:

Example 2

Let's assume a data set of the tree of evolution from trilobites all the way to modern homosapien and every species that has ever lived on planet Earth (whether this is factual is irrelevant to the hypothetical). This hypothetical interactive graph is a teaching tool that allows student's to explore the connections between species freely. A simple scroll/pinch to zoom functionality can change the zoom level of the hub and spoke visualization while clicking and dragging or tapping and dragging allows the user to pan around at that zoom level.

Furthermore, at each zoom level, a maximum number of nodes can be shown (let's say 10 again to be consistent with the previous example). Depending on the zoom level, the nodes will display either the domain, kingdom, phylum, class, order, family, genus, or species appropriate to that zoom level.

In this example, there is no reason to filter options and no selected state that dictates what data is displayed next. There is no need for one. At the most, there may be a drop-down to select the zoom level based on the domain, kingdom, phylum, etc.

Answer

Given the two disparate datasets with their unique data connections, hierarchies, relevant data, and user goals, the UI would have to adapt to suit each. This doesn't even take into account data creation or node-connection creation.

I think it is our job as UX designers not to apply catchall solutions to unique problems, and conversely not create unique solutions to common problems, but to focus on the problem at hand and find a solution that works with the tools at hand. In the event a tool doesn't exist to solve the problem, or a better one can be fashioned to more efficiently (or more pleasurably) solve the problem, then our job extends to the creation of that tool.

TL;DR

There is no catchall design solution. This question requires the designer to first look at the unique dataset and the goals of the user before exploring design and functionality solutions.

Answer 3

Visual Thesaurus focuses with size and centrality, and allows dragging, clicking, and other gesture directions which I think function very well.