First Impressions
The keyboard is light, but doesn't feel flimsy. Due to the fact that the whole upper face of the keyboard consists of keys, it doesn't as much have a case as it has a single-piece shell. It doesn't have feet, which I usually use on keyboards. However, I didn't find it made any difference to my typing so I'm willing to ignore that.
Webwit had noted that the screws had come loose when he got this keyboard originally. When I received it, the left hand side of the PCB was flexing violently, which turned out to be the fault of a loose screw on the left hand side. Given the excellent packing done by Mr. Interface, I doubt that this was shipping damage. Even when the screw was tightened, there was still a bit of flex on the left hand side if I poked at keycaps in the bottom left hand corner. I suspect that another screw may be loose (the PCB is held into the case with three screws) but I haven't gotten around to looking for them. However, given that sixty's keyboard did not have these issues, I'm going to assume that this is some sort of early production quirk which will hopefully be absent from standard production models.
In terms of other build quality issues, the USB port has quite a wide gap around it which exposes the PCB. I'm not too sure how much potential for damage exists here in practical terms, but I think it could do with a tighter fit around the USB port.
This keyboard uses Black Cherry switches, with a Grey switch on the spacebar and a Red switch on the tilde/Esc key. I've typed on old linear keyboards before and didn't like them, but I found the Black Cherry switches to be very pleasant to type on - the stiffness prevents you from bottoming out on keys, and thus typing on them is smooth and involves little travel. Either way, the KBC will be available in a number of different Cherry switch configurations which should keep everyone happy.
The keycaps look smart, if not somewhat unreadable, and seem pretty sturdy, but I've noticed that a few of the keys have already started to shine a little bit. They're also quite hard to remove compared with standard Cherry keycaps, although I think this is an issue with a lot of non-Cherry made keycaps for MX switches. IIRC, KBC is using different keycaps made from a different material on the regular production keyboards which may mean less/more/different problems with the keyboards that most people will actually end up with.
Layout
I'm a big fan of the HHKB, so this thing has a hard act to follow, and I guess it has heavily biased my ideas of how an Fn layer should work.
The KBC promises from the outset to fix one of the big problems with the HHKB design - the absence of keys along the bottom row. They also have a rather interesting way of implementing an inverted-T arrow cluster - pressing Fn + Spacebar turns Right Windows, Context, Right Control and Right Shift into arrow keys. In fact, you could easily leave on the 'Arrow Lock' given how infrequently these keys are usually used. I did however find that I have a habit of using Right Shift to type in ? which led to some bizarre situations where I presssed / and Up Arrow when I forgot that I had the Arrow Lock on.
This sort of thing can be adjusted to, but it underlies a more substantial problem with the layout - the only dedicated Fn key on the keyboard is where Right Alt should be. For one, many people (myself included) use some sort of key mapping that uses right Alt as an Alt Gr key for typing Unicode characters. In Windows, this can be emulated by pressing Control and Alt, but this doesn't work under Linux, leaving me in a rather unfortunate situation if I need to type something like the Euro symbol. By means of a compromise, they could have replaced either the Right Windows key or the Useless Key (Context) with Right Alt. It would not have been in its standard position, but at least it would be there somewhere in place of a lesser used key.
But moreso, the Fn key in a really awkward place - it requires you to move the right hand, hold the Fn key with the right thumb and press whatever other key is needed. One of the great things about the HHKB is the placement of the Fn key in a position that does not require the hand to move too far out of the normal typing position. IMHO, this makes the arrow key implementation on the HHKB superior to that on a standard ANSI/ISO layout keyboard. While I appreciate that there are advantages for manufacturing the Poker with the layout of a standard alpha-block, I think the addition of an Fn key to the right of the right shift key would be highly advantageous.
Speaking of HHKB arrows, the KBC places regular keys on the Fn layer on the WASD block. On paper, this sounds like a clever idea, but in practise, it is really impractical. It turns the arrow key process into a two handed operation which requires the right hand to be moved out of the typing position to press the Fn key. The keyboard has DIP switches that let you turn the Left Widows key into an additional Fn, but this is also problematic - users of Mac OS X really need a Command key on the left hand side of the keyboard. OS X lets you assign Command to something else like Caps Lock or Control, but if Mac users are used to Command being where it is located on a Mac keyboard, then it's unideal. In addition, if the Arrow Lock is on, it forces Windows users to turn it off to use the Win key.
In terms of a solution to this, I think Caps Lock should be made an Fn layer function (who really uses Caps Lock that much that it needs to be a dedicated key anyway?) and the Caps Lock key should be made a left Fn. Then the user should be able to swap Control and Left Fn with DIP switches to suit their taste. In either the Caps or Left Control position, the Left Fn key would be easier to reach, and would offer a direct improvement over one of my big gripes with the HHKB design - the lack of a dedicated left Fn key.
In regards to other keys, the Fn layer is a bit odd. There are two keys which map to delete, I'm not sure why. In general, the editor block keys seem to be thrown around in a haphazard way around the keyboard. End is on '" with Home on top on [{, whereas PgDn is on .> with PgUp to its left on ,< Insert is located on ]}, nowhere near Delete. The HHKB had some degree of consistency in that Home, End, Page Up and Page Down were located in the same approximate placement that they would be on a standard keyboard, and Delete and Insert were located beside eachother (depending on the DIP switch configuration). Again, I fear my HHKB bias seeping in, but I honestly can't see the logic behind the location of the editor keys on the KBC. Perhaps they were an afterthought to the designers - these keys are largely the domain of the more technically advanced, and perhaps it was felt that most people wouldn't care. Then again, keyboards like this tend to be bought by the technically compotent, so it does matter.
Conclusions
Presuming that the issues with the screws on the example I reviewed go away, the KBC is a well built, low cost Cherry switch keyboard. The problems that I have with it lie in what I feel to be some rather poor layout decisions. Any compact keyboard layout is going to have some compromises, but I feel in the case of the KBC that many of the issues I noticed could have been avoided. It would be easy for me to say that they should just look at the HHKB and copy it verbatim, but I think a good way for them to really stand out would be to have a fully programmable keyboard layout for both the standard and Fn layers. Either way, I think the keyboard could do with an extra key serving as a dedicated Fn key. I'd also like to see the Caps Lock replaced with a dedicated left Fn, or even a DIP switch that lets the user decided whether Caps Lock should be on a dedicated key or on the Fn layer.
Verdict:
Nice keyboard, mediocre layout.
