Suggestion Bar Improvement & Feedback

[mastertrivia]

Suggestion Bar Improvement

Please bear with my broken English. I may not be able to explain everything perfectly, but I hope you will understand what I am trying to communicate through the video and the detailed explanation below.

Please treat this as an important optional improvement, not a mandatory change

You are completely free to implement this or not.

I am not trying to force a particular implementation or dictate how the engine should be coded.

However, I want to be transparent about its importance to me:

If this capability remains significantly weaker than a mature keyboard's suggestion engine, I will probably be forced to use another keyboard.

This is because the suggestion bar is one of the major parts of my everyday typing workflow.

I type quickly and rely heavily on the suggestion bar rather than manually correcting every small typing mistake.

---

What I am attaching :-

👉 1. The main source of my feedback is the attached video.

https://drive.google.com/file/d/1DpyCsepS7Pg5wBjPUN-C6FzfoHrS15gk/view?usp=drivesdk

Please watch the complete recording carefully. It demonstrates the actual problem and shows multiple examples of how I expect the suggestion engine to behave.

---

👉 2. I am also attaching:

suggestion-bar-final.md

Suggestion Bar Final.md — this contains substantial technical detail and implementation ideas that should help you understand how the problem could potentially be solved.

The detailed explanation below — coding app have written this to explain the actual user experience, why the current behavior feels different, and what I believe needs to be improved.

The document is intended to give you implementation clues, while the video demonstrates the actual behavior and expected experience.

Important: please don't treat my document as the final implementation specification

The document contains my analysis and suggestions, but I am a normal user, not the engineer implementing the keyboard.

So:

Use the document as a strong source of information and direction.

Use the video as behavioral evidence.

But please perform your own technical analysis as well.

You are completely free to change, improve, reject, or extend the implementation approach if you find a better and more robust solution.

The goal is not to implement my exact proposed mechanism.

The goal is to achieve the actual user experience demonstrated in the video.

Most importantly

Please don't judge the requirement only from my written examples.

Try the behavior yourself.

Install/use Gboard, test it hands-on with English and, if useful, other languages as well. Deliberately type words incorrectly, make adjacent-key mistakes, type partial words, make mistakes in the beginning/middle/end, try different contexts, and observe what appears in the suggestion bar.

The video shows you what I experienced, but personally reproducing the behavior will give you a much better understanding of what makes the suggestion engine feel so smooth.

---

ChatGPT written — Detailed Explanation

Below this point is my detailed explanation of the problem, examples, expected behavior, and the reasoning behind this request.

Please read it together with the video and Suggestion Bar Final.md rather than treating any one of them in isolation.

---

🔥 Feedback — Suggestion Engine Must Become a Core Strength of Dictate Keyboard

I have been using the Dictate Keyboard for roughly two weeks, and throughout that time I kept feeling that I could not type as smoothly as I normally do. Today I finally identified one of the major differences: the suggestion engine is not forgiving enough of normal human typing errors.

This is not a small cosmetic improvement. Suggestion quality is one of the most fundamental parts of a keyboard experience. I want this feedback to be treated as a major usability/engine requirement.

---

1. What makes a mature keyboard feel fast

The important thing about a good keyboard is that the user does not need to type perfectly.

When typing quickly:

My fingers are moving rapidly across the keyboard.

I am not constantly looking at individual keys.

I am not concerned about whether every letter was entered correctly.

I mainly look at the suggestion strip.

I type part of a word.

The suggestion engine understands what I intended.

The correct word appears in the suggestion strip.

I tap that suggestion and continue typing.

This creates a very important workflow:

Type → glance at suggestions → tap correct suggestion → continue typing

The suggestion engine effectively absorbs a large portion of the user's typing mistakes.

That is one of the reasons mature keyboards feel dramatically faster than a keyboard where the user has to manually repair every typo.

---

2. The current Dictate Keyboard problem

The current experience breaks this workflow because the suggestion engine appears to depend too heavily on the literal characters that were typed.

For example, suppose I want to type:

Consequences

I may type rapidly without looking:

C-O-N-S-E-Q...

But because I am typing quickly, I might accidentally hit D instead of Q, or make another nearby-key mistake.

Now the problem is:

I have already typed a substantial portion of the word.

The intended word still isn't appearing.

I have to look down at what I actually typed.

I discover that I made a mistake somewhere in the middle.

I have to press Backspace repeatedly.

I have to manually correct the letters.

Only after correcting them does Consequences finally appear.

Then I can tap the suggestion.

