I recently rewatched two reviews of AI companion devices from Marques Brownlee (a.k.a. MKBHD), which both came out in April 2024 – the Humane AI Pin and the Rabbit R1:

Brownlee is a charismatic reviewer, and I won’t lie – there’s a certain amount of delicious schadenfreude seeing two products announced with so much unnecessary hubris faceplant so solidly.

But past all that, what stood out to me was the storytelling, and this is why I wanted to post these videos; the work feels good here, and deserves studying in how to talk about these things.

Brownlee manages to cut through the bullshit and candidly talk (but also show) what these devices should be all about. There are some nice editing choices; casually pulling up the phone and getting an answer while the AI Pin is still thinking is a pretty powerful moment. The reviews also come with higher-level reflections, and what stuck with me since the original watch years ago were the segments about how more and more often, devices like these – but not just these devices – come out of the gate profoundly unfinished.

The Pin and the Rabbit are also interesting to compare. They are both underbaked in some similar ways: the quality of the AI output, overfocusing on hardware at the expense of software, and the interaction systems that throw good money after bad and come out of the gate with strange complexity – AI Pin had the tricky-to-use laser projector menus, and Rabbit R1 managed to overgimmick a simple thing that is a rotary controller. On the other hand, one of the devices felt a lot more ambitious than the other. Also, both had fascinating differences in the packaging and their whole approach – it almost feels like there was a generational difference between the two endeavors.

(Humane Inc. has folded since. You can still buy the R1, which was since updated with a new UI, but it seems the company is pivoting to more generic-feeling software.)

In 1996, Street Fighter Alpha 2 was ported onto Super Nintendo Entertainment System, a 1990 machine on its way out and not really up to the task of running such a modern game.

The team put up a hell of a job, involving adding a custom compression chip, with the game being much better than anyone expected – but still suffering from a big flaw, which was a momentum-breaking 3-second freeze at the beginning of every battle.

Dimitris Giannakis, also known as Modern Vintage Gamer, describes the problem and community’s more recent efforts to fix it:

Turns out, the problem wasn’t the compression chip, but sound effects – and the fix to complelty remove the delay relatively trivial in hindsight. A community member named gizaha posted a patch to the game in 2020, and its description can send shivers down your spine:

• Disable some waste sample loads

Sounds good.

• Tweaked audio engine for faster start of loading

Alright, fair enough, perhaps the game was rushed to market and some light optimizations skipped.

• Faster audio load, upload 2 bytes at the time instead of 1

Oops.

Also in 2020, people set their sights on another 1990s game, Super Mario 64.

MattKC on YouTube talked about a similar problem as SFA2 – the game seemingly wasn’t properly optimized:

For years, if not decades, this has been accepted as fact: Bowser’s sub is just too big and too goofy for the N64 to draw consistently. But what if I told you it didn’t have to be?

Nintendo just… forgot to turn on a C compiler optimization feature before shipping the game. The result wasn’t as egregious as random 3-second freezes, but still gave people much lower framerate on certain levels:

However, Giannakis followed up on that, and discovered the story wasn’t as simple. The optimization in question was still itself evolving at the time, and had known issues when Super Mario 64 was being developed. As easy as it is to turn it on in 2020, all polished and tested, it was a different story in 1996:

The video actually compares the versions visually, and even investigates other optimizations.

But it all pales in comparison to this 2024 video by Kaze Emanuar, who says “hey, guys, you have been looking at the wrong place the entire time” – as a matter of fact, it wasn’t the optimizations that Nintendo didn’t turn on that made the game slower. It was the optimizations they added:

The video is kind of intense, but I feel you can learn a few really interesting things from it:

• how you show the debug information matters,
• there is such a thing as a “performance lottery,”
• naïve efforts to optimize can be heavier than not doing anything at all,
• it’s best to optimize for maximizing minimum frame rate, rather than average frame rate.

It’s a fascinating watch, suggesting framerate increases of up to 50% on the original hardware, with just software changes.

Both the Street Fighter 2 Alpha and Super Mario 64 efforts also portray a terrifying notion: imagine your code being hyperanalyzed by a group of people 25–30 years later, pointing at your flaws.

Completely unrelated to software, but sometimes stepping outside is what’s needed to develop perspective and find creative solutions – this is Practical Engineering’s video about the many electrical plugs and sockets in America:

There are a lot more socket kinds than I expected, and sprinkled in between are some useful observations about system design, change management, power users, backwards compatibility, and consistency vs. inconsistency – in my head, that last part puts this video right next to the previous post in my brain, even if they seem nothing alike.

Also, that early video snippet from the 1920s?

Jesus Christ. What a UI.

Make Some Noise is one of many fantastic improv comedy shows on Dropout. I noticed one of the ongoing themes is “tech gone bad,” so I compiled a short list below. I just find these really funny.

Video call with shitty wifi:

Logging in with 30-factor authentication:

A cutscene in a video game that’s glitching out:

In case you’re curious, the improv actors are: Zac Oyama, Josh Ruben, and (occasionally) Brennan Lee Mulligan.

If you’re a Dropout member, these are the original, slightly longer landscape videos inside their respective episodes: wifi, 30-factor, game.

Fighting games require rather precise timing: the action is frenetic, the inputs rapid, and the outcomes can be determined by what players do down to – sometimes – individual one-sixtieth-of-a-second frames.

This is fine when you play locally, but gets infinitely more tricky the moment you attempt to kick someone’s more remote ass:

Information sent to your opponent may be delayed, arrive out of order, or become lost entirely depending on dozens of factors, including the physical distance to your opponent, if you’re on a WiFi connection, and whether your roommate is watching Netflix.

The part of the game responsible for dealing with networking is called netcode, and the classic solution to the lag problem has been delay-based netcode with a sort of lowest common denominator approach: if your opponent has a “ping” of 50ms, your actions will also be delayed by 50ms, to ensure fairness.

It’s not that hard to imagine many problems with this idea. Lag comes and goes but the game doesn’t smooth it out, the play feels like jello with even an okay connection, and the game occasionally freezes, waiting for a suddenly dropped connection to resume, not knowing what to do in absence of information.

That’s why within the last decade, what gained popularity is a new kind of netcode called rollback netcode, which operates by… lightly predicting the future. Most of the time, within a reasonable lag, the game will feel as fast as a local game to both players – and even when the optimistic prediction doesn’t match what eventually happens in reality and the code has to roll it back, visibly, in front of a player, the change might be too small to notice and only rarely it’ll result in rubber banding.

Core-A Gaming has a great video about specifics of rollback netcode:

It covers a lot of stuff, including nuances like drift and design decisions that game makers might want to incorporate to soften rollback netcode’s most annoying side effects. (Also, the guitar playing bit at 0:22 is absolutely brilliant.)

The video is largely based on an earlier essay by Infil, which has even more details (audio!) and which I excerpted above.

It’s not just videogames. When Apple announced in 2019 that they reduced the latency when using their iPad Pencil from 20ms to 9ms, they didn’t hide that they had to peek into the future as well:

The specifics were, as far as I know, never revealed. But the fact that some of the input events the app receives are not actually real is official and documented:

It takes time for UIKit to generate and deliver touch events to your app, and it takes time for your app to process those events and render the results. In fact, it takes enough time that there can be a visible lag between the movements of a person’s finger or Apple Pencil and the rendered results. To minimize the perceived latency between touch input and rendered content, you can incorporate predicted touches into your event handling.

In fighting games, the most accurate prediction is a trivial “whatever buttons and controls the player holds on the current frame are likely the same they will hold on the next frame,” but for other games – and for Apple’s Pencil – slightly more advanced prediction might be necessary:

It feels disappointing that no matter what we do, there might be no way to reduce latency below a certain threshold without cheating.

But if there’s any consolation, it’s that cheating seems to be the only answer, and that has been the case long before computers came aboard. There are many documented ways our brains have their own netcode to cover for various lags occurring within our bodies. There’s the stopped-clock illusion, the cutaneous rabbit effect, the color phi phenomenon, and – most relevant for today, even though it has the most boring name – the flash-lag effect, documented on this nice page by Michael Bach:

The flashing lines are shown exactly at the same time and angle as the rotating line, but it certainly doesn’t appear to be the case. Just like fighting games and Apple Pencil do, our brains predict and extrapolate the movement of the moving line so that our other senses can intercept it at the right moment. The go-to example of why it’s needed is that you wouldn’t otherwise ever be able to catch a ball thrown your way – but I imagine it might be useful in a street fight, as well.

For a lotmore technical aspects of rollback netcode, check out this long conference presentation from GDC.

I often link to John Gruber’s Daring Fireball posts with a nod, but this time around I want to offer an opposing point of view. About a month ago, Gruber linked to a Markdown editor written by Sean Malseed in 2026 for the early 1980s Macs, and commented:

I absolutely love that this exists. I don’t like the actual app at all. I guess “full screen” mode is the point of some “distraction free” editors, but I for one would never look twice at a Mac app that didn’t use windows. Full-screen mode just wasn’t a thing back then, except for games. ArtfulType is not a Mac-assed 1984 Mac app.

I posit: It doesn’t have to be. It’s not 1984, after all.

I actually really loved the creator of ArtfulType bringing back a few pieces from the future into the past: the fullscreen/​distraction-free editing, the dark mode menu bar, the shy scrollbar. Those anachronisms felt exciting to me. They made me wonder: What if dark mode was invented decades earlier? What if Mac had a different windowing mechanism? What if we could do it all over again?

I recently linked to Sopwith, which felt interesting in the same way, and I thought I would expand on this and share a few favorite examples of similar projects that inspired me in recent years.

Playdate

Confession: I’m not a fan of Teenage Engineering. I find their products well-put mechanically, but lacking in thought and soul, a certain apotheosis of “capital D Design” that feels as incomplete as it is masturbatory. (Rabbit R1 was a perfect example, consumed by gimmicks and strange design decisions.)

Good news is that Playdate is not a Teenage Engineering project, and that it was actually initiated by the software company Panic, which gave it copious amounts of thoughtfulness and care. Playdate is a 2022 handheld game console, and a fun little device that’s intentionally anachronistic. Its design picks the best parts of each decade: the gadget excitement from the 1980s, the onscreen aesthetics of the 1990s, the social internet of the 2000s, the explosion of indie games from the 2010s, all wrapped in contemporary build quality.

