Competitive & collaborative interfaces

The sad part about the professional UIs of today is the illusion of simplicity.

If one would identify important differences between Unix Open Source applications and other applications one would speak about philosophical differences and differences of aims.

Since text wisely, in the Unix philosophy, is considered to be a universal interface, the input and output of an application should be text. This means that input-output can be piped to other applications. Since the aim of one single application is to do one thing and do it well, a single application could be considered dumb. Smartness rise from the compositions of different applications using pipes.

What's not as often emphasized (I've not seen this argument but presumably it's out there) is the larger take on the environment.

As one understands, Unix tools are by nature collaborative. This is an important, under-stressed difference to other environments and philosophies, closed source, business as well as open-source applications. An application such as Atom or VS Code is meant to be used in singularity; they contain no or few open interfaces to other, 'external' applications. And in their core, they are not build to be collaborative — by nature such applications are competitive.

Unix applications are hackable by default, and connecting applications by piping is an everyday practice. But it's also something you do, when making configurations. The other day I decided to use X-Monad on my Desktop and wanted to configure, so I could change the keyboard layout from English to Swedish (and back). I made a simple Bash script to resolve this,

#!/usr/bin/env bash

current=$(setxkbmap -query | awk '$0 ~ /layout/ {print $2}')

if [[ "$current" == "us" ]]; then
  echo "Switching keyboard layout to SE"
  setxkbmap se -option caps:escape
  echo "Switching keyboard layout to US"
  setxkbmap us -option caps:escape

and spawned a binding in the xmonad config.

Taking advantage of the Unix environment is simple. In this example, I combined a shell script using the applications setxkbmap and awk and created a binding to this script in the xmonad configuration. In the end, five very different applications collaborated with full openness, allowing me to customize things according to my preferences.

New tools should follow these simple philosophical principles, and if so, they can without issues connect to old programs (programs working just fine since they were made for tasks still relevant and were created to solve specific tasks).

The collaborative nature of Unix tools provides an accumulative effect.

Against Unix philosophy, we have mainstream applications in which the quality of UX is assessed by how easy an application is to use for the first time, not how easy it is to use to solve real problems under the presumption that you have to learn the application.

The openness of Unix interfaces stands against closed, mainstream applications. Just as one should think about the stuff, s/he buys and prefer qualitative things (even if they sometimes in the short run are more expensive), we should with greater strength criticize the ecology of modern applications.

It may sound like this is a political critique, but it's not. It would be possible to make money and do business even if an application was not closed and locked in; having no meaningful contact with the rest of the environment. It would still be possible to make money from applications that have interfaces open to other applications. I think this could give rise to a more entrepreneurial spirit, more creativity, a rebirth of the philosophy of applications.

With a smaller scope, smaller groups of collaborators (within a business or in some sort of open-source initiative) could make contributions. It would mean more applications, but also more limited applications. A collaborative spirit would most likely yield more powerful end-users.

People phobic of the text interfaces of Unix could perhaps invent good GUI equivalents (as long as the interfaces, in the end, could be translated to 'text'); why not? We don't have today but it would in theory be possible.

This collaborative approach of Unix applications seems to have been evolutionary successful, since Unix tools, unlike 'modern' mainstream applications are not replaced every fifth year by a new competitive over-lord.