2nd UHK post-campaign update: PCB design now supports LEDs and Matias switches

2016-02-18

Time flies! We promised to touch base every month - so let’s get right into what we’ve been working on!

The mechanical design is being sent to manufacturing

András has been having his fair share of CAD-filled days lately, and as a result we’re days away from sending the design of the case off to manufacturing. He’s made a million little tweaks and a couple of more significant changes.

Foot design - adjustability and portability

The fixation mechanism of the feet is definitely a major one. We brainstormed foot design ideas for a while, and finally found the best option. To keep the UHK as compact as possible, it will feature adjustable (flip open) feet that are entirely removable in addition to the small, flat rubber feet. This way if you decide not to use the adjustable feet, they won’t occupy any extra space. And if you do want them, they can be easily installed with 3 screws per foot. Once you do, you’re able to flip them open in a moment. The current design allows for positive tiling, negative tilting, and tenting - The best of every world! András has yet to finish the design of the adjustable feet so stay tuned for more news.

8 feet in total, 3 mounting holes around individual rubber feet

Mounting bosses - 3 per foot, as seen from inside the case

PCB design - LEDs and Matias switches

We’re also stoked about having added pins for LEDs and Matias switches! We use universal switch footprints that combine the pins of Cherry switches (optionally with fixation pins), Matias switches, and LEDs. We designed the stiffening ribs of the bottom case in a future proof manner by routing them around the hybrid switch footprints to avoid mechanical interference. Please note that we won’t be able provide either an LED, or a Matias UHK version for a while, but the opportunity will be there for modders. You can see the pins on the following section view.

Physical layout - finalized

Another major change is the finalization of the physical layout. Fear not, you shouldn’t even notice the subtleties if you aren’t watching very closely. Space and Mod has been split right where the G and H keys meet. This is the best option ergonomically, as it’s right between the hands of touch typists. This gave us an opportunity to use more standard keycaps so those of you who want to replace keycaps will be in a better situation. Lo and behold, our final ANSI physical layout:

And the ISO version:

Funny thing is, poor András has been working day and night to implement this seemingly small change, as it affected the geometry of the CAD model in major ways. He definitely deserves a day off... only to work even harder as we march towards manufacturing!

Speaking of the above, I’ve created a dedicated layouts and keycaps FAQ page on our site lately, and while being there also spruced up the main FAQ quite a bit to satisfy your endless curiosity.

The state of the ARM port

In our previous update we were looking for a firmware developer to port our existing firmware to NXP’s Kinetis platform and develop it further. We’ve been getting quite a few impressive applications and suggestions.

Say hi to Mr. Jan Rychter, who has been eager to help us, and offer his very valuable advice. Since first contact we’ve been exchanging emails full of geek talk. And did I mention that he’s also a most esteemed backer of the UHK?

Jan got me up to speed in no time. As it turned out, Teensyduino is not the best foundation for a serious firmware application. It’s nice for prototyping purposes but NXP’s sophisticated Kinetis SDK is a much better platform for this purpose.

Unfortunately, the MK20DX256VLH7 processor that we originally planned to use is not a good choice because KSDK won’t ever target it. As crazy as it might seem, there’s a more powerful, fully supported, and cheaper alternative on the market: the MK22FN512VLH12.

How powerful and cheap, you ask? Let’s compare!

Processor name	ATmega32U4	MK20DX256VLH7	MK22FN512VLH12
Processor core	AVR8	ARM Cortex-M4	ARM Cortex-M4
Rated speed	16	72	120	Mhz
Flash memory	32	256	512	kbytes
RAM	2.5	64	128	kbytes
Price	3.6	4.55	4.04	US Dollars

Mind blown. Twice the power for less price? I’ll take that on any day of the week!

Right now, there are a couple FRDM development boards on my table, one of which running our Kinetis firmware port which enumerates as a keyboard + mouse USB device. This is already looking great, and you can expect further major progress shortly, so the port is definitely within reach, and I’m happy taking this direction.