Playdate is partly made out of metal and pleasant to hold and touch in a way no vintage gadgets ever were – this is where Teenage Engineering does deserve a credit – but sports an old-fashioned monochromatic display that seems to be harking back to the darkest years of the first Gameboy… which is very, very deliberate:

I love the black and white, 400 by 240 pixel Playdate screen. I kind of like don’t want to design in anything else anymore,” says [Panic designer] Neven [Mrgan]. “It is so freeing for me, personally, to not think about the color and not think too much about, like, even things like line weight and whatnot. ”

The quote is from a long read about the Playdate’s inception (also available as a well-made podcast ep), which is worth checking out.

Playdate’s games are equally spread across time as if in a horrible time travel accident – some with simple mechanics utilizing the gimmick of a crank, others with much more modern or artful sensibilities. Many, confusingly, with both. Some also come packaged in a novel system of seasons, where the games drip onto your machine at a pre-determined rate, meant to mimic surprises and serendipities one could encounter in record and software stores of yore.

PICO-8

I’ve been profoundly inspired by this talk by Joseph White, explaining his “fantasy console” called PICO-8, introduced in 2015:

PICO-8 is Playdate abstracted away. It flips the world order on its head – emulators are known to emulate existing hardware, but what if they emulated imaginary ones? Why not imagine a gaming console that was never made?

The wild part of this approach is that it automatically gets rid of a lot of unnecessary nostalgia, focusing instead on crafting “hardware” and software precisely calibrated to achieve things White wanted them to achieve.

PICO-8 has a puny 128×128 resolution that makes Playdate feel like IMAX (although with very deliberate 16 colors), and many other constraints that would feel ridiculous even 30 years ago. They are, once again, brought back from the past intentionally – chiefly, to avoid “design fatigue.”

At the same time, PICO-8 doesn’t revel in the past – it also comes with built-in suite of tools, and support for modern keyboard and mouse for development. Its cartridges are not only a single file to allow easy distribution on the web or otherwise – they’re also literally baked into PNG files so the spreading can be even easier.

From a 2016 AV Club article:

White’s software chimera works because he understands where nostalgia ends and the needs of modern development begin. PICO-8’s idiom, for example, is a custom subset of Lua, an easy-to-approach language likely familiar to many game programmers, whether they script emulators or use the free 2D engine LÖVE. Though PICO-8 initially ran BASIC to stay true to its ’80s pedigree, White switched because “Lua has a small footprint and is portable and quite fast. I think any language could have worked though, as long as it allowed the user to mess about in an unstructured way without worrying about programming style.” PICO-8 Lua feels snappy and sensible. There are just enough functions to get up and running quickly without the bulky overhead of complex libraries or object-oriented syntax. Need to draw a sprite? Provide an index and two coordinates. A circle? Coordinates, radius and color. It’s fast and friendly for programming beginners.

The conference talk above and the design of PICO-8 are dripping with intentionality; even the startup chime is meant to evoke a feeling. At some point White went as far as to consider whether his console would glitch nicely if its software was buggy, and then mentions “I designed a [more advanced] PICO-16 just to remind myself to not make that” – a really interesting technique to help him zero in on what he really wanted.

White also expressly states “I value design over content,” which is another thing his project has in common with Playdate.

PICO-8 saw all sorts of software developed for it since 2015 that you can all play online – from the absolute platforming classic Celeste, to a series of unofficial “demakes” like WarCraft III, complex games like SlipWays, or even tools like PicoCAD. The hardware is confusingly powerful enough for Poom (a clone of Doom) to exist, but then there’s also tons of delightful tweetcarts, cartridges whose code used to fit inside a single tweet.

Infinite Mac

PICO-8 started as an emulator for an imaginary thing. Infinite Mac, despite emulating really well-known Macs from the 1980s and 1990s, can also inspire in its imagination.

Made by Mihai Parparita in 2022, Infinite Mac is all about focusing on the right details. Emulators of vintage Macs existed before and, as a matter of fact, Infinite Mac uses those very emulators under the hood. But the glue that holds them together is Infinite Mac’s real and wonderful contribution.

If you’ve ever used an emulator, you know they are usually incredibly unpleasant to set up. You have to find a ROM that fell off of a back of a truck, set up the drives and the media inside, and fight with the poorly-designed settings and a UI that often feels like an afterthought, with the whole thing often feeling more rickety than the very 40-year-old machine it’s trying to approximate.

Infinite Mac awaits you in the browser, literally two clicks away counting this one (there is no step three!). It doesn’t show all the possible options, but curates the most useful machines instead.

The emulation is precise but Infinite Mac also – and this is my favourite thing – breaks the fourth wall in some truly useful ways. You can drag a file into the emulator and it just does the right thing with it. You also set up a magical folder that connects to the host machine both ways, in a way that was simply impossible to do back in the day.

There’s also a CD drawer underneath, and a wonderfully seamless integration with Macintosh Garden’s library of vintage software.

It’s the same story as with Playdate and PICO-8: a lot of intentionality and effort and cherrypicking so you get the best of an earlier experience without the worst of it. Pick a Mac, and use it without worry; Infinite Mac keeps the Macs both faster and more reliable than they used to be. (In a beautiful repudiation of modern software practices, I have heard of people who launch Infinite Mac to write in old word processors not just because they’re simpler, but also because they’re faster than the modern native apps.)

Parparita occasionally writes about the project on his blog; those entries are rather technical, but sometimes also highlight various design considerations (I particularly enjoyed the NeXTSTEP entry).

Epilogue

I was at the Vintage Computer Festival West recently, and for the first time I noticed how many young people were there. This got me excited. It’s one thing to revisit those old machines just to relive your own years of (likely imagined) glory, but yet another to see people see them as inspiration: to encounter computers that were simpler, unencumbered, unenshittified, and with software you could understand, remix, and own.

I hope some of those people find inspiration in the past without succumbing to it as a whole, pushing and pulling on it like the creators of Playdate, PICO-8, and Infinite Mac did.

I think that kind of push and pull is important, especially today. I don’t love using Google Sheets, but my favourite spreadsheet is not Excel 97, either. My favourite spreadsheet is some hypothetical anachronistic version of Excel 97 that also has modern high-dpi typography, and a ⌘K command palette, and today’s trackpad gestures, and support for AVIF and HEIC.

Of course, there is immense value in studying the past just so we know what was already made or just explored, what is worth being aware of, and what could deserve remixing. But it’s not great to get stuck in history.

When you venture out to do some time travelling, you get the booklet with all the rules: don’t interact with another version of you, don’t flirt with your mother, definitely steer away from any butterflies. I love that these projects, and others like them, ignore all those rules.

The title of the post comes from the Playdate’s making of essay.

I mentioned Atari’s Pong recently, a game often considered to be the first videogame ever. It wasn’t, and as a matter of fact, it was a clone of one of the games from the first home console Magnavox Odyssey, released earlier in 1972:

This is a 34-minute video by FrameRater walking through the console and all of its strange games:

I found it a very interesting case study. The Odyssey had a version of Pong before Pong – but it also had many other games that could be charitably described as “Pongs in disguise.”

It all feels very, very convoluted for such a simple concept. You have to insert the right cart, tape an overlay to your TV of a certain size (the roll of tape is included), and understand the complex and poorly written instructions in the manual. Then, during the play time, you’d have to master the very strange controllers (left dial – horizontal movement, right dial – vertical movement), often do a lot of work that the console didn’t do (keeping track of collisions, or even scoring!), and deal will all sorts of accessories in the real world, like included cards, dice, stickers, and so on.

You can admire the scope of this all – when life gives you Pong, you make a pongolade – but it all feels so clunky and convoluted, which the video catalogs in detail. But, in hindsight, it doesn’t matter if the included Pong (here, called Table Tennis) is good, right?

Reader, Table Tennis wasn’t good at all. It wasn’t just the strange controllers, but also the really weird logic where you could twist the ball already in flight:

Only looking at this made me realize, some 50+ years too late, the true power of Pong.

Pong didn’t bother with many games, with complicated rules, with the breadth of it all. It just did one thing really, really well.

For the Odyssey, it seemed like a lot of games were about mastering the controller. For Pong, it was only ever about mastering the game. The interface was simple: you have one dial, so rotate it. The game was fun to play, with its logic both challenging and predictable. The instructions were sparse and barely needed anyway. There was automatic scoring, which Odyssey didn’t have. There were also sounds – turns out, people really liked sounds.

The Odyssey was clearly an in-betweener, a complicated hybrid device weighed down by its well-intentioned maximalism. Pong was simple, attractive, optimized to the bone. I feel that it offers universal lessons, feeling eerily similar to iPod’s release in 2001 – focusing on just the few things that mattered, and doing them really, really well.

It is a testament to how much things have changed in competitive NES Tetris – a game released the same month the Berlin Wall fell – that this hour-long documentary by Summoning Salt that talks about the 2018 Tetris Championship covers the previous revolution in a play technique:

I don’t watch a lot of sports, but I think this is a sport movie: a battle between the classic DAS players – DAS stands for Delayed Auto Shift and means that the player just holds the left or right pad and have the piece slide on its own – and the new-at-the-time technique of hypertapping, which allowed to move the piece to the side faster, but was really demanding on the player’s hands.

It’s gripping at times – wait until the moment when a DAS player runs with a dangerous move called “quick tap” – but also surprisingly touching at the very end.

(If you are interested, the newer playing technique that was invented in the 2020s, and even more effective than hypertapping, is rolling.)

In 2018, Tom Cruise and Christopher McQuarrie teamed up to make a short PSA about the dangers of frame rate interpolation, a.k.a. the soap opera effect:

It’s a strangely boring video from the men known for exciting filmmaking, but it captures a fascinating debate. TL; DR of their argument: Home TVs have an option to take a typical 24fps movie and create interim frames to make it feel like a 60fps production. It’s often on by default, but you should turn it off.

What’s interesting is that 60 or more fps is indeed in some ways objectively better: you see smoother movement, and you can notice more. Once you start paying attention, any whip pan or drastic movement in the cinematic 24fps appears very choppy…

