Hacker News new | ask | show | jobs
by njharman 2219 days ago
GUIs are a discoverability nightmare.

I've always found --help (or help <command> for tools breakin the "standard") and man pages massively more discoverable than any gui.

There are two well known entry points "--help" and "man". There has been much convention standardization with operating system guis, still they have many, many possible entry points. not all programs use same ones, use in same way. And webapps/pages are complete non-convention chaos.

both --help (but not "help <command>" (a reason they are "wrong") and man are 1 level deep and show you the entire ui, all at once. That is definition of discoverable! One action, i've discovered everything.

GUIs are deeply nested. And context sensitive so it may not even be possible to see actions until certain condition is met. The definition of opaque and undiscoverable.

14 comments

> GUIs are deeply nested. And context sensitive so it may not even be possible to see actions until certain condition is met.

This is a feature, not a bug.

For me, browsing 20 pages of --help or man is a discoverability nightmare. I don't want to wade through arcane option after arcane argument.

The GUI gives me a well-organized top-level understanding of the program: organized menus, and organized panes (panels/palettes/tabs/etc.). Then I can drill deeper into dialog boxes and tool settings as needed.

It's far more efficient to quickly browse a GUI to figure out the lay of the land, than it is to wade through what is essentially the reference manual of a CLI tool.

Reference manuals are the opposite of discoverability.

> This is a feature, not a bug.

Seconded.

The hard part of CLIs is discovering what is possible in the current context. You can almost take for granted that a GUI will do this for you. CLI not only won't, but will often fail to discuss this in the man page.

While there are exceptions (eg tmux), I find most man pages are written for someone who already knows how the command works but forgot a particular detail.

> While there are exceptions (eg tmux), I find most man pages are written for someone who already knows how the command works but forgot a particular detail.

Isn't that a function of how much work is put into man pages vs. the GUI? I'd be hesitant to claim that if you took the same number of hours in writing a GUI and put it into writing better documentation that we'd be in the same place we often are with poorly documented tooling.

CLIs and GUIs aren’t an either/or proposition. They each implement very different paradigms; OP goes over them pretty reasonably. You’re not supposed to discover a CLI; you’re either supposed to remember the 4 things you do all the time (see git) or script it and build your own interface/program (see coreutils or stuff like troff). It’s an entirely different UI. Arguing that CLIs aren’t discoverable misses the point just as much as arguing that GUIs aren’t composable. They’re not supposed to be.
“CLIs shouldn’t be discoverable because they’re not supposed to be discoverable.”

Imagine if we applied the same defeatist tautological thinking to our other written materials: books wouldn’t have TOCs or indexes, the Web wouldn’t have search engines, and so on.

10,000 years of the written word, yet nothing is learnt. SMH.

Maybe if text-based interfaces did provide good, safe discovery they wouldn’t have been beaten into a cocked hat by GUIs for 99% of users. And this is despite GUI being something of a UX trap itself (as CLI fans are happy to point out), becoming ever moreso as personal computing moves beyond traditional physical point-and-click and expands into voice control.

Honestly, there’s more text smarts in a modern smartphone’s txt-ing interface than in today’s “cutting edge” of 1970s CLI design.

Is it really about providing good UI/UX, or about preserving the entrenched power structures of the computing world status quo?

--

“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.”—Keith Braithwaite

It's not a tautology, it's choosing how something works. Try it with other things:

"Guitars shouldn't have reeds because they're not supposed to have reeds"

"Cars shouldn't have pitch controls because they're not supposed to have pitch controls"

> Maybe if text-based interfaces did provide good, safe discovery they wouldn’t have been beaten into a cocked hat by GUIs for 99% of users.

This isn't so much CLI vs. GUI but interactive vs. non-interactive. Think CLI vs. TUI. Then (hopefully, I guess) you'll realize that it's a deliberate difference in paradigm vs. one or the other being superior.

Indeed, this is the entire point of OP. Reification of the interaction means making that interaction first-class, and CLIs do this by making the interaction the invocation, which you can then manipulate. You can't (mostly, w/o some kind of session scripting tool or w/e) do that in a GUI or TUI.

Kind of a lot of heated discussion about this but, it doesn't seem like it's that big a deal.

I rarely wade through it and just search for what I'm looking for. Typing '-i' (in the session, not as a param) will make the search case insensitive if using 'less'.
That's great, but that's not discoverability, that's searching for something you know/hope/suspect is already there.

Discoverability is about having what you can do be presented to you in the first place. It's the very opposite of looking things up. The information comes to you in a contextual way, instead of you having to go searching for it.

So the solution is to use another separate CLI utility that you have to read the manual for, and memorize '-i' as an option for it?
I wouldn't consider less a pure CLI utility, since it puts the terminal more into a screen mode.
Same reason I stay away from text books and stick to picture books and comics! Text is boring and tedious, pictures are cute and fun!
Don't think this is a fair comparison. You can drill down quickly to learn new actions you didn't know before in a GUI. That's a whole lot harder to do in a CLI
> GUIs are a discoverability nightmare.

Badly made GUIs are. I started my career developing desktop software. Both Apple and Microsoft used to publish guides for building proper GUIs for their platforms. Our UX designers and PMs were enforcing those vigorously.

On Windows, every feature had to be represented in the menu of the main window. See, right there, by going (not even clicking on) every menu item you will learn about existence of every feature. Photoshop is still like that.

Most frequently used actions deserved two additional things: a hot key and a toolbar button. Each toolbar button had to have a tooltip. See? Right there, by going over the toolbar one could quickly learned the most important features.

Using windows, splitters, panes, tree views and tabs - there was logic behind those choices, and having standardized set of UI controls allowed users to learn software much more rapidly.

Modern web "applications" are crude by comparison. There's no standardized way to discover anything. Is it a button? Is it a dropdown? Is it just a strange background to display an error? Things auto-hide and auto-appear for no reason, you have to move mouse around (or practice every swipe variation you're familiar on mobile). Hotkeys are an afterthought, even resizing the browser or even scrolling sometimes breaks things.