Agent is coming along nicely

Árpi is on a mission to make Agent the most beautiful keyboard configurator application ever crafted. He never ceases to amaze me as he massively cleans up the UI of my original mockup while keeping the original functionality intact. This is the most up-to-date screenshot of Agent:

You’re welcome to check out Agent in the browser. Please note that there’s only a minimal UX code behind the UI, but it should give you a good idea about the final interface.

Thanks for reading, and talk to you on 2016-03-17!

Agent is coming together, looking for a firmware developer!

2016-01-14

A month ago in our previous newsletter we promised to send you an update on the post-campaign happenings on January 14th, so here it is! There is a lot of ground to cover, so fasten your seatbelts and we’ll get right to it!

Extra keyboard cases & keycap sets are for sale

Some of you contacted us to purchase extra keycap sets and cases, and we’ve been very much willing to serve your needs, so why not offer them as extra perks? You’re welcome to purchase them on our campaign page.

Meet Agent, the configuration application for the UHK

We’re proud to show you the first screenshot of Agent, our cross-platform configuration application. It’s being developed by Árpi, a new developer of ours. Please keep reading for more.

The mechanical design is being finalized

András is hard at work finalizing the mechanical design of the keyboard case. Mold making is by far the most time consuming task of the manufacturing process, so it’s supremely important we start as quickly as possible in order to deliver on time.

We’ve already struck a deal with the manufacturing firm for the injection molding tool for the plastic case and the cutting tool for the steel plates, and we’re in the process of discussing relevant design issues with them. Sourcing of the raw material for the steel guides is also in progress - from a well-esteemed Austrian company.

From the very beginning, we’ve been mindful to design the UHK for manufacturing, but there are some details yet to be finalized. One such detail is the connection between the two halves and the modules.

Originally, we used a battery connector because it was easier to use an off-the-shelf part - but later we figured out a much better way: dedicated pogo pins. This is a more robust and better looking solution than the battery connector. The 6P4C connector was also replaced by a 4P4C connector and its wiring has been reversed. This way a standard telephone cable can be used to interconnect the two keyboard halves.

There are a couple of details like the above, and András is rapidly moving forward to address them, so that we can submit the CAD files to manufacturing as soon as possible.

Two developers have joined to our ranks

Back in August we were contacted by Árpád Csányi, who expressed interest in the UHK. Fast-forward to November, and we managed to meet in person over a couple of beers after I gave a talk on the UHK in Szeged, Hungary. It was apparent that he was interested in the project, but I wouldn’t have thought in my wildest dreams that he’d end up being the front-end developer of Agent, our configuration application! Árpi is not only a powerhouse of UI/UX ideas, but he’s very much willing and able to implement them.

After I created some mockups of Agent he quickly followed up to present his ideas and improvements. He then started to write HTML and CSS to make the mockups go alive! We’re making rapid progress and are aiming to freeze the UI/UX specification of Agent by the end of January.

Please note that these mockups are a work in progress but you’re welcome to add your suggestions to the docs. Don’t forget to uncheck the View -> Print layout option in Google Docs or else some pictures will be cropped.

Right after open-sourcing our design a, mysterious GitHub user started contributing to our electronics repo. Say hi to Mr. Spencer Owen, who is very much into devops and using his rad skills, he set up a visual diff mechanism in our electronics repo, so that now we can actually see the changes of the circuit boards that get modified by contributors. This is very much needed because unlike plaintext files, circuit boards can’t be diffed in the traditional way.

Right now Spencer is working on making the PCB compatible with Matias switches. Due to the lack of compatible keycaps, this doesn’t mean that we’ll be able to provide Matias switches from the get go, but we’re trying to future-proof the PCB so that the opportunity will be there, and eventually we can make it happen.

Moving to ARM, and looking for a firmware developer

It’s been a pleasure and privilege to work with Árpi and Spencer and I’m very much looking forward to further expand our team. It may surprise you, but we’re not actually primarily looking for an AVR developer. We’re looking for an ARM Cortex-M4 developer! Why’s that? Let’s consider the following table:

Processor name	ATmega32U4	MK20DX256VLH7	Units
Processor core	AVR8	ARM Cortex-M4
Rated speed	16	72	Mhz
Flash memory	32	256	kbytes
RAM	2.5	64	kbytes
Price	3.6	4.55	US Dollars

The above numbers are pretty telling. The ARM processor costs only a buck more than the AVR but it’s about 10 times more powerful! The plan is to replace the AVR on the right keyboard half with ARM, and keep using AVRs in the left keyboard half and in the modules - which don’t need as many resources as the right half.

We could possibly stick to the ATmega32U4 and implement the planned feature set, but the available 2.5 RAM is very tight. It’d require us to always think about how to not exceed memory and vastly optimize the firmware for memory consumption. This would slow down development and wouldn’t give us room to implement more sophisticated features later on. Bulkier AVRs are moderately more powerful and considerably more expensive, so I truly believe that ARM is the way forward.

It’s also very important to note that the MK20DX256VLH7 is not just another ARM microcontroller, but the brain of the Teensy 3.1 and 3.2 development boards. This is great news because there’s a huge amount of support available out there!

Are you familiar with the Teensy 3 platform, or do you know somebody who is? Do you enjoy the thrill of Open Source? Would you love to work on a one-of-a-kind mechanical keyboard, and help push innovation further? If so, we’d love to have you on our team!

What’s next?

We’re making rapid progress on multiple fronts, but there’s still a lot to do! We plan to finalize the UI/UX specification of Agent by the end of January. I’m sure that we’ll have a lot to talk about in our upcoming updates.

Thanks for reading, and talk to you soon - on February 18th!

The tale of 5 prototypes

2015-11-10

Semi-assembled UHK prototype

You purchase the gadget of your dreams and open the box with excitement - it’s beautiful, functional, well-designed and puts a smile on your face. It’s hard to imagine that at one point, your gadget was nothing more than a big mess of wires. The final product has come a long way, and in many stages, from wires to being ready for a campaign.

Engineers shed blood and tears working out endless technical challenges all for the sake of a fully functional and reliably working prototype. This is our condensed story of trials and tribulations.

Prototype 1

The basic goals were clear - build a truly split, compact mechanical keyboard that merges as one piece. This is a good start, but still pretty vague. So it’s not surprising that our first prototype ended up like this:

UHK prototype 1

As you can see, we were flirting with the idea of building a USB hub into the UHK, which was ditched later on because of the lack of space. Small Molex connectors were used to connect the two keyboard halves, which saved space but they lacked robustness and repeatability, so they had to go.

The above PCB (printed circuit board) didn’t have any wires, so it wasn’t functional by any means. We really just wanted to get an idea how the keyboard would look. Making the electronics work started on a breadboard like this one:

The UHK on the breadboard

The development boards at the bottom are the brains of the left and right keyboard halves. The buttons above them implement a 2x2 key matrix, yielding 4 keys per keyboard half. The boards are connected by a wire, making the left board able to send key press and key release events to the right half. The massive board at the top is an Open Bench Logic Sniffer, enabling me to see the communication between the two boards for troubleshooting purposes.

Prototype 2

Finishing the electronics breadboarding, it was time to turn the wires into traces on a PCB to have a functional prototype. This time, we tried a retractable S-Video cable to connect the keyboard halves. The bulkiness of the plugs is obvious, but what you can’t tell is their lack of reliability. 3 LEDs were used per keyboard half to display status information just because it was a simple solution to implement at that time.

UHK prototype 2

Prototype 3

With the PCB started, it was finally time to come up with the final shape of the UHK and get its case 3D printed. On the following picture, the left half was printed using an EOS SLS (selective laser synthesis) machine and the right half was printed on an Objet polyjet. Unlike the left half, the right half is painted and polished. We ended up using SLS for our prototypes because even though it has lower resolution than polyjets, its shape reflects the shape of the CAD model more accurately, and its mechanical qualities are better. This time we switched to an RJ11 retractable cable, which is a lot less bulky than the previous S-Video cable - but it turned out to be similarly unreliable.