…and, of course, that is completely missing the point. The argument for 24fps is that it’s simply cinema’s vernacular, right next to anamorphic lenses with their blue lens flares and vertical stretching. The movies are not about conveying information, but they are about conveying a certain feel. (And also, about tradition.)

I’m mentioning this because I spotted a similar battle happening when it comes to scrolling.

Go to any page in Vivaldi and hold a down arrow key for a while. That scrolls through the page, moving it in chunks, reacting immediately to the initial key press and then the synthesized autorepeat presses:

Firefox listens to the keys the same way, but it “upgrades” the choppiness to a 60fps movement by interpolating it:

And Safari does something different altogether – it approaches it more like a game physics engine would. It only listens to ↓ down (when it turns on the scrolling “motor”) and then ↓ up (when it turns it off):

This has an interesting effect: the movement is smoother than even Firefox’s – that’s because it doesn’t try to straighten something choppy, but it is itself smooth, by nature.

At the same time, this approach feels a bit loose, like driving an old 1960s car. It also takes away any control of speed; Safari pages always scroll at this rate, no matter your keyboard settings. (Arguably, however, control via the key repeat rate that other browsers respect is also an illusion, as it affects typing as well. Would you ever change it just to control the scroll speed?)

Of course, the analogy to frame interpolation doesn’t really make sense. Safari is not a soap opera, Firefox is not a smooth motion effect on your TV, and Vivaldi is not a cinematic experience. In contrast with movies and television, I don’t think there are any expectations or tradition here.

In this particular context, I believe Firefox and particularly Safari are better because this is about conveying information, and smoother scrolling does help your eyes and your brain connect all the little befores with all the little afters.

But I am sharing it mostly as a reminder that a keyboard is really just a button board by a different name. And sometimes it’s good to look at a key hold, and decide:

• is this a sequence of pulsating key presses,
• or is it a button being held down and then released up?

Some years ago, the inimitable channel Technology Connections posted a 17-minute video about the peculiar design quirk of ceiling and room fans – they usually order their options Off → High → Medium → Low rather than the more natural Off → Low → Medium → High. The video is a bit off topic for this channel, but check it out if you’re interested how sometimes weird physics considerations influence design in the real world:

In the video, the host also talks about the more natural order that typically looked like this:

I wonder if you recognize this kind of an interface. I have a distinct memory of it from radios (where “zero volume” would mean “off”) and from TVs/​early computer displays (where “zero brightness” meant “off,” too). There was something special about these controls that stuck in my memory, motor and otherwise: this tangible, heavy click when you ventured outside or back into “off,” almost as if you had to break the interface itself.

I thought this, too, was a convention from an old analog time. Yet, I keep occasionally finding the “the first notch is special” interfaces on screen.

Sometimes, they are pretty literal translations of the concept, like when you adjust the key repeat rate in macOS:

Or, similarly, when you choose the dock magnification:

But sometimes they are a bit more conceptual. Here, Nova treats the first notch of the zoom scale as a “list” option:

Or: The new horizontal tabs in Chrome allow you to resize to whatever width you want. Below 125px, however, they snap directly to the minimum 55px width, a one-off “column view” with streamlined and purely iconographic controls:

These all have pros and cons, too.

On the con side, just like the fan or volume controls, they miss any memory since turning them off physically moves the knob away from any “value”; if on/off was a separate button, you could just leave the radio at your preferred volume and never touch it again. They also won’t be as discoverable as a separate onscreen toggle would be. (Here’s an example of a more classic treatment from the Nothing Phone.)

Pros? They are compact. They allow you to change from “off” to a value in one quick gesture, skipping an explicit “on” step. You could even argue they are simpler also in a visual sense.

But also, they are a bit… magical. I don’t know. That’s what to me unifies those old physical controls and their newer digital equivalents – they’re a little extra, a little different, a little special. They break the monotony of a predictable interface built out of boring, identical components. (Although, sadly, not a single onscreen example above uses haptics!)

And I think that’s kind of nice. Not just in the very functional sense of breaking up the UI through shape coding etc., but also in a sense of making UIs more interesting.

Speaking of volume, macOS used to show it as a sort of a HUD, using a treatment that borrowed from both the “first notch is special” radio knobs, and from early onscreen interfaces in TVs:

But after 20+ years, macOS Tahoe changed it so it now looks this way:

I can understand the argument that this is more consistent, and that it even teaches you – by proximity – that Control Center is what these controls call home. Yet I can’t help but think (and it seems I am not alone) that this is so boring and exactly how Windows would approach things – and that this change, just like the squared icons, is how macOS lost one more bit of magic.

From Marton Barcza at TechAltar, a good 12-minute video analyzing what went wrong with the famed Live Tiles that Microsoft was pushing throughout most of the 2010s:

Now, among Windows Phone fans the pervasive opinion is that Live Tiles have failed because Microsoft did a poor job with them, which I think is at least partially true – after all, even many key Microsoft apps like Skype had broken Live Tiles half the time, the Windows 10 start menu was filled by Microsoft with Live Tiles that were clearly just animated ads rather than showing you something actually useful, and the company of course never built out any of their advanced interactive concepts either.

But while all of that might be true, the fact that every major company has walked away from this idea and nobody else has picked it up since, means that there probably are more fundamental problems with this idea. And I can think of three distinct ones:

• user experience,
• form factors,
• and horizontal integration.

Barcza goes on to talk about some specific interactions and problems, and arrives at the conclusion that Live Tiles ended up at this unpleasant intersection where they’re tried to be icons, widgets, and notifications all at once, not doing a particularly great job at either task. That, and there were also challenges with the design primarily being mobile-first, and struggling surviving a jump to a large screen. (Live Tiles were abandoned in 2017, at which point desktop Windows reverted back to what it was before, and the mobile/​tablet lines were altogether disbanded.)

What I found interesting in watching this today is that it feels Apple has made some similar mistakes in their Liquid Glass approach and wider platform unification desires (see: macOS Settings). Both these and Live Tiles attempted to create A System Of Systems, and both ended up occasionally feeling like they awkwardly crowbarred some wider concepts into places where they didn’t truly belong.

If it helps with your further research, I understand Live Tiles were part of a bigger UI effort called Metro and started in earnest with Windows Phone.

An interesting 20-minute Config talk from the Instagram designer Rose McManus:

It covers some of the same areas we recently talked about: diacritics and Polish S (and a fun video about English conventions from a while back), but it tackles them on a higher level. McManus talks about how people express themselves via their usernames, how that changes in various countries of the world and for what reasons, how it intersects with some UI considerations, and how people use it creatively – and also, sometimes, abuse it.

This is the K-pop star IU. Uh her Instagram handle is “dlwlrma.” And I think at first this maybe seems already like complete hyperreality, like it’s bearing no relationship with her Hangul name, or even with her stage name. But actually, I think this is at the third stage of Baudrillard’s theory because really “dlwlrma” is Lee Ji-eun’s Hangul name typed out on a Korean keyboard but backwards, distorted, while that keyboard is set to render Latin characters, almost like a cipher. And then her display name is her Hangul name typed out with one of the characters changed, so it’s like a pun.

I didn’t feel the talk stuck the landing – in the end, I wasn’t very sure why the decision that was made was made. But there’s a whole lot of stuff before that was fascinating and thought-provoking.

When you learn computer science, at some point you encounter floating-point numbers in all their peculiar glory. Floating-point numbers allow you to store values that are extremely huge or extremely tiny, but that comes with a strange price. The number is still just a number with a regular limited precision, but is accompanied by a floating point – another number that just says how many zeroes to put after or in front.

In effect, when your number is millions, you get a precision of thousands. When your number if billions, you can only count in millions, and so on. This makes intuitive sense, in a same way a billionaire doesn’t care about pocket change. (Go to a floating point visualizer, and you will see you can input 9000004 and 9000005 and 9000006 with no problem, but add one more zero and 90000004 will be rounded down to 90000000, and 90000005 up to 90000008. Bigger numbers get even less precise.)

This has a strange effect when it comes to videogames or graphic software: The further you move something away from the origin of your universe – where X and Y are 0 – the more you have to worry about its internal precision.

This is not a problem in real world. You can send a tiny, incredibly meticulous watch screw far beyond the solar system and back, and it will do fine. But now jump to the digital world, assume Earth is 0:0 – apologies to Copernicus – and now the further away you go, the more the floating point moves to the left, and at some point the precision of the number on the other side runs out; a value that can express billions of kilometers is too coarse to even consider millimeters.

This is a fascinating problem which is visualized nicely in this short video. This is what happens when you move an object with its constant internal precision further and further away:

There are ways around this – you can increase the precision, introduce a “floating offset,” have two precision centers around two floating points, or do a bunch of other things – but each one will cost you. So, sometimes, the best solution is the simplest one: do not allow the numbers to get too big.

And this is why Adobe Illustrator, Figma, and I bet at least a few other tools that promise infinite canvas, actually stop you if you stray too far away from the center. Precision is like atmosphere, the canvas says, thinning out the further you go. We cannot promise your structural integrity will survive going past a certain point, so we won’t allow you to do that.

Here’s Figma, where I at some point the canvas stops following your scroll commands:

The first invisible X value is 131,072 and it’s not a surprise it’s one of these numbers that will look very, very familiar.

It seems like a huge enough value, but if you consider a slide in a slide deck is 1920×1080, it’s not as infinite as it might initially seem. And this is also why – in part – Figma Slides manually wraps you after 20 slides:

A fun 19-minute video from commonLuke trying to write a short Fibonacci program in increasingly esoteric languages:

Here are the languages:

• Python, Scratch, and assembly (as control),
• LOLCODE, a language resembling lolcat memes of yore,
• Piet, a language whose output looks like Piet Mondrian’s abstract art,
• Brainfuck, whose programs are made chiefly of punctuation,
• COW, a version of the above where each of the few instructions is a variant of “moo,”
• Whitespace, whose code consists only of spaces, tabs, and returns,
• Chef, where programs resemble cooking recipes.

My favourite was Shakespeare, in which the whole program resembles a play. Believe it or not, but this code outputs “HI”:

A New Beginning.

Hamlet, a literary/storage device.
Juliet, an orator.