I am not going to name names, but we tried to use one of web-based conferencing apps a few years ago. The UI it offered for joining a call (the URL you'd include into a meeting invite) was so bad that nearly 30% of people could not find out how to join. That's basically the only thing that page needed to provide, yet their UX people managed to obfuscate it so much that users sat waiting & thinking that something is about to happen instead of clicking the "join" button... Ughh.

There's so much demand for software right now, every industry needs more... There is severe shortage of talent for everything, from engineers to UX designers and product managers. Eventually there will be an equilibrium and we'll have professionals design and program GUIs again.

I am a CLI-first person, but there's no doubt in my mind that a well-done GUI massively flattens the learning curve for a new app.

I fondly remember Apple's Human Interface Guidelines for the Macintosh, and software that followed it. Even if you'd never seen a given application before you could easily discover its features and how to operate it.

Having said that, I think CLI programs tend to not get enough credit for discoverability. It's just a different kind of discoverability (man $program, $program --help).

> Badly made GUIs are.

So pretty much every browser out there? Without knowing ahead of time from random pilfering through various menus, how can you tell if your browser is up-to-date or not?

How do you find the extensions page? Or is it add-ons? Depends, I guess.

How do I figure out which tab of (potentially) hundreds is consuming CPU and memory?

I won't claim that CLIs are better, but GUIs are definitely not made for discoverability these days.

I blame Chrome pissing on the menus for how hidden most functions are. Once they hid the menus, the others fell in line.
Counterpoint: the vast, vast majority of users never do any of that. I’m sure Google collects tons of analytics on how people use Chrome and the current design is tailored to fit the needs of the majority. Common functions like tabs, the address bar, and maybe bookmarks are front and center while everything is shoved into menus to declutter the top-level UI.
Why past tense for guidelines from Apple? They're here: https://developer.apple.com/design/human-interface-guideline....
They may still be published, but GUI guidelines are generally not followed anymore. The rise of Electron applications is just one reason why this happened.
In some ways CLIs are great for discoverability, because they force everything into the familiar "list of commands" paradigm. GUIs can be either much better or much worse for discoverability, because the layout techniques that let GUIs surface important or contextually relevant functions are the same techniques that let GUIs hide the function you need behind six layers of B.S.

See this article (full disclosure: written by me) that talks a bit more about some of the tradeoffs between CLIs and GUIs from a UX perspective: https://medium.com/design-ibm/real-developers-dont-use-uis-d...

There's also this interesting project that attempts to bring some of the discoverability and other benefits of graphical UIs to CLIs: https://github.com/IBM/kui . Would love to see more work in this area.

GUIs can be a nightmare. They can also be a way to digest all the tools at your disposal without ever going to a help page. I think there’s definitely a lot to be said for that, particularly for people less used to a command line environment (and I don’t mean my dad trying to play Tetris, I mean a second-year CS student who is still getting used to Terminal).
> both --help (...) and man are 1 level deep and show you the entire ui, all at once

Have you seen git's help/man? That's at minimum 2 levels deep.

Yes and that is much better than a one level deep manual.
Don't forget "whatis" as your standard third entry point on Unix.

macOS does have a standard Help menu, and you can even live search from within it; it'll find a command within the menus and show you where it is, even if it's deeply nested. Or it will search through help topics if the application provides them.

> And context sensitive so it may not even be possible to see actions until certain condition is met.

That's gotten worse as developers have jammed more and more features into applications, to where they can't lay out their commands in the traditional menus.

We somewhat dodged a bullet in this regard. Apple and Microsoft both did experiments in component software back in the '90s, with Object Linking and Embedding on Windows and OpenDoc on the Mac.

They flopped for a variety of reasons, but one was the insane complexity of the UI: any object in a document was now potentially a mini application and had to negotiate control of the UI with other objects.

Yes. This. Man And help pages are great (and grep-able, ripgrep-able ha).

No ads. No pay wall. Damn I love man pages.

> all at once. That is definition of discoverable! One action, i've discovered everything.

We should make information more discoverable by putting libraries on a single scroll, then it's just one single page.

This! And also even once you find something in a GUI how do you record that and share to somebody else (including you in the future)? I had more success providing a non-technical person eith runbooks with shell commands to copy paste into a terminal to deal with common problems; we tried with GUIs but it was always very hard to work with over the phone (it was also long time ago, and in an airgapped env)
Not to mention that GUI designers have a penchant for moving things around in the interface on every release. So even if you knew where that thing was, you don't necessary know now. Consider Microsoft Office, for example. Ugh.
Microsoft Office has barely changed since Office 2007 and the introduction of the Ribbon. They screwed up the File menu by making it full-screen†, but apart from that I can't see anything to complain about.

† The original 2007 "Office" menu like in File Explorer or Paint is loads better.

It could be that the interface is so confusing and horrible that it only seems different each time I dig into it.

Each time I take a new job, I have to slog around in the config screens trying to figure out how to turn off all of Outlook's !@#$ing awful "corrections" that send my email in variable-width fonts and change my '--' strings into em dashes and so on, thereby destroying my emails to users. Every time I do this, it seems like the layout of this awful pile of config dialogs has rearranged itself. Is it just PTSD?

Yeah, well, Outlook is a different story. The Ribbon interface isn't really suited to a mail client, and Outlook has so much historical baggage that makes it ridiculously hard to use. I try my best to not use it, so I don't know how much it's changed.

But Word, PowerPoint, and to some extent, Excel? The Ribbon is really well thought-out and easy to use. It feels intuitive in a way that the old bloated menus never did. And the command search feature is actually really useful, and teaches you where a command is located so you can just go straight there next time.

This is hopelessly pedantic, but Outlook is (now) part of Microsoft Office. And matters to me the most since it's the only part of Office I hardly ever use.
Not hopelessly pedantic, it's very true. It's just that I've always hated Outlook and I'd honestly forgotten about it when I wrote that original comment.
Maintaining backwards compatibility isn't a problem that's unique to GUIs.
At least in Unix/Linux, I doubt the reshuffling of command flags and arguments is more than one percent of what happens in GUI programs. And it's probably far less.

Command-line people take backward compatibility very seriously. GUI designers seem to think it doesn't matter, because oh, everything's so easy to find. Fie on that.

Yep. CLIs often also have a predictable interface. (Help is almost always -h or --help, version info is -v or --version, etc). On a GUI you'll have to play around a bit more and search for functionality.
CLIs are not guaranteed to have a predictable interface at all. The flag prefix isn't standardized at all. On Windows you see the awkward / prefix. On Linux you will see a random mix between -- or - and the way values are specified is also random. Sometimes it is --flag value at other times it is --flag=value or just -f value or -f=value with no fully written out counterpart. If there was actually a standard that every CLI application followed (or the format was parsed by the shell instead and applications simply receive the parsed array of arguments) then you could make this argument. I would love it if this were true but that isn't the world we live in.
Half the time, -v seems to be a shortcut for --verbose. Or is it -V? Either way, it's not consistent or very predictable.
You call a flat list with a thousand items of tiny text discoverable?

It’s not.

Tab completion really helps with that
> GUIs are a discoverability nightmare.

Which GUI?

Every touch-based one, for starters. I don't know what I can tap, or what will happen if I tap them. Or long-tap, or double-tap, or lightly-tap. Or what the various swipe directions mean, or how swipe-from-edge differs, or the differences between a 1-, 2-, and 3-finger swipe. And nobody ever guessed how to "undo" on iOS without being told.