This is a marker, not a plan. Nothing has been investigated yet; this issue exists so the work is not forgotten and so the shape of it is agreed before anyone starts.
What we want to do
Go through the keyboards people actually use, feature by feature, and find out what they have that Dictate does not — then decide, for each finding, whether it is something we need, something we have an equivalent of already, or something we are deliberately not doing.
Dictate grew from the dictation side inwards: voice first, then a full typing keyboard around it. That means the typing half has been built where issues pointed rather than against a checklist, and it is worth checking once, systematically, what a long-standing keyboard offers that we never thought about — the small conveniences people bring with them from their previous keyboard and quietly miss.
Which keyboards
At minimum: Gboard, Microsoft SwiftKey, Samsung Keyboard, HeliBoard, FUTO Keyboard, Fleksy, Grammarly Keyboard, Typewise. Plus the dictation-side apps where they overlap with us, the way WonderWhisper was mined once before — that pass produced #139–#143 and is the precedent for how this should end.
Ground rule: no source reading
HeliBoard is GPL-3.0, FUTO's keyboard is source-available, and Dictate is Apache-2.0. The audit happens through using the apps and reading their public documentation, help pages, changelogs and store listings — never their source. A feature can be re-derived from its behaviour; copying is a licence problem we would carry forever. This rule already cost us nothing once (see #378, where reading a competitor's source turned out to be unnecessary), and it holds here.
What the result should look like
Not a document. One issue per finding that survives the filter, each with:
- what the other keyboard does, and which ones do it
- what it would mean here, in our own structure
- whether it is worth it — including an explicit "no, and here is why", which is a result as much as a yes
A table of everything considered, including the rejections, belongs in this issue when the pass is done, so the next person does not repeat it.
Deliberately out of scope
Anything that needs an account, a cloud service of ours, or telemetry to work. Anything that would mean shipping a model per language. And visual imitation — we are looking for capabilities, not for a different keyboard's look.
This is a marker, not a plan. Nothing has been investigated yet; this issue exists so the work is not forgotten and so the shape of it is agreed before anyone starts.
What we want to do
Go through the keyboards people actually use, feature by feature, and find out what they have that Dictate does not — then decide, for each finding, whether it is something we need, something we have an equivalent of already, or something we are deliberately not doing.
Dictate grew from the dictation side inwards: voice first, then a full typing keyboard around it. That means the typing half has been built where issues pointed rather than against a checklist, and it is worth checking once, systematically, what a long-standing keyboard offers that we never thought about — the small conveniences people bring with them from their previous keyboard and quietly miss.
Which keyboards
At minimum: Gboard, Microsoft SwiftKey, Samsung Keyboard, HeliBoard, FUTO Keyboard, Fleksy, Grammarly Keyboard, Typewise. Plus the dictation-side apps where they overlap with us, the way WonderWhisper was mined once before — that pass produced #139–#143 and is the precedent for how this should end.
Ground rule: no source reading
HeliBoard is GPL-3.0, FUTO's keyboard is source-available, and Dictate is Apache-2.0. The audit happens through using the apps and reading their public documentation, help pages, changelogs and store listings — never their source. A feature can be re-derived from its behaviour; copying is a licence problem we would carry forever. This rule already cost us nothing once (see #378, where reading a competitor's source turned out to be unnecessary), and it holds here.
What the result should look like
Not a document. One issue per finding that survives the filter, each with:
A table of everything considered, including the rejections, belongs in this issue when the pass is done, so the next person does not repeat it.
Deliberately out of scope
Anything that needs an account, a cloud service of ours, or telemetry to work. Anything that would mean shipping a model per language. And visual imitation — we are looking for capabilities, not for a different keyboard's look.