My thoughts as a new user (UHK80)

General
1

I bought the UHK80 a couple of weeks ago. This is my first programmable keyboard, and I am happy with that, starting my journey with home row keys, etc.
But there are some things I don’t like that much:

  • the wrist pad is ending exactly where my hands are placed. And that way, they are annoying over time. And they could be a little bit softer for my taste.
  • I got the trackball, and I am operating it with my thumb - the ball and the mouse keys as well. I would like to have the keys above, not below the ball. So I could keep my thumb on the ball and press the mouse key with my index finger.
  • I am using some special keyboard layout (NEO-qwertz), but on a few occasions, I use the normal operating system’s layout. I had to mimic a NEO layer with a UHK layer. Quite some work, but I got different results depending on the OS layout. Now I found out that makros with Unicode sequences can solve my problems. Finally, here’s my wish: I don’t want to create makros for my many characters, I want to have a Unicode option in the UHK firmware. In the “keypress” tab, for example.
  • the physical keys are all a bunch of keys without a feelable separation. Just a small space between the two right most columns could provide that, I think. And I hope it would not make the UHK too big. But at the moment, I have to search for e.g. the Home key, maybe I will get used to it of will find a home row mod.
1 Like
2

Have you seen this topic? Usecase: Thumb Trackball :wink:

Regarding NEO, I would suggest using a normal qwerty on uhk side, and choosing neo as your host OS layout. Unicode support on UHK side is troublesome because every OS uses different unicode bindings and because UHK does not know what OS the host PC is running. Not that it wouldn’t be possible, but Laszlo doesn’t think it is worth the trouble. (I can see his point.)

3

Thanks for the quick answer, but I stated that I sometimes do not have NEO as my OS layout. You are questioning my use case, not providing a solution.
If there’s such a problem with the Unicode bindings, then why is there the tapKeySeq CS-u at all in the FW? My naive thought is that it would not be too much effort including it in the key configuration dialog.
Your trackball solution requires activating the mouse layer? Sorry, that’s another step I want to avoid.

4

This bugs me a little as well. I’d like the palm rests to extend maybe a couple centimeters more toward the wrists. It’s usable as is, but a little uncomfortable.

I only have a Touchpad module, but I agree that having the buttons at the top of the trackball module would be a much better placement if you use your thumb on the ball.

As for the navigation columns; I got used to it pretty quickly. Hopefully you will too.

5

@pcooke9 What’s your experience with your UHK 60 in this respect? Is its palm rest long enough?

I’m sorry, but we don’t plan to implement the suggested design, because there’s no space for the key switches in the module, and stretching fingers so far would not be comfortable for many.

I don’t think you’d easily find the Home key if the rightmost column(s) were separate. The issue is rather that there are too many keys vertically in the rightmost region. Using a special Home keycap with a homing bump may help.

6

I stated that I sometimes do not have NEO as my OS layout.

Ah, I see. Then tapKeySeq macros are indeed your best bet unless you prefer to do custom coding.

If there’s such a problem with the Unicode bindings, then why is there the tapKeySeq CS-u at all in the FW?

Well, the command is tapKeySeq, not tapKeySeq CS-u. There is nothing special about the CS-u - it simply means Control+Shift+u.

tapKeySeq is for triggering custom key sequences. It was not designed for altcodes specifically.

Please note that every OS needs a different tapKeySeq sequence.

My naive thought is that it would not be too much effort including it in the key configuration dialog.

Graphical UIs are Laszlo’s domain, but his reasoning would mention that this is a niche usecase that justifies neither the additional GUI clutter, nor coding time and resulting maintenance burden.

Furthermore, the fact that we would have to implement at least 3 different solutions (for different OSes) and further burden the user by manual host OS choice (as UHK doesn’t have that information from the host) doesn’t help. Yet more, implementing a special-case gui for this specific usecase would solve only this one special case, while it would leave a number of other similar issues unsolved.

This leads me to a more general problem of how to parametrize macros. I would love to add a way to easily parametrize macros, but in order to do that, we have to figure out a reasonable way how to expose that feature to the user. For that, I had already tried to kickstart a discussion at Parametrizable smart macros: brainstorm for future specification .

