[dboreham]

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.

[photonthug]

> 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.

[azeirah]

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.

[beardedwizard]

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).

[iamthefury]

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.

[leonseled]

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.

[hcarvalhoalves]

Org files with embedded PlantUML blocks get close to what you want.

[beardedwizard]

Who is using this? I have only seen plantuml written about on blogs, never actually in use.

[chausen]

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.