With 30+ years of software interaction design (since 512 x 342, for those in the know), I’ve always been interested in applying a more systems-oriented approach to problems when applicable – looking at how elements connect rather than optimizing components in isolation.
As I built the **Docsify-This.net** project, that same mindset informs both how the Web app works and relates to users
Revisiting Donella Meadows’ Thinking in Systems recently, I realized how closely the project aligns with her principles. Here’s the connection 👇🏼
Traditional publishing tools structure content as a pipeline: write → upload → format → publish → maintain server. That structure creates predictable behavior – content confined to single platforms, content duplication, and the "walled garden" effect.
Docsify-This changes the structure to a reference-by-address (or as Ted Nelson fans may phrase it, a primitive form of ‘Transclusion’ behavior):
✅ Your Markdown stays in GitHub/Codeberg (the stock)
✅ Docsify-This acts as a transformation layer (the flow)
✅ Content is referenced, not uploaded
This shift produces different behavior: exit becomes frictionless, single-source publishing becomes automatic, and version control becomes editorial workflow.
Meadows identified feedback loops as system engines. Docsify-This installs two critical ones:
The "Edit This Page" Loop
Reader finds issue → clicks to source → proposes changes to Markdown → content improves → next reader benefits. This turns passive consumption into active stewardship without central coordination.
The Visual Feedback Loop
Adjust &font-size=36px → see immediate change. Shortening the delay between action and result helps users understand they’re manipulating a system, not just filling out a form.
Meadows catalogued leverage points – places where small shifts create big changes. Instead of burying styling control in server access and CSS files, Docsify-This puts it in the URL bar:
→ Change &link-color to rebrand instantly
→ Add &sidebar to enhance page navigation