We didn’t move very far, which I among other things take as a lack of interest from the community.

Of course you are welcome to participate in the discussion, or to try to change Laszlo’s mind.

Your trackball solution requires activating the mouse layer?

No. The setup works directly in the base layer.

The solution triggers mouse layer only to faciliate rocking gestures, browser shortcuts and the scrolling navigation mode. (Your original suggestion (additional buttons above the trackball) suffers exactly the same limitations regarding the scroll navigation mode. Feel free to open that topic as well in case that (navigation modes being coupled to layer activations) is what you are complaining about.)

Of course you are welcome to bind stuff however you like.

7

The UHK60’s could still be just a little longer, but it feels much better than the UHK80.

The edge of the UHK80’s palm rests end in the soft part of my palms. If I relax my hands, they rock outwardly (especially when in tenting mode). That makes my fore-fingers and thumbs lift away from homerow/spacebars. This causes fatigue faster due to the frequent repositioning, and a bit of cramping in the little fingers (since they tend to get used as an anchor while searching for the homing keys).

With the UHK60, the palm rest is just long enough to support the top part of my outer wrist bones. That provides stability and prevents rocking outward. This also keeps my wrists as the positioning anchors, instead of my fingers.

I think the UHK80’s palm rest could be roughly 1/2" longer.

And now that I think about it; this extra motion (focused on smaller pressure points) may be contributing to some of the bubbling pad issues. I don’t have rubber palm rests on my UHK60, so I can’t be totally sure of that though.

2 Likes
8

Yes, I use the navigation cluster a lot and this is one of the hardest things for me getting used to. Even after months of use if I’m a little bit tired I tend to press the wrong key and in general it requires more focus and is more tiring to use this type of navigation cluster.
I understand the design intentions behind this type of navigation cluster, but in general I think the “normal” navigation cluster that comes with an average keyboard is unbeatable from an an ease of use perspective. There is also the right control that is in a different position compared to the general keyboard layout. I’ still pretty often land on the left arrow when coming back from the navigation cluster and trying to hit control from there.
I’m now working on switching to using a layer for navigation, but in general I’m very bad with switching already learned muscle memories.

It does not mean this is bad, it is just a personal preference.

I know there is no plan for this but my wish would be to have this same keyboard with the common TKL layout and the real ISO enter (except the top row, I don’t care too much about that). Regarding the ISO enter: I know the saying is that this is more ergonomic this way, but in reality I don’t feel it to be more ergonomic in any way even if that is the theory and it really took me some time to getting used to the small enter and the small backspace and I’m still fighting with it a bit from time to time after a few months.

Whatever, there is nothing that fits everyone, and this is still the only split keyboard that comes close to my needs.

I plan to do a longer review at some time in the future summarizing my experiences.

9

This pretty well sums up how I feel about the UHKs. Any nitpick I may have about em is quickly forgiven whenever I have to type on something else.:slightly_smiling_face:

10

Just wanted to chime in that I also think the wrist pad should be longer on both the UHK 60 and 80. I am a large guy with large hands, and so unless I arch my fingers at an uncomfortable angle, the wrist pad ends about an inch up from my wrist, into my palm. I was planning to buy a 3D printed extender for the UHK60 and then I got the 80.

11

I’m a big dude too. I’m somewhere around 6’ 2-3" (I’m wheelchair bound, so :man_shrugging:). My hand length is a little over 8". My fingers naturally want to rest about one key row higher.

12

I am a little bit surprised that there should be no space for the keys at the upper side of the trackball - I rather thought that probably you and your testers prefered it the way it is.

For the keycaps - yes, I was thinking of that, too. But it was hard enough to invest in the UHK already… maybe you could keep the different keycaps in mind for future development?

13

I was not aware that different OS need different sequences. But would that not strengthen the case for a simple “send this Unicode character” option in the firmware? Not depending on the OS.
Or is there already a good solution I missed?

I will check your trackball solution, my glance into it was probably too quick :wink: Thank you.

14

