In my early transition, I also had to work at my exact position - especially where my elbows were. It was a bit annoying but I still found the TB to be so much nicer in other ways that I still didn’t want to go back. Now I don’t even think about position. In fact, right now, I see that my right elbow is exactly in the WRONG place - it’s where I used to have it with regular keyboards, right against my side. Doesn’t seem to matter now but it sure did for awhile.
Of course, back then we were also dealing with flaws in the TB - like swapped characters so it was hard to be sure if it was user error or TB error. That isn’t the case now so maybe the transition will be faster in this particular area.
A long time after I changed the green layer timing, I started getting the opposite problem - though more rarely. I would want a “(” or maybe it was the other one and I’d get the regular character. So I switched it back to neutral position. I will get my original problem as a result on rare occasions, but clearly my typing adjusted over time.
Many of my boundaries have also changed over time. In either case, I’ll start noticing a pattern to such issues pretty quick and if they persist, I make an adjustment. I recommend just doing one at a time though and see what happens. You likely know what characters tend to give errors so just pick your worst one (that has a boundary change possible) and do that to see what happens. I think that is better than doing a bunch. Well, other than the quote/enter boundary. I change that one to favor the quote pretty quick!
The boundaries and filters all used to just have 3 choices. Boundaries later gave 5, which is much better. For example, with Dvorak, I’d often get T instead of W (K vs comma on qwerty). So I’d kick it over one position to favor the W. It definitely reduced the problem but didn’t go away. So I moved it to the far side. Others I had to move back to a less extreme position. But as I said, over time my typing adjusts and I have been able to move more of them back to neutral. I hope that the filters can later get 5 positions too.
Physiology, from the width of your shoulders, to the lengths of your arms (both upper and fore), to the width of your hands and the lengths of your individual fingers, is going to dictate how you interact with the TextBlade. For example, if you have shorter than average pinkies, you are going to have to pivot your hands more to use the pinky keys that aren’t on the home row. If you have wider shoulders, you might require a greater degree of ulnar deviation when typing. These things are true for any keyboard. A standard keyboard is much larger and has more distinct keys that require greater finger travel, so it is likely more accommodating to greater physiological variation. The fixed angle of the TextBlade and its small size are also going to limit the placement that optimizes ergonomic gains (maybe not more than a standard keyboard would but in different ways). Because people are so varied, there is no single optimal angle for the TextBlade, so WayTools (I’m assuming) chose an angle that required the least amount of compromise from the greatest number of users. Then, WayTools added the option to change the boundaries of the key detection zones when they got enough data to determine that too many users were having accuracy issues.
I suspect that if the TextBlade had more discrete keys or had gaps between keys, there would be less need to modify the key detection boundaries. I also suspect that a design that allows the user to adjust the angle of the blades is something that WayTools has considered for future research.
FYI - we built (and patented) alternate configurations with split keys for index and pinky fingers. So 12 keys total instead of 8. It wasn’t as good as we expected.
12 keys didn’t test as well with users as the TextBlade architecture. There’s something magical and resonant about the one-key-per-finger paradigm. It’s less physical labor to type, and cognitively far simpler to stay aligned with the home row.
Tried changing the green layer timing (slower), and also the v/b boundary. After an hour I changed the v/b back and I seem to be doing better than prior to monkeying w/ the boundaries. Possibly I’m just more careful about that key because I’ve been thinking about it.
The green boundary change seems an unalloyed win so far.
At some point - AFTER the major update - I’d love to hear more about this since it is something I’ve wondered about from the start. The single “advantage” I see in a regular keyboard is the totally separate keys. You either hit the right one or you don’t. Very simple, at least in comparison to the TB.
I could see the narrow keycaps on the TB as perhaps being necessary because individual keys may really suffer from whatever mechanism (butterfly or whatever) you chose to use at such small sizes. But since the 6 character keycaps greatly increase the complication of hitting the wrong spot, I wondered why they couldn’t all be 3 character keys.
True, the characters on the ends are on narrower parts of those keys and, if separate, that may create issues I don’t have the knowledge to know about. But then, no reason I could see why those keys couldn’t be made the same width. Certain is room towards the center by just making the metal connectors narrower. And you can always expand to the outside - you’d simply have a TB that is ever so slightly longer. Considering the competition, that seemed like a non-issue!
So, I’m trying to figure out why that would be an issue. Based on my experience with the TB, I certainly assume you are correct, but some day I’d like more insight into it.
I’d also like to know who came up with the original basic concept because while many things are clever about the TB, I’m most impressed that someone even got the basic idea in the first place! That “basic” stuff would be doing everything with just 36 places to put your finger (not counting the space bar) and doing everything else in layers. The details in implementation certainly are important too and in many areas, I’m impressed with the choices. But without that starting concept, we never get to the other details!
The 8 keys on the TB also have indentations on each of the keys to provide a tactile feel for your fingers when they are in the proper “home” position. Additional keys would probably lead to having your fingers off by one key in either direction at times leading to garbled input. I’ve had this problem on regular keyboards and like that I don’t have that issue with the TB.
I can see potential issues, but not particularly about the indentation and extra keys - at least not any more than with any other keyboard. If just extra key CAPS (12 instead of 8), the indentations would essentially be the same - just a slight wider end section to make them all the same size.
ADDITIONAL keys, such as adding a separate key for command, etc, could be a nice option, but not for the present concept. Some extra keys on, say, a laptop that used the TB concept could be useful to some who just don’t want to learn new chords. And if it was also programmable, it would be even better. In this approach, I could see a place for a separate command, control, alt, and esc keys - BUT everything else would work as what we have now. These would just give options in a situation where the space is available and not needed for anything else.
I agree with dbk. I see no need for additional letter and number keys. However, my one issue is with the space bar where I think it would be better with the hot corners on separate keys. Often, when holding down the space bar to get to the green layer to type a number, my thumb gets too close to the Command hot corner and instead of typing a 5, I get a new tab in the browser (command-T).
For me, based on the present TB, any additional keys would have to be add-one - assuming that could be done. But if a TB version were to be created in a laptop or as a permanent keyboard (not foldable), then I could see extras. After all, the space would be available. But on the present version, we need to keep the extreme portability.