Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atreus2: Proposal for a keyboardio style layout #706

Closed
wants to merge 4 commits into from

Conversation

algernon
Copy link
Member

@algernon algernon commented Nov 1, 2019

For the past few days, I've been thinking about how to best translate the spirit of the default Model01 layout to the Atreus2. There are a good number of challenges, ranging from considerably less keys, through not having palm keys, to less thumb keys. As such, a direct translation is not possible, the best one can do is try to capture the spirit of the Model01 layout.

What I came up with feels okay, but I only tested on an Atreus1, which has two keys less, so I had to imagine how it'd work with two more. Some of the decisions were made based on this practice.

The layout consists of four layers: the base QWERTY layer, a LOWER and a RAISE layer, and a MOUSE layer. The MOUSE layer can be toggled on by pressing LOWER and RAISE at the same time. Pressing either of those again will get us back to the QWERTY layer.

I went with four layers so that we can fit everything we want onto the keyboard, without having to place some keys into awkward places.

Without much further ado, lets look at the layers:

QWERTY

+-------+-------+-------+-------+-------+
| Q     | W     | E     | R     | T     |
| A     | S     | D     | F     | G     +-------+
| Z     | X     | C     | V     | B     | Tab   |
| L1    | Bspc  | Ctrl  | Cmd   | Shift | Esc   |
+-------+-------+-------+-------+-------+-------+

              +-------+-------+-------+-------+-------+
              | Y     | U     | I     | O     | P     |
      +-------| H     | J     | K     | L     | ;     |
      | Enter | N     | M     | ,     | .     | /     |
      | Space | Shift | Alt   | -     | '     | L2    |
      +-------+-------+-------+-------+-------+-------+

