I’ve recently been learning to use Bitwig, and it’s the best designed, cleanest UI I’ve ever seen. The grid editor (a node graph thing) in particular is awesome. Some ideas from various graphical node languages, distilled into an incredibly functional UI for end users

Designing GUI’s is not just about designing graphics, but also about designing interactions. This is much misunderstood, because interactions are “invisible”.

I would love to see someone build a visual programming language with this sort of polish applied to the UI. / walks back down to the basement // hammering and whirring noises // ... /

@Ivan Reese these types of "invisible tricks" are commonly known in game dev; do you know of a repository of similar ones for UI/UX?

for example, this article details all the nuance that goes into making a good PIE/marking menu: https://medium.com/@donhopkins/pie-menu-fud-and-misconceptions-be8afc49d870

and how people who implement them miss tiny details that completely ruin them (guilty of this)

I don't know of a good repository of those techniques because, as with game design, they tend to be "rediscovered" every time someone works on a new UI, whether for a game or program or whatever, doing their best to polish the hell out of it. There are common ideas that apply very generally (eg: Fitts's law), but what I see as missing is the very tightly-targeted micro-optimization of UX in ways very particular to a specific visual language. For instance, there should be polish applied to Max/MSP that is different from the polish applied to Pure Data since, although they are very similar when viewed from a distance, they are extremely dissimilar when you try to use both of them with virtuosity. This is why games are a good example. There's a rich spectrum of these techniques. At the most general level, for instance, it's widely known and very obvious that you should make sure the player's inputs aren't ever dropped. When designing a platformer, and studying other platformers, you'll quickly notice that the more successful ones carefully design the scale of the world around the movement of the player character — ledge heights are set based on jump height, for instance. If your platformer needs tight timing, adding some slack to the inputs (like the "coyote time" example for Celeste) is a technique passed around between game developers, and maybe written down in a few places, but not obvious just from playing other games. But then there are the techniques that only apply to the exact game you're making. There aren't any guides here. But if you spend enough time on it, you'll find them, and they'll make the difference between your game feeling good and feeling amazing. The first Halo, for instance, had an insane level of attention paid to the acceleration curves of the joysticks, and to the physics of the vehicles. They were tuned within an inch of their life. Playing other FPS games or other games with vehicles after playing Halo, you could definitely feel that something was off. Even today, good luck finding a game with vehicle physics that feel as good as Halo 1 from 20 years ago. A counter example — Death Stranding. That game seemingly has zero of this sort of polish applied. It feels terrible to play. But none of the tricks that made Halo feel that good would transfer to Death Stranding. It's up to each team to figure out exactly what polish to apply to the exact thing they're making. This is where it turns into more of an art than a science.

for example, the "invisible game design" is at least searchable and you can find lots of people talking about what they did to make the game feel goood

I tried that after that radial marker/PIE menu article and was impossible too find anything if it existed (problem exacerbated by desig ui/ux is more mainstream approachable to there was a lot of snake oil articles/products in the google query result)