on OS user interfaces

A lot of the time, our preferences for what an OS user interface should look like come down, ultimately, to either nostalgia or past experiences. Someone gets annoyed at a UI change and their instinctive reaction is to assume that whatever “the old way” was, was inherently better.

This especially applies to people who use Linux (or any of the BSDs, but for purposes of this page, I’ll refer to any of the “free desktops” as Linux), since it is rarely ever their first operating system – usually they started off with either Windows or macOS, and picked up habits and assumptions from that.

But, of course, neither Windows, macOS nor any of the Linux desktop environments picked up their design decisions at random – these were motivated by their own reasoning.

macOS was the first OS with a graphical user interface actually aimed at a common user, and so their developers sought to abstract a lot of the actual details away, so they would match the designers’ UI metaphors as closely as possible – which was important, since their target audience were people who have never used a computer before – and, since they were making a new OS from scratch, they could basically make the underlying system adapt to the UI metaphors instead of vice versa.

MS Windows didn’t have that luxury. It was originally created as a GUI that ran on top of DOS and provided its own interface for graphical applications, and, as a result, had to follow a lot of expectations (drive letters, folders, executable files, etc.) that were already in place in DOS, since running DOS apps within Windows, and interacting with files made in DOS, was something that a user was expected to do.

And while they were able to change Windows into a full-fledged OS with a DOS-compatible base in Windows 95, and then a completely reworked OS with DOS emulation with Windows NT, it still used the same underlying file system metaphors as DOS, partly because of compatibility, partly because it was necessary for power users, software developers, system administrators et cetera.

And these days, I feel like the problem now is that UI designers on Windows, macOS and Linux/BSD desktops tend to often copy features without thinking whether or not these make sense in their underlying system.

For example, I remember when it was in vogue to add a macOS-style “global menu” to Windows and GNOME/KDE – but the difference here is that macOS had per-app menus, and (IIRC) could even have running apps with a menu and 0 open windows, whereas Windows and GTK/Qt desktops have per-window menus, so applying macOS’s metaphor didn’t match the way the actual system, or their UI frameworks, in this case, works.

