High-Level is the Goal, Even When Nobody's Watching.

Reply to? Continuation of? Inspired by?
https://bvisness.me/high-level/

Pre-ramble

Recently, in a discord voice chat of all places, the idea of universal ease of use plopped into my head again. It does every now and again. I remember watching a talk a while back entitled 'High-Level is the goal'; it was given at Handmade, a predominantly low-level conference for low-level developers to sit and chat about low-level things. The talk, which I have rewatched in the research for this post (see, i do put effort in!) explains that software is slow because it's built on bloated stacks like React and Redux, and argues that low-level knowledge is how we build better high-level tools from further down the stack, not an end in itself.

To the handmade community, this was different. The Handmade community generally blames - software becoming slow or bloated despite hardware being far more powerful on a lack of low-level programming, but really, "everyone write their own allocators and UI frameworks" isn’t a practical answer.

I'd recommend giving it a watch, or a read, whenever you're able to.

But it was in this discord vc where BiomeBattle event owner, who goes by 'BitSquidd' online, was screensharing general up-and-coming features of the next event update. It was during this screenshare that he opened a GUI menu made purely for the convenience of himself to start up an early version of a minigame. Generally, all of this kind of stuff is done via Minecraft's command system. It's no surprise, then, when Klyx event owner, who goes by 'Asleepp' online, asked bluntly

"Did you just start this game with a menu??"

This is novel. An idea of universal ease of use, for everybody from the players right up to the owner and lead developer, is novel. For a entire community of people who work in the Minecraft event space, you wouldn't dare of using anything but a command for this! Commands are quicker, easier to implement, and cost less development time. It's the exact argument that hyper-linux freaks still use to defend the terminal (sometimes, myself included).

Commands are our 'low-level'. They work because everybody already knows them, and nobody has ever bothered to make them nice because nobody thinks of the person typing them as a user. I can't help but think that tens, maybe hundreds of thousands of developers worldwide are exactly like the Handmade community that Visness aimed his talk at. The tools they have work, but a high-level offering - in his case, new tools built from further down the stack, and in mine, a GUI menu in a video game - is just nicer.

Even if nobody else ever sees it, or knows it exists.
Nobody was ever meant to see BitSquidd's menu; we only did because he happened to be screensharing. He built it for an audience of one. I spoke about this in 'On Making Things', but that should be admirable. Making things without needing anybody else to know about it is admirable.

Where am I going with this.

Universal ease of use has to include the person who built the thing. The developer is a user too, and deserves the high level, even when they're the only one who'll ever use it.

Part one: The command isn't a choice

Commands are cheap and fast to write. They're flexible yet built in to the game. There's no crap UI to maintain, and menus in Minecraft are fiddlier to build than they look. Or from what i've heard, at least. There's a good chance that one of the people i'm talking about is reading this, in which case you know the specifics better than me. Why did you choose commands?

It's probably because, and I am sorry to assume, but it's probably because you haven't thought about using something else. I mean, really, genuinely, actually sat-in-a-call-and-openly-discussed their use. It's just the default! But get this: For the users, oh gosh no. A nice spectator menu and a nice lobby teleporter and a nice x other thing and a nice y other thing are always the top priority. But what about for yourself, or for your team? Why not extend these things to teleporting between build worlds, or developer worlds, or different developer servers?

When you're already using commands, you can easily defend their use. There are benefits to them. They can be run from the server console without being in-game, they’re scriptable and chainable, with tab-complete a regular is often faster typing than clicking through a menu, their easier to scale, and there's less to break mid event - I get all that, I do.

But you didn't choose commands because of these benefits, in fact you didn't really choose commands at all. These are just happy benefits that you notice later on. The fact is, building anything bigger - a necessity for many when designing for a larger audience - is not done here due to this audience, these 'users', being yourself and your immediate team.

Why don't themselves and yourself deserve the same as end users?

For commands that you use every day, and ones that never change, I believe crafting a lovely UX is worth it. It adds polish, you learn more, and these features can be adapted to real end users later down the line. Work rough now and refine later, make a real product at the end rather than jumping right into making a lovely UI for a public audience and finding it more of a headache than you ever imagined.

It's important that when talking on 'UI' here I mean a custom, fabric-mod-based solution. Not inventories or dialogues. Although if mod development isn't your thing, inventories or dialogues work just fine. And if minecraft isn't your thing, I hope you're still following.

Part two: Everyone has commands

Okay okay, this part I have now decided is going to assume that minecraft isn't your thing. If it is still read this section, it's still a pivotal part of the blog post, just know that I'm going to switch from that as a base to something else.

Terminals. (Yayyyyyy....)

