1. 32
    1. 11

      Restores my faith in the whole industry.

    2. 6
      how do I make it stop?
    3. 3

      This’d be great with one of those keyboards that has a little LED screen on each key.

    4. 4

      Thanks. I hate it. :P

      EDIT: tongue emoticon for good measure

      1. 3

        It is a very silly idea that was never meant to be useful.

        Even so, I’m considering training it on ten years of text I’ve typed and then actually learning all 26 layouts! Oh no!

        1. 3

          All 26 layouts? Shouldn’t it be all 26! layouts instead? >_>

    5. 2

      This kind of reminds me of colorForth’s dynamic keyboard. From here:

      Continuing my experiments with keyboards, I currently prefer using 27 keys to provide the 48 characters needed. These are the home keys of a standard 101-key keyboard, allowing the other 74 to be ignored. The assignment of the keys changes, with the current one displayed on-screen at lower right. It’s pleasantly easy to type while referring to the display. These keys minimize finger travel, as close to Dvorak’s arrangement as 27 keys permit. They are used as function keys (menu selects) for applications. The only text that needs to be typed is when editing source code. Other arrangements are possible. Including, gulp, standard qwerty.

      I think there may be something to these experiments, but by golly, the training process can’t be fun.

      1. 2

        Ah another one for my collection. I am currently reviewing all esoteric input methods and compiling them into a book. Boy do I have a long backlog. But it’s really interesting. A lot of them seem silly at first but on a closer look have a lot of interesting ideas. Currently I’m reading up on edgewrite, back when writing recognition and touchscreens controlled by styluses where at thing:

        http://tbf-rnd.life/the-book-of-lesser-known-input-methods/ along with the book i’m working on a framework for developing methods like this. The plan is to have code that can both benchmark them on humans computer generated text and demo them via js as well as plugging them into operating systems.

        To properly compare with a fixed keyboard keep in mind that you have been hacking away on your keyboard for decades. If you are presented with writing Greek letters for physics or whatever then your skills are totally useless. So a keyboard that shows the most probable keys onscreen might in have in fact be much easier to learn.

    6. 2

      Thw training corpus is Sherlock Holmes, and so if you really want to see this moving keys around for convenience try it with the words: the, said, xylophone, statuary.

    7. 2

      I am working on something remarkably similar. In fact it is a framework of sorts to try out different methods of sorts. There might be bits and pieces that might help you ought.

      https://github.com/TBF-RnD/alpha/tree/cleanup/odin This is the node based frequency profile generator

      Go to corpus/wikisample and run make and it’ll generate some json files with data. In lib and dict you’ll find a basic API for predicting. So it can match several symbols back.

      As we speak I am working on having it work on several dictionaries and switch automatically allowing for several languages etc.

      I intend ro implement a JSON based protocol to handle OS integration so that people like you can make experiments like this without the lowlevel parts. If you like these sort of things perhaps you could lend me a hand!!

      Can’t really try it out since I’m a VIM user for life and just the thought of spinning up emacs makes me feel sick ;) For these reasons I prototype in js so that the experiments can be demoed to a larger audience!!

      Seems really cool! Keep it up! I sincerely do believe that concepts like this have an place in UI!!