Adding homing bumps to select UHK 80 keycaps is an option, but only if there’s a solid consensus on which ones.

Implementing this on the firmware level doesn’t feel right. I’d rather prefer this to be implemented via macro templates, which is a planned Agent/firmware feature, very general in nature.

15

Well. Firmware doesn’t send characters to the computer. It sends scancodes (more at How can I type accented characters with my UHK? - Ultimate Hacking Keyboard ).

Whether that strengthens or weakens the case is a question, as the scancode sequences needed to trigger the respective altcodes are still different and uhk doesn’t know which system it is connected to, so the user would have to provide that information.

Personally I am not opposed to implementing it as a core feature. After all, from a user perspective, it would be cool if emojis could be mapped as easily as copy pasting them or even just selecting them from a dropdown. We already have default keymaps customized and named according to the intended OS, so storing an additional flag that would tell the firmware for which OS it is intended wouldn’t be all that a big deal.

16

I do not understand the answer about firmware sending unicode characters. The keyboard does not send the characters, but only the key position. Then the OS comes into play. And Volker, I am sorry to say, there is no simple solution as soon as you go away from just using a US English layout. You will sooner or later find situations where the keyboard will not trigger what you want it to do. That is because how the OS interacts with the keyboard.

On Windows the scancode (which basically is the key position on a standard ANSI, ISO or JIS keyboard) is linked to a keyboard layout which you choose as a language. In the keyboard layout itself there are two definitions. That is first a virtual keycode. You find that in documentation often as VK_… And a key also is assigned a unicode character. But those are two definitions made in the keyboard layout file. Depending if a program queries the scan code, the VK or the character it can behave sometimes in ways which are unexpected. That is because many (most) programs assume you are using a US layout.

What is the best solution to realize your NEO-QWERTZ layout? That depends on the access you have on the PCs you are using. You will get the least problems when you choose a language / keyboard layout which implements your wanted behavior. I am not sure if there is a layout you can download for NEO-QWERTZ, but think so. Otherwise one could create one with kbdedit (paid software, but not too expensive), or with some limitations also with Microsoft Keyboard Layout Creator. To install the layout you will need admin rights.

If you can not change the keyboard layout on your PC there will be no way from the UHK alone to directly give you the greek characters and so on. You can partially work-around with the macros although, with the limitations mentioned.

Another option is to use a software to remap your layers in the way you want. Kanata works great for that. But here you will also find some niggles, for example auto-repeating might not be working and things like that.

Finally, if you are happy with the Neo layer concept that is great. I personally find it much better to create your custom layers – which use layer switching keys which are easier to reach than what Neo does (also does not work well with an ANSI-keyboard).

You might find my article about DeutschlandPlus interesting. I also have published three newer articles with lots of thoughts about creating or finding your personal best keyboard / layout solution.

My articles are on kbd.news:

In summary: for a few characters and symbols I would introduce a layer to be accessed with the CapsLock key (position) as the layer switch. Add a navigation layer with the held space key (SpaceFN concept) and you should be happy. If you need a few symbols like greek characters and so on, use a text expansion program and define what you need. Way more flexible and easier to type. For the latter I can recommend Espanso.

3 Likes
17

The additional flag sounds good to the UHK newbie me :wink:

18

Regarding homing bumps…

Why don’t you make them yourself? You can either replace the two columns with different keycap profile, or just add small bumps to the existing caps using a suitable medium. For instance glass paint (the peelable kind; black contour) works like a charm.

In my opinion this isn’t something that should be coupled to a keyboard design / manufacturer, as every user has different preferences and needs and it is easy to customize at home.

2 Likes
19

Thanks very much for the suggestions, I will look into them. But I am used to the NEO approach and don’t know if I want to learn another layout.
BTW: I only use the first four layers, so no greek letters needed.

In all the answers to my post, I learned that there is much more to this topic than I thought. My dream scenario would be a UHK that is as independent of the computer settings as possible, so I can take the keyboard to any PC and any OS/VM that is installed.

Thanks to everyone for your replies!

1 Like
20

Yes, I will probably do that. Some stickers will be my first try, I guess.

1 Like