About choosing my mechanical keyboard

Every day we use this piece of technology, which stays relatively the same over the years. All these years with a keyboard and I personally never gave any thought of why I am using this particular one. The only thing I seem to remember is that old keyboards use to make a lot of noise back in the day. I used to love that old keyboard, I never stopped using it until it finally stopped working, and never bothered to fix it. So I bought countless new ones, but it never gave the same experience as that old one. I started to read some articles about old keyboards and noticed that a lot has changed over the years in the internal workings of most keyboards. Mainly how the actual key is switched.

Membrane keyboards


How this typically works is that a rubber dome with a metal plate presses down on a membrane to register a keystroke. On most keyboards these keystrokes get registered when the key is completely pressed down. How far the key should be pressed and how much resistance the key has is determined by the thickness and shape of the rubber dome. When you are pressing down a key the force needed to press it down changes with a dome it will require you to put in a lot of force on the start of the key press and at the end it will be less.

Scissor switch keyboards


These are the keyboards that are typically found as the build-in keyboards on laptops. These keyboards still use the membrane with a dome but have a scissor switch. The scissor holds the dome a bit pressed in and keeps the rubber under pressure so the user has to use less force and typically these keyboards have a shorter key press distance. Again here the shape and the thickness of the rubber dome determine how much resistance it has. And still require the key to be completely pressed to the bottom to register the key press.

Mechanical switch keyboards


When I bought a mechanical keyboard a couple of months ago it immediately felt the same as that old keyboard of years ago. A mechanical keyboard does not use a rubber dome but a coil spring for the force needed for the key to put it back in the original position. Each key has its own independent key switch mechanism, which will register that the key is pressed. The registering of when a key is pressed is usually when the key is pressed half way (depending on the type of mechanical switch). This does not require you to press a key completely down in order to type. It will take some practice when you are using a keyboard to not bottom your key. But once you adjust, you will start to type faster and more comfortably.

Find a mechanical keyboard in your local shop

If you are like me and you don’t like the modern keyboards, then think about treating yourself to a new keyboard with some old-style mechanical switches. When I looked at some local stores in the Netherlands, these were relatively easy to get:

  • Cooler Master Storm Quickfire Rapid (MX Red/MX Black)
  • Corsair Vengeance K95 Performance (MX Red)
  • Corsair Vengeance K70 Performance (MX Brown/MX Blue/MX Red)
  • Das Keyboard Model S (MX Brown/MX Blue)
  • Das Keyboard Model S Professional (MX Brown/MX Blue/MX Red)
  • Razer BlackWidow (MX Blue)
  • Razer BlackWidow Stealth (MX Brown)
  • Logitech G710+ (MX Brown)
  • SteelSeries 6Gv2 (MX Black)

It is a matter of taste, but I prefer the silent MX Red or MX Black tactile-less switches. The MX Brown is for people that like to feel when exactly they pressed the key (tactile). The noisy  MX Blue switches will also make sound when the key is pressed. I would recommend NOT get these if you work in an office. The noise is louder than you might expect, and could easily drive your colleagues crazy 😉


There are a lot of different types of mechanical switches. These two great guides formed the basis of this post:

This is the source of all the information about the switches and also the source for all the used images.


Developing a mobile web application with IUI

At LeaseWeb we have a hosting control panel called “Self Service Center” or SSC. We are starting to make our first steps into making the Self Service Center available on a mobile platform.

We have a couple of options on how to implement this:
• Build native applications for each mobile platform ( mainly Android & iOS )
• Build a mobile accessible website

We had to make a list of advantages and disadvantages of the 2 options:

We prefer to keep a single code stack, for maintenance reasons, and so we can make every feature immediately available in the mobile version. This is why we decided to make a proof-of-concept of a mobile accessible website.

The first problem we encountered was to find out how to implement this mobile website the best way possible in the Symfony framework. At first, we checked if this was possible by doing only CSS changes, so without touching the templates. It did not took us long to come to the conclusion that this was not enough and we had to revise all of the templates.

By looking up the API of the Symfony framework on a mobile device we saw that they had a mobile version of it on their website. We were very curious what technology they used and how they implemented it, so we started digging. We found out that they were using the IUI framework on their mobile API page and although it didn’t work flawlessly we were impressed with the way it worked.

So what is this IUI and how does it work?
With IUI you have to think of your webpage as 1 big HTML file which you keep adding content to. So you keep updating your current HTML with new adaptations through AJAX request. When you click a button / link the new page is loaded off-screen. When the screen is loaded it slides smoothly into your screen. The old screens are not unloaded so you can smoothly slide back to the previous screen using the back button in the upper left corner.

Figure 1 – The red box shows the area that is visible on the screen, the other pages can slide in.

Using this framework you can make any webpage feel like a native iPhone application. A single IUI web page can contain multiple related iPhone screens. This makes IUI map on the Symfony MVC framework quite nicely, because all the data of a single MVC view will not fit on one iPhone screen, but it might fit on multiple.

Also for backend developers it is really nice that you don’t have to design all the screen layouts. You can just follow the layout that is provided with the framework and your screens immediately look professional. Although we created an impressive proof-of-concept there were some problems we did encounter:

A broken back button
When you post a form with validation errors, the same page – containing the form – is loaded with the errors displayed next to the input fields. This new page has the same id as the old form causing the back functionality to be broken.

The IUI back functionality works using a “stack”. This stack contains the ids of the previously loaded pages and forms. When the page loads it adds the id to the stack. When a validation error has occurred the stack contains the wrong values, because the validated form and the original form have the same id.

The possible solutions we found are:
1) To fix this we can give the validated form a different id than the original form.
2) Show the (validation) errors on a new page or popup.

An iPhone like way to handle field validation error is to show popups containing the validation errors. This can be achieved in IUI using “Dialog” type forms. First we tried using JavaScript “alert” calls but we had trouble, because these pop-ups are blocking and it is hard to use them without modifying IUI internals.

Displaying flash messages
More or less the same problem occurs when displaying “flash” messages. “Flash” messages are messages often colored yellow, red or green (for warnings, errors and confirmations) and are set on top of the screen displaying the results of the last page load. In IUI the flash messages are not working properly because pages are not reloaded on “back button” navigation. In an iPhone application these messages typically show in a popup.

We think IUI is a good and easy way to convert your current website to a mobile website in a MVC framework. Problems we encountered are related to error and status messages that a typical web application shows inside (and on top of) forms. Unfortunately IUI does not seem prepared for showing these. We’ve found a workaround by showing these messages in “Dialog” type forms.

LeaseWeb Self Service Center – https://secure.leaseweb.com
IUI framework – http://www.iui-js.org/
Symfony framework – http://www.symfony-project.org