Show HN: Splotch – Turn written workflows into live diagrams (splotch.ink)
Human memory and sense-making is visual and sequential. Stories and maps are sticky because they put information in context. We do sometimes use diagrams to show important processes because–unlike a text summary (especially LLM-generated summaries)--a diagram makes it easy to see the relationship between the steps.
AI needs context windows. Humans need context maps: diagrams. We identified four things that could turn text into useful diagrams. These became our product requirements:
WHAT THE TOOL DOES 1. Detect processes described in text. Not everything needs to be diagrammed. What’s the “skeleton” of the plan or process? 2. Auto-generate a diagram that’s close to the text description. Represent the core components as nodes, and link each node to its corresponding source text. 3. Keep the source text and diagram in sync. Most diagrams go “stale” quickly. “Live” diagrams stay current by linking each node to a snippet of text in a source doc. (Surprisingly, this didn’t exist until now!) 4. Edit, iterate and develop the diagram. Assume the process will evolve. Every change to one side (text or diagram) should cause a corresponding change on the other side.
BUILDING IT Even when we started building last January, LLMs could output decent diagrams out of the box. But they were static, and we had to carefully examine both sides to figure out if the diagram was accurate.
It wasn’t too hard to make the diagram editable, but once we made some manual edits (added and reorganized a few nodes) we ran into a big challenge: every AI edit changed the entire structure of the diagram so it was unrecognizable. Any manual changes were effectively lost.
Was it possible to give users both AI editing and fine-grained manual controls? It was kind of like going back and forth between a WYSIWYG editor and HTML. The LLM just overrides manual work, like an editor overrides HTML.
After months of experiments, we developed a protocol to translate text from the LLM into a data model that could be displayed in text or visual formats and an index that keeps the two views linked through iteration cycles.
GRAPHS ARE HARD THO We still had a big, hairy problem: laying it all out. The LLM can parse the meaning of the input text, but then we need a graphing algorithm to arrange the nodes, determine spacing and draw the connections in a simple, human-readable way. LLMs are not equipped to deal with this kind of problem for visual output–especially when the output is changing over time. The diagrams were a mess.
We started with Graphviz, but it got overwhelmed quickly. ReactFlow had good manual controls, but it didn’t offer a layout engine that could digest the LLM output. Mermaid and D3 had good layout algorithms, but they couldn’t handle manual editing.
We spent the summer banging our heads against a wall churning through graphing engines. There’s a reason many PhD dissertations explore graph problems! Then we found YFiles. These folks have solved some really hard graphing problems and built a library that makes those capabilities usable. Unlike the graph tools above, they mostly serve enterprise customers with complex use cases–just what we needed to turn unpredictable LLM output into useful diagrams. With Yfiles, the final piece fell into place.
FEEDBACK What do you want to do with it? We've plans for swimlanes and a bunch of embedded data so every graph shows the right level of detail. What would be useful?
1 comment
[ 777 ms ] story [ 298 ms ] threadWhat would be super cool is if it could read design docs or better yet system architecture (idk not an engineer) to show how data flows in and out of systems. Rules and logic that apply to the data. How it’s transformed as it moves in and out of systems, etc..