Continuation from discussion on Typing git

[iandoug]

hi Hugh

Okay I've browsed around your repos a bit. Also had a look at keyman.com.

Background: the gory history in excessive detail is on my blog http://iandoug.com/?cat=12 which needs to be updated because there's been significant changes since episode 8.

At the moment I'm juggling between physical and logical arrangements of the keys. I guess Workman-P may not be optimal, and thus am looking at alternatives, and how to evaluate them.

The major problem is the standards (ISO/ANSI/etc) which are bad designs, and tweaking a bad design is not going to get the optimal result. Hence I ditched that layout in favour of more ergo shapes. My current version is drifting to somewhere between Maltron and Kinesis... I've moved things to thumb keys, including space, return, backspace, delete, and the letters e and t. The upside of this is that 24 letters remaining map nicely to a 4x3x2 grid... index finger now only has one column to worry about.

The downside of this is that all existing keyboard layout analysis programs will struggle with this arrangement.

Further, none that I have seen consider ortho vs staggered in layout. That's another typewriter legacy which should change.

As you may know, I'm involved with the Keyboard-layout-editor https://github.com/ijprest/keyboard-layout-editor and as such, propose the following:

1. Use raw data from KLE to generate an XML format (simply because I think it's more human-friendly than JSON). This data should include precise descriptions of what each key does when pressed, including with modifiers, and with Compose key. It should also include exact location (centre of key: x,y,rotation). For KLE purposes, it should also include other data like keycap colour, switch data, etc, which is not used for layout analysis. Using a KLE layout is good because then we can map physical much better than just a string of letters and assume it's 3 rows of 10.
2. With this data, a program could (in theory) allocate precise difficulties to any key and key combination. It should take into account duplicate keys (eg numerals) or alternate ways of achieving same result (eg if you can alt-gr é or get it via Compose), and pick appropriate use when required. Eg. typing 6 in between text will likely use numerals above letters, but entering columns of text in a spreadsheet will likely use the numpad.
3. Once we have the precise difficulties, then we can run assorted layout evaluations, knowing where all the possible keys may be. One could specify that certain keys are locked, and focus on the remaining key.
4. KLE does not include facility for entering all the required data, and I'm not sure if it ever will since it is not relevant to its main function. So I want to build a site that will allow that data to be captured.
   Yes this is making the analysis complex, but then we will be comparing apples with apples as well as gaining much needed flexibility.
5. In theory, having some model of average user hand size may be useful.

So now I need to figure out a sane XML layout for keyboards. I know SkullyDazed https://github.com/skullydazed was working on one, but Google won't show me at the moment. I'll ask him. I've looked at some this morning, including in your repos.

[HughP]

OS X uses an XML format are you familiar with that one? The technical documentation is here: https://developer.apple.com/library/mac/technotes/tn2056/_index.html I may be off my rocker a bit but in theory it should be extendable with additional attributes and still validate for OS X purposes.

[iandoug]

So I go Google and discover this cunning stunt...
http://apple.stackexchange.com/questions/44906/how-to-define-lion-s-key-variations-in-a-keylayout-file

Bit curious as to how it knows when to repeat a char... my "repeat timeouts" are set rather low since I hate waiting for the keyboard.

I took a look at the doc and realised how ignorant I am of formal XML definitions. Will take another look later. Not wild about some of their abbreviations though :-)

Thanks, Ian

[iandoug]

Hi Hugh
Do you perhaps recognise the file format used here?
http://bvofrak.blogspot.co.za/

Thanks, Ian

[iandoug]

Looks like it's the export format here:
http://patorjk.com/keyboard-layout-analyzer/#/config

[HughP]

I have been in discussion with patorjk (in the past). I have some of his code. he has a release here: https://github.com/patorjk/keyboard-layout-analyzer

[iandoug]

Ah good thanks, I see I have forked that repo recently, but most recent memory was from his site where he said he wasn't going to release the analyser code.
Don't suppose you know what happened to Anang's analyser? All I can find is the wayback machine pages, but sans the actual analyzer.

[HughP]

No, I don't know what happened to the actual code on that. It was already in the Internet Archive when I started looking into this problem space. The only other ones I sorta know of is the heat map thing https://www.patrick-wied.at/projects/heatmap-keyboard/ and http://spwebgames.com/keyboard/ there is also some discussion about different analyzers in my REPO. It's been a year since I was doing active commits to the repo.

[iandoug]

http://adnw.de/ has an optimizer/ analyzer that only works in UTF-8.
Will help if you know German.

You want
Optimierer als C++-Quelltext, Häufigkeitstabellen für Deutsch und Englisch, Anleitung.
http://509.ch/opt.7z

The file has English docs in the PDF.

[iandoug]

Since we last spoke I have become heavily involved in keyboard layout optimisation...
Patrick's KLA supports unicode AFAIK (well certainly European accented characters I think).
Will check for you. You can specify other Unicode chars on the keys quite easily.

Have been co-operating with Den (shenafu.com), he has made some changes to the algos.

There's a LONG discussion between us and others here:
http://shenafu.com/smf/index.php?topic=89.0

Regret my focus has been on English rather than anything else, but the Seelpy/Essie ideas may give you a different direction to take things. Particularly if you have a lot of characters/sounds to map to a limited keyboard.