For the most part, there's nothing surprising here. The alphas are where one would expect them to be. I'd like to explain the positioning of the rest of the symbols, however:

  • The LOWER (L1) and RAISE (L2) keys went to the pinky position in the bottom row. Reason for the pinky is that this makes one able to hold these keys, and press most others on the same half of the keyboard, without twisting their hands. Placing them anywhere else, it would result in uncomfortable combinations. Thumbs would be another option, but I think thumbs are better used for things pressed more often than layer keys.
  • Talking about thumbs, I can reach the two thumb keys, and the two innermost keys of the bottom row with my thumb, comfortably. So I consider those keys thumb-accessible.
  • This makes Cmd,Shift, and Alt good candidates for those positions. Non-mac users may want to swap Cmd and Ctrl, though. Perhaps we could make a toggle for that somewhere, to support both with the same firmware with ease.
  • Esc went to the lower left thumb key, because it's an important key.
  • Tab went above it, for similar reasons.
  • Space and Enter went on the right thumb keys, for similar reasons. I opted to place them on top of one another (with Space becoming Enter on the LOWER and RAISE layers, to mirror the Model01's Fn+Space behaviour) because it seemed logical to do so. Both are required fairly often, so are prime thumb-candidates. Having them near makes it easier to learn their position. It does make it easier to mishit though.
  • Backspace went to the side, under the ring finger, because it is less often used than modifiers. Like on the Model01, it turns into Delete on the RAISE and LOWER layers.

Lower

I borrowed the term from QMK, it doesn't really mean anything. I just couldn't come up with a better name. It's a combination of a navigation (left) and numpad (right) half:

+-------+-------+-------+-------+-------+
|       |       |       |       |       |
| Left  | Down  |  Up   | Right | PgUp  +-------+
|       |       |       |       | PgDn  | Home  |
| -L1-  | Del   | Ctrl  |  Cmd  | Shift |  Esc  |
+-------+-------+-------+-------+-------+-------+


     .       +-------+-------+-------+-------+-------+
     .       |   `   |   7   |   8   |   9   |  -    |
     +-------|   .   |   4   |   5   |   6   |  +    |
     | End   |   0   |   1   |   2   |   3   |  \    |
     | Enter | Shift |  Alt  |   =   |   *   | *L3*  |
     +-------+-------+-------+-------+-------+-------+
  • Cursors are placed on the home row on the left side, in a hjkl-style arrangement. The reason I didn't put these on the right (where hjkl are) is because the same layer is also used for the numpad, and the numpad made more sense on the right side. Since hjkl is a vim-ism, vim users already have that on the right side, on the QWERTY layer. Everyone else would need to learn that way of navigation, and might as well learn them on the left side then.
  • PageUp and PageDown are right next to the arrow keys for easy paging.
  • I placed Home and End on the top thumb keys on each half, because I wanted them near-ish the cursors. End ended up on the right half, because I didn't find a comfortable place for it on the left one.
  • The numpad on the right side more or less mirrors that of a numpad. The major difference is 0, which ended up on the same row as 123, instead of under 1. The reason for this is that I wanted to keep Alt in the same position on all layers. If I had 0 under 1, the whole cluster would've shifted to the right, and 0+\ would end up closer to the inner side. I didn't want that, because I wanted \ to be in the same position as / on the base layer. I also wanted = in the - position.

Raise

+-------+-------+-------+-------+-------+
|  F7   |  F8   |  F9   | F10   |  >>   |
|  F4   |  F5   |  F6   | F11   |  <<   +-------+
|  F1   |  F2   |  F3   | F12   |Ply/Pse| Mute  |
| *L3*  |  Del  |  Ctrl | Cmd   | Shift |  Esc  |
+-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       |       |       |       |       |       |
     +-------|   {   |   }   |   [   |   ]   |       |
     | Vol+  |  Vol- |       |       |       |  \    |
     | Enter | Shift |  Alt  |       |       | -L2-  |
     +-------+-------+-------+-------+-------+-------+
  • Function keys went on the left side, so that Alt+Fx would be easy to press, and Cmd+Fx would still be comfortable.
  • Besides function keys, the left side sports a next and previous track key, a play/pause and a mute button. I felt that these are the most used media keys, so it made sense to have them on the opposite side than the layer key.
  • The right side has the rest of volume control.
  • Square and Curly brackets are on the right half, in hjkl position.

Mouse

The Mouse layer is accessed by holding both Lower and Raise together, and the layer toggles on. As such, once toggled on, Lower and Raise will not be active anymore, once released. This makes hitting either of those keys again bring us back to the base layer.

It's toggled, because holding both layer keys with the pinkies is awkward and uncomfortable. Most of the keys here are also keys that one is likely to use for a longer time than what's comfortable while holding a layer key.

+-------+-------+-------+-------+-------+
|       |       |  MUp  |       |  MBL  |
|       | MLeft | MDown | MRght |  MBM  +-------+
|       |       |       |       |  MBR  |       |
| *L3*  |       |  Ctrl |  Cmd  | Shift |  Esc  |
+-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       | PrScr | WClr  |       |       |       |
     +-------|  Ins  |  WNW  |  WNE  |       |       |
     |       |       |  WSW  |  WSE  |       |       |
     |       | Shift |  Alt  |       |       | *L3*  |
     +-------+-------+-------+-------+-------+-------+

Unlike on the Model01, mouse movement and mouse warp are on different hands. This is due to having less columns. We can't fit mouse movement, mouse warp, and mouse buttons onto the same side, not unless we sacrifice comfort or reachability.

Summary

I tried to capture the spirit of the default Model01 layout here, while keeping comfortability in mind too. Due to fewer keys, one will require more keys to access the same functionality at times, but I tried my best to keep the number of required actions small in the majority of cases.

I've been typing on a similar layout on my Atreus1: the only difference is that in my case, I only have one thumb key, so I made them into tap-dance key, where one tap functions as if the lower key was pressed, a double tap functions as if the upper one was. This tapping thing is annoying, but it's the closest I could get to the Atreus2's physical layout at this time.

Despite that annoyance, the layout feels surprisingly okay (despite being QWERTY :P).

@algernon algernon added enhancement hardware labels Nov 1, 2019
@algernon algernon requested a review from obra Nov 1, 2019
@algernon algernon force-pushed the atreus2/example-layout branch from e58b193 to 8486063 Compare Nov 1, 2019
@obra
Copy link
Member

@obra obra commented Nov 1, 2019

@algernon
Copy link
Member Author

@algernon algernon commented Nov 1, 2019

I'd love to try an alternative with a number -row- rather than a numpad.

That can be arranged. The Fx keys would need a little squeezing to fit (I'd like them to match the number layout).

The problem with this is that there's only 5 keys on the top and home rows, so I'd have to use the pinky column for a number too. Pressing two keys on that row at the same time is ugh, unless the layer key is a toggle or a oneshot.

An alternate option would be to have one half of the numbers on one layer, the other half on another, triggered by opposing layer keys. No uncomfortable finger gymnastics this way, but splitting numbers between two layers is mentally harder to follow and remember.

Another alternative would be to put the layer keys on one of the thumb keys (the top ones, most likely). That way one would hold the key with a thumb, the numbers and the symbols above on the same hand would still be easy to access, without any finger-conflict. In this case, however, you'd have problems when you apply modifiers: Control and Command are currently on the left side, Alt on the right, and Shift on both. Some combinations would therefore be awkward when the modifier and the number are on the same finger. I feel this'd also be a waste of a good thumb key.

With my keypad layout, and modifiers in those positions, when there's a finger conflict with a modifier, the thumb can still reach the modifier, resolving the problem. If we put layer keys on the thumb keys, then this resolution is no longer possible. If we keep the layer keys on pinkies, then pressing 1 becomes an issue, as that'd be L1 + Q (or L1 + A if numbers are on the home row), which are on the same column. Yes, I can use my ring finger, but that's a kind of gymnastics I find not so comfortable.

I took great care to not place anything on the layer keys' column if it can be avoided. The cursor keys are an exception, because I wanted to go with a hjkl layout. I think an inverted T shape would be better there, shifted one column to the right. I stuck with hjkl due to wanting to follow the Model01 when possible and not sacrificing too much.

My rough thought was numbers on home row on the layer that puts symbols
like brackets on the row above them.

I can give that a go, but the problems outlined above apply.

I'm a little bit conflicted about putting fn/layer on pinkies, though I do understand where you're coming from. I might consider making them sticky keys if tapped.

Sticky-on-tap, or OneShot? From personal experience, sticky-on-tap becomes a chore very quickly. I'd suggest OneShot instead: they'd work as momentary layer keys when held, but would oneshot when tapped quickly (and toggle when double-tapped). (Mind you, I'd use oneshot for everything, but I'm so used to those by now that any layer or modifier that isn't oneshot feels inferior to me, so I'm not the best judge here :P)

@obra
Copy link
Member

@obra obra commented Nov 1, 2019

@algernon
Copy link
Member Author

@algernon algernon commented Nov 1, 2019

We -may- need to banish Fx keys to yet another layer to make this not crazypants.

Oh, I never meant to have them on the same layer as numbers! Just that their layout should mirror the layout of numbers (save for F11 and F12).

Understood. (FWIW, I would have assumed the -bottom- thumb keys)

I was contemplating that too, but... bottom thumb keys are - in my opinion - are easier to hit, so they should have functionality that is more often used. Esc and Space fit that better than layer keys.

Yeah. For "model 01 compatible", I think hjkl is correct.

I've played a bit further with the layout, and found the cursor layout outlined earlier awkward, Left in particular was painful to hit unless I toggled the layer on, which sucked when all I wanted was some quick movements.

I pushed a variant with inverted-T for now, but as a separate commit to make it easier to test both.

Oneshot is great.

For layer keys, or modifiers too? (Please say both, please say both.... O:))

@obra
Copy link
Member

@obra obra commented Nov 1, 2019

@algernon
Copy link
Member Author

@algernon algernon commented Nov 1, 2019

Hm... Dual-use Space/L2 sounds worth trying. I'll give that a go!

@algernon
Copy link
Member Author

@algernon algernon commented Nov 1, 2019

Hrm. Quick try isn't promising. There are a number of times I want to hold space, and want repeat. For example, in many games, space is an important key, and is often held. The Atreus2 is also a nice board to have for gaming, because one can have their mouse closer...

Now, DualUse on something one doesn't hold that often would likely be more useful, I think. It's hard to find such a key, though.

Thus, I'd either stick with a numpad, or push a commit that turns things into oneshots, and another that adds homerow numbers. Then you can try how it works in practice more easily. :)

@algernon algernon force-pushed the atreus2/example-layout branch from d6fc04d to 40d4cf3 Compare Nov 2, 2019
algernon added 4 commits Nov 2, 2019
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Because pressing L1+A for left was awkward. L1+S is considerably easier on the fingers.

Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
@algernon algernon force-pushed the atreus2/example-layout branch from 40d4cf3 to 381f4da Compare Nov 2, 2019
@algernon
Copy link
Member Author

@algernon algernon commented Nov 2, 2019

Pushed an update with hjkl arrows and number row on top of oneshots. I don't like it myself, but try it yourself too:

QWERTY

      +-------+-------+-------+-------+-------+
      | Q     | W     | E     | R     | T     |
      | A     | S     | D     | F     | G     +-------+
      | Z     | X     | C     | V     | B     | Tab   |
      | L1    | Bspc  | Ctrl  | Cmd   | Shift | Esc   |
      +-------+-------+-------+-------+-------+-------+

      .       +-------+-------+-------+-------+-------+
      .       | Y     | U     | I     | O     | P     |
      +-------| H     | J     | K     | L     | ;     |
      | Enter | N     | M     | ,     | .     | /     |
      | Space | Shift | Alt   | -     | '     | L2    |
      +-------+-------+-------+-------+-------+-------+

Lower

     +-------+-------+-------+-------+-------+
     |       | Left  | Down  | Up    | Right |
     |  1    |   2   | 3     | 4     | 5     +-------+
     |       |       | PgDn  | PgUp  |       | Home  |
     | -L1-  | Del   | Ctrl  |  Cmd  | Shift |  Esc  |
     +-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       |   {   |   }   |   [   |   ]   |  *    |
     +-------|   6   |   7   |   8   |   9   |  0    |
     | End   |       |       |       |       |  \    |
     | Enter | Shift |  Alt  |   =   |   `   | *L3*  |
     +-------+-------+-------+-------+-------+-------+

Raise

     +-------+-------+-------+-------+-------+
     |  F11  | F12   |       | <<    |  >>   |
     |  F1   |  F2   |  F3   | F4    |  F5   +-------+
     |       |       |       |       |Ply/Pse| Mute  |
     | *L3*  |  Del  |  Ctrl | Cmd   | Shift |  Esc  |
     +-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       |       |       |       |       |       |
     +-------| F6    | F7    | F8    | F9    | F10   |
     | Vol+  |  Vol- |       |       |       |  \    |
     | Enter | Shift |  Alt  |       |       | -L2-  |
     +-------+-------+-------+-------+-------+-------+

Mouse

The mouse layer is unchanged.

algernon's favourite

My favourite is the variant one commit prior to the above. The QWERTY and Mouse layers are the same, but Lower and Raise look like this:

Lower

     +-------+-------+-------+-------+-------+
     |       |       |  Up   |       |       |
     |       | Left  | Down  | Right | PgUp  +-------+
     |       |       |       |       | PgDn  | Home  |
     | -L1-  | Del   | Ctrl  |  Cmd  | Shift |  Esc  |
     +-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       |   `   |   7   |   8   |   9   |  -    |
     +-------|   .   |   4   |   5   |   6   |  +    |
     | End   |   0   |   1   |   2   |   3   |  \    |
     | Enter | Shift |  Alt  |   =   |   *   | *L3*  |
     +-------+-------+-------+-------+-------+-------+

Raise

     +-------+-------+-------+-------+-------+
     |  F7   |  F8   |  F9   | F10   |  >>   |
     |  F4   |  F5   |  F6   | F11   |  <<   +-------+
     |  F1   |  F2   |  F3   | F12   |Ply/Pse| Mute  |
     | *L3*  |  Del  |  Ctrl | Cmd   | Shift |  Esc  |
     +-------+-------+-------+-------+-------+-------+

     .       +-------+-------+-------+-------+-------+
     .       |       |       |       |       |       |
     +-------|   {   |   }   |   [   |   ]   |       |
     | Vol+  |  Vol- |       |       |       |  \    |
     | Enter | Shift |  Alt  |       |       | -L2-  |
     +-------+-------+-------+-------+-------+-------+

Especially with oneshots, this is nice to type on. There's no finger contortion for the pinky columns, I can even hold the layer keys there.

Layer keys on thumbs

I made a few tries with layer keys on thumbs, even with one - or both - of them being DualUse, and that didn't feel right. No matter what I put as the on-tap use, I always ended up in situations where I wanted it to repeat during normal use of the keyboard. As such, I haven't pushed a variant like that.

@algernon
Copy link
Member Author

@algernon algernon commented Jan 2, 2020

This is obsoleted by #782, closing.

@algernon algernon closed this Jan 2, 2020
@algernon algernon deleted the atreus2/example-layout branch Jan 2, 2020
@obra obra restored the atreus2/example-layout branch Jan 2, 2020
@obra
Copy link
Member

@obra obra commented Jan 2, 2020

Repoening: We still want to end up with a keyboardio-style layout for the Atreus sometime.

@obra obra reopened this Jan 2, 2020
@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented Jan 23, 2020

I don't understand the attraction of hjkl arrow keys, particularly since you've already conceded that vim users will rather use the real hjkl keys on the base layer. The mousekeys are in an inverted-t arrangement, so why not put the arrow keys in inverted-t also, and let the general public remain blissfully ignorant of vim?

@obra
Copy link
Member

@obra obra commented Jan 23, 2020

@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented Jan 24, 2020

Indeed, but the hjkl keys have fallen between two stools now. They made sense when they were actually on "hjkl", but now they're on the wrong hand. The worm can is already open. For example, when you flip the hands should you not also flip J and K? ;-)

@indirect
Copy link
Contributor

@indirect indirect commented Feb 7, 2020

Thank you for putting so much work and thought into this! Now that I've built a board with an Atreus2 layout, I'm starting to develop opinions about it. For whatever it's worth, the my sense of how the Model01 "feels" has always been strongly influenced by the space/enter and backspace/delete symmetry. Any Model01-inspired layout should (imo) have symmetrical space and backspace on the left and right "resting" thumb keys.

Take this with a large grain of salt because I learned vim on dvorak and don't understand hjkl, but it seems weird to me to put the arrows in hjkl order unless they are exactly under the hjkl keys.

When I switch back and forth, I end up really missing the thumb dots from the Model01 on the Atreus2. I hope the Atreus2 "resting" thumb keys (space and backspace on the Technomancy layout) will have positioning dots.

I personally find chording with my pinkies on the bottom row quite difficult compared to chording with my thumbs, so I would stick with both the Atreus and Model01 pattern of thumb-area keys for chording and outer keys for tapping.

Since I never really got into using the numpad layer, my sense of preserving the Model01 "feel" would be to put the L1 and L2 shifts as center thumb keys, put the numbers across the top row of L1, and put the arrows directly under hjkl on L1. The number symbols are then typed chorded or one-shotted with L1+Shift, but in places that match "physical memory" of a keyboard num row.

I hope some of that feedback is helpful! I'm very excited about the upcoming Kickstarter. 😁

@obra obra changed the title Atreus2: Proposal for a new default layout Atreus2: Proposal for a keyboardio style layout Apr 6, 2020
@mattmc3
Copy link

@mattmc3 mattmc3 commented May 14, 2020

I'd love to try an alternative with a number -row- rather than a numpad.

@obra - Based on this comment, I'm curious if you would be open to a simple Number/Symbol layer that takes the place of the missing number row by having the numbers 1-9&0 on home row, and the typical QWERTY number symbols on the top row. Something like this:

      +-------+-------+-------+-------+-------+
      | !     | @     | #     | $     | %     |
      | 1     | 2     | 3     | 4     | 5     +-------+
      |       |       |       |       |       | Esc   |
      | Shift | Tab   | Cmd   | L2    | BkSp  | Ctl   |
      +-------+-------+-------+-------+-------+-------+

      .       +-------+-------+-------+-------+-------+
      .       | ^     | &     | *     | (     | )     |
      +-------| 6     | 7     | 8     | 9     | 0     |
      | Enter | {     | }     | [     | ]     | \     |
      | Alt   | Space | L1    | |     | =     | +     |
      +-------+-------+-------+-------+-------+-------+

Screen Shot 2020-05-13 at 11 56 23 PM

Feel free to grab the spreadsheet and play with the layout here.

I think of these layers as "num" and "nav" layers (num having numbers and symbols, and nav with arrows, home, end, pgup/dn etc). The num layer's purpose is to compensate for the lack of a number row, and then that frees you up to make the other function layer match the model 01 more closely. It makes a great default too because every typist will already understand what to do without a much memorization or retraining since the symbol positions and fingers would match a standard QWERTY layout.

@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented May 14, 2020

Also (sorry for the double) I would rather put `~ in the NUM layer and promote =+ to the base layer, given that the triplet of keys ( -_ '" =+ ) is in a similar location on the model01 and backticks are not commonly used outside of software development.

@mattmc3
Copy link

@mattmc3 mattmc3 commented May 14, 2020

@andrewgdotcom - That's a fair assessment, and I'm certainly not nearly as tied to the punctuation part of this proposal as the number/symbol combos. I will say though that my reasoning for the square and curly bracket positioning is simple - it mirrors the angle brackets <>, and if you offset them then the symmetry is lost. I agree with +=, and those should be more prominent. In my personal mappings, I always put backtick as the function layer of single and double quote because that placement makes the most sense to me being that it's another quote character, and then a dedicated += key has the tilde ~ as its function layer symbol.

@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented May 14, 2020

it mirrors the angle brackets <>, and if you offset them then the symmetry is lost

What about then making the square brackets the inner two fingers and the curlies the outer two? :-)

@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented May 14, 2020

image

@andrewgdotcom
Copy link

@andrewgdotcom andrewgdotcom commented May 14, 2020

@mattmc3 I've just noticed that you only have one pinky-shift. This will make it nearly impossible to type a capital Z, for example.

@mattmc3
Copy link

@mattmc3 mattmc3 commented May 14, 2020

@andrewgdotcom That’s a good point, and could be swapped with CTRL, ALT, or Esc. There’s not as many thumb keys on the Atreus as I use on my Model 01 (I don’t find the reach for the first three on the bottom row of the Atreus to be comfortable for any finger, frankly), but the shift key on the left pinky was intended to somewhat simulate a standard layout. But you’re right, you’d probably have to move your hand position for some capital letters the way I have it, or make it a sticky key. Again, this was a starting point for home row numbers and top row symbols, so I’m not tied to any other elements of this configuration if it makes more sense to reposition. That bottom row especially needs some thought, because those modifiers are pressed in conjunction with a lot of other keys that could be on other layers than just the default one, so reach logistics will be important.

EDIT: One other thing to note - tab is a really weird character outside of programming to have occupy a dedicated key, and having it instead be a function layer of the space key would give you that one additional dedicated modifier key you need to have 2 functional layers.

@obra
Copy link
Member

@obra obra commented May 14, 2020

@mattmc3
Copy link

@mattmc3 mattmc3 commented May 29, 2020

After messing with it for a couple weeks, going back to the original laminated Model 01 key cheatsheet, trial running some options, and taking feedback from @andrewgdotcom, I think I have a revision that stays truest to the keymapping defaults on the Model 01 while providing a number row. If a key absolutely didn't have to be moved, I tried not to move it. You could also add another number pad/mouse movement layer too if you wanted to capture the whole spectrum of Model 01 bindings. The ordering of the thumb keys (Ctrl, Cmd, Shift, Alt) is intended to match the left to right order of the keys on the Model 01 while still respecting the thumb homing on backspace/space, as well as recognizing that the two outermost keys on either side aren't that easily reachable. This layout would be targeted for people who never remapped keys on the Model 01, but are trying out the Atreus.

Screen Shot 2020-05-29 at 11 55 48 AM

Also for completeness, I went the entirely other direction as well and have a number row version of the Atreus layout that just tries to stay true to the default Atreus layout while only changing what is necessary to provide a number row. It uses symmetry between left and right hand for brace characters, and should be much easier to memorize for anyone familiar with a standard keyboard. This one doesn't take the Model 01 into account, but is trivial to implement on the Model 01 so that the you can seamlessly swap back and forth between the two.

Screen Shot 2020-05-29 at 11 56 23 AM

Both layouts throw out a symbol key (|\ and `~ respectively) to make room for the included butterfly key or "any key" for use as the Upper Layer modifier. The examples are here for any further iterations: https://docs.google.com/spreadsheets/d/1xFE5EuDWbzXJ1SN8nyezDhJdCbEmEHpsifcPjBkF18U/edit?usp=sharing

@obra
Copy link
Member

@obra obra commented Jun 2, 2020

@mattmc3
Copy link

@mattmc3 mattmc3 commented Jun 2, 2020

@obra - Good catch on grave accent/tilde character and Esc. That was an oversight. The model 01 has the Enter and Tab symmetry, and this should have too. Also, that adds some symmetry to the quote characters on the bottom row on both sides. And as far as the Function keys go, I think if we make a small tweak that F11/F12 should move to those middle keys, then the numbers would line up with the function keys. Then you can kinda start to see that the whole upper layer is literally the upper part of a full keyboard, albeit with the function keys at the bottom row. I'm open to your suggestions around the tab/command changes. As a Mac user, I am sensitive to the fact that CMD-Z/X/C/V needs to be accessible and easy to press, and for Windows users, it'll be CTRL-Z/X/C/V. It may be that we can't put both CMD and CTRL in an ideal spot, and Mac users may choose to swap the two. Here's the layout with those small revisions:

Screen Shot 2020-06-02 at 7 21 55 PM

@jjsil
Copy link

@jjsil jjsil commented Jun 28, 2020

Sorry to jump in here, I just got my Atreus and this kind of layout is exactly what I was looking for. Thank you!

I came up with an alternative rev3 based on rev2 (I like the Cmd and Shift positioning better than in rev2.1) with the numbers and the F keys on the top row, each with a dedicated layer, somewhat like @obra was proposing.

This means you need to use three keys to enter some of the symbols, Upper+Shift+O for "(" for example so it might not be ideal. I think it does make it very easy to reason from the Model 01 layout though, Upper makes the top row like the Model 01 top row.

Thank you @mattmc3 for providing the Google Sheets link, it made it much easier to try things out!

Screenshot 2020-06-28 at 10 59 47

@graemeg
Copy link
Contributor

@graemeg graemeg commented Sep 23, 2020

I've never used the Model01 and waiting for my Atreus to arrive. Anyway, just thought I would put this idea out there. Does Kaleidoscope support dual keys like QMK? If so, you can free up 4 thumb keys by making the home row dual keys.

A | S | D | F when typed
Cmd | Shift | Ctrl | Alt when held.

...and then the same on the right hand...

J | K | L | ; when typed
Alt | Ctrl | Shift | Cmd when held.

Ctrl and Shift are purposely on the middle and ring fingers as they are strong finger, and the combination of keys are easier (feel better at least) when typed together. I've used this for a couple months on my Ergodox and is very quick to learn, and comfortable to use.

The bonus is that you now have 4 free thumb keys for something else. More layer switching etc.

@gedankenexperimenter
Copy link
Collaborator

@gedankenexperimenter gedankenexperimenter commented Sep 23, 2020

Kaleidoscope does have that feature, in the Qukeys plugin.

@joeynguyen
Copy link

@joeynguyen joeynguyen commented Oct 5, 2020

I've never used the Model01 and waiting for my Atreus to arrive. Anyway, just thought I would put this idea out there. Does Kaleidoscope support dual keys like QMK? If so, you can free up 4 thumb keys by making the home row dual keys.

A | S | D | F when typed
Cmd | Shift | Ctrl | Alt when held.

...and then the same on the right hand...

J | K | L | ; when typed
Alt | Ctrl | Shift | Cmd when held.

Ctrl and Shift are purposely on the middle and ring fingers as they are strong finger, and the combination of keys are easier (feel better at least) when typed together. I've used this for a couple months on my Ergodox and is very quick to learn, and comfortable to use.

The bonus is that you now have 4 free thumb keys for something else. More layer switching etc.

This suggestion sounded great and I tried to implement it using QuKeys, but after some testing and even after changing the timeout and threshold:

  Qukeys.setOverlapThreshold(100);
  Qukeys.setHoldTimeout(1000);
  QUKEYS(
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 1), Key_LeftAlt),      // S / LeftAlt
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 2), Key_LeftShift),    // D / LeftShift
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 3), Key_LeftControl),  // F / LeftControl
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 4), Key_LeftGui),      // G / LeftSuper

    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 7), Key_LeftGui),      // H / LeftSuper
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 8), Key_LeftControl),  // J / LeftControl
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 9), Key_LeftShift),    // K / LeftShift
    kaleidoscope::plugin::Qukey(0, KeyAddr(1, 10), Key_LeftAlt),     // L / LeftAlt
  )

the modifiers were still too easily triggered as I typed. Not sure if I was setting it incorrectly.

@gedankenexperimenter
Copy link
Collaborator

@gedankenexperimenter gedankenexperimenter commented Oct 5, 2020

If you're getting unintended modifiers with Qukeys configured like this:

  Qukeys.setOverlapThreshold(100);
  Qukeys.setHoldTimeout(1000);

…that means that you're either holding the qukey for more than a full second (unlikely), or you're pressing the qukey, pressing another key, then releasing that other key before the qukey — as Qukeys sees it. It's also possible that other plugins are interfering. Qukeys should be the first plugin registered in KALEIDOSCOPE_INIT_PLUGINS(), if possible.

@@ -99,25 +172,14 @@ KALEIDOSCOPE_INIT_PLUGINS(
Focus,
FocusEEPROMCommand,
FocusSettingsCommand,
EscapeOneShot,
OneShot,
SpaceCadet,
MouseKeys,
Macros,
Qukeys
Copy link
Collaborator

@gedankenexperimenter gedankenexperimenter Oct 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Qukeys should get registered before EscapeOneShot, OneShot, SpaceCadet, MouseKeys, and Macros. Of those others, SpaceCadet should be second, though I'd recommend dropping it and just using Qukeys if it's in there anyway.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gedankenexperimenter thanks for the suggestion! I tried implementing it as you said, and it seems a little bit better but still not bulletproof. I still get accidental triggers of the modifiers as I type. Here's a gist of my ino file. Please let me know if there's anything I might have wrong - https://gist.github.com/joeynguyen/c09a5f7cfed683e5db9af6c4cc5c0167

@mattmc3
Copy link

@mattmc3 mattmc3 commented Oct 6, 2020

Seem like we shouldn't be going off topic in this thread. Many users of the Model01 are now receiving their Atreus pre-orders and many will come here looking for help with a Chrysalis config that makes sense with both keyboards. Let's stay on that topic here please and open additional threads elsewhere for other topics.

@joeynguyen
Copy link

@joeynguyen joeynguyen commented Oct 6, 2020

Seem like we shouldn't be going off topic in this thread. Many users of the Model01 are now receiving their Atreus pre-orders and many will come here looking for help with a Chrysalis config that makes sense with both keyboards. Let's stay on that topic here please and open additional threads elsewhere for other topics.

Agreed and I apologize for going off topic. Btw, did you mean "Kaleidoscope config" instead of "Chrysalis config"?

And in an attempt to get back on topic, here's my layout, which builds on what others have posted.

It includes:

  • a number row with symbols similar to @jjsil
  • mouse keys on the Function layer on the left side like the Model 01 although staggered down one row from the Model 01
  • dual-use (QuKeys) for Escape/Ctrl, Tab/Shift, Home/Alt, End/Upper. I like Esc and Tab there because it's similar to their locations on the Model 01. Home and End are in those spots because it makes holding Shift + Home/End easy for highlighting text in Windows/Linux.
  • The reason why there are two Shift keys: the one on the bottom row is meant to be the primary Shift key used for most functions. The one being dual-use'd with Tab above the Ctrl key is there to be used for Windows/Linux where you normally hold Shift+Ctrl at the same time to highlight words and for many other shortcuts (paste in Terminal, reopening closed tabs in browsers).
  • I left ScrollLock and Insert out because I don't use them personally so place them where you think makes sense.

Let me know if there are any questions.

Keyboardio Atreus Layout suggestion to imitate Model 01 - Google Sheets - docs google com

@phildini
Copy link

@phildini phildini commented Oct 8, 2020

Wanted to drop in and say as someone who just got their Atreus that I really appreciate the work y'all are doing, and I would be happy to test out any of these layouts. Testing would be a little easier if people attached Chrysalis json keymaps or .ino files with their suggested layouts. 💚

@joeynguyen
Copy link

@joeynguyen joeynguyen commented Oct 9, 2020

@phildini here's mine - https://gist.github.com/joeynguyen/429d2b9823c7e818e67ef7eb3d162873

Here's the new Google Spreadsheet that matches my new layout - https://docs.google.com/spreadsheets/d/1E1zXXoKZUErhxVVfAMqMfLqDCF3tXGniujSqOXy9EXo/edit?usp=sharing

Note that I purposefully added the Modifier keys to bottom row of the Upper layer on the left side of the keyboard. This is important so that when you're using the Upper layer for the arrow keys but you want to use the Modifier keys to highlight text, it will still work and also for using Upper+Shift to type the symbol characters associated with the number keys on the top row.

Keyboardio Atreus2 Proposal for Layout to imitate Model 01 - docs google com

@phildini
Copy link

@phildini phildini commented Oct 10, 2020

@joeynguyen Thanks! I'm giving it a go. Couple things to note:

  1. I had to turn off EEPROM support to get the hard-coded bindings to work.
  2. You have space and bksp switched in the .ino from what's in the graphic. I like the graphic version better, to be clear, I'm a left-handed spacer.

@joeynguyen
Copy link

@joeynguyen joeynguyen commented Oct 21, 2020

@phildini ah good catch, you're right. And the reason I have it reversed in the graphic is for the same reason as you. I use the space on the left side too, but I meant to have it on the right side in the .ino file to be closer to a direct port of the Model01's default layout.

@LeoLapworthKT
Copy link

@LeoLapworthKT LeoLapworthKT commented Nov 21, 2020

@joeynguyen Thanks! I'm giving it a go. Couple things to note:

  1. I had to turn off EEPROM support to get the hard-coded bindings to work.
  2. You have space and bksp switched in the .ino from what's in the graphic. I like the graphic version better, to be clear, I'm a left-handed spacer.

@phildini do you have the Chrysalis json keymaps files somewhere :) ?

@phildini
Copy link

@phildini phildini commented Jan 21, 2021

Hey all. I had some time with the Atreus again today, and tweaked the layout into something that feels pretty dang close to a Model 01 for me.

Screen Shot 2021-01-20 at 6 52 45 PM

Here's the google sheet: https://docs.google.com/spreadsheets/d/1HT8K4Y_E3A-aiP-UK-1t6nlLbNaAbJVDULIjEgXEXck/edit?usp=sharing

And here's my .ino: https://gist.github.com/phildini/e6af39ab45adafadf4d7e0ca7cb061f9

No Chrysalis Keymaps, sorry @LeoLapworthKT, but hopefully those would be easy to make from the relevant section of the .ino?

@ranguard
Copy link

@ranguard ranguard commented Feb 13, 2021

No Chrysalis Keymaps, sorry @LeoLapworthKT, but hopefully those would be easy to make from the relevant section of the .ino?

I installed the .ino fine thanks (and tweaked, I like space and Bksp the other way around). I did try to then export the Chrysalis json but it had errors opening the keyboard - console said something about unable to find layer 0

Now to find time to practice typing without a palm button!

@algernon
Copy link
Member Author

@algernon algernon commented Mar 31, 2022

Seeing as the Keyboardio Atreus has been out for a while, I think this pull request is very obsolete by now. However, it has a lot of great ideas and discussion, so I'm a bit reluctant to close it. However, all of those discussions are at least over a year old by now, so I'm going to go ahead anyway, and close this PR.

Please feel free to reopen, I'll keep the branch around for a little longer.

@algernon algernon closed this Mar 31, 2022
@QtOnGit
Copy link

@QtOnGit QtOnGit commented Mar 31, 2022

Hey all,

PR closing notification email brought me back to this post that helped me a year ago.
Thought to share my version of layout that's based on Phildini layout and .ino file.
It's a layout might be a good fit for people switching between standard keyboard and Atreus frequently.

Some background info about my usage of Atreus:
I frequently switch between standard keyboard and Keyboardio Atreus.(Home/Office/Laboratory/Colleague's PC)
So, modified the Atreus layout so that most key positions are at same spots as standard keyboard.
Otherwise, muscle memory tends to make mistakes during switch when typing fast.

This layout has been practised most in Vim and Linux Terminal. Felt ok to me after been using it for a year or so.
I kept updating it based on my own user experience.(mainly to reduce frequent typing mistakes during keyboard switch.).
After 3 months, layout appeared have settled at version 5.

One of good thing is 'Arrow key' can move cursor easily without leaving vim INSERT mode. Same for 'End' and 'Home' key,
jump to head and tail of line without leaving vim INSERT mode. 'Esc' key is used so often in vim, so I put it as one of
Thumb key.
Also, this layout is not bad when writing email in outlook web mail, or work under windows.

'upper' key instead of switching layers to type number. It made it easier to type things that have mixed number and letters.
Two 'ctrl', 'shift', 'upper' made it easier to make fully use of both hands.(instead of stretching fingers of one hand to reach multiple keys while the other hand is doing nothing to help. It takes two hands to play piano, why not typing. :-)

Quentin-Atreus-Layout

Here's the google sheet: https://docs.google.com/spreadsheets/d/1qjMmh_Okfs9G5-_XSfNVMaMCdGDQWaob7i2OBMS8VCg/edit?usp=sharing

And here's my .ino: https://gist.github.com/QtOnGit/c09ce3b799760f375eef85a8a798d491

No Chrysalis Keymaps. Sorry. I tried, but never got it worked.

What's 'Qukey':
https://kaleidoscope.readthedocs.io/en/latest/plugins/Kaleidoscope-Qukeys.html
https://github.com/keyboardio/Kaleidoscope/blob/56fc62e8b3c88fb8cb2afbe9f9ac24d7d5902212/docs/plugins/Qukeys.md#dualuse-key-definitions

Note: I might want to try reducing overlap threshold in v5 release from default 80 to 50 as I'm missing some modified key strokes some time when roll over to 2nd key from shift/ctrl/upper. (it's due to released the shift/ctrl/upper shortly before releasing the modified key). If you have the same typing habit, might consider the same.

Here is one example of qukey .ino file
https://github.com/keyboardio/Kaleidoscope/blob/56fc62e8b3c88fb8cb2afbe9f9ac24d7d5902212/examples/Keystrokes/Qukeys/Qukeys.ino

Adding board info into arduino IDE:
https://kaleidoscope.readthedocs.io/en/latest/setup_toolchain.html

gmadrid added a commit to gmadrid/geotreus that referenced this issue May 11, 2022
From here: keyboardio/Kaleidoscope#706
(It's the 'algernon's favourite' version.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement hardware
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet