Alcides Fonseca

We’ve already seen how Eurostile Bold Extended is spectacularly effective at establishing a movie’s timeframe. But if Eurostile isn’t enough, there’s more you can do to clarify your movie’s timeframe. I’d like to introduce you to six easy rules that are pretty much guaranteed to position your text firmly in the FUTURE.

— Dave Addey, in HOW TO MAKE YOUR TEXT LOOK FUTURISTIC

Wonderful description of how to take your typography 50 years into the future. But maybe it only works for 80is and 90ies kids like me.

Terminal User Interfaces (TUIs) are making a comeback. DHH’s Omarchy is made of three types of user interfaces: TUIs, for immediate feedback and bonus geek points, webapps because 37signals (his company) sells SAAS web applications and the unavoidable gnome-style native applications that really do not fit well in the style of the distro.

The same pattern occurred around 10 years ago in code editors. We came from the native editors of BBEdit, Textmate (also promoted by DHH), Notedpad++ and Sublime to Electro-powered apps like Atom, VSCode and all its forks. The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen.

Windows

The lesson is clear: Native applications are losing. Windows is doing the GUI library standard joke. Because one API does not have success, they make up another one, just for that one to fail within the sea of alternatives that exist.

MFC (1992) wrapped Win32 in C++. If Win32 was inelegant, MFC was Win32 wearing a tuxedo made of other tuxedos. Then came OLE. COM. ActiveX. None of these were really GUI frameworks – they were component architectures – but they infected every corner of Windows development and introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.

— Jeffrey Snover, in Microsoft hasn’t had a coherent GUI strategy since Petzold

Since then, Microsoft has gone through Winforms, WPF, Silverlight, WinUIs, MAUI without success. Many enterprise and personal desktop application still rely on Electron Apps, and the last memory of coherent visual integration of the whole OS I have is of Windows 98 or 2000.

It turns out that it’s a lot of work to recreate one’s OS and UI APIs every few years. Coupled with the intermittent attempts at sandboxing and deprecating “too powerful” functionality, the result is that each new layer has gaps, where you can’t do certain things which were possible in the previous framework.

— Domenic Denicola, in Windows Native App Development Is a Mess

Linux

The UI inconsistency in Linux was created by design. Different teams wanted different outcomes and they had the freedom to do it. GTK and Qt became the two reigning frameworks. While Qt is most known for it, both aimed to support cross-platform native development (once upon a time, I successfully compiled gedit on Windows, learning a lot about C compilation, make files and environment variables in the process) but are only widely used in Linux land. Luckily, applications made in the different toolkits can look okay-ish next to each other, something that the different frameworks on Windows fail to achieve. How many engineer-hours does it take to redo the windows Control Panel?

Given the difficulty in testing the million different combinations of distros, desktop environments and hardware in general, most companies do not bother with a native Linux application — they either address it using electron (minting the lock-down), or they let the open-source community solve it self (when they have open APIs).

macOS

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface. Fast forward a few decades, and Apple is doing the best worst it can to break all the guidelines and consistency it was known for.

Now, Apple has been ignoring Fitts’ law, making resizing windows near-impossible (even after trying to fix it) and adding icons to every single menu. MacOS is no longer the safe heaven where designers can work peacefully.

Electron

Everyone knows that the user experience of electron apps sucks. The most popular claim is the memory consumption, which to be fair has been decreasing over the last decade, but my main complaint (as I usually drive a 64GB RAM MacBook Pro) is the lack of visual consistency and lack of keyboard-driven workflows. Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all.

Let us take the example of Cursor (but would be true for VSCode as well). If you are in the agent panel, requesting your next feature, can you move to the agent list on the side panel with just the keyboard? Can you archive it? These are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus. And over the last decade, developers have been forgetting to add menus to do the same things that are available in their application (mostly because the application is HTML within its sandbox). For the record, Slack does this better than the others, but it’s not perfect.

Restarting from scratch

Together with Dart, Google wanted to design a new operating system, without all the legacy of Android, for new devices. It wanted a fresh UI toolkit (Flutter UI) but Google gave up on the project before a real product was launched. It’s one of those situations where having a monopoly (or a large enough slice of the market) is required to succeed.

