How can we improve #LinuxUsability on the desktop? If you are coming from part 1, part 2 ,part 3, part 4, and part 5 to this installment of this series and by now think that UX is all about sugar superficial eye candy — fear not: in this installment we will have some deep looks under the hood of the Linux desktop.
Most people make the mistake of thinking design is what it looks like. People think it’s this veneer — that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.
Let’s dive right in.
Drag and drop
Early Macintosh
On the early Macintosh, each application consisted of a single file. Here is a screenshot of an early development version of the original Macintosh System Software from the early 80s:
Note that “Mac Stuff” is the content of a bootable floppy disk that contains the operating system (called “SYSTEM”), the graphical file manager (called “FINDER”), an application (called “MacPaint”), and a couple of documents.
To “install” an application, you simply copied its file to another floppy disk — done! (There were no hard disks in Macintoshes at that time.)
From thereon, it only got more complicated all the time — to the present day. Let’s strive to get this simplicity back!
NeXTSTEP and Mac OS X
In NeXTSTEP, the predecessor of Mac OS X as well as today’s macOS and iOS, applications were contained in directories that ended in .app — the file manager would treat those as monolithic objects even though in reality they contained all the files that make up the application. This allowed for easy drag-and-drop of applications:
When NeXTSTEP morphed into Mac OS X, so did this convenient drag-of-drop way of “installing” applications. You download a disk image and drag the contained application (which is, in reality, you guessed it, a gedit.app bundle) to the “Applications” folder:
Note that this is on macOS — but with real GNOME on Linux… it is not as easy, by far!
The Linux desktop today
Take GNU Emacs, for example. On its homepage, you find download links to binaries for Windows and macOS. Yet Linux users are left with source code for which they need to download and install a compiler, configure and compile the source code.
Especially with anything that has “GNU” in its name, “we only produce source code, we do not produce binaries nor support end users” is a frequent sentiment — but a dangerous one. In fact, some of the best application projects that produce the most usable software are the ones that interact with their “Average Joe” end users on a daily basis.
Oh, and it’s not just GNU Emacs, an application aimed at developers. Take the GIMP, a popular application for creative artists:
TL;DR:
If you are running Linux, “go compile it yourself” or “get it from your distribution”. If you are running macOS, good luck. If you are running Windows, then download the EXE right here.
This is a pattern!
To a developer, binaries without source code are useless (this is the point that Richard Stallman makes). Yet equally, to the user, source code without binaries is useless (this is the claim I make).
“Get it from your distribution or compile it yourself” it the common answer in the Linux world, but it is an entirely unsatisfactory answer because:
- The distribution usually has an outdated version (especially true for Enterprise-grade and Long Term Stable distributions), and
- “Average Joe” does not know how to, nor should have to know, what a compiler is, how to install the required build-time dependencies, and compile a complex piece of software such as GIMP
Luckily, there are some application authors who care about their users’ experience, like Krita, a professional free and open source painting program made by artists that want to see affordable art tools for everyone:
How do they do it? Surprisingly similar to the simple drag-and-drop application “installation” on the Mac in 1984: You just download one single file from the Krita download page, give it the execute permission, and run it.
Think of an AppImage as the Linux counterpart of an EXE for Windows and a DMG for macOS — but better.
The story doesn’t end here. What if a new version comes around that an artist might want to test, without abandoning the old “workhorse” version (which he is depending on daily for his creative work) entirely?
Krita puts out pre-release versions frequently to get feedback from actual users rather than from developers. Since they are using AppImages, Linux users can try out the new versions without affecting the pre-existing ones.
Side note: Virtually all of the applications I use (from web browser over graphics applications to 3D printing tools) are cross-platform applications, available for Windows, macOS, and Linux. So why do people still waste their time writing applications that run only on Linux, or, worse, only on one distribution?
Additional side note: None of the applications I use is available in the most recent version in my distribution (which happens to be Long Term Stable). Luckily, they all provide AppImages (from web browsers over graphics applications to 3D printing tools). (You are invited to check out the links in the previous sentence.)
Application authors should aim for cross-platform presence, and provide officially-supported binary versions for Linux just like they do for Windows and macOS. They should not delegate the task of shipping (and supporting!) software to others. Application authors should target the oldest still-supported Long Term Stable and Enterprise distributions as targets to run their latest applications on. To achieve this, application authors can use tools like AppImageKit and linuxdeployqt (full disclosure: of which the author is the lead developer).
Handling known files gracefully
This is what happens if you double-click a Linux application that doesn’t have the “executable” bit set:
Wouldn’t it be cool if your desktop would tell you that the executable bit needs to be set, and offer to do it for you?
Originally I thought this was just an oversight and could be fixed quickly. But apparently it’s deliberate — looks like not everyone in the Desktop Linux world wants to make things as easy as possible.
According to someone who spoke to some GNOME developers including Red Hat employee Carlos Soriano,
It is highly likely that quite soon, Nautilus will no longer have the the ability to launch programs by double-clicking on them, even if they DO have execute permission. This means the question of prompting for execute permission is moot, because the program won’t run anyway.
While I can understand that one might want to “move away from allowing untrusted executables to run outside of a sandboxed environment”, the solution for that should be to simply run them inside a sandboxed environment or ask the user what should happen or check the keychain for trusted signatures or whatever, but the possibly worst cause of action would be to remove the ability to execute programs by double-clicking them.
In my opinion, launching applications with minimal fuss is the task of the operating system. Telling the user that “There is no application installed for executable files” is just the worst UX imaginable. There is no excuse for it. But hey — maybe this is all a misunderstanding and the GNOME team is up to something really user friendly in reality.
Linux desktops should handle common file formats more gracefully, e.g., ELF executables downloaded from the Internet that are missing the executable bit.
File associations
On the Mac, Launch Services holds information about file types and the applications that should be used to open them in a database stored at
/private/var/folders/**/**/-Caches-/com.apple.LaunchServices-*.csstoreBut as a user you are never going to see these commands on a Mac since things “just work” with drag-and-drop. Whereas they don’t on the Linux desktop, where you have to wrestle with text files that need to be installed in addition to the application, entirely destroying the drag-and-drop paradigm for dealing with applications. The Linux way of doing things still comes from a time where systems were managed by an administrator who used package manager tools, and hasn’t moved a bit ever since.
Check how far advanced NeXT was in 1989:
In case you have missed it: Please read the text about “The Apps Directory” in the screenshot above. It’s way more advanced than what our Linux desktops have today, almost 30 years later! (With appimaged we are now bringing something similar to the Linux world, but it’s a far cry from being deeply integrated into every Linux desktop, and it is still wrestling with the same old static text files that current Linux desktops need to live with.)
On the Linux desktop, systemd or something like it should be extended to manage a database of file associations, mime types, icons and the like , and update it dynamically as applications come and go, so that we don’t have to deal with text files manually anymore. And please, make it a real XDG standard — not this Red Hat vs. Canonical, GNOME vs. KDE, Gtk+ vs. Qt thing all over again.
The filesystem
Cryptic shorthand directories
With any modern operating system having a number of files in the hundreds of thousands, if not millions, right out of the box, we need a way to understand this amount of stuff and make it manageable for humans.
Yet on Linux, we are holding on to a filesystem hierarchy standard that has been designed for everything but being human-friendly. It starts with the fact that the hard disk is cluttered with lots of directories right from the start that make the computer feel like being busy with its own complex stuff rather than being “just there” for the user. Names like /usr which 99% of my non-geek friends think stands for “user” and /etc which sounds like “miscellaneous additional stuff” make extra sure to scare away mere mortals. (Unix System Resources? Et Cetera? Edit To Configure?)
I have to admit that Windows got this one right early by having one C:\\Windows directory that makes it clear that all Windows stuff is in there. Why cant we have /Linux or /System that encapsulates everything but the users’ own files?
Why are we doing it this way? Because we’ve always done it this way. By now it seems to have emerged into sort of a sacred religion. According to Wikipedia, the Fileystem Hierarchy Standard has its roots in
the hier(7) description of file system layout, which has existed since the release of Version 7 Unix (in 1979)
No one thought of mobile phones or even notebooks when this stuff was invented in the seventies. This was designed when there were still dedicated system administrators for all systems.
Yet why can’t we seem to move on?
When NeXT released NeXTSTEP in 1989 they inherited parts of the Unix filesystem hierarchy, but they decided to hide it from view in the Directory Browser (precursor to the Finder):
This hadn’t been the case in NeXTSTEP 0.8:
Even Apple missed the opportunity, even though when they created Mac OS X using parts of the FreeBSD userland, they must have been well aware of the UX disaster the Unix filesystem hierarchy is. What did they do about it?
As Apple alum Wilfredo Sanchez explained at the USENIX 2000 conference:
By BSD conventions, which are as reasonable as any Unix conventions, files are located according to function; you might put the program in
/usr/bin, the icons in/usr/share/photoshop, the plug-ins in/usr/libexec, and so on. While it has certain advantages, the problem with this approach is that files are scattered around the disk, making it somewhat difficult to install and uninstall software. This is addressable by using a package installer scheme with receipts and so on, but that is easily broken if the user uses different installers or bypasses the installer by unrolling a tar archive.
So you would think they’d have fixed it. Nah: They decided to leave the mess as-is and simply hide it from the users’ view by making the Unix directories invisible. Maybe they were in a rush getting Mac OS X out. Hiding complexity can, in some cases, be better than exposing it, but removing complexity is still way better. And sometimes it needs big moves.
Enter GoboLinux:
GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux you don’t need a package database because
the filesystem is the database: each program resides in its own directory,
such as /Programs/Xorg-Lib/7.7 and /Programs/GCC/6.2.0.
Source: GoboLinux homepage
This is much more like my — and your, I bet — brain works. Yet I find it surprising that this concept has largely went unnoticed.
We should agree on a filesystem hierarchy that humans can understand intuitively. GoboLinux is leading here.
The /usr merge that did not really happen
Then there is the duplication between /usr/{bin,lib} and /{bin,lib} which, in times of initramfs, has no technical reason to exist anymore. Why are we still using this, despite efforts by Harald Hoyer and Kay Sievers to do away with it?
We should just finally get it done. Fedora is leading here.
Icons
Why on earth do Linux binary files still have no icon resources? It’s not that no one would ever have had the idea…
Files should have icons. The icons should be baked into the files themselves rather than having to rely on other files.
Keyboard
On the Mac, in order to enter ``` you press Shift-` three times. On Linux, six times. Unless you switch your keyboard settings to “no dead keys”. In which case you can’t enter é anymore. Which totally works on the Mac. Why is there a “nodeadkeys” option in the first place?
For the extra adventurous, try “Sun dead keys” and “dead grave acute”. What the hell?!? “The rest of us” don’t understand this gibberish. “Mere mortals” just want it to work.
Why can’t thist just work, without requiring the user to choose between pest and cholera (like on the Mac)?
Is the Linux desktop doomed to become ever more complex?
Hiding away complexity and sugar coating it (yes, I am looking at you, GNOME Software) is not the solution in my opinion. Making things manageable by humans, in my opinion, is.
How can we bring that 1984-ish Mac simplicity back to modern Linux desktops?
(EDIT January 2019:) Seemingly not everyone agrees with my points here and with #LinuxUsability tweets, which is fine, but they apparently also think I am a troll:
probono is the founder and lead developer of the AppImage project. NeXTSTEP screenshots were taken on a machine running a Linux Live ISO using the Previous NeXTSTEP emulator AppImage. Krita AppImage for cats by David Revoy, used with the artist’s permission.
