How would you adjust ANSI 60% to be ortholinear?

I talked about this a bit in my introduction post, but this might be a better place for the discussion.

The question is, what minimal changes would you make to the 60% section of an ANSI layout to make it mostly-ortholinear?

Most vertical-column keyboards I’ve come across make other more radical changes to the layout as well (think thumb clusters, function layer dependency, vertical stagger, etc…). How would you go about avoiding that (assuming you wanted to, of course) if you were trying to design an otherwise “normal” TKL or full-size board?

Some design guidelines:

  • Fewer changes are better - if someone familiar with ANSI went to use the modified layout, how disoriented would they be (in terms of both visual and tactile impressions - does the keyboard look “weird”? Are the keys roughly where their fingers expect them to be?)

  • I say “mostly-ortholinear” assuming vertical stagger would be too disruptive to familiarity, but if you can figure out how to make it work in a layout that could be used in a TKL or full-size board, more power to you. The real goal here is vertical columns, not ortholinearity.

  • I also say “mostly-ortholinear” (as opposed to “strictly ortholinear”) working from the assumption that there’s much less benefit to vertical columns for keys outside of the natural vertical travel of your fingers. So modifiers, etc can still stagger horizontally. Also, I suspect without that freedom most feasible solutions would look a lot like Preonics…

  • As a generalization of the previous points, if you can sneak in other kinds of improvements (ergonomics, keycap compatibility, etc) that’s a bonus, as long as it doesn’t have an outsized impact on ANSI familiarity.

Some background: I’m currently working on a custom design/build with the intention of keeping the layout as close to “normal” TKL as possible, but with vertical columns. I’m trying to make something that someone who doesn’t want to learn a new layout could look at without getting freaked out. The function row, arrow keys, etc seem fine as is, so it’s mostly the 60% section (is there a proper name for that?) that I’m looking to adjust. I have some ideas of my own (I’ll post below), but am interested to hear what other folks think!

Finally, here’s your typical ANSI 60% for reference (just in case you’d forgotten :wink: ):

This is where I’m at with this right now:

R1: Widen backtick/tilde by 0.5u and shorten Backspace accordingly. This feels wrong given that most people don’t use backtick much… but they do hit Backspace a lot. But it seemed necessary in order to line up the number keys with R2. I also considered moving backtick to the immediate left of Backspace, and shifting all the other keys left one spot, - that way it would be the 1 key that was larger, which might be a better use of real estate, but that option ultimately seemed more disruptive and less symmetrical.

R2: No changes. This row is nice and symmetrical as is, and I wanted to concentrate the resizing on keys that were already unusually wide or narrow.

R3: Shorten Caps Lock by 0.25u and lengthen Enter accordingly. It’s Caps Lock, I have no problems marginalizing it… A larger Enter seems fine as well.

R4: This is where things get interesting! And potentially deal-breaking for existing “proper” touch-typists. Left Shift is lengthened 0.25u… Shifting the rest of the row to the right by a full column. So, while on a standard keyboard a touch typist would consider V to be “under” F, with this layout it’s actually C that ends up “under” F.


My main motivation here was avoiding shifting the row to the left, which would result in a stubby Left Shift key and a Right Shift key that was almost as wide as the spacebar… That said, I think this decision might also be justifiable given that the R4 alpha keys are offset from R3 (home row) by 0.5u - so geometrically, a shift to the right is no more of a dispacement than a “proper” shift to the left would be. Given that hitting R1 and R2 involves shifting fingers to the left of home row positions, I suspect many people hit R4 by shifting fingers to the left as well (the keys aren’t any further away, after all). The common complaint about B being on the “wrong” sides of split keyboards is one data point here. To be honest, I’m still on the fence about this change, and waffle between it being either clever or utterly disqualifying.

R5: Increase the size of all modifier keys to 1.5u (except Menu, which grows to 2u to keep the spacebar centered around the homing keys), and shorten the spacebar to 4u to match.

Other general comments:

  • One of the goals with this design was to minimize the number of keycap sizes involved (aside from the spacebar and awkward menu key, everything else is 1u, 1.5u, or 2.5u). But while that makes it easier to swap keys around on the board, finding many of those keys in the first place is likely going to be difficult (legends aside, can you even get 2.5u caps?). Of course blank caps would be easier, but that flies in the face of the theme…
  • I find the sloped-in, V-shape of the side modifier key layout on R2-4 of ANSI strangely pleasant and comforting, and was glad to preserve that at least somewhat (more symmetry would be nice, but hey, the slope isn’t symmetrical on ANSI either).
  • Still on the fence about the R4 shift. Personally I don’t think I’d care… unless I needed to go between this and a “properly”-aligned vertical column board. In that case I would probably hate it.

Would love to hear people’s thoughts or suggestions!

1 Like

Why not ape the Boardwalk’s layout?

1 Like

Interesting, I hadn’t seen that before. Sort of Type-Matrix-ish. I like the Ergodox keycap compatibility…

With uniform 1.5u side columns you lose that nice slope on the side keys, which is too bad, but maybe not a deal breaker. This is what you get with the straight side columns and no other special key sizes (other than space):

From there the obvious choice seems like extending out Enter and Left Shift. Then I want to extend Right Shift to shift over R4 again, filling things in and adding symmetry. But that leads back where we started… :thinking:

Maybe instead of extending outwards to fill the R3 and R4 gaps, Shift and Enter should stay the same size and just shift to the right? But then how to fill that awkward space…

Edit: Ok, last one for the night… This eliminates Menu and actually moves a few pinky keys to different rows (:open_mouth: ) but has a nice overall balance to it. Ctrl not being in the very bottom right could be a dealbreaker though (or just having a non-modifier in the modifer row at all…)

Edit 2: Ok, THIS is the last one… Mod keys are bigger again and Ctrl is where you expect it. These last two are only 14u wide, which I kind of like.


I would probably go for something like this

The main issue with something like this will always be keycap compability though, so with that in mind I would perhaps try something like this, that uses only standard keycaps

The brackets end up in a weird position, but other than that this looks very usable IMO.


Of course I will always hold ISO closest to my heart, so here’s a ISO mockup using only two non-standard keys, a 1u backspace, and a 2u vertical enter (which can use a 2u space, or a 2u vertical key from a numpad).

I…I hate that second layout. Group buy soon?

1 Like

Oh yeah, it’s pretty great :stuck_out_tongue:

I actually thing I’ve seen a board with a similar layout to that, but can’t recall where.

If you ever wanted to make one yourself you could just put paste the raw KLE data into and get the files for a plate from there. A lasercut acrylic plate is like $20, but you would have to handwire it though.

We’ve already had the Keeblade, time for the Keebuster Sword