Slim 55% Layout

donpark · August 14, 2019, 11:43pm

Started with a Planck layout and ended up a weird hybrid between 40% and 65%.

UPDATE: I uploaded KLE layout file to my keyboard Github repo.

donpark · August 15, 2019, 5:49am

Sorry. This was just a sketch. I’m not likely to do a GB or go on a 3 month long “you owe us” guilt-trip hike on impulse anytime soon.

XTaran · August 17, 2019, 11:40am

Funnily I was thinking about a very similar layout a week ago. I though started with a 60% layout and wanted only four rows like 40%, but with all columns of a 60% and dedicated cursor keys. The latter caused the design to gain that additional column typical for 65% keyboards.

So here are my designs on this topic:

Most similar to your design, just without dedicated Raise and Lower keys around the spacebar but instead a standard 6.25 spacebar:

The same again, just with dedicated Lower and Raise keys and split space:

Having seen Zambumon’s Tokyo66 on the Nautilus Nightmares page, I couldn’t stop thinking how an arrow up key (and the according keys below) between /? and the right Shift key:

But actually that arrow keys position works nicer with a HHKB style setup as the right arrow key is on the edge of the key space, so I also made a HHKB style design without that additional key column:

And as a variant, here’s also a 1u right Shift plus an additional 1u key, e.g. a function key like the HHKB, because 2u Shift key caps are hard to find:

I do not intend to do a GB or similar either, but I intend to publish anything I needed for building one for my own needs as Open Source. Actually I already have a local git repository with all I did so far (clicking around on http://www.keyboard-layout-editor.com/ :-), but I haven’t found a nice name yet (not even sure if that’s 50% or 55% :-), so I haven’t created a project on GitHub for it yet.

donpark · August 17, 2019, 3:31pm

Neat. I did not place spend much time considering keycap size availability like you have. Slim 55 is I think promising but should be considered WIP.

My initial design focus was familiarity, ensuring keys are where touch typist expect them to be. So my space bar was a compromise between need for more and familiar sized R4 keys and where thumbs usually rest. I did consider moving arrow keys before RShift but didn’t think it’d work for users like who tend to change keyboard multiple times a day.

As to why I have both Lower and Raise when there are enough keys to alleviate the need for upper layer, I use Raise as Shift+Lower. So 1 = Lower+Q and ! = Shift+Lower+Q or Raise+Q. IMO having both LOWER and RAISE layers is too much cognitive load for coding use.

XTaran · August 17, 2019, 5:06pm

Well, one of the initial idea was to make it GMK Paperwork compatible as I like that keycap set a lot.

But then I noticed that GMK Paperwork misses most keys for those additional two or three columns compared to a 40%. At least the HHKB variant with 1u right Shift could be outfitted with GMK Paperwork if use the dark ← and → keys instead of [{ and ]} and the second (dark) '" key instead of \| or so.

Yes, that’s definitely one of my goals, too: being able to not having to think too much when having to type ', /, - or =.

Valid point. I’m not yet fully used to split space yet either, occasionally hitting the wrong space, because I mostly hit space with the left thumb, but occasionally also with the right thumb.

I though think this can be solved with a “tap for space, hold for modifier” QMK configuration.

I agree. All my 40% keyboards are configured with ideas similar to yours, but still actually using two layers to make the function keys more accessible:

Fn1+Esc = ~, Fn1+Q = 1
Fn2+Esc = F1, Fn2+Q = F2
Fn1+A = !, Fn2+A = ! (i.e. Fn<x> as Shift+Fn is equivalent on both layers)

Since I have more keys per row on the 55%, I do not need to use Fn2+Esc for F1, but can use Fn2+Q, which IMHO makes it much more easier to remember and use. (I though wonder, how easy I can then switch between 55% and 40% keyboards. )

XTaran · September 7, 2019, 7:37pm

It’s now published under the project name XTK on Github licensed under GPLv3+.

EDIT: Project renamed from XTKb to just XTK. Link in here updated, but the old link still works as redirect.

FSund · September 9, 2019, 7:45am

That XTK 50 ISO looks really tempting. For full ISO support you should really had a split left shift, but sadly there is no room for that.

XTaran · September 13, 2019, 11:56pm

Thanks!

Indeed, thanks for reminding me of that additional key in ISO layouts! To not forget about this, I opened an issue in the Github repository.

I currently see multiple possible solutions, but all have their downsides:

Extend the board by 0.25u on the left side and use 1u Shift plus the <>\ ISO-specific key. @donpark’s layout does have that addiitional 0.25u width btw. and could probably also support an ISO Enter. This solution would nevertheless have two downsides:
- 1.25u Escape key needed. (Might be substituted with a 1.25u Tab key as in @donpark’s layout.)
- Would need a different (because wider) plate and PCB.
  - In theory one could try to make the ISO-incompatible XTW design (which is 0.25u wider) compatible with that layout, but supporting an alpha block with all keys shifted by 0.25u probably makes the plate very unstable. So using the XTW plate is probably not an option.
Shift the according row by 0.25u to the right and reduce the left Shift key by 0.75u to 1u and right Shift by 0.25u so that this key can fit in the freed space. Downsides:
- Uncommon stagger (same stagger as the BM43a uses and for which it got quite some bad reviews on Massdrop —eh— Drop.)
- And again, supporting a row with all keys shifted by 0.25ueither makes the plate way more unstable or requires another plate variant.
Use shorter modifier keys and put the <>\ key in the modifier row. Downsides:
- Uncommon location for that key.
- Only works with keycap profiles where R4 and R5 have the same profile. Exists, but is not too common. DSS seems to be such a profile.