At that point, the entire advantage of suggestion-based typing has been lost.

What should happen instead

Even if the input is something like:

conseqd

the engine should have enough intelligence to understand that the intended candidate is very likely:

Consequences

The exact implementation is up to the engineering team, but the user experience should not require manually repairing obvious typing mistakes before the suggestion engine can recover.

---

3. This is NOT a request for aggressive AutoCorrect

There is an important distinction here.

I personally do not use traditional AutoCorrect.

I dislike AutoCorrect because it can change words that I intentionally typed correctly and interfere with the user's control.

For example:

I intentionally type a particular word.

AutoCorrect decides it must be something else.

It silently replaces my input.

I then have to undo the keyboard's decision.

That is frustrating.

What I am asking for is fundamentally different

The suggestion strip gives the user control.

The engine can effectively say:

"I think you intended this word."

But it does not force the correction.

The user simply taps the suggestion if it is correct.

So the desired behavior is:

Intelligent correction through suggestions, not intrusive automatic replacement.

This distinction is extremely important.

---

4. Suggestion intelligence should be much more tolerant of errors

The engine should not require an exact or nearly exact prefix.

It should be able to tolerate realistic human typing errors such as:

Beginning-of-word errors

The user makes a mistake near the beginning.

Example:

intended: dictionary
typed: something like dix...

The correct candidate should still be recoverable.

Middle-of-word errors

The user starts correctly but makes a mistake halfway through.

Example:

D-I-X-T...

instead of:

D-I-C-T...

If the surrounding character pattern strongly indicates dictionary, the suggestion should still be able to surface it.

Multiple errors

The engine should not collapse as soon as several letters are incorrect.

Real users sometimes produce:

adjacent-key substitutions

omitted characters

duplicated characters

wrong characters

partially completed words

combinations of these errors

The engine should be robust enough to recover from these situations wherever confidence remains sufficiently high.

---

5. Adjacent-key awareness should be a fundamental signal

One particularly important mechanism to investigate is keyboard geometry.

Human typing errors are not random.

A very large proportion of mistakes happen because the finger hits a key:

immediately to the left

immediately to the right mostly

and above or below diagonally adjacent but rarely

Therefore, the engine should be able to understand the keyboard layout itself.

For example:

Intended: C
Accidentally pressed: X

These two characters are physically close on a QWERTY keyboard.

That should not be treated the same way as an entirely unrelated character substitution.

Suggested direction

Consider incorporating a keyboard-layout-aware error model into candidate generation/ranking:

Typed character
↓
Keyboard position
↓
Nearby-key alternatives
↓
Candidate words
↓
Dictionary + frequency + context + language model
↓
Final ranked suggestions

This is only a conceptual direction—not a demand that this exact architecture be implemented.

The engineering team should determine the most robust implementation.

---

6. This is more than dictionary lookup

This is an important conceptual point.

Please don't treat the problem simply as:

"Find a dictionary word that resembles the typed string."

That will not be enough.

The real problem is closer to:

Infer what the user intended to communicate from imperfect input.

That means the engine should potentially combine:

character similarity

keyboard-key proximity

prefix similarity

edit distance

word frequency

previous words

sentence context

language model probability

learned user vocabulary

capitalization

punctuation

previously selected suggestions

personal names

email addresses / unusual tokens where applicable

learned phrases and recurring patterns

The existing reverse-engineering work already indicates that the Desh English stack is more than a simple dictionary: it involves an English dictionary, LM/probability information, learned-prefix and user-word paths, candidate generation, and final candidate ordering.

Therefore, please do not solve this by merely replacing or enlarging the dictionary.

---

7. The attached video is important evidence

I am attaching a complete recording demonstrating the problem and the desired experience.

Please actually examine the recording rather than treating this feedback as a theoretical request.

The recording demonstrates different typing situations and shows:

imperfect typing

partial words

incorrect characters

rapidly entered words

how a mature suggestion engine can recover from imperfect input

why this produces a dramatically smoother typing workflow

The point of the video is not simply:

"Make this particular word work."

It is intended to demonstrate the general behavior that the suggestion engine should have.

---

8. The Diltate → Dictate example

Another concrete example from the recording is:

Suppose I intend to type:

Dictate

but accidentally type:

Diltate

A possible suggestion strip could currently look conceptually like:

Diltate | Dictate | Dilate

That is already useful because Dictate is being recovered.

However, the engineering team should decide whether showing the raw misspelled word (Diltate) is actually useful.