Act I: The Only Act.

Scene I: The Prince's Speech.

[Enter Hamlet and Juliet]

Juliet: Thou art the sum of an amazing healthy honest noble peaceful
fine Lord and a lovely sweet golden summer's day. Speak your
mind!

[A pause]

Juliet: Thou art the sum of thyself and a King. Speak your mind!

Thou art the sum of an amazing healthy honest hamster and a golden
chihuahua. Speak your mind!

[Exeunt]

It was interesting for me to see programming languages that intentionally remove some of the niceties and affordances we learned to take for granted. My guess is most of them are just art, or jokes, or a certain one-upmanship. But I couldn’t help but think of Arika Okrent’s excellent book In The Land Of Invented Languages. The book is about “human” languages like Esperanto and Klingon, but it’s much more interesting than I imagined, and maybe even quite a bit sadder: a story of people afflicted with a certain perfectionism who are not willing to accept languages simply cannot be perfect.

Perhaps ironically given the subject matter, I found this 34-minute video by Razbuten a bit intense, but I would still recommend it to people who work on onboarding, settings, etc.:

In the video, the author tries to answer the question: how to make any given game a challenge, given there is no universal standard of difficulty and every player arrives at a game not just with different skillset, but also likely different goals.

There are many techniques a game can use to adapt to the player – a simple upfront difficulty selector, complex difficulty settings, a training level, adaptive difficulty, accessibility/​assist modes – but there are no easy answers. Each method comes with pros and cons, and perhaps the very notion that a game should adapt to the user is flawed; some players might find it more rewarding to have to step up to the game instead.

In the video, Razbuten covers a lot of examples really well. I’m not going to say any of this maps 1:1 to productivity software as goals of games are very different than goals of apps… but even though I have never played any of the games mentioned, the examples made me think. After all, some of the psychology of mastery will be the same between these two realms. (I bet there were at least some of you who saw the previous post about LaTeX and thought “this looks hard and fascinating – I’m going in,” and others took a note to never approach it.)

I like Angela Collier’s videos about physics and I was delighted to discover this 18-minute one…

…because it’s a great continuation to the thread about the complexity of Microsoft Office I shared recently.

Collier talks about why physicists prefer LaTeX to Word. LaTeX is sort of a nerdy HTML that predates HTML. It looks like this…

…and given how nerdy HTML already is, you might imagine this is a power-user tool that’s chiefly about power and control. But Collier makes the argument that there are some things that LaTeX makes much easier:

• there is absolutely no need (or peer pressure) to spend time styling the document by choosing fonts, colors, etc.,
• there is no “live preview,” and making a PDF is a separate step similar to compilation in coding – which means it doesn’t constantly occupy your mind,
• GUIs can slow you down because the keyboard is faster than the mouse,
• LaTeX doesn’t give you a lot of control over positioning, which is better than giving you only a semblance of control over positioning (this is the TikTok meme Collier alluded to briefly).

This is really interesting because it goes right to the core of the uncomfortable truth: naïve design decisions meant to make things easier might achieve the opposite. I shared the ForkLift example where the team didn’t understand what made the previous version great, and more recently the animation that could slow people down.

(Of course, there is also the issue of typographical craft of LaTeX documents set in Computer Modern, but let’s save this for another time.)

Also, the video starts with Collier apologizing for potentially making the audience feel dumb in a prior video. I don’t think it’s a joke, and I found it thoughtful and refreshing.

A truly fascinating 17-minute video where Chris Siebert at 100th Coin ventures out to play Super Mario in a way where every single byte of code and every single byte of graphics are used, and then shows his work:

There was something about seeing the visualization of the entirety of the code being “used” that made me sit up:

It reminded me of IBM 1401, the 1959 business computer I saw a lot at the Computer History Museum. It takes up a big chunk of the room…

…but is still so simple that you can watch its console and understand exactly what is going on in its little huge electronic brain:

There’s something very powerful about this and made me imagine a version of it for my code, my CSS, my blog. Even the web lost a lot of its visited link vs. unvisited link fog of war kind of feeling of exploring the space and understanding how it is shaped.

The video gets into the coding weeds in between 2:25 and 13:35 – by the way, isn’t it scary to imagine your code pored over decades later, bugs and hacks and all? – but if you skip this part, make sure to come back at 13:35 for the verdict, and then for the graphics.

Spoiler alert: Some bits of code are never used, but the reasons are fascinating. All the untouched bytes are remnants of shameful mistakes, abandoned decisions, head fakes, and twin protections so strong that their first layer never gets penetrated – each one of them a tiny afterimage of other possible versions of Mario we’ve never gotten.

For a while, the digital artist James Dalzell Hodge kept a video diary of various design decisions while making his next game. This 13-minute video is interesting because it harks back to my mention of diegetic interfaces just a few days ago:

It’s a nice quick dive into the subject – a rare coverage of what “diegetic” means outside of the realm of movies.

I like these videos because Hodge focuses on details and shows working through things, including approaches rejected along the way. Inside, there are even occasional peeks at interfaces from Unreal Engine tools and Blender, not to mention examples from other games.

A funny and occasionally spicy 15-minute video by Nerrel from October 2024 about some of the nuances and legal fights surrounding Nintendo’s fight with community-made emulators:

The video paints Nintendo in the harsh light, highlighting their double standards and willingness to throw their corporate legal weight around just to squash the challenges before they go to court, despite court precedents ruling against them.

The video also talks about software preservation – this is the part that feels very important to me – and I also learned things about piracy, DCMA, and modern video game encryption.

Just to highlight the versatile value of emulation, in another corner of the emulation universe, I found this fascinating project: a web page called Yes we scan, made by George MacKerron, that promises scanning directly from the browser – for example if you have an old scanner unsupported by your modern OS.

And… it actually works! It combines WebUSB with an interesting technique:

Your web browser emulates a whole PC running Linux with open-source scanning software (SANE). It connects that to your scanner via WebUSB.

If you are interested, the details page has more… well, details. MacKerron also wrote Printervertion that allows you to print directly from web, too, even if your operating system abandoned your vintage printer. The way I understand this, both efforts basically invite an alternative operating system that might be more supportive to take a stab at scanning or printing, and do it in a friendly and sleek way through emulation. It’s kind of incredible this is even possible.

I linked to a bunch of speedrunning videos before, but this 43-minute video by hbomberguy from 2018 is a good introduction to the whole concept and why people care:

It’s really funny, romantic (maybe a bit too romantic), and it has a few great examples and explanations of the different kinds of speedruns that exist.

I hate lorem ipsum with passion, but guess what? There’s more intentionality in it than I assumed, and even easter eggs, as this fun 25-minute mini documentary from Emily Zhang/​Rabbit Hole shows:

You can tell that this was not the work of an amateur. The garbled text is done with a lot of care and knowledge. You can see a lot of rational decisions about why it looks the way it does in there. They are making very careful additions, such as adding letters… the “-and”s and the “-ng”s… The “y” got stuck in because that’s an English letter. […] I think the fact that it is garbled Latin text, and that it has those other letters in a fairly Latin-based alphabet amount of frequency, speaks to that it was done very, very carefully.

Just a fun watch all around.

This 22-minute video by Karl Jobst describes a pretty wild discovery of a glitch called Crystal Storage Glitch, allowing to skip a certain level for much faster completion times in Mega Man X2:

I won’t spoil the glitch because it’s a fascinating combination of a corner case, a race condition, and even a dose of dumb luck. Its finding unveils almost like a scientific discovery over many years – first a theoretical possibility, then a first sighting done in a modified emulator, then confirmation made by a machine via a tool-assisted speedrun, and eventually actual performance by someone by hand. And a lot of this achieved by relative newcomers to the community, too.

There is certain poetry here in having to go slow to go fast – you’ll see what I mean.

The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic) very popular in that language.

Here is the before and after of this situation:

Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.

The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.

This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.

First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.

Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.

This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.

Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.

But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:

Stick with the 7-bit ASCII subset. You will never go wrong.

7-bit ASCII basically means “26 Western letters and nothing else.”

I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:

Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.

If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)

If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness:

My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy:

In light of a recent Googlebook announcement that uses a mouse wiggle gesture for AI (which to me doesn’t seem like a pleasant interaction), some of us were talking about how, on macOS, mouse wiggle helps you locate the cursor by making it bigger.

I am maybe a sucker for videos and podcasts where people start laughing, but here we go – a very short video about a version of Linux that “does not limit how big your pointer can get if you wiggle the mouse pointer”:

A fascinating 25-minute video from Mark Brown at Game Maker’s Toolkit about how the team building Grand Theft Auto 3 conquered the technical limitations of PlayStation 2:

How do you squeeze a city that occupies over 50 megabytes into the 32MB memory of the console? You simply do what The Truman Show did, and construct the city around the player as they’re moving around:

This has, as you can expect, a lot of technical and even game-design consequences, and the video goes into a lot of detail on these – including Brown rebuilding the Grand Theft Auto 3 source to visualize things better.

This technique is also used in interface design, for example if you have a really long list of things that would take too much memory or GPU power to render. What the video calls “streaming” is, in the context of UI, often called “virtualization”: instead of having a full long list (or an entire world), you abstract it away – or, virtualize – into something nimbler.

Some of the challenges and techniques used by Grand Theft Auto 3 apply pretty directly here, as well:

• you can use UI skeletons as “low poly” models,
• in some contexts, you can guess the user is more likely to move in one direction (for example, going through fonts in a font picker), and more eagerly preload where they’re going to look next, rather than symmetrically in both directions.

On the other hand, “speedy players” and “pop in” can’t ever be solved because any UI list is random access, and slowing users down is not typically appropriate; better to make loading as pleasant as possible than introduce any roadblocks, even if figurative ones.

The Pixar animated short Lifted was released in front of Ratatouille in 2006:

I’ve always been amused by this imaginary interface, which is so clearly not how any sort of computer would work.

Or so I thought. These are photos I took in Melbourne in 2024 of CSIRAC, Australia’s first digital computer from about 1949:

This is a “console” of the computer, used to tactically probe or input specific memory addresses (in binary), and to control functions like stopping and starting the program. Any proper programming and eventually inputting data would happen using gentler I/O devices like typewriter keyboards, paper tape, and magnetic storage.