Earlier on I admitted that sometimes, I myself am one of those hyper-linux freaks that obsesses over the use of the terminal. This is true, unfortunately. The terminal too allows you to script, run batch processes, interlink your commands with other services. It's web 2.0 but without the web, it's brilliant (I mean, web 2.0 caught on around 2004 and Unix pipes date from the early 1970s, so really I have my chronology backwards, but who's counting.)

These benefits to the terminal are the exact same benefits as that of the command. It also, as you may have guessed, shares the same drawbacks.

The terminal is brilliant - to the people who already know the terminal. To everybody else it's a blinking cursor that won't tell you what it wants. Sit somebody who's never opened one in front of it, ask them to find every file over a gigabyte in their home folder, and watch their face. Then think about how long it took you to be able to do that without looking it up. (Be honest.)

This is the bit Visness is really getting at, and the bit I glossed over in the pre-ramble. His problem with low-level programming is that it's miserable to use, not that it sits low in the stack. In a browser, one click in the dev tools gets you a timeline of everything your page did. Outside of one you get a command-line profiler, a handful of flags you'll have forgotten by next week, and output you have to feed through two other tools before it means anything. Everything you'd need to build something nicer is already there and yet nobody's bothered.

His answer was genuinely actually seriously a philosophical move for me. In answer to the question "Why are things 'low-level' today?" he replied
"Because no one has made them high-level yet."

A brilliant answer. So 'high-level' was never really about where something sits. Visness frames it as how easily a tool lets you say what you actually want to do, and by that measure a terminal can absolutely be high-level. A --help that actually helps, for example. Tab-complete that knows what you're about to type, as a second. An error message that tells you what went wrong and what to try instead -- mistype git stauts and git will point you at status rather than just telling you no. All of this needs somebody to have thought about the person typing, nevermind it be in a TUI or a GUI or a new-flavour-of-the-month-UI.

This is how I get to stay a hyper-linux freak and still write this post. Universal ease of use doesn't mean slapping a GUI on everything. It means that somebody, at some point, treated the person on the other end as a user -- even when that person was themselves. A menu in Minecraft is one way of doing that. A well-made command is another. And that's okay!

If you live in a terminal, you've almost certainly got a long command you fish out of your history every week instead of turning it into an alias or a script. I know I do! That's your BitSquidd menu, just waiting to be built. Okay, take this blog! I've mentioned before that I didn't want to contend with HTML every time I wanted to share my thoughts, so I don't. I write in markdown, and a bit of PHP on the server would turn it into the page you're reading now. (I mean, it used to, until i switched to my own typescript based write-once-use-everywhere parser called fgmd, but just go with my point okay?). You'll never see that part and you don't need to. It exists for exactly one person, and I'm fairly sure it's half the reason I write anything here at all. More effort and I wouldn't bother. I'm writing this on Obsidian on a macbook right now!

Which leaves an obvious question, right? If the fix is that small, a help message or a better error or a nice menu, why doesn't everybody do it?

Because nobody will ever see it!

Part three: An audience of one

Back to BitSquidd's menu. Earlier on I said that building something for an audience of one should be admirable, and then moved straight on without explaining why, which is a bit rich from somebody who told you he puts effort in. So here's why.

Think about how a feature normally earns its keep on a server. Somebody builds the lobby teleporter, players use it, and somebody in chat says it's nice. Maybe it ends up in a clip. Maybe it gets a mention in the update announcement. There's a scoreboard happening there, even if it's a small one, and in 'On Making Things' I spent a good while arguing that scoreboards are written for you by somebody else and are a terrible thing to grade yourself on.

Internal tools don't even get the small scoreboard. Nobody claps for a menu that starts a test build, no player will ever know it exists. By every measure we've borrowed from somewhere else, it's worth nothing, and that's exactly why nobody builds it. Buuuuut, count it a different way. Who is going to use that menu the most? Not a player. A player might touch the lobby teleporter a handful of times in an event. The person starting that minigame is probably going to do it dozens of times in a single evening of testing, and then again the next evening, and the one after that, until the update ships. By sheer number of uses, the developer is the most frequent user that menu will ever have. We just don't count ever them!

Then there's everything you get out of it that nobody else can see. Whoever builds a menu for themselves has just practised building menus. I'm sure BitSquidd would agree that he has now got better at building menus because of this feature. It's the work-rough-now-and-refine-later I mentioned briefly, if you can recalll. The menu nobody was meant to see is the practice run for the one everybody will.

And that's why I think it's admirable. Hidden work isn't nobler than public work, and honestly I'd love it if more people saw more of this stuff. But building something for an audience of one is one of the only times anybody makes a thing for a reason they picked entirely themselves. There's no brief and nobody's waiting on it, no client or line manager on the other end. Somebody just decided that the person typing the same command over and over deserved better, and that person happened to be them.

You're allowed to be your own user.

Visness's talk is called 'High-level is the goal' for a reason. Low-level isn't the enemy in his argument, and commands aren't the enemy in mine. They're the floor you build on with the goal being whatever sits on top: something that lets anybody, from a first-time player to the person who wrote the whole thing, do what they came to do without fighting it.

I'd like to get to a point where "Did you just start this game with a menu??" stops being a question anybody needs to ask; where a developer looking after themselves is just normal.

So the next time you catch yourself typing the same command for the fifth time today, remember that you're a user too. Make it nice. Even if nobody's watching.

Thank you for reading.
- Dia