If it isn't a valid dictionary word, perhaps the suggestion space could instead be used for stronger candidates.

For example:

Dictate | Dilate | ...

The important point isn't the exact number/order of these candidates.

The important point is:

The engine must recognize that the user's input itself may be wrong and generate the intended word anyway.

This should not be limited to one example.

---

9. Context must participate in correction

The engine should not only ask:

"Which dictionary word looks most similar to this input?"

It should also ask:

"Given everything around this word, what was the user most likely trying to type?"

For example, suppose the user types a malformed word, but the previous words strongly constrain the possibilities.

The contextual probability should be able to rescue a candidate that might otherwise look slightly less similar at the character level.

This is why I consider this primarily a context-engineering problem, not merely a spelling-correction problem.

The existing technical investigation also identifies prior context construction and LM ranking as important parts of the prediction pipeline.

---

10. Partial-word prediction is equally important

There are actually two separate capabilities that need to work together.

A. Correctly typed partial word

Example:

D-I-C-T

The engine should already know:

Dictionary

or other highly probable candidates.

I should not have to type the complete word.

B. Incorrectly typed partial word

This is even more important.

Example:

D-I-X-T

where X was accidentally pressed instead of C.

The engine should still be capable of recognizing:

Dictionary

if the overall evidence is strong enough.

Therefore:

Partial input + typing errors must still produce useful candidates.

This is the behavior that makes rapid typing possible.

---

11. Personal words, names and unusual vocabulary must also work

The intelligence shouldn't be restricted to ordinary dictionary words.

For example, suppose I type someone's name:

Alexander Graham Bell

The system should ideally learn from my previous usage.

If I repeatedly type:

Alexander

and then:

Graham

and then:

Bell

the system should investigate whether this recurring sequence can become part of prediction.

Similarly:

personal names

school names

organization names

locations

email addresses

frequently used unusual words

recurring terminology

should be capable of benefiting from learning.

---

12. Does the engine learn sequences/patterns?

This is another important question that should be explicitly investigated.

Suppose I repeatedly type:

Alexander Graham Bell

Does accepting:

Alexander

increase the probability that:

Graham

will become the next suggestion?

And after accepting:

Graham

does:

Bell

become highly probable?

Similarly, suppose I frequently type:

My school name is Convent School

Can the engine learn that particular sequence/pattern?

This is different from simply learning individual words.

It is about learning:

word → likely next word / phrase

Please investigate whether the current Desh engine already supports this kind of contextual/pattern learning, and if it does, reproduce it properly rather than inventing a separate approximation.

---

13. Learning must not be reduced to a basic personal dictionary

This is particularly important given the previous engineering work.

The existing investigation has already found explicit Desh English learning components such as:

english_user_dict

english_learnt_prefix_search

learnt_dict_prefix_search

learnt_dict_suggestions

learning-related configuration

time-decay behavior

This indicates that Desh's learning system is a first-class prediction component, rather than simply a normal personal dictionary.

Therefore, please do not implement:

"User typed a word → put it in a dictionary → show it later"

and consider the problem solved.

The actual learning/ranking behavior needs to be understood.

---

14. Do not treat the coding agent's previous analysis as the final answer

I am attaching the document because it contains a substantial amount of analysis and implementation guidance, including the previous response around issue #334.

That work is valuable and should absolutely be used.

However:

Please do not treat that document as the final implementation specification simply because the coding agent produced it.

I am a normal user, not a keyboard-engineering specialist, yet I have spent significant time:

testing the keyboard

recording the behavior

reproducing different scenarios

identifying the actual usability problem

documenting examples

thinking through possible mechanisms

attaching the recording

explaining the intended experience as precisely as possible

The document already provides substantial technical clues, but the engineering team should perform its own analysis on top of it.

The existing implementation-readiness work itself says the current target should route English through the Desh English engine and preserve the existing suggestion UI rather than simply modifying the UI layer.

---

15. Please aim for the mature-keyboard experience, not a manual workaround

I want to emphasize this strongly.

Please don't implement a collection of manually added special cases such as:

if input == "diltate" → Dictate
if input == "dixt" → Dictionary
if input == ...

That would demonstrate the problem is understood, but it would not solve the underlying problem.

The desired system needs to generalize.

If tomorrow I type another word incorrectly:

a different adjacent key

an omitted letter

two incorrect letters

a wrong middle character

an incorrect beginning

an unfamiliar personal word

the engine should still behave intelligently.

---

16. The target is robustness, not merely matching a few examples

The attached examples should therefore be treated as acceptance examples, not the complete specification.

