This post is not meant as criticism of any existing tool.
LeafWiki itself is still in active development, and I’m sure I’ll eventually run into UX issues in my own project too — that’s normal.
But I want to describe the real workflow pains I experienced while using other wiki tools like Wiki.js, Confluence, and similar systems.
These small frictions kept interrupting my writing flow, and over time they motivated me to build LeafWiki as a simpler alternative for developers and teams.
I’m actively improving the UI and UX, and there are still things I want to polish — but the core philosophy stays the same:
- Simple to run: No container, no database, just Go
- Simple to host: You know where your data is
- Simple to trust: Markdown is portable & future-proof
I chose Go specifically to keep LeafWiki a single, fast binary with no external dependencies.
Your knowledge shouldn’t belong to a database you maintain — it should belong to you.
1. I wanted to paste screenshots directly into the editor (Ctrl+V)
In the wikis I used before, adding a screenshot felt like a mini project:
- Take screenshot
- Open upload dialog
- Choose the correct folder
- Upload the file
- Click the uploaded item to insert it into the page
Every time I tried to quickly document something, this tiny workflow broke my flow.
What I really wanted was the natural workflow developers use everywhere else:
Screenshot → Ctrl+V → done.
So in LeafWiki, pasting images directly into the Markdown editor automatically uploads them and inserts the correct Markdown link — with no dialogs and no mental friction.
Just write.
2. I kept having to choose folders just to upload the right file
Another small thing that slowed me down:
Before I could upload a file, I had to select a folder.
Yes, technically that makes sense - but on the user level, it felt unnatural.
My brain doesn’t think in terms of asset location. I write documentation and the asset should be part of the page. I think:
This file belongs to this page.
Not:
Let me browse to the correct folder for this file…
So LeafWiki stores assets per page.
If you upload an image while writing, it’s automatically attached to that page.
No folder selecting. No searching. No extra decisions.
3. I wanted to create pages directly in the tree where I’m thinking
This one bothered me more than it should:
I’d see exactly where a new page belongs in the structure - but to create it, I had to go somewhere else, usually a top-level menu.
That disconnect always broke my flow.
I also didn’t want to think about slugs during the creative flow.
Yes, I sometimes need to adjust slugs later, but that’s not the usual writing moment. (Of course changing slug is possible in LeafWiki.)
So LeafWiki lets you:
- create pages directly in the tree
- create pages from non-existing links
- create pages from the 404 view
- insert structure while thinking in structure
The wiki should adapt to how you think, not the other way around.
Why these small things matter
None of these issues are “big”.
They’re small, almost invisible UX friction points.
But they add up.
If you document things all day, these little interruptions make the tool feel heavy, slow, and mentally expensive.
LeafWiki tries to remove these tiny friction points:
- Paste-to-upload (no dialogs)
- Per-page assets
- Structure where you think
- Markdown editor
- A single Go binary — easy to host, easy to trust
If that sounds interesting, you can try it here:
👉 Demo: https://demo.leafwiki.com
👉 GitHub: https://github.com/perber/leafwiki
Feedback, ideas, and discussions are always welcome
Top comments (0)