I have built a few graph views and worked on a tool used to specify graph views for existing schemas. My thoughts.
Hierarchical views aren’t easy because they are common, they are easy because it matches how humans think on a basic level. We take a concept, draw a line down the middle, and get two refined concepts. That cleaving is a natural process that produces hierarchical trees. If you can display your data in a tree, you have the optimal view most of the time.
The trick isn’t finding a better graph. The trick is making your data look like a tree.
Don’t confuse your schema and your view. Your schema will almost always be a cyclic graph. But if you define an arbitrary root node and choose a subset of relationships, you can easily create a hierarchy view of a subset of the graph.
All generic nontree views suck beyond a certain complexity. Unless you have a specific kind of cyclic data and specific rendering, it will look bad. The issue is that there is one type of shape for acyclic hierarchical data, the tree, but infinite for cyclic data. If you are displaying cyclic data well, the graph has been tuned for the use case. Drawing cyclic graphs is an NP hard problem, and you need to choose heuristics to layout the nodes.
The best graphs views are a lot more than lines and boxes. They facilitate specific jobs, and surface key information and actions. When nodes have heterogeneous types they may need their own renderings beyond simple styling. Just drawing words with connecting lines provides shocking little value, especially for those who aren’t spatial thinkers.
To add to that, some people really like graphs and some don’t. No graph will be good enough to get a graph hater to like it. So any time you display a graph you need an alternate view, like a list. And that brings us back to hierarchical trees.
Hierarchical views aren’t easy because they are common, they are easy because it matches how humans think on a basic level. We take a concept, draw a line down the middle, and get two refined concepts. That cleaving is a natural process that produces hierarchical trees. If you can display your data in a tree, you have the optimal view most of the time.
The trick isn’t finding a better graph. The trick is making your data look like a tree.
Don’t confuse your schema and your view. Your schema will almost always be a cyclic graph. But if you define an arbitrary root node and choose a subset of relationships, you can easily create a hierarchy view of a subset of the graph.
All generic nontree views suck beyond a certain complexity. Unless you have a specific kind of cyclic data and specific rendering, it will look bad. The issue is that there is one type of shape for acyclic hierarchical data, the tree, but infinite for cyclic data. If you are displaying cyclic data well, the graph has been tuned for the use case. Drawing cyclic graphs is an NP hard problem, and you need to choose heuristics to layout the nodes.
The best graphs views are a lot more than lines and boxes. They facilitate specific jobs, and surface key information and actions. When nodes have heterogeneous types they may need their own renderings beyond simple styling. Just drawing words with connecting lines provides shocking little value, especially for those who aren’t spatial thinkers.
To add to that, some people really like graphs and some don’t. No graph will be good enough to get a graph hater to like it. So any time you display a graph you need an alternate view, like a list. And that brings us back to hierarchical trees.