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.
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.
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.
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.
@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
It is wonderful to see the roadmap.
For mobile platform: please consider these two features for version 11.
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.
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.
- 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.