New: Reorder and Rename Layers

So, the title says it all, really: With the latest update to our Beta configurator, you can now finally give your layers descriptive names, and shuffle them in ways that make sense to you. Here’s a demo video:

Now, let’s drill down a little:

Naming Layers

Naming a layer allows you to be clear about its purpose, both for yourself and for others who are looking at your layout. “This is my mouse-control layer,” or even something like “Fortnite”.

To keep things simple, we capped the maximum length of a given layer’s title, so it never overflows. As a side effect, this forces a pretty focused and clear name for a given layer. Of course, layer names are entirely optional.

To rename a layer, just pop open the new context menu under each tab:

Moving Layers

For this release, this was the big one. There were a couple complications to take into account:

Updating shortcuts

Check out this layout. Now, imagine I wanted to take the Mouse layer and move it so it’s the last one for some reason. Here, let me do just that:

Bam, done. See how all the shortcuts got updated? Compare the two screenshots to see what I mean. All the ones that pointed to layer 1 now point to layer 2, and the one that was pointing to layer 2 now points to layer 1. Slick!

Validating Shortcuts

This was one of the trickier bits. You see, most QMK layer shortcuts only let you move up the stack. In other words, you can have a shortcut from layer 0 to layer 1, but you may not have a shortcut from layer 1 to layer 0.

When you couldn’t move layers, this was easy enough to enforce: We just wouldn’t let you choose a lower layer when setting up your shortcut. Now, however, we needed to find a more intricate fix.

Let me show you how it works by grabbing layer 1 above (Symbols) and moving it so it becomes the new layer 0. This will break all the shortcuts leading to it:

Right away, we can see the compilation button is disabled with the message “Invalid layer shortcuts detected”. We can see two of the tabs are red, and in our current tab, one of the keys is highlighted in red too. Let’s click it:

A-ha! Right away we get a fairly solid explanation, and a hint showing how we can fix it. Let’s click the link.

Immediately, the offending key is opened for us, with an explanation as to what we should fix. No problem — we’ll just move the layer so it’s higher again, and presto:

Now we can compile again!

Technical Challenges

There were several technical challenges Florian overcame along the way when creating this feature:

• The tab component: We opted for a component called react-tabtab which is lovely, but didn’t do everything we needed. Florian contributed some code back and currently has a pending PR with the changes needed to make this work in our case.
• The context menu: This was surprisingly tricky. When you click the caret on each tab, you of course expect to see the context menu in the right place. However, as soon as the tabs began overflowing the container, this stopped working. You’d click the caret and nothing would show up. The solution was to make the context menu “float” and dynamically compute where it should show up, not as a sub-component of the tab.
• Granular validation and error messages: This was both a UX and a raw code issue. How do we explain to the user that a layer shuffle created an invalid configuration? How do we show exactly what to fix? You can see the solutions above. Being able to deep-link to the offending keys made the error messages much more useful.

Thoughts?

So, what do you think of the user experience? Is it clear? Did you notice any quirks? Weigh in below, and feel free to email us at contact@ergodox-ez.com. Thank you!