Good news, everyone! After so many of you have expressed your desire for an ISO version, we finally decided to make it along with the ANSI version.
As for the Enter key, we will only provide bar-shaped Enter which might beg for some explanation.
The main reason is that bar-shaped Enter is more ergonomical. This layout also allows us to make the rightmost UHK keys shorter by half unit than on most keyboards, which makes the UHK more compact, and the keyboard halves more symmetric.
According to our experience, it's very easy to get used used to the bar-shaped Enter key. You can even swap the functionality of the bar-shaped Enter key and the "\" key above it on your UHK, making the "\" key send Enter.
Feel free to read why the bar-shaped Enter key is more ergonomical.
Some of you told us that you want an ISO version of the UHK so we've sent out a survey and received a whopping 1,372 responses over one week! Wow! It's truly exciting to see such an awesome, active community and let me just take the opportunity to thank every one of you for participating. We think that we learned quite a bit so let us share the questions, the responses, what we learned and the road ahead.
There was a text box at the end of the survey where you could enter your suggestions so let's start by addressing the 10 most popular ones.
It's important to note that question 2 and 3 were only visible to those who choose the ISO layout in question 1.
ANSI layout (featuring a bar shaped Enter key)
ISO layout (featuring an L shaped Enter key and an extra key next to the Left Shift key)
I'm fine with the ANSI Enter key despite being an ISO user.
I'd prefer a small ISO Enter key.
Only a full sized ISO Enter key works for me. (Please note that this would make the keyboard wider, more asymmetric and increase development time substantially.)
I don't need a dedicated ISO key. I'd rather map Mod+Z (or some other shortcut) to the ISO key.
I need a dedicated ISO key.
The above chart was filled out by all the 1,372 of the participants and the ISO-specific answers below were filled out by 450.
We expected those who choose the ISO layout to heavily insist to have a dedicated ISO key but oddly most of you choose the "Without ISO key" option. This clearly begs for some explanation so in order to gain a deeper understanding we looked into the keyboard layouts of various countries. As it turns out there are 3 main categories of country-specific ISO layouts regarding the ISO keys.
[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"]
First up, it's important to realize that even though the above is the German layout, its ISO key yields the same characters as the Austrian, Croatian, Finnish, French, Greek, Italian, Latin American, Norwegian, Polish, Portuguese, Serbian, Spanish, Swedish and Turkish layouts so we're talking about a vast number of countries.
Let's name such layouts as "relational ISO layouts" because here the ISO key produces the < relational operator in itself, > when pressed along with Shift and | when pressed with AltGr. These are rather rarely used characters and in 2 of the 3 cases a modifier needs to be pressed to invoke them anyways so the ISO key doesn't seem to be that critical for this layout. One could easily map these characters to Mod+N, Mod+M and Mod+, respectively without significantly affecting productivity, according to the following mapping:
| UHK key combination | Scan code sent to the host | Resulting character |
|---|---|---|
| Mod + N | ISO key | < |
| Mod + M | Shift + ISO key | > |
| Mod + , | AltGr + ISO key | | |
[/fusion_builder_column][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"]
The above is the UK layout and its ISO key yields the same characters as the Irish, Romanian and Russian layouts. In the same vein, \ and | are rarely used characters and they can be similarly mapped to the Mod layer without really affecting productivity.
[/fusion_builder_column][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"]
The above is the Hungarian layout and it's a special case because its ISO key yields letter Í which is part of the Hungarian alphabet. The Bulgarian layout is similarly special with its ISO key yielding letter Ѝ, part of the Bulgarian alphabet.
Even though the ISO key can be mapped to the Mod layer, in these situations this approach may be less comfortable given that we're talking about a letter of the native alphabet of these countries. In any case, these two countries only include 15 million people which is 0.2% of the population of Earth. (As a Hungarian I don't want to belittle these people, I'm merely talking about statistics.)
We think people have reevaluated the significance of the ISO key when presented with an alternative option, namely to map the ISO key to another layer. In light of this realization and according to the above the ISO key doesn't seem so critical. Some people won't be able to live without it but according to the statistics they're the minority of the ISO users.
You know what's the most surprising to us? We, as Hungarians thought that the ISO keys of all countries always feature a country specific letter but according to our research there are only 2 countries where this is the case. From our perspective this hardly justifies having an ISO key in most cases.
According to the statistics 64.95% of the participants who choose the ISO layout want an L shaped ISO key. It's very surprising for us because we thought that the ISO key is the main reason why people prefer the ISO layout but according to the above it's the L shaped Enter key. Also, we'd have thought that it's harder to get used to the Mod key than an alternative Enter key. How's that?
According to the above there's a need for ISO but it's not so big to justify making separate ANSI and ISO versions for a small startup like us. This doesn't mean that we won't ever release an ISO version but probably not for the first time.
We might have came to wrong conclusions here and there. As always, you're welcome to let your voice heard in the comments below.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
If you've checked out our site then you must already have a good idea of what you can expect to have when your package gets shipped. Regardless, we thought that we should clarify what's in the box by creating a nice illustration and listing the items one by one.
From top to bottom:
We've already said some words about the permament interconnection mechanism, but no words have been said about the spring cable, so here it goes:
We provide an extra spring cable besides the retractable cable because some of you have expressed concerns regarding the durability of retractable cables. We've talked to a number of retractable cable manufacturers and we think we have chosen a reliable one but just to address your concerns we will provide a spring cable, too.
Security is a serious business but more often than not it gets overlooked. Ideally, it should be part of the design from the get go but people are prone to overlook it given the huge number of seemingly more urgent issues to be taken care of. That's why it's a blessing when you get contacted by a security consultant like Marcus Gustafsson out of the blue.
Marcus expressed his concern regarding the security of firmware upgrades and we exchanged a couple of lenghty emails full of geek talk. I originally planned to copy-paste all of them here so that everybody can see the gory details but that'd be a very long post so I'd rather just summarize what really matters.
Given his security-conscious mindset Marcus wanted to have a dedicated physical port to upgrade the firmware. He said that he rather would not want to rely on perfect code but enforce a hardware level security mechanism for firmware upgrade purposes so that no unwanted firmware can be uploaded by malicious applications. Originally, I couldn't see a way of making it happen but he was diligent enough to look into AVR datasheets, found the lock bits and ultimately, we figured out a way.
I ended up defining the following 4 security modes:
In insecure mode after the keyboard received the USB bootloader jump control request it immediately jumps to the bootloader. Malicious applications rejoice!
In confirmation mode after the keyboard received the USB bootloader jump control request it captures key input and waits for the "1q2w3e4r5t" confirmation string in order to jump to the bootloader. In this case malicious applications cannot make the keyboard jump to the bootloader without the user explicitly permitting the operation by typing a word, captured by the keyboard. This mode will be the default.
In secure mode after the keyboard received the USB bootloader jump control request it captures key input and waits for a password that was explicitly set up by the user beforehand. The password is stored in the EEPROM as a cryptographic hash. Not only an explicit user interaction is necessary to enter the bootloader but the user must know the exact password.
In locked mode the lock bits of the microcontrolers are set and as such firmware upgrades through the bootloaders are not possible. A dedicated hardware programmer must be used for setting the lock bits and uploading the new firmwares. Connecting the programmer to the programming header requires the disassembly of the keyboard which means unscrewing 2 screws per keyboard half and taking apart the top and bottom part per keyboard half.
I think the above modes should cover enough ground to satisfy the need of every user from the least security conscious to the most. There are only a handful of keyboards on the market whose firmware is upgradable and out of those keyboards every one implements the insecure mode detailed above. I'm excited that we're the first to address this problem!
Lastly, let me just re-emphasize how much your voice matters. Thanks to Marcus the UHK can be better than any other keyboard security-wise. Have a great idea, a critique or concern? Please let us know! We're doing our best to address every issue.
Based on our video and images you must already have a good idea of how the Ultimate Hacking Keyboard looks like. We thought why not take this experience to the next level and provide a 3D model that you can rotate, zoom and pan. You can also go fullscreen and cycle through the annotations. Go crazy!
When I created the mouse layer, I was thinking about adding a boost key to increase the pointer movement speed while it's pressed. It'd allow for faster navigation when large distances need to be traveled by the pointer. I also immediately thought of the left Mod key as the ideal candidate for this purpose. Shortly, I dismissed my idea thinking that Mod is a layer switcher key, and as such, it should only serve one purpose not to overcomplicate matters.
Lately, we've been contacted by two of you, independently suggesting to add a feature akin to my original boost concept. I honestly cannot remember the name of the first person, but I can clearly remember the second of you, Christian Léger, who has suggested not only to enable users to increase mouse speed but also to decrease it for finer-grained mouse interactions. At first, I was a little hesitant, but ultimately, I do think that acceleration and deceleration complement each other very nicely and improve usability, so hence here's the updated mouse layer.
Given the normal, user-configurable speed of the mouse pointer, the accelerated speed can be 2x, and the decelerated speed can be 0.5x of the normal speed, for example, all being user-configurable values.
But there's an important question to be answered: What if both the Mouse and Mod keys are pressed simultaneously? Which layer switcher key should dominate choosing the layer to be used? Easy: let's put the layer switcher keys into a priority list, defaulting to Fn, Mouse, and Mod. I'm not fully confident about the exact order, but in any case, the UHK being a fully configurable keyboard, this priority list will be configurable on a per-keymap level.
Update (2016-07-29): We'll ditch the priority list in favor of a much easier solution: Whichever layer switcher key gets pressed first will be the active one (active layer) until release.
I've also made some other fixes. First of all, I added "button 6", which was missing. Second, I replaced "history prev" with "button 4" and "history next" with "button 5". The original naming of these keys was based on the function of those keys within browsers, but the more generalized naming is clearly better.
We're infinitely grateful for people like Christian who have taken the time to share their thoughts. Believe it or not, even when you ask questions quite often, you make us learn and sometimes reiterate our design. This blog post is the evidence that you can make a change, and we're listening to you. Let's push things further than ever and make the Ultimate Hacking Keyboard a truly remarkable keyboard!
Reducing hand travel distance during typing is a big deal. So much so that we thought that it's important to show you the substantial difference of hand movements distance when using the Ultimate Hacking Keyboard vs a regular keyboard using animations. The result can be seen on our main page.
[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"]
If you take a look at these animations they may look deceptively simple and in essence they are but the road that leads to them is quite bumpy. Let me share the ride.
When it comes to animations animated GIFs are the first thing that probably pop into most people's minds. Unfortunately, they tend to be very large files that download slowly, especially in the case of high-resolution animations featuring high frame rates. But what alternatives exist?
SVG! Unlimited resolution, unlimited frame rate, minimum size. SVG is great but just like in the case of videos it's quite tricky to make them responsive. Thank God there are some excellent writeups out there explaining how to make SVGs responsive.
I really wanted to define SVG animations in a declarative manner so I went with SMIL which stands for synchronized multimedia integration language. It's essentially a set of tags and attributes to describe animations within SVGs. It wasn't trivial to chain a sequence of animations together but eventually I made it work. Then came cross-browser testing and the realization that Internet Explorer (unsurprisingly) doesn't support SMIL. No problem, there's a polyfill for that! Except that it doesn't work well so SMIL can go down the toilet.
Snap.svg to the rescue! I put distinctive IDs on the various elements to be animated. The most important objects are the left hand and right hand elements and there were a couple of target points outside of the alphanumeric area of the keyboard for the hands to reach out. Being able to animate things algorithmically, I randomized hand movements which resulted in a lively moving pattern that is quite enjoyable to watch.
Cross-browser testing revealed a bug that was hard to debug: On the stock Android browser when scrolling downwards only the first SVG started to animate, all the others were not moving. I used Weinre to debug this issue and it turned out that the stock Android browser didn't like that I reused the same IDs in distinct SVGs. Inline SVGs are all part of the same DOM so this is somewhat understandable even though other browsers handle this situation well. Another weirdness is that when reloading the page in the stock Android browser and scrolling from the bottom towards the top the animations start as expected. Anyways, I ended up using classes instead of IDs to match elements which solved this problem.
I noticed that animations were always running on the page, burning the CPU all the time so I started to think how to reduce CPU usage. jQuery inview plugin to the rescue! I wanted to explicitly pause / resume animations when they go outside/inside of the viewport. For that ideally one should use the pause() and resume() methods of the mina object, except that Snap.svg is buggy in this respect so I ended up using Element.stop() and Element.animate().
I also wanted the animations to lazy-load when the user scrolls before them by 200px but this the jQuery inview plugin didn't support offsets. Luckily, I found an unmerged pull request in the repo that implemented this exact feature. Lazy-loading SVGs doesn't exactly work the way it does with traditional images because when animating SVGs, they must be included inline for the individual SVG elements to be separately accessible in the DOM. I could make this work with Snap.load() and Element.append().
Animations are buttery smooth on desktop machines but rather jaggy on mobile devices. It understandable because SVG animations are quite computationally intensive, especially when there are more of them in the view and are topped with JavaScript code that computes target coordinates real-time. Unfortunately, I cannot improve the situation any further.
Low and behold, you can check the final animation code in a GitHub Gist for your viewing pleasure.
"Was it worth all the hassle?" - you may ask. Even though it started as a simple addition to the site it consumed a significant amount of my time which could have been better spent on designing the next prototype. A part of me wishes to recover the time spent but on the other hand I'm a firm believer that it's critical to present products and ideas in the most digestable and intuitive way possible for the people to get their essence. In this very spirit it wasn't a waste of time after all but I surely don't wanna touch the site for a while.
Hope you enjoyed this writeup. I'm back developing the next prototype along with András. We're gonna make another significant improvement to the site soon (which won't consume my time) and we expect it to blow people away. Excited![/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
Instead of hunching over the laptop Laci is typing (and controlling the mouse pointer) in the most laid back fashion ever. A perfect use case of the Ultimate Hacking Keyboard. A more ergonomic working environment is surely preferred on the long run, of course.
I've written a comprehensive article titled From the Ground Up: How I Built the Developer's Dream Keyboard. If you're interested about the internals of how a keyboard of this kind gets built then you're welcome to check it out. Thanks a ton for Toptal for featuring us!
We'd like to show you the inside of our custom LED segment display. Interesting stuff!