Physical consoles like this one were last seen in the 1970s on hobbyist home computers such as the Altair 8800, and the Console app on your Mac diligently spitting out logs is its spiritual and virtual successor. But even if a CSIRAC console feels hostile today, 75 years ago it was quite the opposite:

And [CSIRAC] helped there too. It could display all its working registers and the last 16 instructions executed. It could be given an address at which to stop (a “breakpoint”), and be stepped by one instruction at a time. It even had lights to show the computer’s internal states. This was a user-friendly computer.

CSIRAC stood for Commonwealth Scientific and Industrial Research Automatic Computer, a typical naming scheme of the era. We also got ENIAC (Electronic Numerical Integrator and Computer) in 1945, BINAC (Binary Automatic Computer) in 1949, EDVAC (Electronic Discrete Variable Automatic Computer) in 1946, ILLIAC (Illinois Automatic Computer) in 1952, and then SEAC, SWAC, ORDVAC, TREAC, AVIDAC, FLAC, WEIZAC, BIZMAC, RAMAC, and UNIVAC.

The story goes that the name of 1952’s MANIAC (Mathematical Analyzer Numerical Integrator and Automatic Computer) was chosen to highlight and put a stop to the goofy naming practice. Did it work? I am not sure. Not only two more MANIACs were produced, but we also got 1953’s JOHNNIAC (nicknamed “pneumoniac” since it needed a lot of air conditioning), and SILLIAC (Sydney ILLIAC) in 1956. The last computer I can find using that naming scheme was TIFRAC, operating in India between 1960 and 1965.

CSIRAC had real work to do, but today it is known chiefly for being the first computer to play music in real time. The quality is… I’ll let you judge, with links below pointing to short MP3s preserved by Paul Doornbusch and subsequently Internet Archive:

• Auld Lang Syne
• Chopin’s March
• In Cellar Cool
• (I particularly enjoyed an alt recording of In Cellar Cool where CSIRAC itself appears in a background as a constant humming presence.)

Do you miss your PC speaker yet?

Engineers working on other room-sized computers of that era did similar things; whether this was solely one of the first attempts to humanize the big scary machines, or a distraction from the computers’s typically military uses is left as an exercise for the listener.

Today, one of the 1960s machines still plays music, headlining a fascinating annual tradition – every December, the PDP-1 restoration crew at the Computer History Museum in California invites visitors to sing carols with the computer older than most of them.

The last photo takes us back to where we started. Neither CSIRAC nor PDP-1 might be user-friendly by today’s standards but damn, wouldn’t you want some of your computer’s interface to feel this way?

A surprising entry in the thread started by Photoshop and continuing through screwdriver handles is this 11-minute video from Errant Signal about a platformer game called Derelict Star:

I was inspired by the video, and really enjoyed its exploration of a demanding game that’s composed of just a few mechanics that are done really, really well:

The number of inputs are small, but the expression those inputs allow is deceptively expansive. […] Derelict Star’s various areas are all built to explore the way movement systems function and even interact with one another.

I think of user interfaces similarly, and of their need to build a certain consistent vocabulary of names, gestures, interface elements, concepts, and so on. Perhaps in an enterprise app you right click and discover something useful in a menu, and this will teach you about the usefulness of right click menus in general. Maybe pressing ⌥ to get to alternate symbols on your keyboard would inspire you (either consciously or not!) to try holding ⌥ in said menus, only to discover this brings up useful alternative options. Maybe seeing a keyboard shortcut next to one of these options will suggest to do that next time, and so on, and so on.

I really loved this bit in the video that could apply to a lot more software than just videogames:

It took me maybe an hour to do this, but right on the other side is a checkpoint. The game is hard, but it isn’t cruel. It’s designed to challenge you, but it has faith in your ability to complete it.

The narrator uses the term “ludocentrism” to refer to games that ruthlessly prioritize the mechanics and gameplay over narrative, aesthetics, and so on. (“Ludic” meaning “relating to play.”)

Of course, the calculus of what videogames care about will be different than goals of creative software or enterprise software; no one cares about the hero’s journey of the largest number in your Excel spreadsheet. But I think some version of ludocentrism applies to “boring”software as well. My beliefs here are probably something like this:

• you can’t reduce everything to just functionality or just efficiency,
• especially in creative moments of software use,
• and people use software creatively much more often than we suspect, including software not thought as “for creatives.”

A 19-minute video from Tantacrul about a parallel universe that’s right next to ours, but most of us don’t get to think about – typography of fonts for music notation:

The video has some nice things going on besides specific details and conventions: there is a glimps of an obsolete app with a fascinatingly obtuse interface, a mention of modern standardization developments, and even a little (sad?) story of perfectionism and legacy.

I’m also kind of mesmerized by this shot of what music typesetting used to be:

There is also a short 1936 video showing more of that process. And small contribution from my end – a photo of the Keaton Music Typewriter from a museum in Catalonia:

Minecraft is so complex that it’s sometimes hard to know what is a bug and what is not.

Here’s the logic of the game:

• If you fall from height, you receive fall damage.
• If you fall from height but you’re in a boat, there’s no fall damage.
• If you fall from height and you’re in a boat, but you fall from a distance of 12, 13, 49, 51, 111, 114, 198, 202, 310 or 315 blocks, there is fall damage and you die.

The first is common in games.

The second is – I believe! – a former bug that was grandfathered in as a design decision: people got used to it, started relying on it, and it became “too big to fix.” The retroactive explanation became that the boat is your shield and takes all the fall damage, which is a very Hollywood action movie way of looking at the world.

So, only the third one is a bug… obviously.

But why those specific numbers? Here’s a 16-minute video by Matt Parker at Stand-up Maths that tries to answer it:

It’s an interesting video because it’s lighter on bug causes discussion, but heavier on math – and the moment you realize those numbers above are not random at all and coalesce into a nice formula, is genuinely a pretty fun moment.

I thought this was interesting, and a little contribution to a larger debate about how hard it is to even agree what a bug really is (which I previously briefly talked about).

A fun 24-minute video from Technology Connections about designed sounds in real life: elevator dings, airplane chimes, railway crossing dings, and so on.

While I am sympathetic to the notion that sound pollution is a thing we need to be concerned with, the choice between silence and sound pollution is a false choice. There’s a lot of those happening these days, probably because we’re so stuck in binary thinking. But as airplanes show us, we can design sounds which aren’t obtrusive, but which are helpful. And when you get yourself out of binary thinking, you can do things like make your most obnoxious apps be silent while your important ones make themselves known, and in ways which are meaningful to you and pleasant to everyone else.

It is an interesting parallel to the post about syntax highlighting from a while back, and one of the posts about cartography design I shared recently; they all explore how you can create a richer space capable of conveying more information without overwhelming people, by being intentional about the design.

A 21-minute video from Karl Jobst about a 2025 videogame cheating scandal:

In short: One of the professional teams in the FPS game Squad built a sophisticated set of scripts that made it easier to use the game for esports tournaments by adding additional UI, useful stats, a floating camera, an extra over-the-shoulder view, and so on. The community embraced the scripts as they genuinely made the spectating much better.

Months later, it turned out that the creators not only hardcoded easier rules for their own team, but even added a pretty comprehensive set of cheating keyboard shortcuts.

The useful esports spectating scripts were, in effect, a trojan horse. A fascinating story, plus an interesting case of psychology of cheating.

This 25-minute segment on MKBHD’s Waveform podcast (video or audio, segment starts at 40:21) is from November 2024, and is a nice counterpart to the post about favourite well-made apps and sites.

The original theme is “what is an app that you use all the time, and like to use, but is actually a bad app?” but it quickly moves to a more general conversation about good and bad mobile apps.

It’s always interesting to me to see what themes emerge and what other people think is important. Here’s the list where I linked to relevant apps as long as I could find them:

Bad apps:

• Google Messages – dinged for unreliable spam and lack of organization/​filtering
• Notion (on mobile) – hard to orient yourself and some direct manipulation is wonky
• many smart home accessory apps – bad and redundant with Google Home, but have to keep for emergencies
• Netgear Orbi (network router) – specific functionality and bad password recovery
• Hatch (white noise machine for babies) – simple things are hard to discover
• Nest app/Nest Yale Smart Lock – bad integration
• Goodreads – stale

Good apps:

• ButterflyMX (smart building lock app) – reliable
• UDisc (score keeper for disc golf) – good functionality, great in a free version
• New York City ferry
• New York City ticket payment – reliable and has many payment options
• Greenwich, CT and San Francisco parking apps – live activities
• The StoryGraph – cool graphs and stats about your book reading patterns

Multibowl is one of my favourite emulation projects because it’s a rare example of using emulators creatively, rather than for nostalgia or research.

It’s a 2016 game by Bennett Foddy and AP Thompson that reimagines older existing games as smaller pieces of a new, Super Mario Party-like experience. Two players randomly join one of 300 games – sometimes in medias res – with a small explicit goal that can be accomplished in about ~30 seconds, after which a point is awarded, another game is loaded, and so on.

All of this is done through actual emulation and fast switching of games’s original code:

Regarding the game choices, at the outset, I wanted to curate a list of moments of gameplay that would be meaningful if played for just a short period of time. Sometimes it’s obvious – you can take a moment from a fighting game where both players are low on health, or play a sports game from the start until the first point is scored. So that’s where I started. Over time, I figured out that you could make exciting moments in games that are not otherwise interesting for a competitive duel. For example, in Dodonpachi (a bullet hell game) we take away the player’s guns and challenge them to stay alive in a huge hail of bullets.

For games that were designed as cooperative experiences, I eventually gravitated toward the structure ‘score more points but do not die’, which forces the players to calibrate how much risk they take relative to the other player.

This excerpt is from a 2017 interview of Foddy by Seb Chan from ACMI. There are many interesting moments in that interview, such as the issue of curation:

Multibowl is not a very precise historical curation like you might make for a museum exhibition, where you can only show a couple of dozen things at most. It’s a huge driftnet of games. There is no quality or historical significance standard, and no attempt to balance out the games in terms of nationality or gender. The only curatorial instinct that it follows is to find the most diverse set of game ideas. With each piece distilled down to a randomly-selected 30-second slice, there’s room for an infinite number of them.