The real target is:

Can a user type rapidly without looking at the individual keys, make normal human mistakes, and still reliably obtain the intended word in the suggestion strip?

That is the experience I am trying to achieve.

The existing technical plan already proposes differential testing across:

short prefixes

context prediction

learned words

capitalization

punctuation

candidate ordering

and comparison against Desh.

I strongly recommend extending those tests specifically to error-tolerant prediction.

---

17. Suggested testing matrix

Please test the engine systematically rather than only checking a few manually selected words.

Prefix accuracy

a → likely candidates
di → dictionary / dictate / ...
dict → dictionary / ...
con → consequences / ...

Adjacent-key errors

Test substitutions involving:

left neighbor

right neighbor

upper neighbor

lower/diagonal neighbor

Error position

Test mistakes at:

first character

second/third character

middle

near the end

Error count

Test:

1 wrong character

2 wrong characters

multiple wrong characters

Partial + incorrect input

Test combinations such as:

partially typed + typo + context

Context

Test:

I am going ...
Thank you ...
I would like ...
My school name is ...
Alexander ...
Alexander Graham ...

The existing Desh investigation already identifies context examples such as these as important parity tests.

Learning

Test:

1. Type/accept an unusual personal word.

2. Type only its first few characters later.

3. Introduce an error in those characters.

4. Verify whether the learned word can still be recovered.

5. Test after restarting the keyboard.

6. Test whether frequency/recency affects ranking appropriately.

---

18. Preserve user control

Even while making the suggestion engine much more intelligent:

Do not turn this into aggressive AutoCorrect.

Do not silently replace user text merely because the engine has a high-confidence guess.

Keep the correction primarily available through the suggestion strip.

The user remains the final authority by tapping the desired suggestion.

The goal is:

The keyboard should understand me better, not override me.

---

19. This should become a core priority of the English suggestion engine

The existing technical direction is already broadly correct: the plan identifies a dedicated Desh English stack consisting of the dictionary, LM, candidate generation, probability/LM path, learned-prefix path, user dictionary, learning integration, and candidate ordering, with HeliBoard remaining primarily as the UI/application foundation.

The missing goal I want to emphasize now is:

Make that engine genuinely tolerant of imperfect human input.

A technically correct dictionary/LM integration is not enough if a user still has to stop, look at the keyboard, find their typo, press Backspace repeatedly, and manually repair the word.

---

20. Final objective

My typing workflow is very simple:

Type → type → type → look at suggestions → tap → type → type → tap → continue

My eyes should primarily be on the suggestion strip, not on individual keys.

I should not have to:

Type → stop → inspect letters → discover typo → Backspace → repair → type again → wait for suggestion → tap.

That second workflow is exactly what currently makes Dictate Keyboard feel noticeably less smooth to me.

The final target should therefore be:

A suggestion engine that understands imperfect human typing, uses keyboard geometry + linguistic context + language-model probability + learned user behavior + vocabulary, and presents the most likely intended word without forcing an automatic correction.

Please use the attached video as behavioral evidence and the attached/previous technical documentation as implementation guidance, but do your own engineering analysis beyond it.

I am deliberately not prescribing one exact algorithm because I am not the engineer implementing the system. I am showing you the behavior that needs to be achieved and providing enough examples and technical hints to make the direction clear.

The ultimate goal is simple:

Make Dictate's suggestion experience robust enough that, from the user's perspective, there is no noticeable gap between this keyboard and a mature keyboard such as Gboard when typing rapidly and imperfectly.

That suggestion/prediction layer is, in my view, one of the defining parts of what makes a keyboard feel genuinely good.

21. Please Validate This Yourself — Don't Rely Only on My Demo

One final and very important request:

Please install/use Gboard yourself and test this behavior hands-on.

Don't limit the investigation to the examples I have shown in the video.

Try it with English yourself, using many different words and deliberately making realistic typing mistakes.

Also test other languages, including languages such as German or any other language available to you, because the underlying behavior may reveal useful implementation patterns that are not obvious from English alone.

Try:

correctly typed partial words

incorrectly typed partial words

adjacent-key mistakes

mistakes at the beginning, middle, and end

multiple mistakes in one word

unusual/personal words

words in different sentence contexts

repeated phrases and word sequences

learned vocabulary

different typing speeds

Please actually observe and reproduce the behavior yourself.

I have only been able to show you a demonstration of what I experience. You will understand the engineering problem much better if you personally practice with a mature keyboard, deliberately make mistakes, observe which suggestions appear after each keystroke, and compare how the ranking changes with context.