(Early on, #GNOME 3 also had a weird kind of per-app menu for the focused window on the left of the system bar, kinda resembling an extremely simplified global menu, yet each app also had its own menu as well, either in a menu bar or a button, but at least in this case, the developers figured out this was absurd and made it so that menu instead happens when you right-click on the app icon in the dash (the dock/taskbar-like thingy in the activities view).)

I believe that if you want to make a good UI, you should always keep in mind:

1. how abstracted from the actual details you want to make the user experience,
2. which metaphors actually make sense in your environment

Windows 95 was a resounding success (way more than 1.x, 2.x or 3.x ever were), IMO in large part because it mapped a lot of macOS’s metaphors in ways that also made sense with the DOS-like structure of the actual system.

Let’s take launching apps for an example: on old versions of macOS, a launch icon for an application was the application itself. You could copy or move it wherever you wanted on your desktop, and it could be located next to any other files, but in practice, it functioned more like a folder containing the application, its libraries, all of its resources, etc. Apple could do that, because they were literally designing their OS from scratch, and wanted to match the desktop metaphor they were going for as much as possible (after all, a real desktop can contain documents, but also tools).

DOS was not like that. You installed applications into (usually) a separate directory on your floppy or hard disk, then launched it by either typing the full location, or adding the directory into your %PATH%. You could choose the installation destination freely, and often had to make choices based on how many hard drives and partitions you had and how free they were. Earlier versions of DOS had no concept of directories at all, and there are backwards-compatibility fixes for that, too (that’s why there’s a separate “working directory” for every drive letter, you can copy A:hello.txt to C: and if you’re in A:\LETTERS\ and C:\DOCS\TODO\, it will copy A:\LETTERS\hello.txt into C:\DOCS\TODO\hello.txt).

Early versions of Windows relied first on an “MS-DOS Executive”, which was a primitive launcher based on a directory listing, then on a “Program Manager”, which allowed to create launcher icons for individual programs. They were all made with the expectation that an end user would already know their file system hierarchy – since Windows was a product that had to be installed on top of DOS, it would be silly to expect otherwise.

Windows 95, as the first OS that was available as a separate product from DOS, tried presenting the user with a version of the desktop metaphor that was similar enough to macOS’s version (since a new Windows user could be expected to be familiar with macOS), but also backwards compatible with DOS software and expectations of DOS / older Windows version users.

Perhaps one of the most ingenious ways, IMO, was the implementation of “shortcuts” – little files that point to another file or program, can have a custom icon, and are displayed differently from regular files, with a little arrow in the corner and no file extension, even if the user disables hiding file extensions in general.

Now, just like on macOS, your desktop can have both program icons and actual files to work with. And, even though your copy of Microsoft Word would still be a program that’s probably installed in C:\Program Files\Microsoft Office\Office\WINWORD.EXE, you could have a shortcut to it that’s just as movable as an application icon is on macOS. And, if you ever need to see where the actual executable is, you can open the shortcut’s properties and check the location, even open its folder in the Windows Explorer.

Even better, this is an arrangement that still works with programs from the old DOS era that didn’t come with shortcut files. You could always just create a new shortcut to the program you needed, just by knowing its executable path. Microsoft even supplied a set of icons specifically for some of the most common DOS applications at the time. Sure, they were happy to sell Microsoft Excel to people who wanted a spreadsheet, but they also knew that if someone specifically needed, say, Lotus 1-2-3 (why do I even know the name of this program? I never even used it!), there better be a comfortable way to run it too (there’ll be enough time to offer them to switch to Excel later).

You can even drag files onto shortcuts, and that will open them in the appropriate program by supplying the first argument – and that works with Windows-ready software as well as old DOS ones. Bam, now you don’t have to memorize file paths even if you still use the same programs.

And if you need, the entire file system is still available from the Windows Explorer. Some of it may be hidden, but these files are one setting away from being visible, and you can also use that same file attribute on your own files as well.

The Linux desktop also has a concept similar to shortcuts, at least as far as they apply to programs specifically – the .desktop launcher files. These were designed by GNOME and KDE, converged on a single standard that was eventually adopted by freedesktop.org in 2007 as a specification that Linux and *BSD desktops now follow. It has its own differences from the Windows shortcuts or macOS application icons, and these also take into account the differences between the operating systems:

• The application icons are usually referenced by name, not as a specific icon or image file, because a desktop Linux user may be expected to have different icon themes, and an icon designed for a GNOME desktop might have not looked so well among KDE-style icons, and different icon sizes exist (which is not a problem for Windows, since .ico files and .exe resources can contain icons of different size or color depth). It is still possible to assign a .png file as an icon, but the most common way, even for proprietary software, is to install a basic icon set into /usr/share/icons/hicolor/... and then refer to it by name, so that if “Faenza” or “GNOME-Colors” or “Breeze” happens to include its own icon for the same app, that one will be used.

• The display names for each launcher don’t just borrow the file name, but can be localizable strings written in the file’s contents. (AFAIK) It is only in Windows XP that it became possible for different users to run the same OS in different languages, and to do even that, one usually needed to buy the more expensive English version of the OS. The Linux desktops therefore can easily display the same launcher as “Files” for one user, “Dateien” for another and “Файлы” for a third.

• Since apps on Linux desktops tend to be located either according to the FHS or in their own custom directories, typically specified by the package manager and not the end user, and a user’s home directory is typically where their activities are restricted, there is no need to specifically make sure that the user does not accidentally move the executable somewhere else. So the app launchers don’t feature a shortcut arrow in the corner – instead, it is used for symbolic links, which also work kinda like shortcuts in that they point to files and directories based on name, but unlike shortcuts, are an actual feature of the file system, in which applications not specifically expecting to open a symbolic link will just interact with the underlying file by default (whereas Windows could only do that if, say, the file was opened via common dialog box).

And you can tell that the app launcher specification has been a success, because despite the rapid changes in the Linux desktop space, nobody has yet suggested a new replacement for them since 2007. They still work with Flatpak, Snap, immutable distros, NixOS…, even when a lot of the traditional assumptions of a Linux or BSD system get a little bit broken.

So, I guess, what I am trying to say is that designing UI features for Linux desktops should, ideally, always be done with those desktops’ unique features in mind. Simply copying Windows or macOS (or iOS or Android) would result in a substandard design.

This is partly why, even when I disagree with the individual decisions made by the GNOME project, I still tend to respect their vision of what a Linux UI can be. They’re figuring out an interface that can work well on desktops, tablets, even phones, and isn’t as bound to legacy decisions as Microsoft’s or Apple’s desktops have to be. This also comes across, IMO, in individual apps. A GNOME or GNOME-like file manager, or document viewer, or Fediverse client, happens to fit into a non-GNOME environment (like a Sway-based tiled desktop) a lot better than a KDE-like app (by which I mean specifically an app written using KDE libraries and designs, and not just any Qt app, which can have any UI design to it) on a non-Plasma environment.