🗺 Keyman Roadmap - March 2020

Update: March 2020 roadmap now available!

We have now made a Keyman Roadmap available for review. Comments and feedback are welcome here!


It would be a huge help if a localization framework were added to the roadmap for Keyman (esp. for iPhone and Android) so that it could be localized for communities where most people do not read English. In our context, that means simplified Chinese – we could and would happily help with actual localization efforts, but right now there’s no framework for it. As a result, potential users are still non-users if they can’t understand enough English to set up Keyman and download an appropriate minority language keyboard on their smartphones.

1 Like

Thanks for the suggestion. I’ve added it as a feature request to localize the Android app.

FANTASTIC! I love it! This roadmap seems to address a number of things that have been on my mind regarding Keyman.
One major concern that is only hinted at is in regards to simplification of the development process. Such as extending the features which can be created using a GUI. I really don’t think this would be too hard to implement for at least some of the more advanced features such as dead keys and looping sequences accessed by multiple taps.
I also see that you’re already familiar with InKey and the Tinker language; many cues & features could be taken from that! Such as regex-based rules for one… It is also, in general, much more intuitive—at least to me.
Starting with no experience with either system, I have been able to develop an alpha prototype demo keyboard for a language of medium complexity much more quickly and easily with the InKey’s Tinker language than with Keyman’s development language.
Many of the keywords that Keyman uses for the various features are not particularly intuitive, and the syntax is either not well described or seemingly more complex than necessary. I’m not a software developer so my opinions and experiences are somewhat ignorant; however, I think that they also represent what may be discouraging a number of potential users.

1 Like

I think that Ukelele probably provides the best interface/GUI I’ve seen key for programming deadkey sequences; however, I think it would be a great improvement to edit deadkeys in a separate window or pane (with the main keyboard still visible & accessible), and to be able to see and edit multiple deadkeys simultaneously. I also think that the mappings on the other non-active layers need to be visible in a smaller font (probably color coded) at all times and in all states on every key.
Users also need to be able to modify the actual underlying keyboard (there are just too many variants available to be able to account for all of them!
KbdEdit for Windows is another potential source of inspiration for GUI implementations if needed, and features.

Another area that could use some TLC is the character picker. A feature that I feel would be much more helpful there would be to allow users to create a list of all the symbols needed for their keyboard (by clicking them in the “master” unicode list) and let the character picker only include those characters; or even allow multiple custom lists of characters to be mapped.

And if I understand that by switching from IE to chromium for Developer with will open it up for all platforms, YES! That is definitely the way to go.

A flaw that seems to be universal among all keyboard development tools has to do with limitations of the interface; a specific example being: when resizing the interface for a larger display (owned by a quickly increasing number of users), there needs to be more control or more intuitive behavior. For instance, when I enlarge the interface I don’t need the keyboard to get bigger, or any other element to expand by “zooming”- I need the character picker/palette to expand by increasing the number of character cells- not making the cells larger. Probably the ideal solution would be to make the interface very modular, with the individual panes/palettes being resizable regarding its footprint in the interface as well as the contents being resizable as well.

1 Like


I’m wondering what is meant by “Dictionary support” under “Predictive Text” in the Roadmap? I’m hoping it might refer to dictionary based input methods -I believe this is what the Simplified Chinese keyboard uses, but relies on IMX coding?

If this is what the topic is about, would the keyman keyboard language be extended to support dictionaries somehow? Or include a dictionary file into a regular keyboard file? Consider me available as a tester.



1 Like

@dyacob, Yes, there are two parts to dictionary support. As part of the predictive text design work, we want to see how feasible it is to build in support for dictionary-based input methods such as Simplified Chinese. If we can build a good plan, then we’d aim to include that in the predictive text development. For testing, that should be in the 12.0 alpha series so you can get on board as early as you like :slight_smile:

1 Like

It is wonderful to see the roadmap.
For mobile platform: please consider these two features for version 11.

  1. Multiple templates to match the xcode device list (ipad mini, ipad, ipad pro), (iphone se, iphone, iphone plus). same in Android. We are designing all the keyboards to two sizes, phone and tablet. As we know, phones and tablets have multiple screen size, system keyboards in these devices take advantage of the real estate and add more keys. iPad pro 12.9 has full desktop class keyboard.

  2. Also, there are couple of features in iOS, right handed, left handed in mobiles and spilt keyboard for iPad. Keyman doesn’t support it yet.

  1. If we can have optional key in the keyman keyboard to the system emoji keyboard. It will be a good enhancement.

Indeed. The challenge here is that every form factor adds more complexity to both testing and maintenance of a keyboard. We could go open slather and allow the developer to create a different layout for every size device, but then we lose the benefit of a cross-platform design! So finding the best compromise in break points for device sizes is what we are looking for. It’s certainly something we can consider in future versions of Keyman Developer.

for spell check feature, are we considering hunspell or other engine?

We have not yet made decisions on this.

1 Like

Is Windows is planned for Predictive text in version 12?

in the road map, its Windows is not included!

Predictive Text

  • Wordlist and FST support
  • Corrections
  • Word / phrase completion
  • Android, iOS and web platforms initially

No, for version 12, we plan to include predictive text support for mobile platforms only. Desktop platforms will be a future version.

has any documentation been created for the predictive text support? (I looked but couldn’t find)

Documentation for the predictive text support is still in early stages. Here are some documents, available for viewing:

1 Like

Hello Marc,

is predictive text planned for desktop applications in version 13?

No, we plan predictive text for desktop in a later version. It requires some significant architectural work in order for it to be feasible (and some big questions on user interface as well). We need to finish some refactoring of the existing codebase before we start adding in features like predictive text for desktops :slight_smile:

The good news is that when we do get to it, all the of the models created for languages for mobile devices will also work on desktop devices.

Suggestions for UI: you could look at
Windows 10 provides predictive keyboard for 10 Indic languages

Bhasha India, Microsoft for Indian languages have predictive keyboards for Wins 7, 8

Google Input Tools also has predictive/suggestions

Why not complete predictive/suggestion support for Mac OS now?

Primary reason we aren’t doing it now is we are a tiny team with a lot to do – and few resources!