Feature Request: Powerful but Extremely Simple Custom Symbols / Secondary Layouts
I would like to request a Custom Symbols / Custom Secondary Layouts feature.
HeliBoard already demonstrates how powerful this concept can be through its secondary-layout configuration, and I have attached screenshots showing how I currently use it. Please take HeliBoard as inspiration for the capability, but do not copy its configuration UX. Its JSON/manual configuration is powerful but too easy for an ordinary user to get wrong.
The main goal here should be:
Give every user the freedom to build their own personal symbol keyboard, while making the configuration so simple that even a non-technical user can understand it immediately.
Why this feature is genuinely useful
The default symbols provided by a keyboard are necessarily generic.
A symbol that is extremely useful to one person may be almost useless to another. This varies by:
country and language,
profession,
study/work requirements,
mathematics/programming/science usage,
chatting/social-media usage,
personal preferences,
and even individual frequently used Unicode characters.
For example, one user may frequently need:
₹ ≠ ≈ ∞ √ π ≤ ≥ →
while another may want:
© ® ™ § ¶ † ‡
and another may want decorative/chat symbols.
Often the user can find exactly what they need by searching the web and copying the Unicode character. A site such as CoolSymbol demonstrates how many different Unicode symbols users may want to discover.
Unicode itself states that Unicode characters can be used without obtaining special permission from the Unicode Consortium. So the keyboard could safely provide a curated collection of Unicode characters as defaults, while avoiding copying any third-party site's proprietary presentation or content.
The important idea is:
The keyboard should not decide which symbols are important for every user. It should give the user the power to decide.
- Add a Custom Symbols feature with Enable / Disable
Something like:
Secondary layouts
Symbols
More symbols
Custom symbols OFF
When the user enables it:
Custom symbols ON
Edit custom symbols >
This should be a normal customization feature, not a developer/debug feature.
It can be placed under an Advanced/Customization section if necessary, but it should still be a proper supported user feature.
- Do NOT make the user type JSON
This is probably the most important UX requirement.
HeliBoard's approach is powerful because the user can manually define layouts, but ordinary users can easily make mistakes with:
spaces,
line breaks,
ordering,
number of keys,
missing entries,
extra entries,
etc.
Instead, show the user an actual visual keyboard editor.
For example:
Custom Symbols
[1] [2] [3] [4] [5] [6] [7] [8] [9] [0]
[✓] [•] [∞] [√] [π] [≠] [≈] [±] [×] [÷]
[≤] [≥] [→] [←] [↑] [↓] [↔] [₹] [€]
[©] [®] [™] [§] [¶] [†] [‡]
The exact default symbols are up to you.
The crucial thing is that the keyboard itself becomes the editor.
The user doesn't need to understand any syntax.
- Preserve the exact physical QWERTY geometry
The custom layout should follow the same physical character-key geometry as the English QWERTY keyboard.
Conceptually:
10 keys
10 keys
9 keys
7 keys
So:
1 2 3 4 5 6 7 8 9 0
Q W E R T Y U I O P
A S D F G H J K L
Z X C V B N M
The exact key widths/offsets should follow the actual keyboard implementation.
Other keys such as:
Shift
Backspace
?123
comma
language switch
Space
period
Enter
remain unchanged.
This is important because switching from English → Symbols should feel like switching the contents of the same keyboard, not opening a completely different grid.
- First Symbols layout
On the first Symbols page, I would keep the number row:
1 2 3 4 5 6 7 8 9 0
because users commonly need those numbers there.
Then the 26 alphabetic positions become customizable symbols:
10 positions
10 positions
9 positions
7 positions
Therefore:
10 permanent numbers + 26 customizable symbols.
This is especially useful because many of the current "secondary" symbols could now be promoted into the user's frequently used primary symbol layout.
- Second / More Symbols layout
On the next symbol page, I recommend making all 36 character positions available for additional symbols:
10
10
9
7
Rather than permanently repeating 1–0.
The user already had 1–0 on the first Symbols page.
Those ten positions are therefore much more valuable as another ten custom symbols.
So the second page can provide:
36 additional primary symbol positions.
The developer may choose a different default arrangement if there is a strong UX reason, but the principle should remain:
Anyways, like if any user still want to keep the numbers on the second layout, he can manually type.
Do not waste available physical key positions unnecessarily.
- Pre-fill the layouts with useful defaults
This is important.
When a user enables Custom Symbols, do not show an empty keyboard.
Every primary position should already contain a useful symbol selected by the developer.
For example:
✓ ✔ ✗ • ◦ ° ∞ ≠ ≈ ±
√ π ≤ ≥ × ÷ → ← ↑ ↓
↔ ⇒ ⇔ ₹ € £ ¥ © ®
™ § ¶ † ‡ …
The exact selection is your design decision.
The user can then replace anything they don't like.
This makes the feature immediately useful even before the user customizes anything.
It also guarantees that the physical layout can never accidentally collapse because a user forgot to define a key.
You can pre-fill several symbols which you actually think as important and useful by default by googling or by searching online from websites.
- Primary symbols should always have a value
A physical character position should not disappear simply because the user didn't enter something.
For example, if there are 36 positions, the application should always have 36 primary values.
If the user changes one:
π → ∑
only that position changes.
If they don't touch another position, its default remains.
If they try to delete the primary symbol, the cleanest behavior would be something like:
Reset to default
rather than allowing an empty physical key.
This guarantees:
No missing key can ever shift the rest of the layout.
- Long-press customization should be equally simple
Each primary key should independently support additional long-press characters.
For example:
┌─────┐
│ ✓ │
└─────┘
Tap the key → edit it.
The editor could show:
Primary
[ ✓ ]
Long press
[ ✔ ] [ ☑ ] [ ✅ ] [ + ]
The + button adds another long-press symbol.
The user can add/remove/reorder them.
Another key might have:
Primary
[ ∞ ]
Long press
None
That is completely valid.
There should be no requirement that every key have the same number of long-press options.
The main goal is not to design a system that adds extra spaces or symbols when assigning multiple characters to a key on long‑press; it should stay simple. If you insert spaces—whether one, none, or three—the individual characters will no longer appear distinct. In the Heliboard this is problematic: using two spaces or no space at all disturbs the layout, and using three spaces breaks it. So avoid repeating this mistake. When you assign many symbols to a single key, you must ensure they are separated by a single space; without that space the characters merge, and with too many spaces the layout breaks. Presenting them box by box or handling spacing correctly will prevent these issues.
- The visual editing experience should be extremely simple
I think the best UX would be:
Normal view
The user sees their keyboard exactly as it will appear.
There is a pencil/edit button at the top.
Tap pencil
The keyboard enters editing mode.
Tap a key
That particular key becomes selected/enlarged.
The user can directly change its primary symbol.
A small + allows additional long-press symbols.
Tap Save / Back
The configuration is saved.
The user should be able to understand the entire system without reading documentation.
The preview should look as close as possible to the actual keyboard so the user can immediately understand:
"This is exactly where my symbol will appear."
That is much better than asking users to imagine the result from a JSON file.
- Do not artificially restrict what users can put in a key
This is another important point.
The fixed geometry should not mean the developer restricts the symbol choices.
A user should be able to put essentially whatever appropriate Unicode character/string they want.
For example:
∑
∞
₹
Ж
अ
Ω
✓
→
©
or any other supported character.
They can even put the same symbol in multiple positions.
That is fine.
The keyboard doesn't need to police whether the configuration is "optimal."
The user owns the layout.
The application only guarantees that the physical keyboard structure remains intact.
- Emoji should also be allowed
Do not unnecessarily prevent emoji.
A user should be free to put:
❤️
😂
👍
🔥
✅
wherever they want.
However, users should understand that emoji may render as colored glyphs.
If they place emoji as primary symbols on the main QWERTY-linked layout, they may naturally notice that those keys look colorful. That's a consequence of their customization, and they can change it if they don't like it.
There is no need to impose an artificial restriction.
For many users, emoji will actually make sense on their custom secondary layouts.
- Think of this as a personal keyboard, not merely a symbol list
This is perhaps the broader design philosophy.
The user isn't just creating:
"a list of Unicode symbols."
They are effectively creating their own keyboard layer.
For example:
First layer:
Frequently used symbols
Second layer:
Mathematics
Third layer:
Personal shortcuts / special characters
Long press:
Additional variants
A user could even use a position for a character from another language if that is useful to them.
So the system should be flexible enough that the developer isn't deciding what the user is "supposed" to put there.
- Import / Export and Backup / Restore
This should absolutely be included.
There should be:
Custom Symbols
Export
Import
And the normal keyboard:
Backup / Restore
☑ Custom symbol layouts
☑ Primary symbols
☑ Long-press symbols
☑ Layout configuration
The user's complete custom configuration should survive backup/restore.
This also allows users to share their layouts.
- Use HeliBoard as the technical inspiration, not the user interface
HeliBoard proves that a system like this can be extremely powerful.
The attached screenshots show that users can manually define their desired symbols and long-press alternatives.
That is the right level of freedom.
But the configuration method is too technical for many users.
So the ideal solution is:
HeliBoard's flexibility + a visual keyboard editor + automatic validation + sensible defaults.
The user should never need to understand:
JSON syntax,
commas,
spaces,
row lengths,
key counts,
internal layout ordering.
The application should handle those things internally.
- The key design principle
If I had to reduce the entire request to one sentence:
Make custom symbols as easy to configure as changing keys on a physical keyboard: show the keyboard, let the user tap a key, change it, add long-press options, and save.
That is the experience I would prioritize above everything else.
The feature should feel empowering rather than technical.
A technically sophisticated user can still get enormous flexibility, but a completely normal user should be able to open it, see a familiar keyboard, tap the pencil, and immediately understand what to do.
I was using the heli board from very longer time. So I feel that feature literally missing here. I am also attaching what symbols I was using.....Please decide/ set the custom default symbols by yourself..
Primary Symbols
✓ ✅
• ● ⬤
| ║
= ≠ ≈ ∝
₹
@
↑ ↓ ← →
_ ⎯
&
×
÷
< ≤ « ‹ ⟨
≥ » › ⟩
/ \
Seondary Symbols (More Symbols)
%
`
∝
√
π
°
●
❛
❜
∆ ∞ ¶ §
꧁ ꧂
★ ✪ ❀ ✿
✅
❌
^
❓
★
{
}
$
👉 👇 👈 👆
⭕ 🟢 🔴
;
❝
❞
[
]
< !fixedColumnOrder!3 ‹ ≤ «
!fixedColumnOrder!3 › ≥ »
Finally, please don't take everything above as a strict command or assume that every implementation detail I suggested must be followed exactly. I have simply tried to explain the problem, how I currently use HeliBoard, and the kind of experience I believe would make this feature genuinely useful.
You can absolutely rethink the implementation and come up with an even better approach. The most important requirement is the user experience: setting, editing, replacing, and adding symbols should feel ultra-simple and completely intuitive, even for a non-technical user.
HeliBoard is a good reference for understanding the capability, but its JSON-based configuration can be difficult for ordinary users and can easily lead to formatting mistakes. I personally mainly use it for its symbol layouts, so even if implementing every possible type of secondary layout is too much initially, a polished Custom Symbols feature alone would already be extremely valuable.
Ideally, a user should be able to look at the keyboard on the screen, immediately understand where every symbol will appear, tap the pencil/edit button, tap any key, change its symbol or add long-press options, and save — without having to understand JSON, separators, spaces, row numbers, key counts, or any technical configuration.
At the same time, the implementation should make it practically impossible for a normal user to accidentally disturb the keyboard structure. The 10–10–9–7 QWERTY geometry should remain stable, while the symbols themselves can remain completely user-controlled and flexible.
Please feel free to improve upon all of my suggestions and design the final interaction in whatever way you think is best. My main request is not a particular UI or file format; it is to make personal symbol customization powerful enough for advanced users but simple enough that literally any normal user can use it confidently without making an error.
I genuinely think this could become one of the best customization features of Dictate Keyboard, because instead of giving every user the same fixed collection of symbols, it lets everyone build the symbols they personally use most — whether for chatting, studying, mathematics, programming, another language, professional work, or simply personal preference.
Please consider implementing it. I believe the combination of a fixed, familiar keyboard layout and extremely simple visual customization would make this feature much more useful than the current approach, while still keeping the keyboard clean and easy to use.
Feature Request: Powerful but Extremely Simple Custom Symbols / Secondary Layouts
I would like to request a Custom Symbols / Custom Secondary Layouts feature.
HeliBoard already demonstrates how powerful this concept can be through its secondary-layout configuration, and I have attached screenshots showing how I currently use it. Please take HeliBoard as inspiration for the capability, but do not copy its configuration UX. Its JSON/manual configuration is powerful but too easy for an ordinary user to get wrong.
The main goal here should be:
Why this feature is genuinely useful
The default symbols provided by a keyboard are necessarily generic.
A symbol that is extremely useful to one person may be almost useless to another. This varies by:
country and language,
profession,
study/work requirements,
mathematics/programming/science usage,
chatting/social-media usage,
personal preferences,
and even individual frequently used Unicode characters.
For example, one user may frequently need:
₹ ≠ ≈ ∞ √ π ≤ ≥ →
while another may want:
© ® ™ § ¶ † ‡
and another may want decorative/chat symbols.
Often the user can find exactly what they need by searching the web and copying the Unicode character. A site such as CoolSymbol demonstrates how many different Unicode symbols users may want to discover.
Unicode itself states that Unicode characters can be used without obtaining special permission from the Unicode Consortium. So the keyboard could safely provide a curated collection of Unicode characters as defaults, while avoiding copying any third-party site's proprietary presentation or content.
The important idea is:
Something like:
Secondary layouts
Symbols
More symbols
Custom symbols OFF
When the user enables it:
Custom symbols ON
Edit custom symbols >
This should be a normal customization feature, not a developer/debug feature.
It can be placed under an Advanced/Customization section if necessary, but it should still be a proper supported user feature.
This is probably the most important UX requirement.
HeliBoard's approach is powerful because the user can manually define layouts, but ordinary users can easily make mistakes with:
spaces,
line breaks,
ordering,
number of keys,
missing entries,
extra entries,
etc.
Instead, show the user an actual visual keyboard editor.
For example:
Custom Symbols
[1] [2] [3] [4] [5] [6] [7] [8] [9] [0]
[✓] [•] [∞] [√] [π] [≠] [≈] [±] [×] [÷]
[≤] [≥] [→] [←] [↑] [↓] [↔] [₹] [€]
[©] [®] [™] [§] [¶] [†] [‡]
The exact default symbols are up to you.
The crucial thing is that the keyboard itself becomes the editor.
The user doesn't need to understand any syntax.
The custom layout should follow the same physical character-key geometry as the English QWERTY keyboard.
Conceptually:
10 keys
10 keys
9 keys
7 keys
So:
1 2 3 4 5 6 7 8 9 0
Q W E R T Y U I O P
A S D F G H J K L
Z X C V B N M
The exact key widths/offsets should follow the actual keyboard implementation.
Other keys such as:
Shift
Backspace
?123
comma
language switch
Space
period
Enter
remain unchanged.
This is important because switching from English → Symbols should feel like switching the contents of the same keyboard, not opening a completely different grid.
On the first Symbols page, I would keep the number row:
1 2 3 4 5 6 7 8 9 0
because users commonly need those numbers there.
Then the 26 alphabetic positions become customizable symbols:
10 positions
10 positions
9 positions
7 positions
Therefore:
10 permanent numbers + 26 customizable symbols.
This is especially useful because many of the current "secondary" symbols could now be promoted into the user's frequently used primary symbol layout.
On the next symbol page, I recommend making all 36 character positions available for additional symbols:
10
10
9
7
Rather than permanently repeating 1–0.
The user already had 1–0 on the first Symbols page.
Those ten positions are therefore much more valuable as another ten custom symbols.
So the second page can provide:
36 additional primary symbol positions.
The developer may choose a different default arrangement if there is a strong UX reason, but the principle should remain:
Anyways, like if any user still want to keep the numbers on the second layout, he can manually type.
This is important.
When a user enables Custom Symbols, do not show an empty keyboard.
Every primary position should already contain a useful symbol selected by the developer.
For example:
✓ ✔ ✗ • ◦ ° ∞ ≠ ≈ ±
√ π ≤ ≥ × ÷ → ← ↑ ↓
↔ ⇒ ⇔ ₹ € £ ¥ © ®
™ § ¶ † ‡ …
The exact selection is your design decision.
The user can then replace anything they don't like.
This makes the feature immediately useful even before the user customizes anything.
It also guarantees that the physical layout can never accidentally collapse because a user forgot to define a key.
You can pre-fill several symbols which you actually think as important and useful by default by googling or by searching online from websites.
A physical character position should not disappear simply because the user didn't enter something.
For example, if there are 36 positions, the application should always have 36 primary values.
If the user changes one:
π → ∑
only that position changes.
If they don't touch another position, its default remains.
If they try to delete the primary symbol, the cleanest behavior would be something like:
rather than allowing an empty physical key.
This guarantees:
Each primary key should independently support additional long-press characters.
For example:
┌─────┐
│ ✓ │
└─────┘
Tap the key → edit it.
The editor could show:
Primary
[ ✓ ]
Long press
[ ✔ ] [ ☑ ] [ ✅ ] [ + ]
The + button adds another long-press symbol.
The user can add/remove/reorder them.
Another key might have:
Primary
[ ∞ ]
Long press
None
That is completely valid.
There should be no requirement that every key have the same number of long-press options.
The main goal is not to design a system that adds extra spaces or symbols when assigning multiple characters to a key on long‑press; it should stay simple. If you insert spaces—whether one, none, or three—the individual characters will no longer appear distinct. In the Heliboard this is problematic: using two spaces or no space at all disturbs the layout, and using three spaces breaks it. So avoid repeating this mistake. When you assign many symbols to a single key, you must ensure they are separated by a single space; without that space the characters merge, and with too many spaces the layout breaks. Presenting them box by box or handling spacing correctly will prevent these issues.
I think the best UX would be:
Normal view
The user sees their keyboard exactly as it will appear.
There is a pencil/edit button at the top.
Tap pencil
The keyboard enters editing mode.
Tap a key
That particular key becomes selected/enlarged.
The user can directly change its primary symbol.
A small + allows additional long-press symbols.
Tap Save / Back
The configuration is saved.
The user should be able to understand the entire system without reading documentation.
The preview should look as close as possible to the actual keyboard so the user can immediately understand:
That is much better than asking users to imagine the result from a JSON file.
This is another important point.
The fixed geometry should not mean the developer restricts the symbol choices.
A user should be able to put essentially whatever appropriate Unicode character/string they want.
For example:
∑
∞
₹
Ж
अ
Ω
✓
→
©
or any other supported character.
They can even put the same symbol in multiple positions.
That is fine.
The keyboard doesn't need to police whether the configuration is "optimal."
The user owns the layout.
The application only guarantees that the physical keyboard structure remains intact.
Do not unnecessarily prevent emoji.
A user should be free to put:
❤️
😂
👍
🔥
✅
wherever they want.
However, users should understand that emoji may render as colored glyphs.
If they place emoji as primary symbols on the main QWERTY-linked layout, they may naturally notice that those keys look colorful. That's a consequence of their customization, and they can change it if they don't like it.
There is no need to impose an artificial restriction.
For many users, emoji will actually make sense on their custom secondary layouts.
This is perhaps the broader design philosophy.
The user isn't just creating:
They are effectively creating their own keyboard layer.
For example:
First layer:
Frequently used symbols
Second layer:
Mathematics
Third layer:
Personal shortcuts / special characters
Long press:
Additional variants
A user could even use a position for a character from another language if that is useful to them.
So the system should be flexible enough that the developer isn't deciding what the user is "supposed" to put there.
This should absolutely be included.
There should be:
Custom Symbols
Export
Import
And the normal keyboard:
Backup / Restore
☑ Custom symbol layouts
☑ Primary symbols
☑ Long-press symbols
☑ Layout configuration
The user's complete custom configuration should survive backup/restore.
This also allows users to share their layouts.
HeliBoard proves that a system like this can be extremely powerful.
The attached screenshots show that users can manually define their desired symbols and long-press alternatives.
That is the right level of freedom.
But the configuration method is too technical for many users.
So the ideal solution is:
The user should never need to understand:
JSON syntax,
commas,
spaces,
row lengths,
key counts,
internal layout ordering.
The application should handle those things internally.
If I had to reduce the entire request to one sentence:
That is the experience I would prioritize above everything else.
The feature should feel empowering rather than technical.
A technically sophisticated user can still get enormous flexibility, but a completely normal user should be able to open it, see a familiar keyboard, tap the pencil, and immediately understand what to do.
I was using the heli board from very longer time. So I feel that feature literally missing here. I am also attaching what symbols I was using.....Please decide/ set the custom default symbols by yourself..
Primary Symbols
✓ ✅
• ● ⬤
| ║
= ≠ ≈ ∝
₹
∵
( { [
) } ]
@
↑ ↓ ← →
_ ⎯
&
×
÷
< ≤ « ‹ ⟨
" ❛ ❜ ❝ ❞
'
:
!
?
~
Seondary Symbols (More Symbols)
%
`
∝
√
π
°
●
❛
❜
∆ ∞ ¶ §
꧁ ꧂
★ ✪ ❀ ✿
✅
❌
^
❓
★
{
}
$
👉 👇 👈 👆
⭕ 🟢 🔴
;
❝
❞
[
]
< !fixedColumnOrder!3 ‹ ≤ «
You can absolutely rethink the implementation and come up with an even better approach. The most important requirement is the user experience: setting, editing, replacing, and adding symbols should feel ultra-simple and completely intuitive, even for a non-technical user.
HeliBoard is a good reference for understanding the capability, but its JSON-based configuration can be difficult for ordinary users and can easily lead to formatting mistakes. I personally mainly use it for its symbol layouts, so even if implementing every possible type of secondary layout is too much initially, a polished Custom Symbols feature alone would already be extremely valuable.
Ideally, a user should be able to look at the keyboard on the screen, immediately understand where every symbol will appear, tap the pencil/edit button, tap any key, change its symbol or add long-press options, and save — without having to understand JSON, separators, spaces, row numbers, key counts, or any technical configuration.
At the same time, the implementation should make it practically impossible for a normal user to accidentally disturb the keyboard structure. The 10–10–9–7 QWERTY geometry should remain stable, while the symbols themselves can remain completely user-controlled and flexible.
Please feel free to improve upon all of my suggestions and design the final interaction in whatever way you think is best. My main request is not a particular UI or file format; it is to make personal symbol customization powerful enough for advanced users but simple enough that literally any normal user can use it confidently without making an error.
I genuinely think this could become one of the best customization features of Dictate Keyboard, because instead of giving every user the same fixed collection of symbols, it lets everyone build the symbols they personally use most — whether for chatting, studying, mathematics, programming, another language, professional work, or simply personal preference.
Please consider implementing it. I believe the combination of a fixed, familiar keyboard layout and extremely simple visual customization would make this feature much more useful than the current approach, while still keeping the keyboard clean and easy to use.