flowweaver · Philosophy
Editors were expected to adapt to the software
The background
Johan Furuskog
Developer, and the person behind Flowweaver
I have spent years building things that editors then have to use. What follows is not an opinion I arrived at at a desk — it is the pattern I watched come back, job after job, until I finally did something about it. Flowweaver is what came of that.
Why this exists
After years of building solutions for editors and content teams, one pattern kept returning. The editor was the one who had to change.
They learned the developer's words for things they already understood. They filled in fields that mirrored a database rather than their work. They were careful with the tool instead of confident in it — and being careful is expensive: it means changes that should take an afternoon wait for someone who is not afraid of the system.
None of that is a technical problem. It is a decision, taken early and usually without noticing, to build around what the technology finds convenient. Flowweaver is an attempt to take the decision the other way round and see how far it goes.
Editors first. Then features that make it easy to do the right thing. So that you feel safe editing a flow.
That order is the whole argument. Safety is not a feature you add at the end — it is what is left over when the right thing is the easy thing, and when the tool says what it is doing instead of leaving you to find out.
The principles, and what makes each one true
A principle nobody can point at is a slogan. Each one below is followed by the thing in the product that makes it true — something you can open and check.
-
Editors first
Every decision starts with does this help editors?, not can the technology support this?
What makes it true
The tool's language and the guide's language are separate settings. An English-speaking editor translates a guide into Arabic with the interface in English — so a municipality can offer a guide in Somali without waiting for anyone to translate a palette.
-
Transparency over surprises
You should always know where you are, why something happened, what changed and what still needs attention.
What makes it true
This guide has not been translated into Finnish. It is shown in Swedish.
The fallback was always there. Saying it out loud is the principle.
-
Confidence instead of fear
Nobody should be afraid of changing content. Experimenting has to feel safe.
What makes it true
Translation mode does not report a percentage and leave you guessing. Untranslated steps are marked on the canvas, a button jumps between them, and the count is measured against what this guide can actually show — an eight-step guide is not told that fifty-odd things remain.
-
Easy to do the right thing
The interface should lead towards good decisions and make mistakes harder, not easier.
What makes it true
No
modeattribute is set, so the editor is read-only. Nothing in the guide can be changed. That is the intended default — setmodefrom your own permission system when a user may edit.Every check says what is wrong and what it leads to. The second half is the part that helps.
-
Respect the visitor's time
Do not ask for information without a clear reason. Every question costs the visitor time and attention. It has to be possible to explain why the answer is needed — to change the path through the guide, to carry out what the visitor is trying to do, or because the recipient needs the information afterwards.
If the page already knows something that can be used in a way that makes sense, the visitor should not have to type it in again.
What makes it true
The guide asks a question when it needs the answer and skips it when it does not — the guide's own rules decide, not a fixed form. And a page that already knows something about the person reading can hand it over to the guide, so the question is never asked. What a visitor is spared filling in is therefore a decision you make, not one the tool makes for you.
The promises, and what would break them
The start page lists what you get. This section says something else: what we have bound ourselves to, and what would make it untrue. A property describes how things look today; a commitment says something about tomorrow, and only the latter is something anyone can weigh in a decision.
- A file you saved yesterday has to open tomorrow. An older format is read and brought forward; anything you put in the file yourself that we do not recognise is kept rather than quietly dropped. The promise covers every version to come, not only the one in front of you — otherwise it would be luck rather than safety.
- Your details never leave your systems. There is no place at our end for anything to be sent to, and the commitment is not to build one. Where the answers go is your decision, inside your own systems, exactly as with every other piece of content you publish.
- Starting needs neither an account nor a key. No registration with us, nothing to keep valid, nobody who can switch you off. An account is the first step in every lock-in ever built, and that step is not taken here.
This is not a feature list, because a feature can be removed on a Friday. Three changes would make the promises untrue, and none of them is a feature:
- A login required to get started.
- A store the guide cannot leave.
- A file format only our own tools can read.
Each of those would change what the product is, rather than add something to it. If one is ever proposed it has to be argued as exactly that, in the open — not slipped into a release. Flowweaver must never become the thing it exists to spare you.
The test is a single question, and somebody has to keep asking it: can a customer walk away with what they built, and use it with something that is not ours? Today the answer is yes. It stays an answer only as long as the question is asked.
Languages are three things, not one
This is the sharpest difference and the least obvious. Most tools have one language setting. Flowweaver has three, and they move independently.
| Setting | Whose | For example |
|---|---|---|
| The tool's language | the host system's | the palette and menus in English |
| The guide's content | the editor's and translator's | the questions in Arabic |
| Which languages are offered | the host's | Swedish, English, Finnish, Somali |
Translating the content into a language must never require the tool to be translated into the same language.
It matters because of who it is for. A Swedish municipality in a Finnish administrative area may be obliged to offer a service in Finnish. Under a one-setting model, that means somebody has to translate the editor first. Here it means a translator opens the guide and starts writing.
You can watch all three move on the languages page, which runs the real calls and prints what they returned.
What we decided not to build
A roadmap says what we intend to do. This says how we think, which is usually more useful.
- A mirrored canvas for right-to-left languages. The flow could be flipped when the content is Arabic. It is not, because the canvas belongs to the tool and the tool exists in Swedish and English — letting the content decide how the tool is laid out is the coupling the three settings above remove. The text inside a node does read right to left. Whether the canvas should mirror is a question for people who read that way, and it stays open until one of them answers it.
- Translating the names of shared templates. A template an administrator named is their organisation's vocabulary. Asking them for an English version of their own words would put the work on the wrong person, so the names stay as they were typed. The ones that ship with the tool are ours, and are translated.
- Defensive machinery for problems nobody has had. The string keys were renamed while nothing was in production, without a migration, because there was no data to protect. Doing it properly after launch is written down. Building it before there was anything to migrate would have been work for its own sake.
Where this is heading
A list of what will be built ages in a quarter. The direction does not, and of the two it is the only one you can weigh in a decision.
It began as an editor for guides. The same engine should carry e-services with more fields, conditions and connections to systems you already run — and the editor is built so that it will not have to be made again when that step comes. That is why some of it looks overbuilt for a guide with four questions: it was not built for that one.
What gets built first follows from where the value sits. Showing a finished guide is a solved problem. The hard part, and the only part worth anything, is that an editor with no technical knowledge can build a correct decision flow without writing code — so work that makes an editor's day clearer comes before work that makes a page prettier. The visitor's side still has one hard requirement: small, accessible and able to stand alone, because it is the only part a visitor actually downloads.
The aim is to be the easiest way to build guidance people can trust, whatever publishing system you run.
Something that connects to systems you already have rather than replacing them — SiteVision today, others later — and that stays when everything around it is swapped out. A tool you keep through a platform procurement is a different kind of tool from one you replace along with it.