I love it, but I can't help but wonder why I almost never see complete or up to date diagrams in an enterprise or at scale software engineering setting, despite there being so many tools in this space (mermaid, uml, draw.io, graphviz, etc). I wonder what the barrier is or how to make tools like this fundamentally different so that we would see more adoption.
This comes up frequently in the context of secure design review, or more generally when outside stakeholders need to understand a foreign system.
Nobody argues against diagrams as good practice, but so few actually make them. That tells me incentives/costs are still off, despite good intent.
Information extraction from design docs could be one approach to suggest a diagram for free but that creates a dependency on the fidelity of the design document.
That's a huge scope question on its own. What's "complete"? How low level or wide do you go? What about the view of internals of the external systems you rely on? What about their mapping to teams/owners? C4 helps a bit here by saying "whole organisation throws everything possible into this and when you want to see it, you use scoped views instead".
> or up to date diagrams
"When exactly does the system change" is tricky too. When you change the code? When you enable the new system? Who knows that the diagram of the system exists and where? It's a bit of an issue of unknown unknowns. Again, the C4 idea helps here a bit, but there are still going to be random projections of state at a given time saved in various places.
Another big issue is that structure and presentation are very different. Generated diagrams of infrastructure or code look shit, universally. On the other hand, well presented diagrams are just snapshots in time that get preserved for years even if their outdated. I mean this is what C4 page shows as one of their results https://c4model.com/img/alternative-1.png which is an unreadable mess and this is what they initially complain about https://c4model.com/img/sketch-2.jpg which is perfectly sized and context specific goodness. The first is good for knowledge preservation, but if anyone needs to understand things, I'm making the second one for them.
I've lived this life first-hand, and it is refreshing after experiencing the vast open sea of half-assed Confluence sprawl, huge PDF design documents that aren't kept up to date with changing requirements, etc.
The other sibling comment regarding rendering documentation source to Confluence or <required external system> to keep the corp overlords happy is a great middle ground IMO.
Merely as a "for your consideration," if you already have a build pipeline, rendering the in-repo docs and pushing them into Confluence could be a middle ground between "corporate overlords" and the workflow that works best for you and your team
I tried to solve this after years of frustration, but it's a complex task, especially that "complete" means there is a lot of noise in the diagrams. Plus the data gathering is an immense task, not everything is in the repo even with world class terraform, you have to connect to external sources.
My take is that it's a bit worse than that: the whole doc tooling scene is a dumpster fire. I want to maintain technical documentation under revision control (same revision control system as I use for source code), and I want to be able to embed diagrams in said documents (also under revision control) and I want to wysiwyg edit those things. Amazingly in 2024 this does not exist.
> I want to maintain technical documentation under revision control
This kind of effort is sabotaged at every place I've ever worked, usually because product or leadership insists that it moves to confluence, and then predictably this increases friction and no one ever updates those diagrams again. People with "20 years experience in industry" can't be bothered login to github, and in the best case instead of confluence they want lucidchart, where inevitably the whole org is sharing like 3 seats.
Partly this is just laziness or ignorance, but partly it's deliberate overreach into engineering business because there's lots of people who see actual information as a threat to to their preferred narratives (think hype/sales promises/etc). Plus you can't say that you didn't know about a design flaw if there is 6 month old diagram calling out the need for a solution in big red letters. Since a picture is worth a 1000 words, and since a git hash can get a date attached to it, dead-on-arrival docs/diagrams tends to decrease accountability.
Jetbrains' recent WriterSide tool is a great addition into this space. It's not exactly wysiwyg, it's side-by-side live preview with different source languages (right now, markdown and some xml language are supported, but they want to support more popular doc languages).
It allows you to specify definitions in one location, and reference them in other pages. So if you have for example a documentation page which is about "installing our nodejs package", you can write a version in vars.json or vars.xml or whatever, and reference it in your installation documentation page.
When you later have another page which is saying "Hey, we found a bit of an issue with ...this-or-that... package because we're using $NODE_VERSION, and the package hasn't been updated so we have ...such-and-so... workaround", you know when you update the $NODE_VERSION in your vars, that you need to take a look at that package again.
It's an extremely basic part of software development, being able to define variables, but I think this is a very good sign of powerful documentation tooling.
The only major downside about the platform is that their XML (HTML) extensions to markdown are proprietary, and as such the platform isn't able to grow outside of Jetbrains' oversight. I'm still debating whether I want to switch from Gitlab's Wiki (which is very basic but is really really easy to edit for anyone on the team) to a solution like Jetbrains' Writerside.
I think this captures the sentiment I have been seeing and feeling myself. Docs and diagrams die because they aren't code. When the code changes, the docs are left behind.
What is interesting here is that mermaid and graphviz could be committed to source control, but I have never seen it done anywhere likely because the burden of drawing/updating is still too high (hence your wysiwyg comment).
I helped implement Mermaid as a part of Apollo GraphQL’s public documentation to address the “docs as versioned artifact with code” challenge. It’s a win, but still another Yak to shave since public docs are a product, not the source code for the internal teams’ use.
I’ve used it for a long time; even if I don’t end up sharing with others it can help me quickly visualize things (the ease of change often makes better than pen and paper). At one of my jobs we had an architect join and he was amazing; I really respected him. He used PlantUML and would open it up and start writing sequence diagrams with us. He would make sure complex flows that were actively being implemented were kept up to date and they were useful references.
If you want to understand the underlying problem, think about geographical mapping (e.g. Google Maps). When drawing a map, how do you decide what gets featured? Roads, businesses? How big can the text be? How do you keep it all readable?
Diagramming is the same problem, but usually lacking the context to decide what to draw. The same stakeholders may be interested in different combinations of features depending on which business questions they're trying to answer. Geographic mapping is practically a constrained domain by comparison. And it's supposed to be feasible to do it automatically for systems diagrams? /hard-skeptic
I understand the argument but think this is a straw man based on my experience. The issue isn't so much that people can't decide on the level of detail, it's that the diagram is drawn only once or in most cases never.
A dataflow diagram for example is mostly self constraining in scope.
Automating it is another problem entirely and I agree it has a lot of hard challenges.
Honestly, I think you are using free (and old) diagramming tools, and you are getting why you pay for. There are plenty of tools designed specifically for documenting large systems, but they cost money.
It has the best "move element" behavior of any diagramming tool I've ever encountered (it shifts neighboring elements predictably, minimally and often in the exact way that I actually want).
gg-charts is pretty close in some respects, but still feels a bit more clunky to me, because the "move element" function gives less direct feedback, and in some cases complicates the layout more than I feel necessary.
> It has the best "move element" behavior of any diagramming tool I've ever encountered (it shifts neighboring elements predictably, minimally and often in the exact way that I actually want).
Thanks for calling attention to this. You are right. Drakon does that incredibly well!
Is there a text format for this? I’d be interested in seeing if we can generate these from trace data the way that we do for sequence diagrams and flow charts.
Thanks for sharing your work. I too have the problems you’re attempting to address. Makes me think of LabView (which I would recommend checking out for inspiration if you’re unaware of it).
The love-hate relationship with LabVIEW is something I can not get closure about : great tool, abysmal ergonmics, revolutionnary piece of software, ubiquitous in some fields and still some LabVIEW ergonomics is just SO...bad : want to zoom on your diagram ? Out of luck !
Heard of death by a thousand cuts ? LabVIEW comes to mind.
This is pretty cool. I’ll definitely be following the development of this. I was just starting to look at how something similar could be done using mermaid.js or plantuml.
Wow, this looks very interesting. I saw the diagram of your own application and it looks more dynamic than the ones that I am generally used to at work.
I am curious about the motivation behind this project. What experiences triggered you to think that static diagrams are a problem?
Your answer will help me decide whether I'd like to use it for my own documentation or not.
I decided to work on gg because I want my colleagues to grok our complex software architecture, and I don't feel like I am able to achieve that with textual documentation + static diagrams alone.
I have been in a lot of brainstorming sessions drawing boxes and arrows on a whiteboard. I have produced a lot of diagrams with mermaid, draw.io, miro, etc. I produced a lot of documentation to explain how the software is built. Those are all good tools to get everyone on the same page, and yet, I feel like there is a missing piece of the puzzle to explain a software architecture simply and concisely that even the new junior developer recruit will understand.
I thought about extending mermaid's flowcharts instead of starting from scratch.
No particular reason I did not go that route, mostly "to do my own thing".
Wow, I'm glad that I visited HN when your tool was at the top. I'm going to use it to illustrate docs on our internal DAG-like system. By the way, is there a simple way to export the animated diagram as a GIF?
I'm working on supporting webm first, as I am close to have a working feature using the MediaRecorder API of the browser. Exporting to gif will come after that, as it can be done by third-party tools as a workaround in the meantime (i.e. webm to gif).
The site doesn't work, I've tried reaching it from Amsterdam, Netherlands.
First it raises an issue with the certificate, then it's blocked by the ISP. Very strange.
In case any of you use draw.io note that you can animate lines with a right click. Last time I did this for a presentation I did have to record to gif but it worked really well.
There is currently a bug in the app that let someone inject a JS snippet to execute (to confirm) in the URL "file" property. The app then save the content of that "file" property in the local storage, so every time you open https://gg-charts.com, it loads this data from local storage and re-execute the JS snippet.
I'll fix that today, sorry for the inconvenience. :-/ The web is the far west!
There is no plan yet to support importers directly in gg but the graphs produced with gg have a YAML/JSON representation under the hood so producing a "draw.io to gg" importer is feasible.
My algorithm to detect / resolve collisions has a bug in it. In some cases, a system will be displaced on the right, then on the left, then on the right... until it reaches a maximum number of allowed displacements. When it happens, moving a system feels very slow.
I intend to fix that bug (eh!) and I'm also thinking about moving this costly algorithm in web workers (+ parallelize it).
I'll create an issue to support exporting the animation in v1.
Any particular reason for APNG vs GIF?
The animation in the README.md was captured with the MediaRecorder API.
It produced a webm that I "cropped -> clipped -> to gif" manually.
I am not that far to produce a looping webm that is perfectly cropped & clipped.
I may release that first, and then tackle gif / apng / ??? later.
GIFs support only 256 colors while APNG supports millions of colors and does have multi-browser support now. PNGs are also inherently high quality and don't pixelate like lossy image formats - GIF, JPG etc.
I think the core concept is flawed, though. "Animated diagrams" are great for generating engagement on social media, but in practice an animated line doesn't tell you anything an arrow wouldn't. They just become a distraction. Plus, they make it harder to read a label on the line (and "real" diagrams should have those).
Someone submitted an issue on Github to add labels on links (i.e. lines) and I think it's a great idea for a v1. In my mind, the animations won't get in the way of reading the labels, but implementation will tell! I will also probably implement them like I implemented titles on systems, which is to avoid routing links over them.
> "Animated diagrams" are great for generating engagement on social media, but in practice an animated line doesn't tell you anything an arrow wouldn't.
Instead of showing a little green box moving from system A to system B, I could have shown static arrows alongside the link between system A to system B, or something similar.
I chose the moving green box as it represents the data flowing in the system, in a tangible / concrete manner.
It communicates:
- A data is created/produced/etc. at system A.
- The data is transferred/copied/moved/etc. to the system B.
- The data is received/consumed/etc. by the system B.
Such a wrong take. An animated line instantly brings you focus, and remove any guess work, and unease, when analysing a complex system.
And in this example , allow you to instatly replay part of the system in your head.
Keep working in the direction.
If you replace the moving green boxes with arrows, you get the same information (specifically, flow direction). And if the goal is to show the order/steps, then the right tool for the job is a sequence diagram [0]. Again, the animations are good for getting attention, but otherwise this is re-inventing the square wheel.
The animations turn these diagrams into hybrid between basic box-and-arrows diagrams and sequence diagrams, because the animations capture the temporal relationship between actions. They certainly can not be naively substituted with static arrows without loss of information.
I know you said you prefer the GUI over text-based, but that was the exact thing I wanted to ask for after trying your demo. GUI just doesn’t scale like text does. How will you be able to generate a diagram from code or a running process unless you have some intermediate textual representation? I assume you do anyways, at least implicitly, to save the state of your GUI’s output. You should bring that into focus. The GUI editor is simply a nonstarter for me. How do you compare the difference between two diagrams?
IMO the editing/sharing/maintenance experience of Mermaid’s sequence diagrams is nicer. What is your opinion on sequence diagrams in general? I much prefer their static nature and directional flow over animations you have to wait for when you need to review a detail you missed, and the top/down direction is better than trying to track points moving around in arbitrary directions.
> I assume you do anyways, at least implicitly, to save the state of your GUI’s output. You should bring that into focus.
Indeed, I do have a YAML / JSON representation under the hood, which is validated by JSON Schema. In the app, you can click on "file > yaml editor" to access it.
I thought about having a mermaid-like syntax on top of my YAML representation but before adding this, I need to have a proper "auto-layout" feature.
Currently, the editor is responsible to detect collisions between systems and to "space them out" until no collisions are found.
I need to bring that responsibility back to the core library instead of the editor, as right now, the core library only accept systems without collisions to resolve.
TL;DR: it's feasible and I'm open to the idea!
> What is your opinion on sequence diagrams in general?
I like them in small bites, i.e. with few participants and presenting one simple flow.
They do become daunting (for me) to read and maintain with more participants and complex flows.
I like to sprinkle them in my documentations.
In mermaid, I find myself bouncing from "flow diagrams" to "sequence diagrams" all the time.
> over animations you have to wait for when you need to review a detail you missed
I'm currently working on a "viewer mode" / "presentation mode" as I don't want this continuous playback loop to become the default way to present a flow in a system.
This continuous playback is useful as an overview of a flow but not to present it to an audience or to embed in a technical documentation.
I want to be able to present a flow, step by step, as if it was a slideshow.
Thanks for the responses! Honestly I wouldn’t hate just using YAML to edit these. Great points otherwise. I didn’t see in the demo, but if I could scrub back/forth through the animation, that would be really nice. Good luck on the project!
I love it, but I can't help but wonder why I almost never see complete or up to date diagrams in an enterprise or at scale software engineering setting, despite there being so many tools in this space (mermaid, uml, draw.io, graphviz, etc). I wonder what the barrier is or how to make tools like this fundamentally different so that we would see more adoption.
This comes up frequently in the context of secure design review, or more generally when outside stakeholders need to understand a foreign system.
Nobody argues against diagrams as good practice, but so few actually make them. That tells me incentives/costs are still off, despite good intent.
Information extraction from design docs could be one approach to suggest a diagram for free but that creates a dependency on the fidelity of the design document.
> why I almost never see complete
That's a huge scope question on its own. What's "complete"? How low level or wide do you go? What about the view of internals of the external systems you rely on? What about their mapping to teams/owners? C4 helps a bit here by saying "whole organisation throws everything possible into this and when you want to see it, you use scoped views instead".
> or up to date diagrams
"When exactly does the system change" is tricky too. When you change the code? When you enable the new system? Who knows that the diagram of the system exists and where? It's a bit of an issue of unknown unknowns. Again, the C4 idea helps here a bit, but there are still going to be random projections of state at a given time saved in various places.
Another big issue is that structure and presentation are very different. Generated diagrams of infrastructure or code look shit, universally. On the other hand, well presented diagrams are just snapshots in time that get preserved for years even if their outdated. I mean this is what C4 page shows as one of their results https://c4model.com/img/alternative-1.png which is an unreadable mess and this is what they initially complain about https://c4model.com/img/sketch-2.jpg which is perfectly sized and context specific goodness. The first is good for knowledge preservation, but if anyone needs to understand things, I'm making the second one for them.
In my dreams, you have docs and source code in the same repo, and update both in a single pull request. In reality, confluence...
I've lived this life first-hand, and it is refreshing after experiencing the vast open sea of half-assed Confluence sprawl, huge PDF design documents that aren't kept up to date with changing requirements, etc.
The other sibling comment regarding rendering documentation source to Confluence or <required external system> to keep the corp overlords happy is a great middle ground IMO.
Merely as a "for your consideration," if you already have a build pipeline, rendering the in-repo docs and pushing them into Confluence could be a middle ground between "corporate overlords" and the workflow that works best for you and your team
I tried to solve this after years of frustration, but it's a complex task, especially that "complete" means there is a lot of noise in the diagrams. Plus the data gathering is an immense task, not everything is in the repo even with world class terraform, you have to connect to external sources.
https://github.com/specfy/specfy
My take is that it's a bit worse than that: the whole doc tooling scene is a dumpster fire. I want to maintain technical documentation under revision control (same revision control system as I use for source code), and I want to be able to embed diagrams in said documents (also under revision control) and I want to wysiwyg edit those things. Amazingly in 2024 this does not exist.
> I want to maintain technical documentation under revision control
This kind of effort is sabotaged at every place I've ever worked, usually because product or leadership insists that it moves to confluence, and then predictably this increases friction and no one ever updates those diagrams again. People with "20 years experience in industry" can't be bothered login to github, and in the best case instead of confluence they want lucidchart, where inevitably the whole org is sharing like 3 seats.
Partly this is just laziness or ignorance, but partly it's deliberate overreach into engineering business because there's lots of people who see actual information as a threat to to their preferred narratives (think hype/sales promises/etc). Plus you can't say that you didn't know about a design flaw if there is 6 month old diagram calling out the need for a solution in big red letters. Since a picture is worth a 1000 words, and since a git hash can get a date attached to it, dead-on-arrival docs/diagrams tends to decrease accountability.
Jetbrains' recent WriterSide tool is a great addition into this space. It's not exactly wysiwyg, it's side-by-side live preview with different source languages (right now, markdown and some xml language are supported, but they want to support more popular doc languages).
It allows you to specify definitions in one location, and reference them in other pages. So if you have for example a documentation page which is about "installing our nodejs package", you can write a version in vars.json or vars.xml or whatever, and reference it in your installation documentation page.
When you later have another page which is saying "Hey, we found a bit of an issue with ...this-or-that... package because we're using $NODE_VERSION, and the package hasn't been updated so we have ...such-and-so... workaround", you know when you update the $NODE_VERSION in your vars, that you need to take a look at that package again.
It's an extremely basic part of software development, being able to define variables, but I think this is a very good sign of powerful documentation tooling.
The only major downside about the platform is that their XML (HTML) extensions to markdown are proprietary, and as such the platform isn't able to grow outside of Jetbrains' oversight. I'm still debating whether I want to switch from Gitlab's Wiki (which is very basic but is really really easy to edit for anyone on the team) to a solution like Jetbrains' Writerside.
I think this captures the sentiment I have been seeing and feeling myself. Docs and diagrams die because they aren't code. When the code changes, the docs are left behind.
What is interesting here is that mermaid and graphviz could be committed to source control, but I have never seen it done anywhere likely because the burden of drawing/updating is still too high (hence your wysiwyg comment).
I helped implement Mermaid as a part of Apollo GraphQL’s public documentation to address the “docs as versioned artifact with code” challenge. It’s a win, but still another Yak to shave since public docs are a product, not the source code for the internal teams’ use.
Have you taken a look at swimm.io? Been curious about it for a while now but not a fan of the friction to demo it.
Org files with embedded PlantUML blocks get close to what you want.
Who is using this? I have only seen plantuml written about on blogs, never actually in use.
I’ve used it for a long time; even if I don’t end up sharing with others it can help me quickly visualize things (the ease of change often makes better than pen and paper). At one of my jobs we had an architect join and he was amazing; I really respected him. He used PlantUML and would open it up and start writing sequence diagrams with us. He would make sure complex flows that were actively being implemented were kept up to date and they were useful references.
If you want to understand the underlying problem, think about geographical mapping (e.g. Google Maps). When drawing a map, how do you decide what gets featured? Roads, businesses? How big can the text be? How do you keep it all readable?
Diagramming is the same problem, but usually lacking the context to decide what to draw. The same stakeholders may be interested in different combinations of features depending on which business questions they're trying to answer. Geographic mapping is practically a constrained domain by comparison. And it's supposed to be feasible to do it automatically for systems diagrams? /hard-skeptic
I understand the argument but think this is a straw man based on my experience. The issue isn't so much that people can't decide on the level of detail, it's that the diagram is drawn only once or in most cases never.
A dataflow diagram for example is mostly self constraining in scope.
Automating it is another problem entirely and I agree it has a lot of hard challenges.
Honestly, I think you are using free (and old) diagramming tools, and you are getting why you pay for. There are plenty of tools designed specifically for documenting large systems, but they cost money.
Which ones are those? Who is using them? I don't limit this discussion to free tools, the list I gave happens to include some well known free things.
This is pretty nice! Really like the choices for the Keyboard shortcuts and how they are presented.
My favorite tool for creating diagrams so far is still Drakon (try in browser: https://drakonhub.com/start-drakon).
It has the best "move element" behavior of any diagramming tool I've ever encountered (it shifts neighboring elements predictably, minimally and often in the exact way that I actually want).
gg-charts is pretty close in some respects, but still feels a bit more clunky to me, because the "move element" function gives less direct feedback, and in some cases complicates the layout more than I feel necessary.
That's pretty nice that we can now do that in a browser!
I was also surprised diagrams are exportable to json. Yet, it does contain (x, y) coordinates, making that json impossible to write by hand.
If drakon had a a more human friendly and git friendly format (at least json is more git friendly), I'd gladly use it much more often!
> It has the best "move element" behavior of any diagramming tool I've ever encountered (it shifts neighboring elements predictably, minimally and often in the exact way that I actually want).
Thanks for calling attention to this. You are right. Drakon does that incredibly well!
Love this. Would love to be able to: a) Pause b) Step through the individual steps (I see they're titled) c) Go back / Forward to grokk better
Yes, me too :) I am working on a viewer / presentation mode that will do just that.
Wishlist: Plug into existing tracing systems. Meaning if I use Datadog, I could use this to map my environment if I have tracing enabled.
Is there a text format for this? I’d be interested in seeing if we can generate these from trace data the way that we do for sequence diagrams and flow charts.
https://appmap.io/docs/reference/navie.html#diagram
https://gg-charts.com/#=&file=eJyVksFSgzAQhu88xQ4X9FBa2jodkT...
For those reading this, do not click on that link above. It executes a script that renders the app unusable until you clear your local storage.
Thanks for the report, I'll fix that.
Fixed in production!
Thanks for sharing your work. I too have the problems you’re attempting to address. Makes me think of LabView (which I would recommend checking out for inspiration if you’re unaware of it).
The love-hate relationship with LabVIEW is something I can not get closure about : great tool, abysmal ergonmics, revolutionnary piece of software, ubiquitous in some fields and still some LabVIEW ergonomics is just SO...bad : want to zoom on your diagram ? Out of luck !
Heard of death by a thousand cuts ? LabVIEW comes to mind.
This is pretty cool. I’ll definitely be following the development of this. I was just starting to look at how something similar could be done using mermaid.js or plantuml.
Wow, this looks very interesting. I saw the diagram of your own application and it looks more dynamic than the ones that I am generally used to at work.
I am curious about the motivation behind this project. What experiences triggered you to think that static diagrams are a problem?
Your answer will help me decide whether I'd like to use it for my own documentation or not.
Thank you for your comment!
I decided to work on gg because I want my colleagues to grok our complex software architecture, and I don't feel like I am able to achieve that with textual documentation + static diagrams alone.
I have been in a lot of brainstorming sessions drawing boxes and arrows on a whiteboard. I have produced a lot of diagrams with mermaid, draw.io, miro, etc. I produced a lot of documentation to explain how the software is built. Those are all good tools to get everyone on the same page, and yet, I feel like there is a missing piece of the puzzle to explain a software architecture simply and concisely that even the new junior developer recruit will understand.
This is really great. However, I’d prefer this as a layer on top of an existing graphing library / syntax.
I thought about extending mermaid's flowcharts instead of starting from scratch. No particular reason I did not go that route, mostly "to do my own thing".
Reminds me of this old project..
https://netflixtechblog.com/vizceral-open-source-acc0c32113f...
I wish ^ were still alive. It was very cool and way ahead of its time.
Wow, I'm glad that I visited HN when your tool was at the top. I'm going to use it to illustrate docs on our internal DAG-like system. By the way, is there a simple way to export the animated diagram as a GIF?
Thank you for your comment :)
I'm working on supporting webm first, as I am close to have a working feature using the MediaRecorder API of the browser. Exporting to gif will come after that, as it can be done by third-party tools as a workaround in the meantime (i.e. webm to gif).
The site doesn't work, I've tried reaching it from Amsterdam, Netherlands. First it raises an issue with the certificate, then it's blocked by the ISP. Very strange.
In case any of you use draw.io note that you can animate lines with a right click. Last time I did this for a presentation I did have to record to gif but it worked really well.
When going to https://gg-charts.com all I got is a popup of 1 and displayed Hacked by NSF instead.
Try cleaning your browser local storage for https://gg-charts.com.
There is currently a bug in the app that let someone inject a JS snippet to execute (to confirm) in the URL "file" property. The app then save the content of that "file" property in the local storage, so every time you open https://gg-charts.com, it loads this data from local storage and re-execute the JS snippet.
I'll fix that today, sorry for the inconvenience. :-/ The web is the far west!
I fixed the issue, you can reload the page!
I really liked the UI and the ease with which diagrams can be created.Will it be possible to import diagrams from other tools like draw.io here.
I think it is a great idea!
There is no plan yet to support importers directly in gg but the graphs produced with gg have a YAML/JSON representation under the hood so producing a "draw.io to gg" importer is feasible.
As the author of that original Redux docs tutorial and data flow graph, happy to see it being used as an example here :)
Very cool! Love how the links rearrange themselves when you move a node.
My laptop screamed after I played around in the redux demo. Must be something like infinite loop.
My algorithm to detect / resolve collisions has a bug in it. In some cases, a system will be displaced on the right, then on the left, then on the right... until it reaches a maximum number of allowed displacements. When it happens, moving a system feels very slow.
I intend to fix that bug (eh!) and I'm also thinking about moving this costly algorithm in web workers (+ parallelize it).
Thanks for this! I love how minimal and intuitive it is.
Feature request - ability to export to Animated PNG!
I'll create an issue to support exporting the animation in v1. Any particular reason for APNG vs GIF?
The animation in the README.md was captured with the MediaRecorder API. It produced a webm that I "cropped -> clipped -> to gif" manually. I am not that far to produce a looping webm that is perfectly cropped & clipped. I may release that first, and then tackle gif / apng / ??? later.
> Any particular reason for APNG vs GIF?
GIFs support only 256 colors while APNG supports millions of colors and does have multi-browser support now. PNGs are also inherently high quality and don't pixelate like lossy image formats - GIF, JPG etc.
I'd love to see more demos
Congrats on the launch. Looks very clean.
I think the core concept is flawed, though. "Animated diagrams" are great for generating engagement on social media, but in practice an animated line doesn't tell you anything an arrow wouldn't. They just become a distraction. Plus, they make it harder to read a label on the line (and "real" diagrams should have those).
Someone submitted an issue on Github to add labels on links (i.e. lines) and I think it's a great idea for a v1. In my mind, the animations won't get in the way of reading the labels, but implementation will tell! I will also probably implement them like I implemented titles on systems, which is to avoid routing links over them.
> "Animated diagrams" are great for generating engagement on social media, but in practice an animated line doesn't tell you anything an arrow wouldn't.
Instead of showing a little green box moving from system A to system B, I could have shown static arrows alongside the link between system A to system B, or something similar.
I chose the moving green box as it represents the data flowing in the system, in a tangible / concrete manner.
It communicates:
- A data is created/produced/etc. at system A.
- The data is transferred/copied/moved/etc. to the system B.
- The data is received/consumed/etc. by the system B.
Such a wrong take. An animated line instantly brings you focus, and remove any guess work, and unease, when analysing a complex system. And in this example , allow you to instatly replay part of the system in your head. Keep working in the direction.
If you replace the moving green boxes with arrows, you get the same information (specifically, flow direction). And if the goal is to show the order/steps, then the right tool for the job is a sequence diagram [0]. Again, the animations are good for getting attention, but otherwise this is re-inventing the square wheel.
[0] https://en.wikipedia.org/wiki/Sequence_diagram
The animations turn these diagrams into hybrid between basic box-and-arrows diagrams and sequence diagrams, because the animations capture the temporal relationship between actions. They certainly can not be naively substituted with static arrows without loss of information.
As noted below, the right tool for that is a sequence diagram [0]. These can be static images and read at one's own pace.
[0] https://en.wikipedia.org/wiki/Sequence_diagram
I know you said you prefer the GUI over text-based, but that was the exact thing I wanted to ask for after trying your demo. GUI just doesn’t scale like text does. How will you be able to generate a diagram from code or a running process unless you have some intermediate textual representation? I assume you do anyways, at least implicitly, to save the state of your GUI’s output. You should bring that into focus. The GUI editor is simply a nonstarter for me. How do you compare the difference between two diagrams?
IMO the editing/sharing/maintenance experience of Mermaid’s sequence diagrams is nicer. What is your opinion on sequence diagrams in general? I much prefer their static nature and directional flow over animations you have to wait for when you need to review a detail you missed, and the top/down direction is better than trying to track points moving around in arbitrary directions.
> I assume you do anyways, at least implicitly, to save the state of your GUI’s output. You should bring that into focus.
Indeed, I do have a YAML / JSON representation under the hood, which is validated by JSON Schema. In the app, you can click on "file > yaml editor" to access it.
I thought about having a mermaid-like syntax on top of my YAML representation but before adding this, I need to have a proper "auto-layout" feature. Currently, the editor is responsible to detect collisions between systems and to "space them out" until no collisions are found. I need to bring that responsibility back to the core library instead of the editor, as right now, the core library only accept systems without collisions to resolve. TL;DR: it's feasible and I'm open to the idea!
> What is your opinion on sequence diagrams in general?
I like them in small bites, i.e. with few participants and presenting one simple flow. They do become daunting (for me) to read and maintain with more participants and complex flows. I like to sprinkle them in my documentations. In mermaid, I find myself bouncing from "flow diagrams" to "sequence diagrams" all the time.
> over animations you have to wait for when you need to review a detail you missed
I'm currently working on a "viewer mode" / "presentation mode" as I don't want this continuous playback loop to become the default way to present a flow in a system. This continuous playback is useful as an overview of a flow but not to present it to an audience or to embed in a technical documentation. I want to be able to present a flow, step by step, as if it was a slideshow.
Thanks for the responses! Honestly I wouldn’t hate just using YAML to edit these. Great points otherwise. I didn’t see in the demo, but if I could scrub back/forth through the animation, that would be really nice. Good luck on the project!
Super cool. Huge potential.
Thank you! :)