In fact, contrary to a museum curation, the point of Multibowl is to have too many games for a single player to see. It’s best when it feels too big to grasp. I think, now that there are 300 games in there, it’s starting to feel that way.

Unfortunately, it is not possible to actually play Multibowl outside of special events, given copyright issues. In addition to general emulation copyright murkiness, Foddy adds, “I don’t think the actual bits of actual games have ever been used as the fabric of a larger game before.”

However, a really fun introduction to Multibowl is another art project from a now-defunct comedy duo Auralnauts, who actually played Multibowl pretending to be Kylo Ren and Bane, to hilarious results:

A thoughtful 26-minute talk by Imani Joy, the solitary full-time designer on Mastodon, reflecting on her nine months there:

It’s an interesting peek behind the curtain at designing for this particular space, and the many unenviable constraints: lack of data, care for privacy, tension between Mastodon’s power-user early adopters (“they are values-driven, they want control, they’ll tolerate a lot of the clunkiness of the Fediverse”) and “mainstream audience [that] expects polish.”

At some point, design needs to be authoritative, but how do you combine that with wanting the process to be as inclusive as possible? The product itself is a federation of various servers that can exert their own control – so how do you bring it all together under one neat umbrella for the user? (Also a challenge for Android in comparison with iOS.) The mainstream design has certain fashion-y tendencies. How to make sure you don’t lose yourself while chasing them, but also not to stay ossified out of fear of making changes? (Wikipedia, Internet Archive, and other similar places look and behave a certain way, after all, and it’s not usually because of lack of talent to “modernize” them.)

The most interesting thing to me was this:

It’s easy to talk in terms of who to optimize for. Things get harder when you start to articulate who you won’t optimize for, what trade-offs you must make in pursuit of your goal, and who you’re going to risk letting down along the way. What the team needed from me more than anything was not the probabilities, not the usability findings, not the story of who we’re making happy. They needed to hear who will choose to disappoint and why. And I told them that building the best experience on Mastodon means that we’ll solve for the extremes, but we won’t center them. And sure, we do risk frustrating some power users who want absolute control over their profiles, but that risk is necessary to optimize the experience also for browsing users.

When we were working at Figma in 2019 shipping an update to text line height algorithms (moving them from the way print does things to the way web does things), I started an internal document called “The new line height and its discontents,” where myself and the team deliberately wrote out who will be most annoyed about the changes, and why. We listed our arguments, workarounds, even “deal sweeteners” (“but look at this other thing that will get better as a result!”), but we also tried very hard to be candid with ourselves. Some people were not going to be happy no matter what we do or say. Do we know precisely who these people are and are we okay with that? I’d recommend that approach for any change-management project, rather than keeping fingers crossed or toxic positivity.

Joy so far worked on quote posts and new profiles, and I appreciated her ending the talk on a note of recognition for these kinds of projects in these kinds of settings:

I know that we’re building something that will continue to be imperfect, but it doesn’t have to be perfect to make a positive difference in the world.

This 9-minute video from PetaPixel probably won’t make much sense for non-photographers, but there is something refreshing about this idea that there are still places where adding software is seen as positive:

The video talks about Tamron’s lenses which have their own software (independent of the camera), and even their own USB-C port.

In a camera lens equivalent of fly-by-wire, the software allows to fine-tune the behaviour of hardware: what should soft buttons do, should the focus ring be responding in a linear or not, or even in which direction should it rotate. However, there are also more complex behaviours – like time lapses with focus pulls – with an interesting interface that’s definitely not beautiful, but I think still worth checking out for how it uses skeuomorphism.

It is common knowledge that Luigi is just a palette-swapped Mario, and that the characters facing left are the same characters as those facing right, only rendered mirrored.

This interesting 9-minute video from Core-A Gaming explains how this can be kind of tricky for fighting games in particular:

Suddenly, a character with a claw on one hand, or a patch on one eye, becomes a more complex situation – without redrawing, the claw or the patch move from one side of the body to another. Then there’s the issue of open stance toward the player, turning left-handed characters into right-handed ones just when they switch to the other side.

3D fighting games can, in theory, fix all of this with more ease, as instead of redrawing hundreds of sprites they can just introduce one change to a model… but they often choose not to. Enter the issues of 2.5D fighters vs. 3D fighters, 2D characters in 3D spaces, and lateralized control schemes.

It’s a small thing that quickly becomes a huge thing.

Here’s an object in Figma with one rounded corner. Notice how the UI always tries to match the rounded corner value based on where it is physically on the screen…

…which makes for a fun demo and feels smart, but: why don’t width and height do the same?

Turns (heh) out that this is a similar set of considerations as those in fighting games: both thinking deep about what is an intrinsic vs. derived property of an object, and what is the least confounding thing to present to the user. Since objects usually have noticeable orientation – text inside, or another visual property – width still feels like width and height like height even if they’re rotated. The same, however, isn’t necessarily true for four rounded corners. Or, perhaps, the remapping of four “physical” corners to four “logical” corners can be more error-prone.

Then, of course, there’s a question of what to do when the object doesn’t have a noticeable orientation. Like with many of the things on this blog, there are no “correct” answers. This too is a small thing that quickly becomes a huge thing.

I had no idea it was Alan Kay himself who was responsible for the mouse pointer’s distinctive shape. In 2020, James Hill-Khurana emailed him and got this answer:

The Parc mouse cursor appearance was done (actually by me) because in a 16x16 grid of one-bit pixels (what the Alto at Parc used for a cursor) this gives you a nice arrowhead if you have one side of the arrow vertical and the other angled (along with other things there, I designed and made many of the initial bitmap fonts).

Then it stuck, as so many things in computing do.

And boy, did it stick.

But let’s rewind slightly. The first mouse pointer during the Doug Engelbart’s 1968 Mother Of All Demos was an arrow faced straight up, which was the obvious symmetrical choice:

(You can see two of them, because Engelbart didn’t just invent a mouse – he also thought of a few steps after that, including multiple people collaborating via mice.)

But Kay’s argument was that on a pixelated screen, it’s impossible to do this shape justice, as both slopes of the arrow will be jagged and imprecise. (A second unvoiced argument is that the tip of the arrow needs to be a sharp solitary pixel, but that makes it hard to design a matching tail of the cursor since it limits your options to 1 or 3 or 5 pixels, and the number you want is probably 2.)

Kay’s solution was straightening the left edge rather than the tail, and that shape landed in Xerox Alto in the 1970s:

Interestingly enough, the top facing cursor returned as one of the variants in Xerox Star, the 1981 commercialized version of Alto…

…but Star failed, and Apple’s Lisa in 1983 and Mac in 1984 followed in Alto’s footsteps instead. Then, 1985’s Windows 1.0 grabbed a similar shape – only with inverted colors – and the cursor has looked the same ever since.

That’s not to say there weren’t innovations since (mouse trails useful on slow LCD displays of the 1990s, shake to locate that Apple added in 2015), or the more recent battles with the hand mouse pointer popularized by the web.

But the only substantial attempt at redesigning the mouse pointer that I am aware of came from Apple in 2020, during the introduction of trackpad and mousing to the iPad. The mouse pointer a) was now a circle, b) morphed into other shapes, and c) occasionally morphed into the hovered objects themselves, too:

The 40-minute deep dive video is, today, a fascinating artifact. On one hand, it’s genuinely exciting to see someone take a stab at something that’s been around forever. Evolving some of the physics first tried in Apple TV’s interface feels smart, and the new inertia and magnetism mechanics are fun to think about.

But the high production value and Apple’s detached style robs the video of some authenticity. This is “Capital D Design” and one always has to remain slightly suspicious of highly polished design videos and the inherent propensity for bullshit that comes with the territory. Strip away the budget and the arguments don’t fully coalesce (why would the same principles that made text pointer snap vertically not extend to its horizontal movement?), and one has to wonder about things left unsaid (wouldn’t the pointer transitions be distracting and slow people down?).

Yet, I am speaking with the immense benefit of hindsight. Actually using that edition of the mouse pointer on my iPad didn’t feel like the revolution suggested, and barely even like an evolution. (Seeing Apple TV’s tilting buttons for the first time was a lot more enthralling.) And, Apple ended up undoing a bunch of the changes five years later anyway. The pointer went back to a familiar Alan Kay-esque shape…

…and lost its most advanced morphing abilities:

Watching the 2025 WWDC video mentioning the change (the relevant parts start at 8:40) is another interesting exercise:

2020:

We looked at just bringing the traditional arrow pointer over from the Mac, but that didn’t feel quite right on iPadOS. […] There’s an inconsistency between the precision of the pointer and the precision required by the app. So, while people generally think about the pointer in terms of giving you increased precision compared to touch, in this case, it’s helpful to actually reduce the precision of the pointer to match the user interface.

2025:

Everything on iPad was designed for touch. So the original pointer was circular in shape, to best approximate your finger in both size and accuracy. But under the hood, the pointer is actually capable of being much more precise than your finger. So in iPadOS 26, the pointer is getting a new shape, unlocking its true potential. The new pointer somehow feels more precise and responsive because it always tracks your input directly 1 to 1.

(That “somehow” in the second video is an interesting slip up.)

I hope this doesn’t come across as making fun of the presenters, or even of the to-me-overdesigned 2020 approach. We try things, sometimes they don’t work, and we go back to what worked before.

I just wish Apple opened itself up a bit more; there are limits to the “we’ve always been at war with Eastasia” PR approach they practice in these moments, and I would genuinely be curious what happened here: Did people hate the circular pointer? Was it hard to adopt by app developers? Was it just a random casualty of Liquid Glass’s visual style, or perhaps the person who was the biggest proponent of it simply left Apple? We could all learn from this.

But the most interesting part to me is the resilience of the slanted mouse pointer shape. In a post-retina world, one could imagine a sharp edge at any angle, and yet we’re stuck with Kay’s original sketch – refined to be sure, but still sporting its slightly uncomfortable asymmetry.

The always-excellent Posy covered this in the first 7 minutes of his YouTube video:

But specifically one comment under that video caught my attention:

Honestly, I’ve never thought of the mouse cursor as an arrow, but rather its own shape. My mind was blown when I realized that it was just an arrow the whole time.

