3 ms·
I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc). Granted, it's labor inten
by amirkdv 6y ago
I have gotten really used to drawing all my technical diagrams with Inkscape (system arch, sequence diagrams, product roadmaps, etc).
Granted, it's labor intensive and hard to justify the learning curve just for technical diagrams but I find that once you have built the muscle memory and a good mental map, it's not that slow (and encourages concision and good abstraction to make the diagram simpler) and superior to auto-generated layouts because it gives me the flexibility to make prominent what deserves to be prominent (objects, paths) and complete control over styling. I also hate it when adding a single element might change the auto-optimized layout entirely.
I wonder what folks who use (go-)diagrams at scale think of this. Maybe my solution is untenable for large enough projects.
- jjnoakes 6y agoOne thing I like about textual diagramming tools (in code like this project or in a markup dsl) is I can version control and diff changes.
- amirkdv 6y agoFair! Do you build workflows around the diffs themselves (collaborate, review, update)? I can already put my svgs in version control and have history/versions. But I've never felt compelled to look at a textual diff of viz code.
- jjnoakes 6y agoYes, absolutely. SVG is lower level than I'd want to do this with though - instead of comparing things like individual paths and fill colors, a dsl at the right abstraction level lets you compare things like adding a server to a load balancer in a network topology diagram.
- tikhonj 6y agoI've made diagrams for my talks in both style (with code and with Inkscape or, these days, Lucidchart). Writing code to generate diagrams had a much larger setup cost but once I had it going, iterating on the diagrams became much easier. I had a talk about radix trees[1] where I wrote some Haskell code that could take trees and generate diagrams from them. Getting the code right in the first place took a few hours but in this case it was clearly worth it in hindsight for two reasons: 1. I ended up with a lot of tree diagrams. Once the code was working, the marginal cost of adding an extra diagram went way down and I think that improved the talk as a whole. 2. Code made it much easier to iterate on my examples. I had an extended example[2] that I changed several times; if I had had to manually redo the diagrams for it each time, I would not have bothered. These days, this trade-off (up-front vs ongoing costs) makes the decision reasonably easy. If I'm going to be making a single diagram and I don't expect to change it much, I'll do it manually; if I'm going to be making a series of similar or related diagrams or if I expect to iterate on the diagrams a lot, I'll write some code for them. So far, I haven't regretted following this approach in either case :). [1]: https://jelv.is/talks/lambda-world-2018/slides.html#/sec-title-slide https://jelv.is/talks/lambda-world-2018/slides.html#/sec-tit... [2]: https://jelv.is/talks/lambda-world-2018/slides.html#/slide-org36e08b7 https://jelv.is/talks/lambda-world-2018/slides.html#/slide-o...
- amirkdv 6y agoThanks for this! Ceating multiple slightly different diagrams manually is indeed a painpoint.
- c3c 6y agoThis is interesting. I am working on a tool (sourcespy.com) to create diagrams specifically because maintaining large diagrams in Inkscape and Lucidchart is cumbersome. Another pain is grouping the nodes. I wish there was something interactive where care about semantics and tool takes care of node arrangement.