Hi,
First of all, I want to say that I really appreciate the direction you are taking with the project. I saw your recent issue #382 — “Audit the big keyboards for features we are missing”, where you mentioned going through major keyboards feature-by-feature and checking what Dictate already has, what it is missing, and what should or should not be added.
This is actually very close to what I have been trying to communicate through my previous feedback.
My only suggestion is: while looking at other keyboards, please don't look only at which features they have that Dictate is missing. Also look at how well the features Dictate already has actually work compared with those keyboards.
New features are obviously welcome. I am not against them at all. But I sometimes feel that the existing foundation still has quite a lot of room for improvement.
Dictate Keyboard is already doing something extremely impressive on the dictation/AI side. But the typing side came from the FlorisBoard foundation, and because of that, I feel that some parts of the everyday keyboard experience still don't feel as mature as they could be. Your own README describes Dictate as being built on top of FlorisBoard for the keyboard foundation, while adding the dictation and AI layers on top.
So when you compare Dictate with Gboard, SwiftKey, Samsung Keyboard, HeliBoard, FUTO, etc., I think there are two different questions worth asking:
-
What features are we missing?
For example, transliteration is one capability I still miss on suggestions bars etc.
-
For the features we already have, how good is our implementation?
This is the part I think is equally important.
For example:
Is the clipboard as convenient and space-efficient?
Is the suggestion bar as intelligent and forgiving?
Is the typing experience as smooth?
Is the UI as compact and well organised?
Does the interaction behave as naturally?
Does the keyboard make the same everyday tasks easier?
Are there small usability details that users of other keyboards have simply become accustomed to?
Sometimes another keyboard doesn't have a completely different feature. It simply does the same thing better.
And I think that distinction is extremely important if the long-term goal is to make Dictate not just a keyboard with a huge number of features, but a really strong complete keyboard.
I also want to say something because I sometimes feel a little bad about continuously sending issue after issue. 😅
I am not trying to just keep throwing complaints at the project.
A lot of these reports take me a surprising amount of time — recording videos, reproducing the behaviour, explaining what I am seeing, comparing it with other keyboards, and trying to describe what I think could be improved.
So when I send something detailed like this, please don't interpret it as me being dissatisfied with the project as a whole. It is actually the opposite.
I see a lot of potential in Dictate Keyboard, which is why I keep taking the time to report these things.
My hope is that, alongside all the exciting new features, you also keep doing this kind of quality audit of the existing experience:
Not only “What does another keyboard have that we don't?”
but also “Where does another keyboard already do something better than we currently do?”
If both sides are improved together — new capabilities + stronger existing fundamentals — I genuinely think Dictate could eventually become an exceptionally complete open-source keyboard, rather than simply an excellent dictation feature attached to a keyboard.
Yes, I understand the point much better now. You don't want this as a generic introduction. You want to first give the actual Clipboard feedback, and after that, add a stronger closing section explaining why you are reporting these things and what you expect from the project's development priority.
The key idea is:
A feature audit tells you what exists. Daily usage tells you what feels wrong. Both are necessary.
And your experience with Gboard/SwiftKey means you notice those differences almost automatically when switching to Dictate. I would write the closing like this:
One More Important Point About Priorities
I also want to explain why I keep reporting these kinds of things.
I have been using established keyboards such as Gboard, Desh keyboard for a long time, just like millions of users do. When someone moves from a keyboard they have been using for years to a completely new keyboard like Dictate Keyboard, the brain immediately notices that something feels different.
It is not always something that the user consciously searches for.
You don't necessarily open the keyboard and think:
“Let me find five bugs today.”
Instead, while typing normally, your brain automatically starts noticing things:
“This feels less smooth.”
“Why is this suggestion not appearing?”
“Why is the clipboard taking so much space?”
“Why does this emoji row behave differently?”
“Why does this UI feel less compact?”
“Why is this language interaction different?”
“Why do I have to perform an extra step here?”
“Why does this feature feel weaker than what I am used to?”
That kind of feedback mainly comes from daily usage.
You can compare screenshots and feature lists between keyboards, but you cannot fully understand the typing experience simply by checking:
“Keyboard A has this feature, Keyboard B has that feature.”
You have to actually use the keyboard for days.
And that is why I think your current approach in #382 — looking at other major keyboards — is very useful, but I would strongly suggest expanding the comparison beyond missing features. Issue #382 on GitHub
Please Compare Existing Features Too
Whenever you explore another keyboard, I think there should be two questions:
- What does that keyboard have that Dictate doesn't have?
and equally importantly:
- What does Dictate already have, but that keyboard does better?
The second question is extremely important.
For example, don't only check whether Dictate has a clipboard.
Actually use the clipboard and compare:
How much screen space does it consume?
How quickly can I find recent items?
How are pinned items handled?
How compact is the content?
How does navigation work?
How many interactions are required?
Does it feel natural for someone coming from another keyboard?
The same principle should apply to everything already implemented:
Suggestion engine
Typing experience
User-word learning
Languages
Transliteration
Emoji suggestions
Emoji row
Clipboard
Themes
Key spacing
Keyboard layout
Long-press behaviour
Cursor interaction
UI density
Overall visual consistency
And the small interactions that users perform hundreds of times every day
These things can matter more to the user's perception of the keyboard than another ten new features.
Simply having the functionality already present in the base keyboard doesn't necessarily mean the problem is solved.
For example, having a suggestion bar is not enough.
The suggestion engine is effectively the brain of the keyboard. If it cannot intelligently understand imperfect human typing, context, learned vocabulary, partial words, and common typing mistakes, then the keyboard can have an excellent UI and many features while still feeling weak during actual typing.
That is why I have been spending so much effort specifically investigating the suggestion system.
The same thing happened with user-word learning. I initially reported that the capability was missing, then I went much deeper into how it could actually work and provided additional analysis. You subsequently improved that area.
I have been trying to do the same thing with the suggestion engine.
I provided another video showing the behaviour, detailed explanations, and even implementation directions based on my investigation. I am not expecting you to blindly copy the implementation suggestions from a coding agent. The intention is simply to give you as much useful information as possible so that you can investigate the underlying problem faster.
Please Also React to Existing Reports
There is another reason I am mentioning this.
I sometimes feel a little bad continuously sending issue after issue.
It takes a lot of time and effort to:
reproduce the behaviour,
record a video,
explain exactly what happened,
compare it with another keyboard,
investigate the possible technical reason,
sometimes use coding agents to understand the implementation,
and then write everything clearly enough for you to act on it.
I am doing this because I genuinely want to help improve the keyboard.
So when I report something, it would be extremely motivating if there were at least some indication of how it is being treated.
For example:
If it is important: prioritize it when possible.
If it will be implemented later: a short comment saying that would be helpful.
If it is not planned: close the issue and explain that it is not currently planned.
If more investigation is required: even a short acknowledgement would help.
I am not expecting every issue to be implemented immediately.
I mainly want to know that the report has actually been seen and considered.
When older reports remain pending for a long time without any reaction, it becomes difficult to know whether I should continue spending hours investigating and documenting additional problems.
On the other hand, when I see that the reports are being acknowledged and some are actually being addressed, it gives me much more motivation to continue contributing.
A Small Point About User Engagement 😇😇😇
From a user-psychology perspective, prioritization does not necessarily mean implementation. Even a simple acknowledgement, reaction, comment, or indication that an issue has been considered can make a big difference.
When a user spends time reproducing something, recording a video, comparing keyboards, and explaining an issue, but then sees older reports remain open for weeks with no response while newer issues are being addressed, the motivation to keep contributing naturally decreases.
The user may start thinking:
“Is my effort actually worth putting in? Am I just creating more work for the developer? Will this feedback also remain ignored?”
Eventually, the user may simply stop reporting things they notice.
On the other hand, when users see their reports being acknowledged, discussed, prioritized, implemented, deferred with an explanation, or closed with a clear reason, it creates the opposite effect. They feel that their contribution is actually reaching the development process, so every new problem or improvement they discover feels worth sharing.
I am not saying every report needs to be implemented. I am simply saying that some visible response or prioritization from the developer can make users much more willing to continuously contribute.
I can still see that some of my older reports have been open for quite a while without any response, and that is honestly what makes me hesitate before spending the time to document the next one.
Thank you for building and continuously improving this project. You have already done awesome work with Dictate AI voice typing, which is genuinely impressive and stands out in this field.
Thank you for all the effort you are putting into it.
Hi,
First of all, I want to say that I really appreciate the direction you are taking with the project. I saw your recent issue #382 — “Audit the big keyboards for features we are missing”, where you mentioned going through major keyboards feature-by-feature and checking what Dictate already has, what it is missing, and what should or should not be added.
This is actually very close to what I have been trying to communicate through my previous feedback.
My only suggestion is: while looking at other keyboards, please don't look only at which features they have that Dictate is missing. Also look at how well the features Dictate already has actually work compared with those keyboards.
New features are obviously welcome. I am not against them at all. But I sometimes feel that the existing foundation still has quite a lot of room for improvement.
Dictate Keyboard is already doing something extremely impressive on the dictation/AI side. But the typing side came from the FlorisBoard foundation, and because of that, I feel that some parts of the everyday keyboard experience still don't feel as mature as they could be. Your own README describes Dictate as being built on top of FlorisBoard for the keyboard foundation, while adding the dictation and AI layers on top.
So when you compare Dictate with Gboard, SwiftKey, Samsung Keyboard, HeliBoard, FUTO, etc., I think there are two different questions worth asking:
What features are we missing?
For example, transliteration is one capability I still miss on suggestions bars etc.
For the features we already have, how good is our implementation?
This is the part I think is equally important.
For example:
Is the clipboard as convenient and space-efficient?
Is the suggestion bar as intelligent and forgiving?
Is the typing experience as smooth?
Is the UI as compact and well organised?
Does the interaction behave as naturally?
Does the keyboard make the same everyday tasks easier?
Are there small usability details that users of other keyboards have simply become accustomed to?
Sometimes another keyboard doesn't have a completely different feature. It simply does the same thing better.
And I think that distinction is extremely important if the long-term goal is to make Dictate not just a keyboard with a huge number of features, but a really strong complete keyboard.
I also want to say something because I sometimes feel a little bad about continuously sending issue after issue. 😅
I am not trying to just keep throwing complaints at the project.
A lot of these reports take me a surprising amount of time — recording videos, reproducing the behaviour, explaining what I am seeing, comparing it with other keyboards, and trying to describe what I think could be improved.
So when I send something detailed like this, please don't interpret it as me being dissatisfied with the project as a whole. It is actually the opposite.
I see a lot of potential in Dictate Keyboard, which is why I keep taking the time to report these things.
My hope is that, alongside all the exciting new features, you also keep doing this kind of quality audit of the existing experience:
If both sides are improved together — new capabilities + stronger existing fundamentals — I genuinely think Dictate could eventually become an exceptionally complete open-source keyboard, rather than simply an excellent dictation feature attached to a keyboard.
Yes, I understand the point much better now. You don't want this as a generic introduction. You want to first give the actual Clipboard feedback, and after that, add a stronger closing section explaining why you are reporting these things and what you expect from the project's development priority.
The key idea is:
And your experience with Gboard/SwiftKey means you notice those differences almost automatically when switching to Dictate. I would write the closing like this:
One More Important Point About Priorities
I also want to explain why I keep reporting these kinds of things.
I have been using established keyboards such as Gboard, Desh keyboard for a long time, just like millions of users do. When someone moves from a keyboard they have been using for years to a completely new keyboard like Dictate Keyboard, the brain immediately notices that something feels different.
It is not always something that the user consciously searches for.
You don't necessarily open the keyboard and think:
Instead, while typing normally, your brain automatically starts noticing things:
“This feels less smooth.”
“Why is this suggestion not appearing?”
“Why is the clipboard taking so much space?”
“Why does this emoji row behave differently?”
“Why does this UI feel less compact?”
“Why is this language interaction different?”
“Why do I have to perform an extra step here?”
“Why does this feature feel weaker than what I am used to?”
That kind of feedback mainly comes from daily usage.
You can compare screenshots and feature lists between keyboards, but you cannot fully understand the typing experience simply by checking:
You have to actually use the keyboard for days.
And that is why I think your current approach in #382 — looking at other major keyboards — is very useful, but I would strongly suggest expanding the comparison beyond missing features. Issue #382 on GitHub
Please Compare Existing Features Too
Whenever you explore another keyboard, I think there should be two questions:
and equally importantly:
The second question is extremely important.
For example, don't only check whether Dictate has a clipboard.
Actually use the clipboard and compare:
How much screen space does it consume?
How quickly can I find recent items?
How are pinned items handled?
How compact is the content?
How does navigation work?
How many interactions are required?
Does it feel natural for someone coming from another keyboard?
The same principle should apply to everything already implemented:
Suggestion engine
Typing experience
User-word learning
Languages
Transliteration
Emoji suggestions
Emoji row
Clipboard
Themes
Key spacing
Keyboard layout
Long-press behaviour
Cursor interaction
UI density
Overall visual consistency
And the small interactions that users perform hundreds of times every day
These things can matter more to the user's perception of the keyboard than another ten new features.
Simply having the functionality already present in the base keyboard doesn't necessarily mean the problem is solved.
For example, having a suggestion bar is not enough.
The suggestion engine is effectively the brain of the keyboard. If it cannot intelligently understand imperfect human typing, context, learned vocabulary, partial words, and common typing mistakes, then the keyboard can have an excellent UI and many features while still feeling weak during actual typing.
That is why I have been spending so much effort specifically investigating the suggestion system.
The same thing happened with user-word learning. I initially reported that the capability was missing, then I went much deeper into how it could actually work and provided additional analysis. You subsequently improved that area.
I have been trying to do the same thing with the suggestion engine.
I provided another video showing the behaviour, detailed explanations, and even implementation directions based on my investigation. I am not expecting you to blindly copy the implementation suggestions from a coding agent. The intention is simply to give you as much useful information as possible so that you can investigate the underlying problem faster.
Please Also React to Existing Reports
There is another reason I am mentioning this.
I sometimes feel a little bad continuously sending issue after issue.
It takes a lot of time and effort to:
reproduce the behaviour,
record a video,
explain exactly what happened,
compare it with another keyboard,
investigate the possible technical reason,
sometimes use coding agents to understand the implementation,
and then write everything clearly enough for you to act on it.
I am doing this because I genuinely want to help improve the keyboard.
So when I report something, it would be extremely motivating if there were at least some indication of how it is being treated.
For example:
If it is important: prioritize it when possible.
If it will be implemented later: a short comment saying that would be helpful.
If it is not planned: close the issue and explain that it is not currently planned.
If more investigation is required: even a short acknowledgement would help.
I am not expecting every issue to be implemented immediately.
I mainly want to know that the report has actually been seen and considered.
When older reports remain pending for a long time without any reaction, it becomes difficult to know whether I should continue spending hours investigating and documenting additional problems.
On the other hand, when I see that the reports are being acknowledged and some are actually being addressed, it gives me much more motivation to continue contributing.
A Small Point About User Engagement 😇😇😇
From a user-psychology perspective, prioritization does not necessarily mean implementation. Even a simple acknowledgement, reaction, comment, or indication that an issue has been considered can make a big difference.
When a user spends time reproducing something, recording a video, comparing keyboards, and explaining an issue, but then sees older reports remain open for weeks with no response while newer issues are being addressed, the motivation to keep contributing naturally decreases.
The user may start thinking:
Eventually, the user may simply stop reporting things they notice.
On the other hand, when users see their reports being acknowledged, discussed, prioritized, implemented, deferred with an explanation, or closed with a clear reason, it creates the opposite effect. They feel that their contribution is actually reaching the development process, so every new problem or improvement they discover feels worth sharing.
I am not saying every report needs to be implemented. I am simply saying that some visible response or prioritization from the developer can make users much more willing to continuously contribute.
I can still see that some of my older reports have been open for quite a while without any response, and that is honestly what makes me hesitate before spending the time to document the next one.
Thank you for building and continuously improving this project. You have already done awesome work with Dictate AI voice typing, which is genuinely impressive and stands out in this field.
Thank you for all the effort you are putting into it.