And even in modern CAD systems the GUI makes no sense anymore.
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.
And it should be like this, in the early days of GUI it was a mess and in many places still is, but people understood how to use it properly - eg as a "frontend" part of an application "kernel".
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.
On my Linux box I'm running the Awesome WM, and I don't see how anything could possibly be better than it (or anything that works similarly, obviously).
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.
Discoverability. CLIs are notoriously bad at discoverability. GUIs, on the other hand, are much better about showing a user what options / commands are available.
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).
> Oh and when people read instruction manuals. 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)
I think most people couldn't read yet when they learned about balls. A better example would be games. Remember how thick the manuals were 20-30 years ago? Remember when you last time read a manual for a modern game?
I don't think that this is a question with an absolute answer.
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.
I don't think it's reasonable to expect the average computer user to go digging through man pages to figure out how to do literally everything they use a computer for.
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)
This is really a really good description of the problem. People use computers in ways that seem bizarre to us.
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.
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.
and, importantly, they can still pick up the metaphors even if they don't understand english (or the language of preference) very well. MAN pages often require really really good language skills in the given language to understand.
This is one of the things that I love in PowerShell. It autocompletes the command from all of the commands available through either scripts or modules on the path, and then it autocompletes parameters (their names, and when they're an enumeration, the value). Discoverability makes life much much easier.
I think he's implying it's built in by default? I personally have never observed it, but I don't really use powershell so maybe I'm doing something wrong
I know of multiple Debian systems I've used with decent bash-completion for most commands out-of-the-box–now, whether this was because it had already installed bash-completion and the associated completion files for each preinstalled APT package in the bash-completion directory, I don't know.
Bash completion scripts have to be hand written for each command. Ok, at best they can be autogenerated from some tool if the command's development environment has a tool for it. But many of these scripts are handwritten.
So they have to be created by humans and then installed on the system.
There's nothing in linux that is baked in on every install except for kernel. On most desktop/server distributions bash-completion is installed by default. On embedded it mostly isn't.
bash-completion is a package containing pretty capable autocompletion functionality for a large set of common Unix/Linux commands. It is not installed by default on some distributions for reasons that are beyond me.
It's a matter of scope. For bash pretty much everything is foreign, so it can only autocomplete if it get's some external source information for it, which usually means someone must write/generate it.
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.
GUIs, on the other hand, are much better about showing a user what options / commands are available.
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.
It is objectively one of the worst in existence. Same as with photoshop. It just ended up like that, everyone learned it that way, and now no one dares to revolutionize.
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.
> Blenders UI is a horror show unlike anything in existence. Blender is extremely capable though.
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.
I have no doubt that if you work in it every day and properly learn how it works then you can do amazing things with it very efficiently. It's a complex tool for doing complicated tasks that works for those users who need to do that.
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.
I think perhaps the most important thing to learn about 3D graphics is patience. 3D graphics is a craft. If you're from an art background, you're used to the idea of drawing the same things every day for decades, and still not being 'ready' - because you're not just training your brain, you're training your eye and your body. It's the same with Blender.
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.
Another blender example: hidden options revealed by sliding the container (which doesn't scale the contents displayed but instead slides out hidden space to reveal additional controls and options)
Vim is contextually sensitive too, and it doesn’t tell you why “q” sometimes types a letter, or starts recording a macro, or exits the program. Because vim is specifically designed for power users who want a lot of capability and a very effient workflow. And so is Blender.
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.
Vim is not primarily a CLI program, it's an interactive editor with a GUI. That this GUI is sometimes laid out in a row/column addressable terminal is besides the point.
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'
>GUIs, on the other hand, are much better about showing a user what options / commands are available.
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.
Yes this is a big plus for CLI. I don't know how many times "something --help | grep keyword" has immediately solved a problem while for GUI apps you always need a google search. I mean it's not really that bad, you always have the browser open anyways and 99% of times someone had the same problem before, but still, it just feels cumbersome.
Yeah, I agree, and a good --help might not be included in every CLI app, but then again a lot of GUIs are also barely discoverable if the options have bad names and no tooltips.
I was going to mention PyCharm. The Jetbrains editors (intellij) are about the only GUI app that I've ever replaced a CLI app with and been happy. Their discoverability and documentation played a big part in that.
And this was the hands down best feature of unity, they provided a way where you could search within these menus... So sad to see the project fail due to reactionary criticism. Now the functionality still sort of exists in Ubuntu 18 but not by far as well made as in 16.
This continues to be the feature that keeps me using macos for work - the search field in the help menu searches all the menu options, each of which displays its own shortcut key beside it
> 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.
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.
GUIs have manuals too, and usually they are searchable. Additionally there are GUIs around with the ability to search in the GUI itself. Usually it's limited to Option-Dialogs to find the specific setting, or menus to find the specific entry you wanna call.
But in generally it's only a matter of effort how accessable something is.
> Additionally there are GUIs around with the ability to search in the GUI itself. Usually it's limited to Option-Dialogs to find the specific setting, or menus to find the specific entry you wanna call.
JetBrains tools, Netbeans (ctrl- i) and VS Code (ctrl - shift - p) all has this in the main interface I think.
To be fair, `ffmpeg` and its audio and video converting capabilities are quite large, therefore this has to be reflected in the amount of options available. But the basics of it is pretty easy to grasp through the manual.
I could equally argue the opposite is true today. A good CLI program has either a —help option / man file. I run that and presto, I have every command and option succinctly presented.
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.
A good CLI program, with autocompletion and on-screen documentation, will show how to use it. That's what UX is all about.
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.
Can you name a CLI program that is as complex as Photoshop? There’s certainly CLI apps with good UX, and ones with bad UX. But I don’t see a reasonable way to argue that CLI has better UX tools than GUI. Autocomplete and tips can make a good CLI experience, but a good GUI experience can convey more information without even using those things.
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.
I don't mind CLI programs. But there are definitely some things I wouldn't want to use them for. I couldn't imagine using a non GUI CAM or CAD program and a CAM program is far superior to coding a bunch of complex G-Code by hand. CLI video editing, 3D modelling or GIS work would be a pain compared to GUI versions. There are definitely places for both. Hence why we have both.
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.
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".
I've often figured out a GUI faster than it would take me to sift through to the relevant part in a manpage. They work well enough as a reference but I don't understand how people genuinely think they are the ideal tool for learning how to use some new software.
I think so, too. This doesn't mean the CLI is less discoverable (assuming good design), just that active knowledge is harder to aquire than passive knowledge. Passive knowledge is enough to use a GUI, because you can just see where you need to click. There's a lot of "information in the world".
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.
I don’t think the last part has anything to do with the topic at hand, however
> 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_.
The article is not against your points. It is against creating GUI-only applications. Explains why it is better to have modules in applications with functional "backend" and GUI if needed, and CLI for programmability.
True, but it's a CLI tool which basically has humans at the end of the tunnel. After all, you're searching for stuff written by other humans, preferably things which directly address your problem and are actionable, not vague high level advice.
Modern mobile UIs have often forgotten discoverability; interactable elements are not always highlighted, there are different types of touch, and sometimes things behave differently for no good reason (e.g. web pages that want to disable pinch-zoom).
I think the intention, despite the title, is not to say that GUIs are harmful. I think more what he's saying (especially in the closing paragraphs) is that both a GUI and CLI need to co-exist because they target different groups.
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.
> We use CLIs to remote into servers because it doesn't require much bandwidth and it works with high latency, etc.
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.
I agree to a point, but I have come across some remarkably opaque GUIs - in cars, for example.
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.
You can make modern CLI tools today with great discoverability, there are a couple of great frameworks that makes this possible like Click[1] for Python or cobra[2] for Go.
I think a nice solution for what the author is looking for in a GUI, namely the ability to write a script that controls them, is achieved today by something like AppleScript, which pretty much does exactly that: you can write little scripts that allow you to have basically full control of the application's UI (and in some cases, the parts not visible). So you really have the best of both worlds: a nice, pretty, and simple GUI interface that most people can use, and a scriptable backing that can be queried and manipulated in useful ways for purposes such as automation.
Less related: This is from 1998, I believe, but I guess the general date is obvious from the title itself.
If I understand it correctly it's actually from 1992.
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?
> If I understand it correctly it's actually from 1992.
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.
AppleScript is great, and I taught it to myself when I was 13. I still use it often. But I'm wanting to move to Linux. So far I haven't found a real replacement. If anybody's interested in working on that together, please get in touch!
Not everyone uses Apple, and not all GUIs use the system widgets. The latter are usually opaque to such scripting tools, at most you can script clicking to a certain position in a window which can break the script if buttons are moved.
I'm not saying that everyone has access to this; my goal was to merely bring up an example of a system that already exists and works reasonably well. I'd really love for every application and system to adopt something like this, because, like you've mentioned, other solutions are generally very brittle.
>That way, naive users can use push-button
GUIs, blind users can use Braille terminals, and sophisticated users
can program solutions to intricate problems.
I don't know. I think the original idea for Windows was that services are accessible through APIs on a system-wide message bus (COM) and the various GUIs are simply clients for those APIs.
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...
Maintaining such internal APIs is additional work and since most users prefer clicking in GUIs, companies ditched this approach, because it's simpler and cheaper to create a GUI only tool.
True. From an API standpoint, SPAs actually improved the situation a lot: Introducing an API boundary and separating concerns is now a routine part of developing an SPA.
> A precision pointing device that didn't require taking your hands off the keyboard would help.
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.
Maybe I'm biased because I work on a git GUI, but even if you ignore the discoverability and accessibility argument, I think graphically displaying information is useful.
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.
So the git client I work on has a built in kanban that syncs with github issues, and I work on that part of the application as opposed to the git graph itself - Having dedicated the last 6 months of my life to a kanban, I'd be really interested to see how they solve a bunch of the UX issues surrounding not having a drag and drop pointing device, which in my mind is like the central interaction in a kanban board. Thanks!
Which git GUI do you work on? I'm a big fan of GUIs for git mostly because I'm able to combine several views into one, such as commit log, file status (staging, etc), and diff. Show this all at the same time is such a huge time saver.
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.
Waaay too much whitespace. I have to maximize the window to make it useful. It's really easy to shrink the window down to where the graph becomes completely useless. Even in the image/GIF on the homepage there's only room for about 20 characters of the commit message if you want to see the whole branch graph.
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.
The argument here is that every tool should have a programmatically accessible core (prob pipelines in linux, apis in windows, etc) and that the GUI should be built in addition to this core.
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.
> 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.
That's called a TUI (text user interface), by the way.
What OP fails to see is that GUIs are 80% of the reason why you see technology all around you. It’s the layer of simplification the vast majority of people need. PCs didn’t catch on until the GUIs were born. GUIs help architects design the same buildings OP lives in. 99% of the stuff in his home were designed and crafted tnx to a variety if GUIs in the process.
Having a contrarian view is fine. But keep things in the correct perspective.
I think the perfect engineering is to build two pieces: the data functionality should be built into a CLI tool that could potentially be triggered by a human or other third party software, and then build a UI on top that mainly interacts with the CLI. Essentially this is the MVC pattern we nowadays mainly talk about in a web context.
One could argue that web GUIs are the best of both worlds. If done right, user can easily discover new functions and how they are used, while they still allow interaction with other apps through REST API. They can also be used remotely, the HTTP stream can be forwarded through different means (SSH,...), there are standard ways of authentication,... If done right.
I always thought something like this would be neat to explore further: https://www.youtube.com/watch?v=gifzjhyBwOc (warning: contains some intense flashing at a couple points).
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.
Programs should have a UI that make them as useful as possible. For a large client app “useful” means discoverable, efficient.
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.
I agree, there's always types of programs where one beats the other. I will never argue that a CLI browser, photo editor (if it exists?) or IDE for say Java has any advantage over a GUI. It's the stuff "in the middle" where it gets interesting. Even if you only consider power users or developers, many times the Windows user still resorts to GUI apps either out of habit or since there is no built-in CLI solution to the problem, and if you need to download anything anyways you might just go with a GUI app.
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.
Sure, I was more thinking of hand tuning a photo (retouch, cover up, remove a person in the background). But even if you just tweak contrast and brightness a GUI probably still wins if you don't know the exact values you want to apply beforehand.
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.
> 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?
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.
Right, a CLI is just another UI. Regardless of whether your app has a CLI, GUI, or both normal architecture rules apply. I’m arguing that usually the best design is a core as a library api with CLI and GUI being two independent applications.
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.
> 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?
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
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.
The argument is not about having complex CLI only apps. The argument is that by having a separate GUI frontend and a backend with a CLI interface:
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.
We’ve already had ‘considered harmful essays considered harmful’ [1], now I’m waiting eagerly for someone to write ‘software development considered harmful’, followed speedily by ‘communication via any form of symbolic representation considered harmful’.
I wish the command line approach was used in the WWW. The world would be so much better place if web resources provided REST API as a primary way to access the data and the web UI was only one possible visualization.
Also, when you get yourself into trouble with a CLI, you can usually look back through the session history and figure out what went wrong. GUIs often have an undo stack, but there's no real log what you've done.
I know that Microsoft have promoted powershell in their OS, and I believe they tend to build a GUI on top of powershell commands.
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.
> Gratuitous distractions from the keyboard only slow down the experienced user.
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.
GUIs are problematic in the same way command line tools are: there is no way to access the internal functionality of both from a programming language.
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.
> 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.
Building a GUI that consumes a command line interface turns that command-line USER interface into an APPLICATION PROGRAMMING interface, and that's asking for trouble. USER interfaces and PROGRAMMING interfaces are different things, with different, sometimes conflicting purposes and goals. Conflating the two leads to fossilization and confusion for users and application programmers alike. It also causes unnecessary conversion to and from brittle human-readable formats.
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.
To use most CLI programs efficiently you need to remember commands and parameters to avoid scrolling through man in pursuit of "that one parameter combination I used last month but cannot find in my terminal history".
On the other hand I love GUI apps which show which CLI command corresponds to the selected action (zenmap for example).
My opinion is that the pattern object -> action is better than action -> object. That isn't necessarily the same thing as GUI vs. CLI, but there is some correlation.
148 comments
[ 5.9 ms ] story [ 172 ms ] threadMost 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?
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).
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)
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!
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.
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)
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.
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.
Those days never existed. Support stories of exasperated developers are in abundance from 1970s.
So they have to be created by humans and then installed on the system.
Far from auto-introspection into a standard API.
Is it built into bash, and working for every single script and module by default?
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.
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.
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.
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.
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'
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.
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.
Additionally - documentation of gui app needs images which make searching for stuff much harder when you don't know the keywords.
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.
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.
> 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.
Our best discoverability tool is the Google Search. It's actually kinda a CLI tool.
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.
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.
[1] http://click.pocoo.org/6/
[2] https://github.com/spf13/cobra
And yes it's 80s/90s newsgroup flamebait. The author concedes GUIs are useful, they just want access to APIs.
It feels like the more recent versions of these articles are more poorly written. This article, however, was much more reasonable.
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.
ha! I hope this was tongue in cheek...
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...
COM came along much much later.
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
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.
https://en.wikipedia.org/wiki/Pointing_stick
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.
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.
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.
That's called a TUI (text user interface), by the way.
Invoke features via command line, but display results graphically.
Having a contrarian view is fine. But keep things in the correct perspective.
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.
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.
[1] https://meyerweb.com/eric/comment/chech.html
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.
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.
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.
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.
On the other hand I love GUI apps which show which CLI command corresponds to the selected action (zenmap for example).