…because maybe this is actually the answer. Maybe the mouse pointer went on the same journey floppy disk icon did, and transcended its origins. It’s not an arrow shape anymore. It’s the mouse pointer shape,and it forever will be.

One of my favourite genres is “I’m going to teach you something secretly while you’re having fun.”

This 2020 post by George Cave is ostensibly about Lego interface panels, but quietly sneaks in some stuff about shape coding and other kinds of coding:

The Lego interface panels seem to have a certain hold on people. Artist Love Hultén recreated some of them in a more human-compatible scale and even made them interactive:

It was fun to see one of the most well-crafted of early arcade games, Tempest, in this kind of a view, with the stud reimagined as a paddle controller:

Just earlier this month, designer Paul Stall announced his project M2x2 (the page itself is beautiful and interesting to visit – I paticularly loved the horizontal galleries):

The M2x2 is a functional homage to the classic Lego computer brick, upscaled and re-imagined as a high-performance workstation. […]

If our tools could look as playful as the things we built as kids, would we approach our work with more joy? The M2x2 is just the beginning of a workspace that feels less like an office and more like a laboratory for breakthroughs.

But both of these are enlarged Lego bricks. Three years ago, James Brown a.k.a. Ancient made an effort to embed an LCD screen in a regular-size Lego brick. It’s a fun 12-minute video of the construction process:

If you are into that kind of stuff, Brown followed it up 2 months later by putting a playable Doom inside a Lego brick:

But the most amazing to me outcome was this video, called “Busy little screens”:

A lot of diversity of the original bricks is gone, but it’s hard to expect Brown to recreate and animate them all. It’s a mesmerizing thing to watch nonetheless; one can almost taste a future where the technology will allow for Lego bricks to be animated, but look exactly as they originally did.

I mentioned before how the old-fashioned pixels on CRT screens have little in common with pixels of today. The old pixels were huge, imprecise, blending with each other, and requiring a very different design approach.

Some years ago, the always-excellent Tech Connections also had a great video about how in the era of analog television, pixels didn’t even exist.

But earlier this month, MattKC published a fun 8-minute video arguing that for early video games it wasn’t just pixels that were imprecise. It was also colors.

What was Mario’s original reference palette? Which shade of blue is the correct one? Turns out… there isn’t one.

Come to learn some details about how the American NTSC TV standard (“Never The Same Color”) worked, stay for a cruel twist about PAL, its European equivalent.

One of my favorite bits of trivia about the 1983 movie WarGames is that all the computer typing scenes have been faked in a clever way: The actors (many of whom might have never typed before, as home computers were only slowly becoming popular) were allowed to press any key they wanted, but the interface would still proceed as if the correct letter was typed.

This allowed the computer to respond to keystrokes, making it all feel real, but also reduced the burden on actors to type things properly – and also make it easier for proper sight lines to happen, as the actors didn’t have to constantly look at the keyboard.

WarGames used it really well, showing all sorts of face reflections in the CRT screens, as if people literally talked to the machines, which must have been hell to film:

I have never seen this demoed or mentioned outside of the anecdote. However, yesterday, Cathode Ray Dude released an excellent video about the challenges of filming computer screens. The whole video is worth watching, although at this point mostly off-topic for this blog. But starting at 1:32 and ending around 1:37, there’s an actual demo of a similar piece of auto-typing software used in the 1996 movie Scream:

You might think this is just a piece of old-computer trivia, but I’ve actually used that in at least two of my talks, for some of the similar reasons! I run most of my talks from HTML/CSS/JS; it’s nice for the audience to see things being typed and responding properly to (audible, and occasionally visible) key presses – but it’s also nice as a speaker not to worry about messing things up under pressure.

For extra realism, make sure Backspace goes back in the script – you might occasionally press it instinctively – and for extra extra verisimilitude, actually bake in a typo or two into the predefined sequence. (And an escape hatch if you actually change your mind and want to go manual.)

Then, of course, there’s a classic 2011 piece of software called HackerTyper. Did someone already marry this idea with an LLM? Seems like a logical next step.

Many of you have probably heard the repeated story of the first Moon landing in 1969 almost getting undone by a bunch of onboard computer glitches:

There could not be a worse time in the flight to have computer problems. At, the time the press gleefully reported how Armstrong seized manual control from a crippled and failing onboard computer and managed to heroically and single-handedly land the spaceship on the surface of the Moon against all odds.

Robert Wills argues against this narrative in this 2020 talk, wanting to shine a spotlight away from Neil Armstrong and toward people who designed the software (among them Margaret Hamilton), and the mission control’s Steve Bales, who made a decision not to abort the launch as the 1201 and 1202 errors were piling up.

The argument: the computer was working as intended, it fixed itself over and over again owing to its clever software, and it actually helped Buzz Aldrin understand (at least subconsciously) what led to the seemingly random and distracting computer errors.

The above is more of a traditional talk than the videos I usually share – a bit more technical, taking up an entire hour, and with generic slides – but it’s buoyed by Wills’s enthusiasm and knowledge.

Besides, it’s lunar landing! Did you know about DSKY and its fascinating keyboard and UI? Did you know the spacecraft’s window was part of the interface, too? Or that its software was woven into the hardware? Or that the Apollo 11 had a… guillotine in it?

Unaddressed in the talk, but also important:

An unsung hero of the decision not to abort the landing is Richard Koos, a NASA simulation supervisor who […] 11 days before the launch of Apollo 11, put the team of controllers including Bales […] through a simulation that intentionally triggered a 1201 alarm. […] Unable to figure out what the 1201 was, Bales aborted that simulated landing. He and Flight Director Gene Kranz were dressed down for it by Koos, who put the team through four more hours of training the next day specifically on program alarms. When the 1202 and 1201 alarms occurred during the actual landing, Garman, Bales, and even Duke recognized them immediately.

Fortune favors the prepared.

RuneScape is a popular MMORPG that reached its peak popularity in the late 2000s.

In the game, combat – colloquially known as PvP, or player vs. player – is limited to a specific map area (called the Wilderness) and otherwise people’s houses.

On 6/6/6 (sic!) a bug in RuneScape made it possible for a few players to start killing others outside of designated areas, without them being able to defend themselves. One of these players, Durial321, gained a lot of notoriety:

A player called Cursed You had invited some friends to his in-game house once he had maxed his construction skill, but decided to eject them all from the premises. Things turned sour, however, as a group of players marked as PvP in the house didn’t lose this PvP flag when ejected, allowing them to storm through Falador and massacre whoever they pleased. The most notorious of these players was named Durial321.

This event went down in internet infamy and meant that many players lost their items when killed as well as the banning of those involved.

I don’t have any context of RuneScape and I found it really funny to learn about this event from different retellings of the story.

This wiki entry reads almost as journalism:

Several others were able to use this glitch, but Durial321 abused it the most. His rampage lasted for about an hour, starting at Rimmington, where the house party was, then proceeding to Falador and subsequently Edgeville. At Edgeville, he gave Voodoolegion the green partyhat, who never gave it back to him. Soon after, he finally encountered a Jagex Moderator, Mod Murdoch, who disconnected him and locked his account. Durial321 was later permanently banned from RuneScape. In a 2006 interview, he said that player killing outside of the Wilderness was exciting, although he felt bad for the players who lost their belongings.

The 2006 incident later became known as the Falador Massacre.

(The tone is even more funny if you actually read the interview.)

There is also this more modern retelling that feels like scary story time by the campfire:

Reactions from players were initially kind of incredulous. Plenty of people were shocked and found the whole incident quite funny. Durial had essentially broken the game, after all. Some players wanted to be like him, whipping strangers to death and taking their items. But soon, as more players started hearing about what had happened and seeing the video, the mood shifted. Players wanted Durial321 hung, drawn and quartered, with his head displayed on a pike outside Lumbridge Castle.

You can witness the event PC Gamer called “one of the best all-time MMO bugs” by yourself since there is video capture of the Falador Massacre taken by one of the witnesses. At least to me, it’s rather incomprehensible.

Fear not, however, because there are many (!) documentaries. This recent one is reportedly the best one and also goes into the technical details:

Without spoiling too much, the bug was a classic Swiss cheese situation involving a new untested item, a race condition, peculiar timing, and a player with an unusually high uptime and a whole lotta luck.

This video from Marblr about adding fall damage to Overwatch is really intense – 45 minutes of length and a lot of footage of frantic gameplay – but really informative, too.

It’s a great case study of how something seemingly really simple – deducting health from the player as they fall from height – can be a complicated thing to figure out in all the detail.

I never played Overwatch and rarely play videogames anymore, but many of the lessons here more universal for any sort of UI and system design:

• You will have to introduce tactical inconsistencies for the system to feel consistent, but be careful as there might be a point those inconsistencies start to outweigh the whole thing.
• Wanna learn how you and others feel about something? Overcrank it to make the feelings come out more easily. (And to find bugs.)
• There will always be tensions between what the data says and how you feel about something. (I was surprised how often the word “intuitive” entered the picture.)

Also, it’s just a really well-made video, filled with little presentation and storytelling details that elevate it. I wish more videos like this existed for UI mechanics.

But maybe the most important takeway? You don’t have to choose between rigor and fun. You can have both.

This was a fun 15-minute architectural video from Stewart Hicks (absolutely worth a follow otherwise) that mapped precisely into the same kind of tension and internal debate I sometimes feel when talking about minimalism in UX design: Minimalism is good! Until it’s not!

One interesting lesson here is that the famous “less is more” was actually – surprise! – perverted from the original poem, where it meant “less technical perfection means more emotional impact.”

I wasn’t fully sure why Hicks decided to incorporate a commentary to his own story this way – maybe he was afraid that the sarcasm of “steel wanting to share its joy” and “lessness” and “simplificity” wouldn’t land well? Or perhaps it was just the introduction that didn’t quite work for me, as it confused the entire joke.

But it was fun to watch it twice anyway. Those stories are never easy. I am not ready to draw too many parallels between architecture and UX design, even if Hicks lightly does so at the end. There’s no gentrification and displacement when Liquid Glass takes over Aqua, although I think a lot of people would love to see a Apple’s recent design decisions meeting the business end of a wrecking ball.