Meanwhile, Zed did the same thing in Rust: they designed their own GPU-renderer library (GPUI) which is cross-platform. Despite the high-speed, it lacks integration with the host OS on itself, requiring the developers to add the right bindings. Personally, I would rather have a slow renderer that integrated with my OS than the extra speed.

TUIs

TUIs are fast, easy to automate (RIP Automator) and work reasonably well in different operating systems. You can even run them remotely without any headache-inducing X forwarding. When the native UI toolkits fail, we go back to basics. Claude and Codex have been very successful on the command-line: you focus on the interaction and forget about the operating system around you. You can even drive code and apps on cloud machines, or remote into your GPU-powered machine from your iPad. TUIs are filling the void left by Apple and Microsoft in the post-apocalyptic world where every application looks different. Which is good if you are doing art (including computer games), but not if your goal is to get out of the way of letting the user do their job.

What’s next

A checkbox is also part of an interface. You’re using it to interact with a system by inputting data. Interfaces are better the less thinking they require: whether the interface is a steering wheel or an online form, if you have to spend any amount of time figuring out how to use it, that’s bad. As you interact with many things, you want homogeneous interfaces that give you consistent experiences. If you learn that Command + C is the keyboard shortcut for copy, you want that to work everywhere. You don’t want to have to remember to use CTRL + Shift + C in certain circumstances or right-click → copy in others, that’d be annoying.

— John Loeber in Bring Back Idiomatic Design

We need to go back to the basics. Every developer should learn the theory of what makes a good User Interface (software or not!), like Nielsen, Norman or Johnson, and stop treating User Design as a soft skill that does not matter in the Software Engineering Curriculum. In any course, if the UI does not make any sense, the project should be failed. And in the HCI course, we should aim for perfect UIs. It takes work, but that work is mostly about understanding what we need. The programming is already being automated.

Operating systems and Toolkits authors should drive this investment. They should focus on making accessible toolkits that developers want to use, and lower the barrier to entry, making those platforms last as long as possible. I do not necessarily argue for cross-platform support, but having one such solution would help reduce the electron and TUI dependency.

How to improve macOS in 5 steps, by Alex Potenza

To be clear: bottom-of-the-barrel Windows laptops, Linux laptops, and Chromebooks can plug into these multi-display docks over one cable. No Mac can, regardless of its price.
Hilariously I have even seen Intel Macs gain MST support once booted into Windows via Boot Camp, which at least suggests software and driver support are and always were a huge part of this story.

1. Add DisplayPort MST support.

Brightness control on non-Apple displays is smaller, but it points in the same direction. A lot of displays support DDC/CI. In plain English, the display already knows how to listen, but macOS behaves as if only Apple’s own displays deserve convenient controls. If a connected display supports standard brightness, the keyboard keys, the menu bar, and Control Center should be able to use it. MonitorControl and BetterDisplay exist because people clearly want this to be native.

2. Add brightness control to non-apple displays. I use both apps (one on my M1 and another on my Intel MacBook pros) for my external LG displays.

What if Apple Intelligence was smart enough to know ‘you’re using these three specific windows from different apps and swapping between them to do this one task’ and intelligently surface those groups of app windows for users. Picture an Apple Intelligence managed better version of Stage Manager where you can easily orchestrate it all from ‘Mission Control 2’. Those are the sorts of features I want from Apple Intelligence.

3. Focus on user tasks, and not application or window-level UI control.

Apple could retire Zoom entirely, make Fill the standard ‘make this window bigger’ action, and have the green button, title bar, and top-edge drag all follow the same model.

4. Bring back old maximize.

udio has gaps too. Per-app volume control should be built into the system, and external audio devices, in particular USB audio interfaces, should be more widely supported from the keyboard and menu bar. SoundSource is useful precisely because it solves both problems at once. The market keeps proving demand for things Apple could and should have built years ago.

5. App-level volume control.

You do the five things, and I won’t consider moving to linux anytime soon. Your move, Apple.

Three weeks before launching its new line of products, the Surface design team took a trip to Pasadena, CA, where they held a 3 day workshop with renowned design school Art Center College of Design.

The group of 11 students chosen for the workshop were the first people outside of Microsoft to see a new accessory the design team has been working on: a music attachment that clicks into a Surface and allows users to easily remix music. They asked the students: what else would you want to attach to a Surface? They code named these attachments blades.