UHK prototype 3

Prototype 4

Apart from fixing a lot of errors on the PCB, we added stainless steel inserts to this prototype, letting users to mount the keyboard halves onto many objects. The other day, a disabled person emailed us who will use the inserts to mount the keyboard halves onto his armchair. We’re very glad that our keyboard supports such scenarios out of the box.

At this point, we realized that retractable cables of all kinds are supremely unreliable, and only a cord cable would do the job.

The back of the left keyboard half

The inclusion of stainless steel inserts reshaped the contour of the PCB quite a bit, as you can see below:

UHK prototype PCB

Prototype 5

Our last generation prototype featured only very minor improvements to the PCB. We also found a super talented professional who polished and painted the 3D printed case to make it resemble the final look of the injection molded plastic case.

During the course of working on the UHK, we put more than 10,000 hours into it, and failed numerous times. Every failure taught us a lesson - a way to do something better. There is an industry term called MVP, which stands for Minimum Viable Prototype. The UHK is already far beyond this point.

UHK prototype 5

The prototyping is done, but it’s not quite the end of the story. We have yet to unveil some one-of-a-kind, game changing addons. Stay tuned!

Ultimate configurability

2015-11-06

Many of you have asked us to talk more about the various ways in which the UHK can be configured. It’s certainly not a trivial matter, so let’s take a detailed look.

To explain configuration as precisely as possible, we should start by examining the exact definition of a key.

UHK key IDs

It’s actually pretty misleading to describe keys by their standard function (the Tab key, the Backspace key, “A”, etc.). A better way to talk about keys is using their explicit location, like A1, B5, or C10 (see above graphic).

This is because a key like Backspace is really just a scan code that the keyboard sends to the host computer. On the UHK any of these scan codes can be triggered by any of the keys. So using the base layer, the following correlations are made:

A14 yields Backspace
B1 yields Tab
C2 yields letter “A”

But what are layers? A layer binds actions to keys and 4 layers compose a keymap. Let’s visualize the 4 layers of the factory keymap.

UHK layers

Given the above, in a way, the UHK is not 1 keyboard but 4 keyboards right on top of each one another. “But how can I move across layers?” - you may ask.

Layer switcher keys to the rescue! Let’s see the default ones.

UHK layer switcher keys

While keeping a layer switcher key pressed, the relevant layer gets activated - and as soon as you release it, the base layer becomes the active one again. It’s that simple! (Of course, with the UHK, you can make any key a layer switcher key)

As mentioned above within a layer, keys are mapped to actions. But there various kinds of actions. An action can be a key action, mouse action, macro action, or a keymap switcher action.

A key action emits a scancode like “L”, along with optional, additional, modifiers. So the single keypress can also emit shortcuts like Left Alt + Tab. A key action can also be dual-role, which acts as a normal modifier, like Control when pressed along with another key, but behaves as another key like Escape when pressed in itself. (We may add a user-specifiable interval for the latter case so no accidental keypresses will be emitted.)

A mouse action is one of movement {left, right, up, down}, scrolling {left, right , up, down}, or clicking {left, middle, right}. The mouse layer of the factory keymap contains every one of these sub-actions intuitively laid out.

UHK mouse keys

A macro action is composed of a sequence of key actions, mouse actions and delays. It will also have a loop flag which will loop the macro until the associated key is pressed.

A keymap switcher action switches to the specified keymap. This allows you to make many different keymaps, each for their own use-case.

When you make your configuration comprised of keymaps of layers of actions, it’s all saved right in the UHK’s on-board memory. So when you plug it into another computer, your configuration remains intact! The on-board EEPROM has enough to store a very large amount of configurations.

There are even more parameters that you can control with the UHK, like maximum speed and acceleration of the mouse pointer.

