If the contents in the sections here comes off as a bit dense and hard to ingest, fret not! They are more teasers or appetisers, the full course meal will have better pacing and technical depth.
Indeed all the points are quite dense and imperscrutable.
But this point caught my attention:
The ‘professional’ is acknowledging that there is a large number (millions) of key individuals in a wide gamut of professions that are [currently] wasting much of their time and talents thanks to misguided attempts at software ergonomics […]
This is more or less how I feel when I use UIs based on GNOME 3/GTK 3.
Right now I’m using a desktop computer (not even a laptop, a proper desktop computer) with a hi-res widescreen and yet the interface is presented to me as if I were on a tablet. For example my mouse has to carefully move over an oversized title bar to click on a button instead of being able to swiftly smash my cursor against the top edge of the screen and click on a menu. Yes, if I had a touchscreen and that touchscreen were few centimeters away from my fingers, that huge-button-in-title would probably be OK. But I am not. I am at my desktop and my mouse is about one meter away from my screen.
Now, the key questions are: How many GNOME users in 2020 use GNOME via a tablet and benefit from this design? How many users interact with the system via a desktop PC or a laptop? How does the benefits to the tablet users compare to the costs that these design choices bring to the desktop users? Wouldn’t these two kinds of fruition be better served by two separate UIs backed by the same core logic?
(These are not rhetorical questions, but sincere requests for data-driven UI design.)
How many GNOME users in 2020 use GNOME via a tablet and benefit from this design?
Agreed. Tablets, phones, and desktop are very different form factors with very different ways of using them. Trying to unify this under one user interface concept –even partially– has failed (Windows 8/Windows Phone. IIRC, KDE tried something like this too). Contrary, macOS and iOS applications follow very different interface concepts. And Apple’s success shows that they were on the right side of history here.
I’m using GNOME as daily driver coming from all iOS and Mac. It sometimes hurts a lot.
Indeed all the points are quite dense and imperscrutable.
It’s a damned if you do, damned if you don’t situation. Putting out individual posts without an overview and the ability to forward-reference would not be much better. It is already well in TL;DR and about half of it was cut.
How many users interact with the system via a desktop PC or a laptop? How does the benefits to the tablet users compare to the costs that these design choices bring to the desktop users? Wouldn’t these two kinds of fruition be better served by two separate UIs backed by the same core logic?
You can do both. How about, for instance, having the mechanism to ask for alternate views of an application. One that is friendlier to touch, or for screen readers, or for debugging? In the video in leveraging the display server to improve debugging, I show one way to do that.
For an example on more dynamic options over a single UI: I have an unhealthy thing for input devices. This photo is from one of my setups in the lab. There’s an eye tracker, stream-deck, 3d-mouse, rotary dial, touch screens, screenpad, input stylus. All of them in use, mostly for command-line / IDE stuff.
The WM on all of those machines, Durden, is built as a virtual filesystem.
echo 'hi' > /windows/all/input/keyboard/type
Would write that into well, all windows. Last I counted there’s over 600 such paths at roughly that level of abstraction. Sets of such paths can be tied to certain events, such as a device entering or leaving idle state. When I touch the touchscreen with my finger, something like this is run:
Decorations appear and are resized to match text at 18pt, which was picked based on my finger accuracy on the display in question. The buttons on the title-bars are set to be dynamically populated by bindings announced by the clients, mixed with my custom defined ones for the touch state specifically. In other states they might be mixed with my ‘todo’ list on the stream deck. The clients aren’t written to take any of these devices into consideration.
Very, very good. Much of this resonates with my desires for modern computing, and my disappointment with “desktops” as they are today.
Where I do find a little solace is inside Acme, which has been my daily driver for programming work for ~8 years now. Acme deals only in text, but it has essential properties that very few other environments have. I can identify many of these properties in the principles you have enunciated.
In reference to #1 - Professionals First: Acme is a programmer’s enviroment, through and through. Most UNIX tools (not the ones with the insufferable terminal spinners, though, like npm!) find themselves right at home inside Acme, and Acme integrates them in a lovely way. Acme is an Integrating Development Environment, as such.
In reference to #2 - Diversify Experience: Acme has “client side links” in the sense that the user writes so-called plumbing rules, and if it matches a plumbing rule, every bit of text in a window can become a “link” when you right click swipe it. There are a few default rules, such as rules for file paths, but you can extend them to your liking.
In reference to #11 - Defer Composition: “Popups” that tools create are real windows inside acme. If you execute a command from inside Acme, its output is directed to a new window, which you can manipulate like any other window. This enables the construction of context-aware “menus” that are, after all, only regular Acme windows.
In reference to #12 - Simplicity is Systemic: Acme exposes all of its internal state as a file system in userspace. As such, acme can be extended using programs written in any language, not just the tired old “scripting language” of choice, such as VimScript, elisp, Lua, JavaScript, etc. I have extensions to acme written in shell script, C, Python, and Go.
Much more can be said, but I will stop here, since these things are better experienced than described. In case you are unaware of Plan9 and/or Acme, I hope this post contains information that might interest you. If you are already aware of Plan9 and/or Acme, then I hope this post contains encouragement and validation (if you need it at all, at this point). Arcan seems like a very ambitious project. Unlike Acme, which restricts itself only to text (and gains tremendous power in the process), it seems like it is aiming to invent a whole new multimedia userland. I hope it succeeds.
I would be surprised if the author had no prior knowledge about plan9.
I find acme both liberating and infuriating: while the features you mention are indeed great, I find it difficult to live with the keyboard navigation limitations. That and the weird compose key behaviour :) Acme is pretty easy to patch and extend however, so I added what I missed the most, but still use vim as my daily driver.
I have had a look at different interesting projects, inspired by acme:
https://github.com/karahobny/acme2k seems dead and featured some hacks on top of the legacy codebase to support colorschemes and keyboard navigation. There are quite a lot of these projects on github, providing such sets of patches and utils.
I’ve looked a fair bit at (8.5)/plan9/9p/rio/acme/plumber and most of the stuff Rob Pike has published on the matter - it is something of a recurring theme in the IRC channel. Going back a few years, you have a blogpost about an experiment preceding this article 2017: One night in Rio: Vacation photos from Plan9 looking at the window management scheme specifically.
There is something in the pipeline nearly ready to show off that, to me at least, serves as the missing link between wm/cli/ide that has some acmeisms, though I think that much of acme can be reproduced in durden, should the editor part (neovim ui driver using our curses-like api) improve a wee bit.
What I am curious about, should you have the time and its not too much of an inconvenience, video documentation of acme workflows are quite few and far between (livestream, silent video, heck animated gif). I think there’s quite a few that would be interested in seeing some patterns of established / daily driver use.
Russ Cox’ tour of Acme is pretty good video documentation on what daily use of acme looks like. I’m currently on vacation, and I may record a session or a stream of my own when I return. Unlike that video, in my case, there are three columns. The right column always contains a shell session and the guide file open for the project I’m working on. The guide file is a list of common commands for a project. The left column contains mostly read-only code and documentation, while the middle column is read-write. Russ’ video doesn’t show this, but I also make extensive use of the Dump command to save state and switch between projects.
Delayed composition is exactly correct, and I habe long be saddened by tabbed interfaces. However, getting the composition tools right is also quite tricky.
The second one is at the other extreme of the complexity spectrum, and that is the relatively modest pipes and filters text oriented procesing tools like ‘awk’ and ‘grep’ as well as some of the more interactive textural user interfaces (TUIs) through its subset of command-line interfaces (CLIs). These are much limited by their form of legacy, reasoning in terms of serial lines and character graphics terminals.
I should tell this person about how easy it is to combine command line programs with GUIs, but it would likely break their whole worldview.
The previous barriers to simply booting into the user interface immediately are all but gone, and forcing the user to stare into a splash screen or a stream of fast scrolling text by the init system mutated into service manager, when the real interface could have been there from the start is quite simply an act of negligence.
Spoken like someone who’s never had to diagnose anything.
One example of how easy it is is Zenity: Make windows and dialog boxes and so on from the command line directly. You can also use it from Python as a library, which isn’t as compelling since Python has real GUI bindings, but it can be simpler if you just want a few dialogs to get and display info.
Another example is Acme which takes it in the opposite direction: Instead of having the shell be the base and creating GUI elements as needed, make the GUI window the base and create command lines as needed, using mouse commands. More information.
Indeed all the points are quite dense and imperscrutable.
But this point caught my attention:
This is more or less how I feel when I use UIs based on GNOME 3/GTK 3.
Right now I’m using a desktop computer (not even a laptop, a proper desktop computer) with a hi-res widescreen and yet the interface is presented to me as if I were on a tablet. For example my mouse has to carefully move over an oversized title bar to click on a button instead of being able to swiftly smash my cursor against the top edge of the screen and click on a menu. Yes, if I had a touchscreen and that touchscreen were few centimeters away from my fingers, that huge-button-in-title would probably be OK. But I am not. I am at my desktop and my mouse is about one meter away from my screen.
Now, the key questions are: How many GNOME users in 2020 use GNOME via a tablet and benefit from this design? How many users interact with the system via a desktop PC or a laptop? How does the benefits to the tablet users compare to the costs that these design choices bring to the desktop users? Wouldn’t these two kinds of fruition be better served by two separate UIs backed by the same core logic?
(These are not rhetorical questions, but sincere requests for data-driven UI design.)
Agreed. Tablets, phones, and desktop are very different form factors with very different ways of using them. Trying to unify this under one user interface concept –even partially– has failed (Windows 8/Windows Phone. IIRC, KDE tried something like this too). Contrary, macOS and iOS applications follow very different interface concepts. And Apple’s success shows that they were on the right side of history here.
I’m using GNOME as daily driver coming from all iOS and Mac. It sometimes hurts a lot.
It’s a damned if you do, damned if you don’t situation. Putting out individual posts without an overview and the ability to forward-reference would not be much better. It is already well in TL;DR and about half of it was cut.
You can do both. How about, for instance, having the mechanism to ask for alternate views of an application. One that is friendlier to touch, or for screen readers, or for debugging? In the video in leveraging the display server to improve debugging, I show one way to do that.
For an example on more dynamic options over a single UI: I have an unhealthy thing for input devices. This photo is from one of my setups in the lab. There’s an eye tracker, stream-deck, 3d-mouse, rotary dial, touch screens, screenpad, input stylus. All of them in use, mostly for command-line / IDE stuff.
The WM on all of those machines, Durden, is built as a virtual filesystem.
Would write that into well, all windows. Last I counted there’s over 600 such paths at roughly that level of abstraction. Sets of such paths can be tied to certain events, such as a device entering or leaving idle state. When I touch the touchscreen with my finger, something like this is run:
Decorations appear and are resized to match text at 18pt, which was picked based on my finger accuracy on the display in question. The buttons on the title-bars are set to be dynamically populated by bindings announced by the clients, mixed with my custom defined ones for the touch state specifically. In other states they might be mixed with my ‘todo’ list on the stream deck. The clients aren’t written to take any of these devices into consideration.
Very, very good. Much of this resonates with my desires for modern computing, and my disappointment with “desktops” as they are today.
Where I do find a little solace is inside Acme, which has been my daily driver for programming work for ~8 years now. Acme deals only in text, but it has essential properties that very few other environments have. I can identify many of these properties in the principles you have enunciated.
Much more can be said, but I will stop here, since these things are better experienced than described. In case you are unaware of Plan9 and/or Acme, I hope this post contains information that might interest you. If you are already aware of Plan9 and/or Acme, then I hope this post contains encouragement and validation (if you need it at all, at this point). Arcan seems like a very ambitious project. Unlike Acme, which restricts itself only to text (and gains tremendous power in the process), it seems like it is aiming to invent a whole new multimedia userland. I hope it succeeds.
I would be surprised if the author had no prior knowledge about plan9.
I find acme both liberating and infuriating: while the features you mention are indeed great, I find it difficult to live with the keyboard navigation limitations. That and the weird compose key behaviour :) Acme is pretty easy to patch and extend however, so I added what I missed the most, but still use vim as my daily driver.
I have had a look at different interesting projects, inspired by acme:
I’ve looked a fair bit at (8.5)/plan9/9p/rio/acme/plumber and most of the stuff Rob Pike has published on the matter - it is something of a recurring theme in the IRC channel. Going back a few years, you have a blogpost about an experiment preceding this article 2017: One night in Rio: Vacation photos from Plan9 looking at the window management scheme specifically.
There is something in the pipeline nearly ready to show off that, to me at least, serves as the missing link between wm/cli/ide that has some acmeisms, though I think that much of acme can be reproduced in durden, should the editor part (neovim ui driver using our curses-like api) improve a wee bit.
What I am curious about, should you have the time and its not too much of an inconvenience, video documentation of acme workflows are quite few and far between (livestream, silent video, heck animated gif). I think there’s quite a few that would be interested in seeing some patterns of established / daily driver use.
Russ Cox’ tour of Acme is pretty good video documentation on what daily use of acme looks like. I’m currently on vacation, and I may record a session or a stream of my own when I return. Unlike that video, in my case, there are three columns. The right column always contains a shell session and the guide file open for the project I’m working on. The guide file is a list of common commands for a project. The left column contains mostly read-only code and documentation, while the middle column is read-write. Russ’ video doesn’t show this, but I also make extensive use of the Dump command to save state and switch between projects.
How are you running Acme these days?
My work is Linux-based, so I use Acme from plan9port on Debian.
Delayed composition is exactly correct, and I habe long be saddened by tabbed interfaces. However, getting the composition tools right is also quite tricky.
I should tell this person about how easy it is to combine command line programs with GUIs, but it would likely break their whole worldview.
Spoken like someone who’s never had to diagnose anything.
Well, how easy is it?
One example of how easy it is is Zenity: Make windows and dialog boxes and so on from the command line directly. You can also use it from Python as a library, which isn’t as compelling since Python has real GUI bindings, but it can be simpler if you just want a few dialogs to get and display info.
Another example is Acme which takes it in the opposite direction: Instead of having the shell be the base and creating GUI elements as needed, make the GUI window the base and create command lines as needed, using mouse commands. More information.