Some of the main lessons from this software, which can be applied by other projects:
- For certain applications, people need rich types of diagrams, not just dots and lines. Many automatic tools including ours often still do not reach the quality of the best handmade diagrams.
- We can benefit from using more general systems of constraints, and this area of research deserves further study and exploration.
- Interaction, complex APIs, embedding your software in bigger, more elaborate systems is great, but presents some users with a lot of complication that is too costly to surmount.
- Documenting your work in a way that makes it accessible is as important as the work itself. We did fall short there.
We're grateful we had a good run with graphviz.
Stephen North north from graphviz.org
We are a small team specializing in data visualization, especially in web. I feel like we can help you with this amazing project. And we would be proud to do so.
See our recent work published on HN to get the idea of what we can do .
If you have any thoughts on how we can contribute, let me know by writing me an email on michael[at]tehcookies.com.
This work is absolutely amazing. I've tried implementing it a few years ago (as an excervise when preparing for Google interview). So naive. I've found out that I have read each and every sentence extremely carefully to get things right. I got quite far but never finished the implementation. (And I did not get an offer from Google either.)
There are research groups (I'm thinking of Tim Dwyer's specifically) that are specifically trying to improve the situation. When you say "it's just a pile of incompatible heuristics", it sounds like you haven't taken the time to try and implement a better solution.
Graph drawing is the kind of thing that seems trivial, right until you try to work on it.
(disclaimer: I'm clearly biased here since I worked with the people who wrote graphviz.)
I hardly think they'd turn away algorithmic contributions, if you've got some.
Do you have an example of your hideous bow ties? I don't usually use graphviz to 'draw' anything, so I don't really have the context to understand your complaint. I've never seen a result I think of as a hideous bow tie.
Page 6 Figure 5.
Originally what spurred me towards text based diagram generation was a visceral hatred for out of date visio network maps, so I wrote a script to automatically update network maps and diffarchive old ones so I could walk back in time on the network.
It was something that could be put in a report and look nice (due to manual layout control) vs the automap generation of things like LibreNMS/Zabbix/Nagios.
It provides bunch of types of diagrams, including GUI mockups (salt), gantt charts, all UML types, time diagrams etc.
It can also export to ASCII art, totally awesome.
Plugins are there for everything, such as Gitlab, VSCode, Redmine etc. and you can easily integrate it otherwise.
It seems to me that the syntax is rather simple and minimal.
- scoping for node and edge styles (among other things, this would help
towards copy-pasting graphs into subgraphs)
- named styles (e.g. define *”shape=foo”* as red rectangles with italic
- more consistency in graph attributes across layout engines
- more intuitive effect of graph attributes on layout
- easier way to style node content (the ‘old’ way was ugly, but the
restricted subset of html isn’t that nice, either)
- ability to switch layout engines in subgraphs (among other things,
this would help towards copy-pasting graphs into subgraphs)
I haven't thought about it enough but I am a big fan of Elm's declarative graphics . I think starting with something like that would be interesting.
n1 = circle "node 1"
n2 = square "node 2" |> outlined red
main = graph [edge n1 n2, edge n2 n1]
For graph layout, tools worth looking at include OGDF (an open source C++ library), the commercial yFiles Java library with free yEd editor/layout tool (includes support for GraphML attributes), and Gephi (an open source Java-based graph layout/visualization tool).
If your graph represents some type of directed dataflow, then maybe Google's Tensorboard graph visualizer (intended primarily for neural nets) is of interest - it's open source and very slick (esp. wrt subgraph collapsing/expanding), but you'd be on your own in terms of importing a foreign graph format.
Two other alternatives:
The best one for network-bounce / sequence diagrams.. great for when you need to explain all the bounces in your mulit-tiered web app
IIRC I did some graphs for my bachelor thesis (10+ years ago) with graphviz, and then basically just passed them through OmniGraffle to make them beautiful.
Using Graphviz is the only way I know to build such specs. Bonus point: many online VCS renderer are able to display .md format, with embedded .svg images (directly produced from Graphviz).
Of course, you can change the defaults, but creating the 'look' you want textually without an interactive creator is non-trivial. Given that the main strength of graphviz is that I can write it in a stream of consciousness (like markdown), or generate it automatically using some kind of script from another data source, this is somewhat of a blocker in its usefulness.
And, of course, the customisation syntax is fairly clunky and not easily readable. I don't think I've seen a DSL that does colouring well in this regard, but graphviz goes a step further by not being consistent with CSS or other markups.
It is good in terms of feature-completeness, but as mentioned in the TC, there are areas where it could be polished up a bit to make it feel more modern.
Edit: found it https://github.com/vidarh/diagram-tools/tree/master
And then the graphics need to look more D3 than UML.
I'm thinking 200k nodes and 2 million edges? Graphviz segfaults graphs a fraction of the size and even at that scale a node by node representation isn't super helpful without being able to zoom out and look for patterns.
Gephi and Cytoscape are the main free graphical applications for analyzing networks; they might work for you.
Tulip  might also be worth a try.
The idea is by connecting GPUs in your browser to GPUs in the cloud, we can do bigger and bigger datasets over time. We're currently 1M nodes & edges in interactive-time (so no leaving your computer for 1hr+ or crashing), and actively working on the V2 engine to get us to 100X more. And yep, generally we don't want to stay long in large views, so we see it more about being scalable / smart / usable enough to let you go in-and-out.
There are some tools in R and python that seem to turn up. I'm sorry I don't have anything more specific than that to suggest, though it might be a fruitful direction.
Sometimes it’s painful to go back and see the code you wrote that long ago, but what’s great is to see frameworks like this still chugging along providing value for over a decade.
When we needed high res images, we exported to SVG, and I was able to import those into Visio. She saved me days or weeks of documenting.
Saves heaps of time over fiddling with Visio.