As you can see, you are given a lot of freedom configurability-wise. And with this freedom comes the chance that you can screw up your own keymaps! But fear not, that’s exactly why there’s a factory reset switch on the back on the UHK which you can press with a toothpick. No worries, this won’t erase your configuration, merely restore the factory keymap.

That’s it! Hopefully, I was able to clear up any questions you may have had about UHK configuration functionality.

Repair for the win

2015-11-03

UHK fully disassembled

The UHK is durable, super durable - and adding to that innate strength, it’s highly hackable and repairable. Contrary to the attitude of most keyboard manufacturers, we believe that you should have full access (and ease of access) to tinker. Keep reading for a complete picture, or click through to the campaign page for more UHK info.

The UHK differs from usual keyboards in a number of ways. You can tell by starting at the back of the board.

UHK keyboard halves viewed from underside

There’s a lot of content here, but I’d like to highlight something specific. The wrench icon:

Durable and repair icons on the back of the case

It says “Repair friendly”. This is not something that companies usually like to put on their products - and there are a number of reasons why:

Psychology - The first question that this icon may trigger in customers is, "Oh, crap, is this product gonna break?!". Which is ironic if you think about it, because everything breaks eventually. Nothing lasts forever. To combat this reaction, we put a Durable icon next to the Repair icon because the fact of the matter is that we designed the UHK like a tank.
Future profit - If a gadget can be repaired, that means that when something goes wrong, you don’t need to just go out and get a new one. As profits and sales numbers are the single most important focus to most companies, most companies are very averse to repairability.
Extra work - Helping customers repair their gadgets takes support resources. So rather than be creative, and make it easier for customers to conduct their own repair, most companies strive to make repair as difficult as possible.

The above mindset leads directly to the following image:

ewaste dump

Image is courtesy of TheConversation.com

But there’s a better way! It’s actually possible to design for repair in a number of ways, and some of ours are pretty unique. We can:

Print instructions right on the circuit board! "Unscrew the 5 large screws below the keycaps and the 1 screw on the PCB" - it’s hard to get any clearer than this.

Repair instructions on the UHK PCB

Print similar instructions on the case.

Repair instructions on the case of the UHK

Display not only component types, but also their value, right on the PCB. See the 10 ohm resistor, and the 0.1 microfarad capacitor.

UHK PCB labelled

Little things like the above go a long way, but we’re planning to do even more - like creating a repair manual and repair videos.

In addition, one of our most innovative concepts is to log the number of keypresses for each UHK key-switch. This way, you can keep track of the wear on each individual key as they approach their 50 million keypress lifespan, so you know which will need to be replaced before they even get close.

iFixit said that "Above all,

[the UHK] is proof positive that even compact, performance-designed, single-purpose gadgets can be designed for repair, from the ground up - complete with repair documentation".

This feedback makes us very proud and assures us that we’re on the right path.

Upgrading the firmware with a neodymium magnet

2015-07-20

Under normal circumstances, it's possible to upgrade the firmware of the UHK by sending a special USB control request from the host to the keyboard to reenumerate it as the bootloader.

However, when developing the firmware, one can easily screw it up so badly that it won't be possible to reenumerate it as the bootloader via USB. In such scenarios, one has to pry open the case and short the GND and RESET pins in order to enter the bootloader. This is obviously cumbersome, and it would be great to be able to easily reenumerate the keyboard as the bootloader without opening the case, even when the firmware is screwed up.

When I was thinking about this problem, I figured why not put a reed switch inside of the case to short the pins, so I silicone-glued a switch onto the PCB and wired it. Apparently, this is working like a treat.

As it turns out, most reed switches have molded glass bodies that break like a toothpick under the slightest pressure. This is quite a problem for a mechanical device like the UHK. Luckily, not all reed switches are that fragile, and I found one that I especially like due to its rigid body and small size. The PCB of the 6th generation prototype will have a footprint for such an optional reed switch to be soldered by hardcore developers.

This is yet another useful, unique, developer-oriented feature that we can boast.

