GUIs Considered Harmful (1992)
porkmail.org
porkmail.org
If you look around, GUIs and CLIs are both around because they are each good at specific kinds of tasks. We use CLIs to remote into servers because it doesn't require much bandwidth and it works with high latency, etc.
The right tool for the right job. I don't understand this mentality that people have that one tool is superior to another in all cases (e.g., linux is always better than Windows, open source is always better than proprietary, etc).
In general this is only the case if the user is browsing and not looking for anything in particular. That is, when the user is trying to learn about the program in general.
If you're trying to find anything in particular, that thing might be hidden in an options window in a submenu of a submenu somewhere. The only effective way to find it is to google for the functionality and to hope that someone else has already asked the same question. This is my experience with Inkscape.
A well written, flat manpage can have much better discoverability than a GUI with poor or hard to search documentation. Bad manpages are of course considered harmful.
Not sure about other platforms, but I sure use that feature a lot in e.g. intellij.
Related, it's sad that not only users - including many developers - can't be bothered to sit down and skim a manual, but we're actually legitimizing this as an industry.
Or, let me rephrase it: bothering to read is a superpower. Having enough patience to skim a man page can be enlightening, and I do actually feel like I gained +2 levels of wizardy by developing the habit of reading Info pages.
But in generally it's only a matter of effort how accessable something is.
JetBrains tools, Netbeans (ctrl- i) and VS Code (ctrl - shift - p) all has this in the main interface I think.
Whereas with unfortunately far too many GUI apps today, discoverability is a trial and error mix of gesturing with various swipes, clicking odd shapes and asking friends how they accessed some random feature.
If we assume a given tool has little or no documentation, a GUI wins out.
Additionally - documentation of gui app needs images which make searching for stuff much harder when you don't know the keywords.
Many people cannot switch from one GUI to another GUI, e.g. from Photoshop to Gimp or from MS Word to LibreOffice, because they learned one GUI and don't want to relearn.
GUI, video, VR are much better to transfer information than text. It's better to see once than to read 1000 times. GUI, video, and VR interfaces are much closer to real-world, so we can reuse our existing skills and be much more effective from start, without additional training. Text interfaces are often require abstract thinking, so left part of brain is working all time, while right part is sitting idle.
But from UX perspective, voice (Alexa) or input line (Google) can be as powerful as GUI. We already know that search engine is much better when user knows what he want but doesn't know where it is. Personal assistant (bot) is better than GUI when it is smart enough, because user can offload work to assistant. It's much easier to enter query or task than to draw it or select from endless options. It's also much easier to automate CLI than GUI.
Also as a counter point switching between something like vim and Emacs is about as difficult as switching between Photoshop and gimp if not moreso.
I find that CLIs are usually a little bit harder to learn, but often so much faster if you've learned them, that all professional developer tools should at least have CLI as a possibility.
Also, help is nice but I often end up having to search up examples to find out when certain options are appropriate. awk is my very least favorite in terms of "ease of use".
Not everything can be done with microsoft home office.
You run: apropos "keyword"
It shows all installed programs that have "keyword" in their manual page.
It shows gui programs as well, but sadly they often don't have a good manual.
Except when they're not. Take Blender for example - the GUI is contextually sensitive in the sense that buttons do different things in different circumstances, but they don't inform you why or what you can do to change their action. Consequently options are greyed out seemingly randomly. You can't discover things because you can't know the way they work consistently.
Good GUIs are discoverable. Bad GUIs actively work against discoverability.
Blender has an almost unbelievable amount of capability and it can give you access to nearly all of it with a few keystrokes. It’s designed so that you can keep your right hand on the mouse and your left hand on the keyboard to do almost everything. It has a fantastic UI that can reconfigure to do modeling or video editing or texture mapping or rigging or animation or a dozen other things. Discoverability is not one of the design goals. Don’t take an overly simplistic view of an incredibly powerful program.
CLI means that you operate the interface via a command line. I guess this is true for Vim if you use the Ex mode exclusively, in which case there is no context sensitive 'q'
But it definitely isn't discoverable, and it's often touted as a good app to learn 3D graphics with or something to use to make a quick 3D sketch. It's neither of those things.
So I'll agree that it's not a good program for a quick sketch - but I think it is a good program to learn 3D graphics. Ultimately, what you learn in a craft is how to train your body and eye to make fine movements and spot fine differences, at a good rate. That's why people who are good at drawing are good at clay sculpture.
The nice thing about Blender is it's really designed to appeal to somebody who knows the program like the back of their hand. You can incrementally improve your process, taking repetitive tasks and working out how to do them more efficiently. Ultimately, it's this approach which will make you a better artist - and the unfortunate truth is, there isn't an easy road to this point - you get there by being frustrated.
I tried to work strictly with the B (3rd) and A (4th) color channels separately in photoshop but I clearly don't understand how its supposed to be done. Blenders UI is a horror show unlike anything in existence. Blender is extremely capable though. No question about that.
That kind of goes together, though. Simple UI is usually a symptom of lack of capabilities of the software at hand. When your software has a lot of power, UI design becomes tricky. Doubly so when, like in case of Blender, you aim for efficiency of usage, which is usually at odds with typical UX guidelines, and instead expects the user to actually learn something.
> open source is always better than proprietary
I don’t think anyone has ever claimed this. But for people ( like me) who care about their freedom, it’s mostly a small sacrifice you can make to retain freedom. I find the latter is more important, not that OSS is _better_.
> I don’t think anyone has ever claimed this.
There was this one guy who maintained Emacs for some time.
Powershell on the side is an object-orientated shell, and makes big efforts to pull everything into it's objectspace so it can use it's introspection-abilities to deliver as much information as possible about a command. Thus it can generate the neccessary informations for autocompletion on the fly.
Powershell is more like IPython (with .NET as backend) then bash.
Is it built into bash, and working for every single script and module by default?
So they have to be created by humans and then installed on the system.
Far from auto-introspection into a standard API.
A decent manual beats a "discoverable" GUI almost always.
Sorry, but nope. You can rant about GUIs all you want, but UX research did yield a lot of actual insights about how people interact with systems and learn usage. From a learning standpoint, RTFM is enormously inefficient and error-prone.
You can learn about usage of an application a lot faster if you can use existing knowledge (e.g., leveraging standard UI widgets or menu items) and if the application gives you feedback loops, so you can evaluate what a command did or will do (ideally before it does anything consequential)
Standard UI widgets and current design conventions aren't always great or even good ways to tackle the problem in terms of productivity and efficient use. For a complex productivity application that I'll use daily for a long time, learning the basics is always a relatively small initial hurdle whether it takes an hour or a week. It's much more important that its application of standard UI widgets doesn't get in the way of productivity later on when I am at a stage of learning where I can perform the basic operations from muscle memory.
For such an application, say a music sequencer, 3D modelling software or CAD software, I'd much rather have a terse UI and a manual in a binder than standard UI widgets that are worse than specialized solutions that take into account every aspect of the problem.
Didn't you also learn about balls by someone giving a 100 page dissertation into spheroids? After all, all the info you needed was in there!
My mom relies on information and actionable instructions being presented in the context which it is used. I once discovered that she didn't know what a button did because there was a delay between pressing that button and the change it made, the delay was enough to break the cause and effect relationship in her mind.
You and I have spent our entire lives training on, memorizing UX metaphors and computer patterns. We go into a problem knowing generally how we want to solve it, so we know what to look for when reading a man page. My mom methodically reads every option in the context menu when she right clicks on a file in an email before choosing save, because nothing is obvious and if she didn't have that she'd be writing down explicit, context sensitive, step-by-step instructions for how to save an attachment (I know because before I taught her to read the menus that's literally what she did)
Hand an average consumer an iPad. Then hand them a laptop with no interface except for a command line.
Watch what happens. We already know exactly what happens. The average consumer absolutely detests the CLI. The iPad GUI is so trivially easy to immediately learn to use that children in third world villages with zero formal education and zero knowledge of modern technology can instantly pick it up and begin using it without training.
It really isn't. I've only handled an iOS device a couple of times and I still have no idea how to switch back to my previous app.
Another e.g. I have lots of scientific colleagues (I don’t think any of our teams programmers) who still don’t know when to single click vs double click, OS vs Browser. All they know and care is that double click works almost everywhere.
Those days never existed. Support stories of exasperated developers are in abundance from 1970s.
If that were a primary concern then we wouldn't be using SSH but rather something like Mosh instead since SSH requires remote echoing and other tricks to function - which aren't ideal for low bandwidth / high latency connections.
CLIs are great for administrative tasks - be it remote or local - because it's more expressive than GUIs. You can chain tasks together, and you can expose more options in a cleaner syntax than you can with a GUI.
This is also the same reason why Puppet et al also work for administrative tasks. They understand the requirements for expression so provide a syntax that offers that.
I don't think GUIs make for good administration beyond allowing for configuration of common tasks in an environment that is already running. That's not to say you cannot do sysadmin work purely in the GUI (Windows admins will testify to this) but the CLI does make things easier once you get a handle on the tools. If that weren't the case then there simply wouldn't be a need for Powershell.
You can have the best of both worlds if there is a well-designed API behind the GUI that also supports CLI tools. This also helps with test automation.
He's against bundling a GUI as the only method of interface to a given program, but rather wants the application to be open to both.
Not agreeing or disagreeing with his viewpoint, just summarising.
Our best discoverability tool is the Google Search. It's actually kinda a CLI tool.
Think about a kanban application - it's just not something that makes sense as a CLI thing. And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. Usable via terminal emulator does not necessarily mean CLI tool to me, at least within the context of OP's arguments. A lot of the things OP argues have to do with composition. CLI tools are useful in scripts because you can pass them inputs programmatically access and use their output; in this sense, a tool like vim or lynx doesn't fit OP's definition of a CLI tool, they're more like text-based GUIs.
vim didn't do this correctly, so neovim was born (which sort of proves his point imho). One of the goals of the neovim project is to enable the implementation of new/modern user interfaces without any modifications to the core source since the existing C89 code is hard to deal with.
mkdir kanban
cd kanban
mkdir 0todo 1doing 2done
touch 0todo/task1.md
ls *
0todo:
task1.md
1doing:
2done:
I didn't open that yet, but the coincidence just made me smile (if you can call trello a "kanban" board)
SourceTree is my go-to, but alas, there isn't a Linux version. GitKraken is a little... over the top. tig works in a pinch.
Compare to SourceTree how the graph window uses a small/normal font, not much padding, and tiny little commit dots and thin, close together lines.
Seriously, try to use it reduced to half the screen space on a 1080p monitor.
That's called a TUI (text user interface), by the way.
Invoke features via command line, but display results graphically.
For a small text utility such as “grep” a good UI night absolutely be CLI.
I don’t see how someone would argue that a photo editing app, music workstation, IDE, CAD program etc would somehow be better because it had a graphical UI that was layered “on top” of something that was textual?
I think some of the Unix people bashing (no pun I intended) GUIs just don’t use programs where GUIs shine. Sure there are cases where a GUI could and should be layered on top, but for complex media apps it normally doesn’t make sense.
But let's take find as an example: as a power user you might want something a little more involved than what the window search GUI offers, but as soon as you end up with something that involves AND and OR expressions a GUI is already subpar, and then you might want to process the files so you need either an "export to text file" function, or the ability to specify a command to execute. And even if the tool offers both, it's still hard to impossible to automate that task. You might find yourself ending up trying a dozen different file search utilities since you find one you manage to actually embed in an automated workflow. My experience is that Windows people just don't automate in many cases, although it's obviously absolutely possible to get all the GNU tools etc. on Windows too. They're just not being used that much.
ImageMagick. Mighty efficient, if you know what you want to do, and need to do this on couple hundred images.
But batch processing on its own is another great example where CLI shines. With GUI apps you have to rely on the app shipping that feature, and then it's almost guaranteed it works slightly different in every app, has different semantics, hidden in a different spot etc. On the command line, the batch processing is external to the tool doing the processing, constructed using features of the shell, so once you understood how to batch process with one utility, you can do it with everything.
Because then you could use all the advanced capabilities of those applications in batch mode.
I'll grant you CAD apps here (as did the OP), though decent CADs are at least thoroughly scriptable, and then there's space for text-oriented tools like OpenSCAD. As for the rest of your examples: decent IDEs are already text-and-keyboard-oriented (even if they present text oriented spatially), and it would be a small step to expose their capabilities to the command line for e.g. batch processing. Photo editing app - it's cool to click around, but then if you have to do this on 2000 photos, there's ImageMagick to the rescue. Music workshops - I haven't worked with those much, but I'd assume the case is somewhat similar to photo editing, except with audio as the output.
I do feel that the original article goes a bit overboard with praising CLIs, but I also think that a weaker version of that proposal is very much defendable - exposing software capabilities to CLI leads to both more efficient workflows and creates new workflows. More efficient, because of batch processing. New workflows - because now I can do at least some of those tasks e.g. via SSH from my phone, or via a Slack bot, or whatever.
And with such capabilities, you could then add e.g. "export CLI command" button to your GUI, so that I could e.g. do some processing and experimentation on one photo, and then copy a CLI command that will repeat that on the whole folder.
The mistake that is made for some applications in the Unix world is that the CLI app is used as the API, so they are not independent (and the CLI can’t change without breaking guis.
inkscape has "headless" cli mode, I've used it for batch processing svgs, and (independently) seen it used in similar manner in one of the companies I worked for.
I use mainly mplayer on linux for playing music/videos and simple processing (for example changing speed or encoding). You can argue it's not CLI app because it opens a graphical window, but it has text-only interface and additionally some gui, exactly as the article suggested.
Emacs and vi serve as an ide for many people, but these are just text-mode GUIs, what's important is that some of their capabilities can be also used in batch mode (for example - let's say you want to refactor 100 methods in 30 files - woudln't it be nice to be able to write a small for loop and call some cli app to do that?)
I don't know much about CAD but I suspect text mode for doing repetative parametric work would be useful as well.
Having a libsomeghing and a something-cli and something-gui is a perfectly good solution, but usually not if the GUI calls the CLI instead of the lib.
That's what he proposes?
> The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology...
> This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems.
Basically he says we need to use model-view-controller architecture to write desktop applications.
1) Your app becomes much less dependent on the platform and the toolkits you use
2) Even if the CLI interface is cumbersome to use manually someone can use it for scripts that can then do batch processing of whatever your application does including piping with other applications.
Long story sort linux has a great mechanism for making user-friendly applications that retain advanced features via shell scripts.
I'd go a step further and say that software should first and foremost be libraries exposing carefully designed APIs, then have user facing tools (command line and/or GUIs) built upon that.
I'd love an "ouput powershell window", which displays the powershell that a GUI is running under the hood.
I mainly write apps that talk to sql, so always try to include a "sql called" debug output in applications that I write for the same reason: It makes it easier for other people (me, when I forget what something's doing) to pick up what's going on.
Less related: This is from 1998, I believe, but I guess the general date is obvious from the title itself.
As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case?
I think you're right–the 1998 is the date it was forwarded, or something like that.
> As for Applescript: how precise can we get with it actually? I think when applications use native toolkits Applescript can figure quite much out on its own, but with custom elements (an Electron application), is this still the case?
AppleScript can do everything you, the GUI user can do, at least for native applications. There is an API for adding functionality that doesn't map cleanly to a user interface through scripting dictionaries, so from a certain perspective it can actually do more.
With regards to Electron, all bets are off: the application only has this functionality if it writes it itself. This is one of the reasons I generally have a distaste for Electron; it really breaks a lot of nice things that the system provides that are nonobvious if you don't use them but really hurt if you do.
I'd argue that, if that design were held through (and an easy to use universal client for COM had been available) it could have become even more versatile than unix. But of course, that's not what happened...
Then, today, we have a new trend where "GUI-only" functions are actually used deliberately to implement security restrictions or preserve business models.
And then there is the mess that is "web-based" GUIs...
I am an all-for-native guy (Qt, etc.), but the "web-based" GUIs are actually bearable from the stand point of the developer with a CLI:
their data interfaces are HTTP, so it's easy to hook them into CLI tools
their graphics are decently accessible through Selenium
COM came along much much later.
This is true even for GUIs. I used to maintain an accounting software. Everything could be done just with the keyboard. You could use the mouse, but it was optional.
People were registering hundreds of invoices a day. That will not be possible if they need to take their hands out of the keyboard, go to the mouse, move it and go back to the keyboard.
Web UIs are extremely inefficient. But it is not a big deal as they are designed more for leisure than for the professional. Hacker News or Reddit interface is good enough to write a message like this one.
I would like to see which interface use professional Reddit posters. From Russian trolls to /r/hailcorporate professionals need an interface that is not so mouse dependent.
The command line it is also a GUI, mine at least allows me to use the mouse to copy/paste text. But it is an optional feature that I don't need to use each time I write a command.
ha! I hope this was tongue in cheek...
Programs should come in three levels:
1) libraries, so anyone can make a program off them. 2) command line tools, which use the libraries to achieve specific goals. 3) GUI tools, which use the libraries or tools to show a nice graphical representation to the user.
I often wonder if this entire notion of a 'program' is not useful. What people really want, I think, are components. Give people components and they can wrap CLIs around them if they want. Give people components and they can drop them into GUI workspaces if they want. Microsoft COM may be pure unmitigated evil... but the vision, the dream, was on the right track. This thing that happens today where developers throw big, monolithic programs at users doesn't really make anybody happy.
Most better ones separated the kernel from the GUI already, where the GUI only serves for random input and as viewer, but the kernel allows scripting to automate tasks. The GUI's became so complicated, it's easier to design by rules and scripts and avoid osnap'ing to random objects lying in the view.
So in my view GUI is not harmful, but completely the opposite. It gives you tons, tons of possibilities and improvements. If used sensibely, of course.
I open terminals, neovim, etc. in tiling mode with the WM automatically arranging things according to my settings. Much like tmux etc.
Firefox opens in full screen on a separate tag, automatically. As does VSCode.
If I want to run something that fits best with a floating window style I can set that up on another tag and it's all automatic. I stay in one WM/mode the entire time and move seamlessly between whatever tool I want to use and I use that tool in the manner it's best used in.
What could be better?
On the other hand I love GUI apps which show which CLI command corresponds to the selected action (zenmap for example).
IBM created this for the ThinkPad. I had a Dell D830 with the little mouse between the G/H keys and the left/right buttons just below the spacebar. It was amazing.
A GUI is ultimately producing a stream of actions; these actions can be reified as text and displayed. Then you can copy the text to perform the actions again, modify the text, include it in scripts, and so on.
It feels like the more recent versions of these articles are more poorly written. This article, however, was much more reasonable.
And yes it's 80s/90s newsgroup flamebait. The author concedes GUIs are useful, they just want access to APIs.
Having a contrarian view is fine. But keep things in the correct perspective.