The objective is not to copy one particular example from my video. It is to discover the underlying behavior and engineering principles that make Gboard's suggestion system so tolerant and useful, and then determine how those principles can be reproduced robustly in Dictate Keyboard.

Please don't just implement what I described. Reproduce the behavior yourself, experiment with it, analyze what you observe, and then engineer toward that level of robustness.

That hands-on comparison should be considered part of the investigation before deciding that the suggestion engine is "good enough."

[mastertrivia]

Heliboard already has the same feature what I have discussed above, , like even on typing the wrong spellings, still the suggestion bar is able to suggest the correct words.

But that is not as stronger as Google Keyboard, but still the feature is present.

So the main benefit is that because the Heliboard is open source, you can directly find where your FlorisBoard base is lagging behind.

The attached document in the above comment is also very important because that is written on the basis of Google Keyboard.

You can also completely compare the suggestion engine of Dictate Keyboard and the Heliboard.

And can find what's the pros and cons, regarding the suggestion engine in the dictate keyboard.

Record_2026-09-17-12-47-11.mp4

[DevEmperor]

Thanks for the detailed report. I've read it and it's on my list — I'll get to it as soon as I can.

[DevEmperor]

Thank you for this report. The two videos and the document made the problem very concrete, and your Gboard comparisons showed exactly what was missing. Here is what changed. All of it will be in the next update.

1. The strip no longer goes empty on a typo when Auto-correct is off

This was the biggest part of what you saw. In your first video the strip stays empty on helwo, which is only one letter from hello. That happens when Auto-correct is switched off, and your video suggests you have it off (you wrote that you don't use it). The switch was meant to control only the automatic replacement on Space. In fact it also hid every spelling fix in the strip.

Now the switch only decides whether Space replaces a word by itself. The fixes are always offered in the strip, and you tap the one you want. That is exactly the "offer, don't override" behaviour you asked for.

2. Both ways of reading a typo now work together

The keyboard reads a typo in two ways: from where your fingers landed, and from how the word is spelled. Until now the first one switched the second off as soon as it found anything. helwo only offered growl, because every one of your taps sits next to a key of "growl", and it never offered hello. Now both are asked, and the second always gets a place in the strip.

Measured on about 2,400 simulated typos, the intended word is now offered 94 % of the time instead of 86 %. For swapped letters (becuase) it went from 66 % to 99.7 %.

3. A typo inside a half-typed word now still completes

conseqd → consequences, vecau → because, Wochenem → Wochenende. Before, a typo in the part you had typed so far meant no completion at all: 0.4 % in our measurement.

Now the keyboard also looks for words that begin with something close to what you typed, both from your tap positions and from the spelling. The best such word goes into the second slot, but only when it is a more common word than the fix it would push aside, so finished words keep their fixes. None of these is ever inserted automatically. Measured: the intended word is now among the first three suggestions 22 % of the time and somewhere in the strip 40 % of the time. The first three stay limited because many prefixes are genuinely ambiguous.

4. Speed

While testing I measured every keystroke on a real phone and found two slow spots:

• Your own dictionary words and shortcuts were looked up in the database on every key press, which cost 25–70 ms each time. They are now kept in memory and cost under 1 ms. As a side effect, words you add or remove in the settings take effect immediately.
• The search for words two letters away took up to ~300 ms on long typos, so the strip visibly lagged behind. It finds exactly the same words as before, but is now typically 5–40 ms.

What I didn't do, and why

• Hiding the word you typed. It stays in the strip on purpose. It is your one-tap way back when the keyboard corrects something you meant, and long-pressing it teaches the keyboard a new word.
• A "same row only" rule for slips. The keyboard already uses the exact position of every tap, which is more precise than a row rule.
• HeliBoard's code. It is GPL-licensed, so it cannot be reused here. I used HeliBoard and Gboard as behavioural references only.
• Known limits. Two mistakes inside a half-typed word (fedva → feedback) are not reached yet. dixt → dictionary appears further to the right, because sixth is one key away and is the more common word. The sentence context (the word before) also helps with such cases in real typing.

Follow-ups

The remaining ideas from your document are tracked in #432:

• learning your own word sequences (Alexander → Graham → Bell, "my school name is" → Convent);
• scoring next-word suggestions on one scale;
• the two-edit tier (doinb → doing and going).

#419 was closed as a duplicate of this issue.

Thanks again for the effort you put into testing and documenting this. It made a real difference.