The nuts and bolts

2015-07-13

In this blog, I usually talk about topics like the firmware, electronics, product design, and all that kind of jazz but not many words have been said about the mechanical side of things. To give you a glimpse into this world, let me show you some pictures of András, mechanical engineer extraordinaire assembling our latest prototypes.

Not many people would think that 3D printed objects can be extremely malleable but pretty often this is exactly the case. We used to use Objet polyjets to print the case as opposed to our more recent SLS case. As it turns out, if you leave an object made of such a photopolymer resting in an unfavorable position it changes its shape significantly according to the forces that act upon it. We weren't particularly mindful about this problem so András had to put weights onto the the case to make it even.

But it's not enough in itself. The weighted down case must be heat gunned so that it'll "remember" its current shape.

Making the metal guides that hold the two keyboard halves together is also more difficult than one might think, especially for one-off prototypes. First up, András had to grind the steel pin so that it could be shoved into the sleeve.

And then, it had to be oriented before fitting it into the hole.

Next up, the pin was interference-fitted into into the sleeve for the shaft to be securely held.

All these steps resulted in the male part of the guide.

After finishing with the above and taking care of many more problems we ended up with the inner assembly.

Looks like a shining armor of a noble knight, worths all the sweat in the world!

Assembling prototype PCBs

2015-07-03

A couple of years ago, I was completely new to electronics and never soldered a thing in my life. Fast forward to the previous week, I was soldering the 5th generation prototypes of the Ultimate Hacking Keyboard. It's been quite a journey and although I am by no means perfect at this stuff, upon reflecting on it I realized that I was able to push my PCB assembly productivity to the next level several times in a row, so let me show you what I learned.

Given that you asked for panels from the fab everything starts with depanelization. Even though this is a no brainer and doesn't require any skills or equipment other than a flash cutter, I decided to show it because I'm sure a lot of people have never seen it in action.

Next up, PCB assembly follows, so it's time to heat up the soldering iron.

Some words of advice:

You can notice at the beginning of the video that it takes me about 4 minutes to find the MCUs which is exactly what you want to avoid. A while ago, I purchased way too many AVRs, put them into a drawer and didn't take the time to organize them properly which causes me a time penalty every time I search for a specific AVR. I have yet to solve this problem but regarding passive components I already solved it by buying a resistor and capacitor book and a blank SMT storage book. The productivity boost is incredible.
It's easier to solder large components first. It's not a coincidence that I started with the AVRs.
After soldering large components, it's worth progressing by the descending number of components used per type. In order to generate such a list I ended up writing a node module (and its dependencies) to extract this information from KiCad files.
For passive components that have two or three pads it's worth pre-tinning a pad per component before actually soldering them, then soldering the components using the pre-tinned pads, then soldering the rest of the pads. You only have to grab the soldering 3 times this way instead of hundreds of times.
Adding easily readable reference designators and component values to the silk screen can be a major productivity booster. Component values are especially handy.
There is no such thing as too much flux and a flux pen is the best choice to deploy flux. I use a Circuitworks CW8100 pen which does a great job.
DRC is your friend so use it extensively. Even better if your fab provides you a state-of-the-art PCB visualizer that checks your gerbers, like in the case of Eurocircuits.

Often times, it comes very handy to salvage SMD parts from previous prototypes which can be hard to desolder but with Chip Quik it's so much easier. On the video below it takes me 21 seconds to desolder a TSSOP 20 after starting to heat up the Chip Quik with my soldering iron.

Reusing PTH parts is usually much simpler but it can still be a pain. A desoldering station to the rescue! I purchased my ZD-985 desoldering station for about $100, probably the best bang for the bucks ever.

I'm pretty sure that I missed a lot of things but this is a very broad topic and I mostly wanted to give a glimpse into the world of PCB hand assembly. You're welcome to correct me, add suggestions and ask questions!

Securing firmware upgrades

2015-02-26

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.

Hand movements minimized

2015-02-03

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.

Check out the animations!

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!