Hacker News Reader

Comment by Osiris | Hacker News Reader

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).

View on HN

>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.

In most GUI apps on the Mac you can do this kind of thing through Help > Search..., though.

Not sure about other platforms, but I sure use that feature a lot in e.g. intellij.

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.

It doesn't get better with the newer generations favoring YouTube tutorials over reading.

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.

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.

GUI applications can have good documentation, which, if they do, makes your point moot.

If we assume a given tool has little or no documentation, a GUI wins out.

A good GUI will show you how to use it. That’s what UX is all about. But a CLI will always have to be learned.

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.

VIM

Are you saying that vim is as complex as Photoshop? Or that the program famous for users not knowing how to exit it is an example of CLI UX?

Yes

https://sanctum.geek.nz/arabesque/vim-koans/

ImageMagick is CLI tool for photo editing.

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.

If we take a random gui app and a random cli app the documentation of the cli app will usually be much better.

Additionally - documentation of gui app needs images which make searching for stuff much harder when you don't know the keywords.

But how do you know which CLI program to use?

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".

How do you know which gui programs to install?

Not everything can be done with microsoft home office.

Same way I find out which CLI program to use: Google.

> But how do you know which CLI program to use?

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'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.

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.

That is just bad design. You would have the exact same problem with CLI if a command was contextual sensitive.

Blender has a fantastic UI though.

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.

It’s extremely difficult to craft any interface, GUI or CLI, that is both efficient for regular users and easy for casual users.

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'

That might have been true once, but now every button is a different hieroglyph I'll take `man foo` or `foo --help` any day.

Gmail is especially bad about that. Luckily there's an option to change buttons to use text labels.

good luck with `man ffmpeg`.

That's what Stack Overflow is for ;)

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 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_.

> > open source is always better than proprietary

> I don’t think anyone has ever claimed this.

There was this one guy who maintained Emacs for some time.

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.

How does this differ from bash-completion?

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

Bash completion for every single installed module isn't baked in on every install?

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.

Far from auto-introspection into a standard API.

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.

I've not encountered bash-completion.

Is it built into bash, and working for every single script and module by default?

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.

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.

I remember the days when CLIs had a HELP command built in and accurate enough. Oh and when people read instruction manuals.

A decent manual beats a "discoverable" GUI almost always.

> 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)

What do you mean by that?

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!

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'm perfectly fine not having to read manuals for games...

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.

This can be made even more simple as a contrast.

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.

> The iPad GUI is so trivially easy to immediately learn to use

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.

> I remember the days when CLIs had a HELP command built in and accurate enough. Oh and when people read instruction manuals.

Those days never existed. Support stories of exasperated developers are in abundance from 1970s.

> 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.

[1] http://click.pocoo.org/6/

[2] https://github.com/spf13/cobra

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.

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).

Discoverability?

Our best discoverability tool is the Google Search. It's actually kinda a CLI tool.

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.

As a counterpoint: a command-line application with a --help option has just as much discoverability, IMO.

Reply on news.ycombinator.com