My favourite recent saying to replace “less is more” is this, by Paul Valéry (another poet!):

Everything simple is false. Everything complex is unusable.

You can see it as unsolvable, cynical, maybe even nihilistic. I do too, on a dark day. But more often, I see it as a great challenge. “Less is more” has this simplistic seductiveness that feels naïve. “More” is not an option, but often in my work on complex systems “less” is neither, and a lot of UX design is finding the perfect shade of gray.

A really interesting 28-minute video by daivuk about making a first-person shooter game QUOD that fit in just 64 kilobytes:

I found watching it strangely enthralling and even nerve racking. The creator keeps adding stuff that seemingly has no chance of fitting into such a small space – textures! sounds effects! music! his own language! – and somehow finds a way to squeeze them all in.

This is inspiring, but also practically useful: even though you and I are maybe never likely to need such high optimization, some of these techniques alone could be useful in some tight quarters like a load-bearing CSS file, or embedded software.

As an example, the author wrote his own “music tracker,” which is a clever way to reduce the weight of music: instead of the tune being one big audio file, only the instruments are sampled, and then arranged in repeating patterns.

Except in his case, there were no instruments… just audio effects already existing in the game. And audio effects themselves were generated in a similar way, by combining smaller waves and effects.

The same was done for textures: the creator wrote a bespoke text editor that saves each texture as smaller pieces and combination instructions – a sort of a “PDF” of a texture rather than a more costly scan of the printed page – and re-generates it on entry.

Lastly, this debug view of “cost” was really interesting. (Good debug views, in my opinion, are generally underrated.)

Palette cycling is an interesting technique borne out of limitations of old graphic cards. Today, any pixel can have any color it wants. In the 1970s and 1980s, you were limited to just a few fixed colors: as few as 2 for monochrome displays, or 4, or 8, or – if you were lucky – 16. Some of those fixed palettes, like CGA’s, became iconic:

But there was an interesting hybrid period in between then and now where you still were only allowed 4 or 8 or 16 or 256 color choices in total, but you could assign any of these at will from a much bigger palette.

So, as an example, each one of these three is made out of 16 colors, but each one is 16 different colors:

Moving pixels was slow. But palette swaps were so fast and easy, that it led to a technique known as palette cycling. This is probably the best-known example, from an Atari ST program called NEOchrome.

Despite so much apparent movement, no pixels are changing location, as that’d be prohibitively slow in 1985. Only the palette is changing. If you watch the same animation with the UI visible, you can clearly see which colors are “static,” and which are moving around:

But this was 1985, so why I am mentioning it 40 years later?

I like looking at old computers for a few reasons. Some of these seeminly-ancient techniques are inspiring and remind me that the limitations are often in the eye of the beholder. Seeing someone really good pushing a platform to its limits is just a good thing to load into your neurons – this could be you next time! And, believe it or not, some tips and tricks can still be relevant.

For example, this is a 9-minute video by Steffest from just earlier this year that walks through a modern attempt to make a palette cycling animation, including starting on an iPad:

The end result goes much harder than I expected. It was interesting to see again the technique of dithering to simulate transparency (we’ve seen it before, but this one is more advanced). But what particularly stood out to me here was the artist making his own little tools to aid in the creative process; I’ve always loved the notion that a computer is really just meant to be an accelerant, making it easy for you to avoid drudgery.

An 8-minute video by Bread on Penguins about some fun uses of terminal:

I am pretty sure this is nothing new for heavy command-line gurus (and heavy Raycast users, and so on), but I found it delightful to see someone so excited about creative uses of the terminal, and it made me realize how much time I do waste going through the browser, then Google Search, then scrolling. I am sure tightening some of these loops would feel great.

There is also something interesting in the argument about terminal being the ultimate “reading mode” of any website, chiefly because it cannot be anything else.

Mostly, this and Strudel before make me excited to see some new (to me) stuff happening with text-based user interfaces.

An entertaining 9-minute video by Shloop that starts with a common mistake of typing in an English mode on a Korean keyboard, but then goes through a bunch of other fun and light input internationalization stories:

This is the page for non-English programming languages that is shown at some point. Quite a bit of stuff in there.

Oh, also, in Polish (my native tongue), spitting is “tfu.”

A nice counterpart to my post from a few days ago – a 5-minute video by philive of more kill screens from various classic arcade games, with simple explanations.

I linked to Strudel before, but this 6-minute video is even better – it shows a musician named Switch Angel constructing a trance track from scratch:

This is of course competence porn, made even better by the dry Polish lektor-like delivery. But it’s also a puzzle. I watched this so many times. There are so many great UI lessons in here:

• You can absolutely put graphics inside a textbox
• Sparklines rule
• Slider is still the best UI element in history
• Previews don’t have to feel like training wheels
• Synchronizing sounds to visuals is so powerful (see: turn signals on a car dashboard)

I found myself thinking about how you’d design something that feels real-time, but also needs to be resilient against typos, and has a distinct “commit” moment (which is what I think those yellow flashes are); some of the best moments in the video are the quick fixes that aren’t narrated.

Ultimately, this also shows how powerful and underrated plain text can be as interface. It’s a bit like designing straight in CSS, operating at the weird intersection of motor memory, creativity, and abstraction. (Is there a CSS editor that feels more like this?)

On top of all of this, the act of building the track this way is also how the finished track would sound like. Amazing stuff.

Remember all these jokes that went like this?

[God looking at a pug dog for the first time] What the hell did you humans do with my bad ass wolf I gave you?

Imagine sitting the creators of the typewriter in front of YouTube and having them watch this video.

I’d guess a lot of people know that the original 1980 Pac-Man ends accidentally with an iconic, glitchy, and impassable “kill screen.” Many people will also nod with recognition at hearing the kill screen is level 256, a number that immediately gives some ideas on what might have happened.

But this fun 11-minute video from 2017 by Retro Game Mechanics Explained doesn’t stop there. It shows, step by step, exactly what is going on when you reach level 256, and how each one of the glitchy things appear on the screen.

It’s a little mesmerizing, like watching a building demolition in slow motion.

I was reminded of and rewatched this 43-minute 2016 talk by David Jonathan Ross with great interest:

Ross designed Input, a coding font superfamily which was very inspiring to me in the day, and taught me that coding fonts could be a place of surprising creativity and innovation.

First of all, Input has four width options: from regular through Narrow to Condensed to Compressed – this not only allows to avoid the “blocky/​squareish” nature of many coding fonts, but also, pragmatically, to squeeze in more stuff on mobile screens.

Secondly, since a lot of coding environments didn’t (and maybe still don’t) allow for fine-tuned typography settings, you can bake them into a font upon download – choose a different default line height to be there in the font itself, or have your favorite style of zero just hanging there in the default slot.

Thirdly, serif versions of Input coexist with sans serif, and so does italic, and you can mix them together.

But most important thing comes at the end: you can imagine coding in non-monospaced fonts! What seemed like blasphemy before made so much sense once I put it to use – I still code in Input Sans Narrow (non monospaced) to this day:

Of course, since the release of Input in 2014 a few other coding fonts did interesting creative things in this (mono)space. But to me this will always be the original that opened my eyes to what’s possible, and the talk captures so well a lot of deep thinking that went into the font. To quote Ross:

Type design is design and design is about solving problems.

A good 22-minute video from XDA about the debacle that was Windows Vista and the corrective measure that followed, Windows 7:

It taught me many things and it clarified that things were more complicated than they seemed. Windows Vista (widely seen as failure) perhaps wasn’t so bad, and 7 (quoted by many as the best Windows ever) was not that far away from Vista, down to its internal version number being 6.1 to Vista’s 6.0.

It’s also interesting to reflect on this today, when macOS is having its own Vista moment.

There is also a follow-up video on Windows 8, the possibly most consequential Windows release of that era, with product decisions that reverberate still today.

Main takeaway: An entire book could be written and a lifetime of lessons learned from Microsoft’s “.1” releases.

I mentioned speedrunning before in the context of mastery, but there is the other side of speedrunning that’s equally interesting: that utilizing bugs (or, glitches) to get the fastest possible time.

This 17-minute video by Msushi covers “one of the most loved and broken glitches in Portal 2” and the strange relationship the community has in following a bug to its conclusion – which, in this case, is not fixing it, but creatively using it to shave of speedrunning time. (There is an element of mastery there too, with spawning and despawning, but I don’t want to spoil the surprise.)

Perhaps the only ever musical that’s about a buggy piece of software. From the inimitable Cabel Sasser, this 2006 video about Saints Row, with three songs and a goddamn reprise at the end.

It’s very good.

my car door’s freaking out
it seems to be forever in the concrete barricade
I wonder how I’m ever gonna drive away
this really is isn’t my day
the sparks are flying
people dying
metal frying
and I wonder if there’s more to life
or if I’ll find that this is really it
this game is a piece of work

A fun and short video from Juniper Dev about how Undertale is a fantastic game despite being fantastically poorly written:

When you make dialogue in a video game you have a distinct file that has all the possible text that can pop up in your game. This is usually a CSV file, or a JSON, and you can think of it as basically a database for text. So then at different parts in your code, you extract specific parts of this file, and that’ll depend on what character you’re talking to, if you have a certain item, whatever, and that’s one of the most efficient and common ways to do it.

But the way that Undertale handles dialogue is much worse. All of the dialogue in the entire game, every text box that pops up, is handled in one massive if statement. […] case 737 out of what must have been at least 1,000 lines.

This reminded me a little of my first week with my personal computer, when I didn’t yet know you can write IF X <> 3 THEN, so I spent half a day writing statements like IF X = 1 OR X = 2 OR X = 4 OR X = 5…

Vibe coding was there long before AI.

I gave a talk about the craft of pixel fonts at Config last year, and this fresh YouTube video by Noodle seems to be a great and quirky companion to the whole issue of “how did pixels look on old CRTs,” including many examples from modern games.

Fascinating quick walkthrough of Strudel on TikTok from DJ_Dave (sound on!). Sometimes you see an interface and you immediately just sense how efficient and fun and powerful it is, without ever touching it.

Very bretvictorian in a way. Also related: a recent video from Benn Jordan walking through obscure music software used by Aphex Twin.