26 ms·

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party p

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder. If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. It's interesting that there is some analogy to object-oriented and functional paradigms -- if I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it. Might be a too far fetched analogy though. I think we need all of it, and also need to make the distinction less apparent. Would be nice to make GUIs more composable, and TUIs more discoverable. Ideally it should be a spectrum of interfaces, so you don't have to make a hard choice and can gradually move into the direction you want.

koolba 6y ago
> If I don't remember the `df` command... what do I do apart from searching on the internet? You can do that locally on the command line too! https://en.wikipedia.org/wiki/Apropos_(Unix) https://en.wikipedia.org/wiki/Apropos_(Unix)
- homarp 6y ago
  or man -k "disk space"
  - aidenn0 6y ago
    disk space: nothing appropriate.
    - Annatar 6y ago
      As root run catman -w just once to (re)build the index. Results are guaranteed to be of high quality only on a real UNIX, preferrably one of open source Solaris (illumos) distributions, and likely FreeBSD.
    - homarp 6y ago
      on Ubuntu 18.04 this is what I got $ apropos "disk space" df (1) - report file system disk space usage $ man -k "disk space" df (1) - report file system disk space usage and $ man -k "disk usage" docker-system-df (1) - Show docker disk usage
  - stjohnswarts 6y ago
    hmmm this one I didn't know :D
- lanna 6y ago
  But what if one doesn't remember the `apropos` command?
  - koolba 6y ago
    Then you fire him and hire someone else.
  - deleted 6y ago
    [deleted]
  - Annatar 6y ago
    Then that person is the wrong person for the job.
  - weinzierl 6y ago
    apropos apropos if you forget that apropos apropos apropos Recursion solves every problem;-) More seriously: You can alias it to something you can remember, for example: alias help=apropos
    - dredmorbius 6y ago
      'help' is already the shell's built-in help function in most cases. That'd be a poor choice of alias. There are a small number of seed keywords which are ueeful to know. 'help' (shell), 'apropos', 'man' (online manual), 'info' (GNU documentation), and dwww (local documentation presented through a Web interface, available on Debian-based Linux, see https://ostechnix.com/dwww-view-complete-debian-documentation-offline-via-web-browser/ https://ostechnix.com/dwww-view-complete-debian-documentatio...) are among them. Knowledge requires a certain baseline. If that's too much ... perhaps a GUI is in fact advisable.
  - diffeomorphism 6y ago
    The same thing if someone does not remember there is a right mouse button?
    - lanna 6y ago
sbuttgereit 6y ago
A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discoverability you mention found in the GUI based system. It was just easier to use. This didn't come for free however. At a different client making the same transition from TUI based system to GUI based system (same target software), we measured the productivity of well trained staff and the TUI was well ahead in daily productivity. Now the different companies had different employment profiles; they were both retail businesses, but the first one that measured training was more decentralized and saw higher staff turnover rates and so cared more about training efficiency; the other had more centralized operations and so had fewer, more senior staff members with longer tenures where daily performance was a more important metric for efficiency. Now a TUI isn't the same as command line and most GUIs allow for substantial keyboard functionality, but I think developing for a TUI tends to get you thinking about a person working a keyboard whereas developing a GUI you're thinking more about the person with a mouse/trackball/trackpad/touchscreen. Personally, I do a lot of database work; mostly PostgreSQL. I decided some years ago to bite the bullet and get rid of the GUI and just use straight psql. I largely haven't looked back, though if I'm doing heavy development work I just started using DataGrip since it helps avoid stupid errors that a simpler text editor doesn't find.
- xupybd 6y ago
  Have you looked into pgcli, psql is great but pgcli is a little nicer. https://www.pgcli.com/ https://www.pgcli.com/
  - sbuttgereit 6y ago
    I have, but it's been awhile since I looked. My recollection was that it felt sluggish, but that might be a false memory. I think what it brings to the table is helpful, but not enough for me to warrant it's use. When I'm writing simpler queries at the command line, I'm usually well within my knowledge of the databases I'm writing for or would have to appeal to something like the table definition anyway... which as I recall I couldn't really do in pgcli (start writing, flip to the table definition, pick up where I left off). When the sorts of things that pgcli does becomes most helpful is when I'm writing functions and procedures, but then the command line isn't well suited for that. That's where I'm finding something like DataGrip helpful: a database tool focused on development rather than administration. DataGrip has a lot of faults, but for the past couple of weeks I've been using it, it's been on balance a win.
drivers99 6y ago
> I can right-click to see everything that can be done with the file, including some third party programs Smart move by (for instance) Microsoft when they did that in Windows 95 and continued it til now. You could theoretically design the same functionality into a text user interface. Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) it could give you a menu to choose from context specific commands. It would seem pretty natural in that case if you are using post-fix (arguments(s) and then commands, like in Forth). Maybe something already exists like that.
- yissp 6y ago
  In bash I can type, for example, "git <tab><tab>" and it will list out all of the git commands. Not quite as nice as a menu, I suppose, but still helpful for discoverability.
- a1369209993 6y ago
  > Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) How about: $ file --help | grep util -u, --utils output utilities related to FILE $ file -u index.html index.html: HTML document, ASCII text, with very long lines cat index.html ed index.html lynx index.html
  - drivers99 6y ago
    I meant like index.html <tab> And you’d get open, copy, rename, create symlink, delete, compress, etc.
    - a1369209993 6y ago
      That sounds like a GUI; how do I pipe [open, copy, rename, etc] into sed or awk? (Because the^Wa problem with GUIs is that the answer tends to be "Why would you want to do a wierd thing like that?".)
      - 6y ago
User23 6y ago
This reminds me of my first experience with (DEC) Unix at JHU. I had been a VMS user, so when I logged into the unfamiliar system I typed in "help." The JHU site admin had helpfully set the output of the help command to be, paraphrasing, "I see you know nothing about Unix, please talk to the staff member." He told me, "oh, in Unix help is spelled man." Obvious!
- tuatoru 6y ago
  Bash, at least, is more helpful these days. $help GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) These shell commands are defined internally. Type `help' to see this list. Type `help name' to find out more about the function `name'. Use `info bash' to find out more about the shell in general. Use `man -k' or `info' to find out more about commands not in this list. That last sentence in particular.
ta20210405 6y ago
GUIs are great, but not having a CLI is an anti-pattern. Also, having an API, but no reference CLI is an anti-pattern (depends on your API, but if your examples are poorly constructed bash scripts with cURL lines you need a proper CLI).
closeparen 6y ago
One thing that I hate to admit is great at this, is JIRA. It is definitely a UI centric product! But when I want to compose it with something, the REST API is right there. In fact, when a mostly-background system needs a human in the loop, sometimes we can grab JIRA to be our UI.
rewgs 6y ago
I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications? I see no technical reason for the lack of it. Look at something like htop -- it has a sort of "command line version of a macOS menu bar" with each menu selected by a function key. I could easily seeing this idea being extended to, say, being called by the familiar --help flag, or each menu visualizing a sub-menu upon pressing a function key, etc...there's no reason CLIs can't have the same discoverability as GUIs.
- molasses 6y ago
  There are shells that help with discovery. And auto completion helpers. These are great. You might infer from documentation. There was a big thing about spacial awareness years back, my brain works well like that, familiar brain paths for controls in certain places. But that relies on repetition. I pretty much always forget shell incantations. So any helper tools are a boon for me. Self described to GUI or richer UI would be welcome. If it's not already done. File explorer multi pick is the thing I desperately claw for for a pointer.
- planckscnst 6y ago
  I don't think there is a club to be in, but if you want to feel in the club about such things, just say something like "I expect that there is an option for like '-w whatever_madeupoption' that is useful here, but I'd have to take a look at the man page or use '--help' to know for sure". Be prepared to respond to "how would that work?" with APIs/syscalls/etc that you might use to implement that or say something like "I'm not sure, it sounds like an interesting problem if I had time to solve it"
- jcrawfordor 6y ago
  The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not all, Windows GUI conventions and keyboard shortcuts come from CUA, and this is its lasting legacy. That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands. Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities. And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified. This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX. Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).
msla 6y ago
GUIs have a nice ramp-up and a fixed ceiling, whereas command lines require you to climb a brick wall (the part where you learn enough commands to make it worthwhile, pretty much by rote) but, as long as they're scriptable, the ceiling is close to unlimited. (TUIs are, or can be, GUIs with box drawing characters instead of pixel displays. They're not necessarily any more scriptable or any less discoverable; however, a TUI on top of a command line, like Norton Commander or Midnight Commander, can be a real winner of a design paradigm.)
Animats 6y ago
The systems which did that, TOPS-20 and VMS, lost out to Unix, which didn't.
- jcrawfordor 6y ago
  By nearly the same token, though, one could say that Windows NT, which is for most practical purposes a descendant of VMS, implemented these ideas... and UNIX lost out to it. I think that some version of this dichotomy has existed at nearly every point of computer history where technology allowed it, and that is surprisingly far back!
  - Annatar 6y ago
    How did UNIX lose out to NT, when market forces coerced Microsoft to include a shoddy copycat version of UNIX named GNU/Linux inside of NT? That is almost the ultimate punishment for Dave "Gettabyte" Cutler, the father of NT and a notorious UNIX hater.
axiolite 6y ago
> If I don't remember the `df` command... what do I do apart from searching on the internet? I'd try "ls /bin" and see if any of the names sounded familiar or possibly relevant. Or "man -k space" which shows "df (1) - report file system disk space usage" on line 24, which isn't a lot of reading. GUI's aren't always intuitive. Nothing worse than not having the option in your right-click menu because you tried right-clicking in the left "explorer" column, but really needed to open the parent dir then right-click on the folder in the right-hand side. GUIs can be infinitely more difficult/complex. Back in the Win95 days, I recall a case where someone couldn't figure out how to format a floppy. After struggling for hours, he did a search which found format.exe, and used it. It's hard to discover that you can right-click on the drive to get the option, because there are many things that don't show up there... You can't create partitions or change drive letters in the right-click menu there, for example, but how would you know? You've got to learn the options/capabilities for your system, whether its GUI or CLI. What a GUI really has going for it, is that it offers a limited set of options, greatly simplifying the exploration. Something like Norton Commander, DOSBox or other limited/restricted shell (which shows only the most common commands) has similar discoverability benefits without the graphics, and still with those cli benefits available to you.
inetknght 6y ago
> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). No. One has to be trained to right-click. What about interfaces that don't have a right-click, such as a touch interface? Not only that, but the right-click menu has to be programmed. A lot of designers want minimalistic interfaces and would remove anything that isn't used often. So your right-click menu won't have those features. > TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder. Are you kidding?! I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! > In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. I've found plenty of GUIs that simply don't have what I want. Or... maybe they do have what I want but I couldn't find it.
- adwn 6y ago
  > What about interfaces that don't have a right-click, such as a touch interface? Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? > I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! For example?
  - inetknght 6y ago
    > Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a completely different interface so nothing is ever consistent even on the "same" operating system. > For example? Example 1: download one file from a url mentioned somewhere curl -fLsS "$(query for url)" -o ~/Downloads/file Example 2: download a bunch of PDF files cat ./file | grep -P '\.pdf$' | while read -r url; do curl -fLsS "${url}" -o ~/Downloads/"$(basename "${url}")"; done Example 2: move all PDFs that I just downloaded: mv ~/Downloads/*.pdf /path/to/pdfs Example 3: find what text file(s) have some text grep -nRIiw "magic" /path/with/content Example 4: find what pdf file(s) have some text find /path/to/pdfs -iname '*.pdf' -exec pdfgrep "magic" {} + Example 5: compare filenames in the two sets: sort <(grep -lRIiw "magic" /path/with/content | while read -r path; do basename "${path}" .txt; done) <(pdfgrep -l "magic" /path/to/pdfs | while read -r path; do basename "${path}" .pdf; done) | uniq And now, I have accepted a file from a team member which describes URLs to PDF reports with magic. I have generated a one-off report describing which files have magic content that needs to be reviewed because it contains magic that's described in in a local database. How about generating a git-diff, encrypting it, and emailing it? cat <(echo Subject: diff for the work you needed) <(gpg -a -u inetknght -r recipient -o - -e <(git diff new..old)) | sendmail recipient ... Okay so those one-off things are complex things. How about simple things? Example 6: move a file. mv ~/Downloads/foo ~/Documents/ Example 7: open a file xdg-open file Example 8: delete a file rm file Example 9: mount a thumb drive mount /dev/device /mnt/filesystem Example 10: unmount a thumb drive umount /mnt/filesystem Example 11: shutdown, and don't let any bad app stop the shutdown systemctl poweroff --force All of these are IMO easier than in a GUI
axelfreeman 6y ago
I think this is because of the "default" behaviour pattern. You can rightclick or do a context click on the most systems. Even on smartphones you can hold your finger on the file to get a context menue. This is not the case for cli. There is not global pattern like "context file" or "options file" that works on every cli. There are not a lot of easy common patterns in the cli world. Even for autocomplete you have to change the default shell on the popular systems.
ronyeh 6y ago
I like your point about discoverability. What if there was such a thing as a right click menu for command line programs? Like if I type ffmpeg or youtube-dl with no args, it lists the 3 most common ways to use it, and maybe allows an interactive CLI menu where you can build up the correct argument list by answering a few questions. I would love the most useful commands to look like: ffmpeg --resizeVideoTo input.mp4 50% (0.5 also works of course) youtube-dl --do-the-thing-you-know-i-want-to-do <YOUTUBE_URL> cd --show-a-menu-of-the-last-10-paths-i-changed-to git --i-fd-up-my-last-commit-please-help Most realistically, I'd want the invocation without arguments to show an interactive menu of the top 3 uses, so I could just select what I want to do. Or if I provide a partial argument list, it should ask me to supply the rest of the args. Or maybe it should guess and do the right thing. For example: ffmpeg input.mp4 >> What would you like to do with input.mp4? 1) resize 2) rotate 3) crop 4) change video format youtube-dl URL >> Download the best video for URL to the current path? Press Enter to confirm. cd >> Here are the last 5 paths you switched to. Choose 1...5. find >> Start typing a partial file name and we will show the top 10 matches from this path and its subdirectories. CTRL-<period> to turn on regular expression search.
- berkes 6y ago
  Would tab completion be a startingpoint for this?
  - ronyeh 6y ago
    Yes, I love tab completion. When I enabled tab completion for git and google cloud CLI, my life became much better. However, I still think there needs to be a "right click menu" for command line programs. Someone needs to determine the 3 most common uses and make it so that --help lets me choose one of them by pressing 1, 2, or 3. Right now, --help usually gives me something that is difficult for me to understand, especially if I have never used that command before. Tab completion works great if I have used the command before and want to save time.
    - berkes 6y ago
      hence the "starting point". Tab-completion could additionally list the "most common things given the context* I have". Tab-completion needs not nessecarily be postfix. I've seen completion tooling** that would work somewhat like `invoice.pdf<tab> -> `open invoice.pdf\n cp invoice.pdf` etc. And if `<tab>` conflicts, or breaks your mind because it must only work on postfix, it could be anything really, such as `<cmd>-r`. Additionally, or underlying, a reasonable simple command like `whatcan` or `ctxt` (context) could work and be leveraged: `whatcan invoice.pdf` -> a list of common commands given the context* I have. --- * Context I have would be your ~.\_history, the current directory-tree, permissions (why show `mv` if you don't have write access?), applications available, etc. pluggable maybe? ** e.g. the <ctrl>-r, interactive bash history search come to mind as pattern. But also tools like FZF https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an... that don't nessecarily only "complete" on tab, but may replace larger parts of the commandline.* Edit: formatting.
freeone3000 6y ago
Except modern UI design sort of threw the aspect of discoverability out the window. Context-sensitive elements, dependent elements, hidden elements, and the dreaded hamburger menu are all awful for discoverability, and they're present on nearly every GUI.
- incrudible 6y ago
  There's always a space tradeoff, of course. If you didn't make some things contextual or put them behind a menu, you'd have to find permanent space for it on-screen. At some point, your UI then turns into a "Find Waldo" scenario.
- yccs27 6y ago
  For everything negative you can say about modern UI patterns like the hamburger menu, lack of discoverability isn‘t one of them imho. You have a single button with an almost-standardized icon, from which you can get an overview of all the (non-context-sensitive) actions. Relative to menu bars, the actions are sorted more by their importance than some vague categories. (Where do you find Settings? Under File, Edit or Help? No, as a top-level entry of the hamburger menu.) Of course it has its own problems, like number of clicks...
  - TeMPOraL 6y ago
    Hamburger menus work because software that employs them is trivial. Often not far from a toy MVP. Discoverability is easy when there's not much to discover. All the pre-Web UI patterns start to shine when you're working with more powerful software tools - where there are more than half-dozen available actions, so you can't just stuff them under a single hamburger list. You have to start categorizing, grouping actions by their commonalities. You can't sort by importance, because importance changes from minute to minute. And menus of old were plenty discoverable. They weren't categorized for discoverability, because that's not the job of categorization. If you want to discover what the software can do, you spend 60 seconds expanding every single menu and reading available options. The categorization is there to introduce grouping concepts that are easy to remember, so that next time you're looking for an action you know (or suspect) exists, you know where to look for it.
Annatar 6y ago
what do I do apart from searching on the internet? On a real UNIX like HP-UX, IRIX, Solaris, FreeBSD or illumos (and any of its distributions), you'd run catman -w as root only once for the lifetime of the system, then run: man -k "disk space" and then you'd search for SEE ALSO with "/", eventually you'd run into df(1), under the very bad presumption that it isn't the first hit. EXAMPLE (Solaris 10, identical for illumos / SmartOS) > man -k "disk space" cfsadmin cfsadmin (1m) - administer disk space used for caching file systems with the Cache File-System (CacheFS) df df (1b) - display status of disk space on file systems df_ufs df_ufs (1m) - report free disk space on ufs file systems snmpdf snmpdf (1m) - get a listing of disk space usage on a remote machine by means of SNMP space space (4) - disk space requirement file df df (1) - report file system disk space usage df df (1gnu) - report file system disk space usage ...on a real UNIX, manual pages are THE resource, they are very comprehensive because they were written by professional documentation departments, respectively professional technical writers in those departments working with the actual engineers who developed the software. The manual page system on a real UNIX is designed to locate exactly the type of information you would be looking for quickly, efficiently and most importantly, consistently. It's GNU/Linux manual pages that are utter garbage, ergo switch to a system like SmartOS and never look back.
- adwn 6y ago
  > real UNIX [...] real UNIX [...] real UNIX Yes, we get it, you hate Linux. Your user profile page says as much. Get over it.
  - Annatar 6y ago
    Never! And Linux will go out of fashion soon anyway, as is the norm in IT.
vbsteven 6y ago
Does something like `apropos` in emacs exist for the shell? I've always seen that as a command to find a function or feature based on some keywords.
slightwinder 6y ago
> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate I think that's more a design-problem than actual trait of GUIs. GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells. > TUI/console is very good for interoperability/automation/muscle memory, TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript. > If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.
SPBS 6y ago
Text-based interface with fuzzy contextual autocomplete is the best of both worlds. Think of an IDE's autocomplete popups, but for terminal commands. Or how the Command Palette in means I almost never have to memorise where some obscure setting because I can just type the first few letters and find it as a top match. No such UI exists for terminal emulators because they don't work that way, but I'm convinced if someone made a program entirely around text with autocomplete it would be just as accessible to non-technical people.
bregma 6y ago
>GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file... You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable. My wife, for example, grew up before Windows 95 and its descendents were invented, holds multiple post-secondary degrees, and works with computers every day. She has no idea a second mouse button exists let alone that she can use it to perform file manipulation operations. She doesn't quite get the idea of "home directories" or "nested folders" or anything that is hidden like menus (or, frankly, tabs in the browser.. or multiple browser windows in fullscreen mode). Those things are not intuitive or discoverable in any way if you haven't been trained in their use. I, too, often forget the context menu is there although with practive I'm getting better. I certainly would never forget the `df` command though because it's second nature to me after over 40 years of use. People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar.
- ryanbrunner 6y ago
  You're right that there's some irreducible aspects to even GUIs that isn't intuitive and you just need to be told how to use it once, but GUIs have an advantage in that the overall 'language' of those things is far more limited at a basic level. Once you've figured out that mouse movements correspond to moving the pointer, clicking your left button usually means you want to do the primary interaction with whatever you're clicking on (opening a program, pressing a button, checking a checkbox), and right click gives you additional things you can do with the thing you're right clicking on, you've figured out enough to be able to at least use the system (I agree you're by no means proficient in it though). To get comparable proficiency with a command line requires a much larger set of things to remember for even basic usage.
- jodrellblank 6y ago
  > "People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar." That is not the argument they made, they said right-click acts as a "tell me what I can do with this file" discoverability tool, not that right-click is itself discoverable. There is approximately no way to discover this on a command line, but if you right-click and "play with Windows Media Player" is there, it tells you something useful. But I'm going to make the argument that it is discoverable. Why isn't the context menu second nature to you after over 25 years of use? You put your hand on the mouse, it has two buttons, you click one of them in ordinary operation, what kind of hyperbole is it to say that "clicking the second button does things" is "not discoverable in any way"? You discover that by accidentally mashing it one day, if nothing else.
globular-toast 6y ago
> I can right-click to see everything that can be done with the file, including some third party programs Everything? Almost certainly not! That is the main problem with GUIs. The "everything" is defined by the programmer, not the user. Sometimes that works for you, sometimes it doesn't. It's important not to confuse TUI with "console". TUIs are essentially the same as GUIs in this discussion. CLI (console) is completely different. CLIs use a language to describe what you need. To use an analogy, imagine ordering food in a restaurant. You could get away with pointing at the menu as long as you're happy with getting the default configuration. If you want to ask for no cheese, or less mayonnaise, you have to use language.
herbst 6y ago
Interestingly enough i have no idea how to see free space with an UI on my desktop. Once df is momorized there is no reason to ever use an UI
yabudemada 6y ago
I'm surprised there is a distinction between the two at this point. What we have are "user interfaces" and both are graphical, whether it's interacting with text or graphics. I think the main issues of usability are paradigm-independent—how do you make the UX more discoverable for text interfaces? How do you make the GUI more powerful and accessible to scripts? GUI development was introduced to make computers more tactile, and feel more life-like and accessible; and it works. The reason Text-UIs work better for automation is that programming languages these days are text-based. How might one shift to a more graphical-programming paradigm? Machine learning I think has a lot of potential in this area and I would love to see some new work in this space.
marcosdumay 6y ago
> f I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it. No OOP language can have a search feature as useful as Hoogle: https://hoogle.haskell.org/?hoogle=%5BMaybe+a%5D+-%3E+%5Ba%5D&scope=set%3Astackage https://hoogle.haskell.org/?hoogle=%5BMaybe+a%5D+-%3E+%5Ba%5...
Geezus_42 6y ago
I feel like the autocomplete offered by fzf with <command> * is a step in the right direction. I don't think it supports flags atm but that could probably be done with a script.
- Geezus_42 6y ago
  https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an...
dllthomas 6y ago
> `man -K "free space"` isn't very fruitful "free space" doesn't turn it up, but on my system only turns up one result that obviously isn't it, no big loss. "free" also doesn't turn it up, which seems like a missed opportunity. Going through the 40ish results before you're confident it's none of them is needlessly painful, but not crazy. Both "disk" and "space" do turn it up, though, and also surface du (amongst about 50 other things). I don't think scanning through <100 text items is clearly worse than digging through (say) the Windows control panel GUI. ~~~ I'd also note that TUI encompasses two kinds of thing - the utility in the shell (like df) and the captive interface that takes you away from your shell for an extended time as you navigate possible actions in some other manner. The latter has more of the benefits and drawbacks of a GUI. ~~~ In any case, I don't think your thesis is too far off, and I certainly welcome improvements to composability and discoverability across the board.

koolba 6y ago

> If I don't remember the `df` command... what do I do apart from searching on the internet? You can do that locally on the command line too! https://en.wikipedia.org/wiki/Apropos_(Unix) https://en.wikipedia.org/wiki/Apropos_(Unix)

homarp 6y ago
or man -k "disk space"
- aidenn0 6y ago
  disk space: nothing appropriate.
  - Annatar 6y ago
    As root run catman -w just once to (re)build the index. Results are guaranteed to be of high quality only on a real UNIX, preferrably one of open source Solaris (illumos) distributions, and likely FreeBSD.
  - homarp 6y ago
    on Ubuntu 18.04 this is what I got $ apropos "disk space" df (1) - report file system disk space usage $ man -k "disk space" df (1) - report file system disk space usage and $ man -k "disk usage" docker-system-df (1) - Show docker disk usage
- stjohnswarts 6y ago
  hmmm this one I didn't know :D
lanna 6y ago
But what if one doesn't remember the `apropos` command?
- koolba 6y ago
  Then you fire him and hire someone else.
- deleted 6y ago
  [deleted]
- Annatar 6y ago
  Then that person is the wrong person for the job.
- weinzierl 6y ago
  apropos apropos if you forget that apropos apropos apropos Recursion solves every problem;-) More seriously: You can alias it to something you can remember, for example: alias help=apropos
  - dredmorbius 6y ago
    'help' is already the shell's built-in help function in most cases. That'd be a poor choice of alias. There are a small number of seed keywords which are ueeful to know. 'help' (shell), 'apropos', 'man' (online manual), 'info' (GNU documentation), and dwww (local documentation presented through a Web interface, available on Debian-based Linux, see https://ostechnix.com/dwww-view-complete-debian-documentation-offline-via-web-browser/ https://ostechnix.com/dwww-view-complete-debian-documentatio...) are among them. Knowledge requires a certain baseline. If that's too much ... perhaps a GUI is in fact advisable.
- diffeomorphism 6y ago
  The same thing if someone does not remember there is a right mouse button?
  - lanna 6y ago

sbuttgereit 6y ago

A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discoverability you mention found in the GUI based system. It was just easier to use. This didn't come for free however. At a different client making the same transition from TUI based system to GUI based system (same target software), we measured the productivity of well trained staff and the TUI was well ahead in daily productivity. Now the different companies had different employment profiles; they were both retail businesses, but the first one that measured training was more decentralized and saw higher staff turnover rates and so cared more about training efficiency; the other had more centralized operations and so had fewer, more senior staff members with longer tenures where daily performance was a more important metric for efficiency. Now a TUI isn't the same as command line and most GUIs allow for substantial keyboard functionality, but I think developing for a TUI tends to get you thinking about a person working a keyboard whereas developing a GUI you're thinking more about the person with a mouse/trackball/trackpad/touchscreen. Personally, I do a lot of database work; mostly PostgreSQL. I decided some years ago to bite the bullet and get rid of the GUI and just use straight psql. I largely haven't looked back, though if I'm doing heavy development work I just started using DataGrip since it helps avoid stupid errors that a simpler text editor doesn't find.

xupybd 6y ago
Have you looked into pgcli, psql is great but pgcli is a little nicer. https://www.pgcli.com/ https://www.pgcli.com/
- sbuttgereit 6y ago
  I have, but it's been awhile since I looked. My recollection was that it felt sluggish, but that might be a false memory. I think what it brings to the table is helpful, but not enough for me to warrant it's use. When I'm writing simpler queries at the command line, I'm usually well within my knowledge of the databases I'm writing for or would have to appeal to something like the table definition anyway... which as I recall I couldn't really do in pgcli (start writing, flip to the table definition, pick up where I left off). When the sorts of things that pgcli does becomes most helpful is when I'm writing functions and procedures, but then the command line isn't well suited for that. That's where I'm finding something like DataGrip helpful: a database tool focused on development rather than administration. DataGrip has a lot of faults, but for the past couple of weeks I've been using it, it's been on balance a win.

drivers99 6y ago

> I can right-click to see everything that can be done with the file, including some third party programs Smart move by (for instance) Microsoft when they did that in Windows 95 and continued it til now. You could theoretically design the same functionality into a text user interface. Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) it could give you a menu to choose from context specific commands. It would seem pretty natural in that case if you are using post-fix (arguments(s) and then commands, like in Forth). Maybe something already exists like that.

yissp 6y ago
In bash I can type, for example, "git <tab><tab>" and it will list out all of the git commands. Not quite as nice as a menu, I suppose, but still helpful for discoverability.
a1369209993 6y ago
> Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) How about: $ file --help | grep util -u, --utils output utilities related to FILE $ file -u index.html index.html: HTML document, ASCII text, with very long lines cat index.html ed index.html lynx index.html
- drivers99 6y ago
  I meant like index.html <tab> And you’d get open, copy, rename, create symlink, delete, compress, etc.
  - a1369209993 6y ago
    That sounds like a GUI; how do I pipe [open, copy, rename, etc] into sed or awk? (Because the^Wa problem with GUIs is that the answer tends to be "Why would you want to do a wierd thing like that?".)
    - 6y ago

User23 6y ago

This reminds me of my first experience with (DEC) Unix at JHU. I had been a VMS user, so when I logged into the unfamiliar system I typed in "help." The JHU site admin had helpfully set the output of the help command to be, paraphrasing, "I see you know nothing about Unix, please talk to the staff member." He told me, "oh, in Unix help is spelled man." Obvious!

tuatoru 6y ago
Bash, at least, is more helpful these days. $help GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) These shell commands are defined internally. Type `help' to see this list. Type `help name' to find out more about the function `name'. Use `info bash' to find out more about the shell in general. Use `man -k' or `info' to find out more about commands not in this list. That last sentence in particular.

ta20210405 6y ago

GUIs are great, but not having a CLI is an anti-pattern. Also, having an API, but no reference CLI is an anti-pattern (depends on your API, but if your examples are poorly constructed bash scripts with cURL lines you need a proper CLI).

closeparen 6y ago

One thing that I hate to admit is great at this, is JIRA. It is definitely a UI centric product! But when I want to compose it with something, the REST API is right there. In fact, when a mostly-background system needs a human in the loop, sometimes we can grab JIRA to be our UI.

rewgs 6y ago

I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications? I see no technical reason for the lack of it. Look at something like htop -- it has a sort of "command line version of a macOS menu bar" with each menu selected by a function key. I could easily seeing this idea being extended to, say, being called by the familiar --help flag, or each menu visualizing a sub-menu upon pressing a function key, etc...there's no reason CLIs can't have the same discoverability as GUIs.

molasses 6y ago
There are shells that help with discovery. And auto completion helpers. These are great. You might infer from documentation. There was a big thing about spacial awareness years back, my brain works well like that, familiar brain paths for controls in certain places. But that relies on repetition. I pretty much always forget shell incantations. So any helper tools are a boon for me. Self described to GUI or richer UI would be welcome. If it's not already done. File explorer multi pick is the thing I desperately claw for for a pointer.
planckscnst 6y ago
I don't think there is a club to be in, but if you want to feel in the club about such things, just say something like "I expect that there is an option for like '-w whatever_madeupoption' that is useful here, but I'd have to take a look at the man page or use '--help' to know for sure". Be prepared to respond to "how would that work?" with APIs/syscalls/etc that you might use to implement that or say something like "I'm not sure, it sounds like an interesting problem if I had time to solve it"
jcrawfordor 6y ago
The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not all, Windows GUI conventions and keyboard shortcuts come from CUA, and this is its lasting legacy. That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands. Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities. And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified. This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX. Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).

msla 6y ago

GUIs have a nice ramp-up and a fixed ceiling, whereas command lines require you to climb a brick wall (the part where you learn enough commands to make it worthwhile, pretty much by rote) but, as long as they're scriptable, the ceiling is close to unlimited. (TUIs are, or can be, GUIs with box drawing characters instead of pixel displays. They're not necessarily any more scriptable or any less discoverable; however, a TUI on top of a command line, like Norton Commander or Midnight Commander, can be a real winner of a design paradigm.)

Animats 6y ago

The systems which did that, TOPS-20 and VMS, lost out to Unix, which didn't.

jcrawfordor 6y ago
By nearly the same token, though, one could say that Windows NT, which is for most practical purposes a descendant of VMS, implemented these ideas... and UNIX lost out to it. I think that some version of this dichotomy has existed at nearly every point of computer history where technology allowed it, and that is surprisingly far back!
- Annatar 6y ago
  How did UNIX lose out to NT, when market forces coerced Microsoft to include a shoddy copycat version of UNIX named GNU/Linux inside of NT? That is almost the ultimate punishment for Dave "Gettabyte" Cutler, the father of NT and a notorious UNIX hater.

axiolite 6y ago

> If I don't remember the `df` command... what do I do apart from searching on the internet? I'd try "ls /bin" and see if any of the names sounded familiar or possibly relevant. Or "man -k space" which shows "df (1) - report file system disk space usage" on line 24, which isn't a lot of reading. GUI's aren't always intuitive. Nothing worse than not having the option in your right-click menu because you tried right-clicking in the left "explorer" column, but really needed to open the parent dir then right-click on the folder in the right-hand side. GUIs can be infinitely more difficult/complex. Back in the Win95 days, I recall a case where someone couldn't figure out how to format a floppy. After struggling for hours, he did a search which found format.exe, and used it. It's hard to discover that you can right-click on the drive to get the option, because there are many things that don't show up there... You can't create partitions or change drive letters in the right-click menu there, for example, but how would you know? You've got to learn the options/capabilities for your system, whether its GUI or CLI. What a GUI really has going for it, is that it offers a limited set of options, greatly simplifying the exploration. Something like Norton Commander, DOSBox or other limited/restricted shell (which shows only the most common commands) has similar discoverability benefits without the graphics, and still with those cli benefits available to you.

inetknght 6y ago

> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). No. One has to be trained to right-click. What about interfaces that don't have a right-click, such as a touch interface? Not only that, but the right-click menu has to be programmed. A lot of designers want minimalistic interfaces and would remove anything that isn't used often. So your right-click menu won't have those features. > TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder. Are you kidding?! I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! > In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. I've found plenty of GUIs that simply don't have what I want. Or... maybe they do have what I want but I couldn't find it.

adwn 6y ago
> What about interfaces that don't have a right-click, such as a touch interface? Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? > I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! For example?
- inetknght 6y ago
  > Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a completely different interface so nothing is ever consistent even on the "same" operating system. > For example? Example 1: download one file from a url mentioned somewhere curl -fLsS "$(query for url)" -o ~/Downloads/file Example 2: download a bunch of PDF files cat ./file | grep -P '\.pdf$' | while read -r url; do curl -fLsS "${url}" -o ~/Downloads/"$(basename "${url}")"; done Example 2: move all PDFs that I just downloaded: mv ~/Downloads/*.pdf /path/to/pdfs Example 3: find what text file(s) have some text grep -nRIiw "magic" /path/with/content Example 4: find what pdf file(s) have some text find /path/to/pdfs -iname '*.pdf' -exec pdfgrep "magic" {} + Example 5: compare filenames in the two sets: sort <(grep -lRIiw "magic" /path/with/content | while read -r path; do basename "${path}" .txt; done) <(pdfgrep -l "magic" /path/to/pdfs | while read -r path; do basename "${path}" .pdf; done) | uniq And now, I have accepted a file from a team member which describes URLs to PDF reports with magic. I have generated a one-off report describing which files have magic content that needs to be reviewed because it contains magic that's described in in a local database. How about generating a git-diff, encrypting it, and emailing it? cat <(echo Subject: diff for the work you needed) <(gpg -a -u inetknght -r recipient -o - -e <(git diff new..old)) | sendmail recipient ... Okay so those one-off things are complex things. How about simple things? Example 6: move a file. mv ~/Downloads/foo ~/Documents/ Example 7: open a file xdg-open file Example 8: delete a file rm file Example 9: mount a thumb drive mount /dev/device /mnt/filesystem Example 10: unmount a thumb drive umount /mnt/filesystem Example 11: shutdown, and don't let any bad app stop the shutdown systemctl poweroff --force All of these are IMO easier than in a GUI

axelfreeman 6y ago

I think this is because of the "default" behaviour pattern. You can rightclick or do a context click on the most systems. Even on smartphones you can hold your finger on the file to get a context menue. This is not the case for cli. There is not global pattern like "context file" or "options file" that works on every cli. There are not a lot of easy common patterns in the cli world. Even for autocomplete you have to change the default shell on the popular systems.

ronyeh 6y ago

I like your point about discoverability. What if there was such a thing as a right click menu for command line programs? Like if I type ffmpeg or youtube-dl with no args, it lists the 3 most common ways to use it, and maybe allows an interactive CLI menu where you can build up the correct argument list by answering a few questions. I would love the most useful commands to look like: ffmpeg --resizeVideoTo input.mp4 50% (0.5 also works of course) youtube-dl --do-the-thing-you-know-i-want-to-do <YOUTUBE_URL> cd --show-a-menu-of-the-last-10-paths-i-changed-to git --i-fd-up-my-last-commit-please-help Most realistically, I'd want the invocation without arguments to show an interactive menu of the top 3 uses, so I could just select what I want to do. Or if I provide a partial argument list, it should ask me to supply the rest of the args. Or maybe it should guess and do the right thing. For example: ffmpeg input.mp4 >> What would you like to do with input.mp4? 1) resize 2) rotate 3) crop 4) change video format youtube-dl URL >> Download the best video for URL to the current path? Press Enter to confirm. cd >> Here are the last 5 paths you switched to. Choose 1...5. find >> Start typing a partial file name and we will show the top 10 matches from this path and its subdirectories. CTRL-<period> to turn on regular expression search.

berkes 6y ago
Would tab completion be a startingpoint for this?
- ronyeh 6y ago
  Yes, I love tab completion. When I enabled tab completion for git and google cloud CLI, my life became much better. However, I still think there needs to be a "right click menu" for command line programs. Someone needs to determine the 3 most common uses and make it so that --help lets me choose one of them by pressing 1, 2, or 3. Right now, --help usually gives me something that is difficult for me to understand, especially if I have never used that command before. Tab completion works great if I have used the command before and want to save time.
  - berkes 6y ago
    hence the "starting point". Tab-completion could additionally list the "most common things given the context* I have". Tab-completion needs not nessecarily be postfix. I've seen completion tooling** that would work somewhat like `invoice.pdf<tab> -> `open invoice.pdf\n cp invoice.pdf` etc. And if `<tab>` conflicts, or breaks your mind because it must only work on postfix, it could be anything really, such as `<cmd>-r`. Additionally, or underlying, a reasonable simple command like `whatcan` or `ctxt` (context) could work and be leveraged: `whatcan invoice.pdf` -> a list of common commands given the context* I have. --- * Context I have would be your ~.\_history, the current directory-tree, permissions (why show `mv` if you don't have write access?), applications available, etc. pluggable maybe? ** e.g. the <ctrl>-r, interactive bash history search come to mind as pattern. But also tools like FZF https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an... that don't nessecarily only "complete" on tab, but may replace larger parts of the commandline.* Edit: formatting.

freeone3000 6y ago

Except modern UI design sort of threw the aspect of discoverability out the window. Context-sensitive elements, dependent elements, hidden elements, and the dreaded hamburger menu are all awful for discoverability, and they're present on nearly every GUI.

incrudible 6y ago
There's always a space tradeoff, of course. If you didn't make some things contextual or put them behind a menu, you'd have to find permanent space for it on-screen. At some point, your UI then turns into a "Find Waldo" scenario.
yccs27 6y ago
For everything negative you can say about modern UI patterns like the hamburger menu, lack of discoverability isn‘t one of them imho. You have a single button with an almost-standardized icon, from which you can get an overview of all the (non-context-sensitive) actions. Relative to menu bars, the actions are sorted more by their importance than some vague categories. (Where do you find Settings? Under File, Edit or Help? No, as a top-level entry of the hamburger menu.) Of course it has its own problems, like number of clicks...
- TeMPOraL 6y ago
  Hamburger menus work because software that employs them is trivial. Often not far from a toy MVP. Discoverability is easy when there's not much to discover. All the pre-Web UI patterns start to shine when you're working with more powerful software tools - where there are more than half-dozen available actions, so you can't just stuff them under a single hamburger list. You have to start categorizing, grouping actions by their commonalities. You can't sort by importance, because importance changes from minute to minute. And menus of old were plenty discoverable. They weren't categorized for discoverability, because that's not the job of categorization. If you want to discover what the software can do, you spend 60 seconds expanding every single menu and reading available options. The categorization is there to introduce grouping concepts that are easy to remember, so that next time you're looking for an action you know (or suspect) exists, you know where to look for it.

Annatar 6y ago

what do I do apart from searching on the internet? On a real UNIX like HP-UX, IRIX, Solaris, FreeBSD or illumos (and any of its distributions), you'd run catman -w as root only once for the lifetime of the system, then run: man -k "disk space" and then you'd search for SEE ALSO with "/", eventually you'd run into df(1), under the very bad presumption that it isn't the first hit. EXAMPLE (Solaris 10, identical for illumos / SmartOS) > man -k "disk space" cfsadmin cfsadmin (1m) - administer disk space used for caching file systems with the Cache File-System (CacheFS) df df (1b) - display status of disk space on file systems df_ufs df_ufs (1m) - report free disk space on ufs file systems snmpdf snmpdf (1m) - get a listing of disk space usage on a remote machine by means of SNMP space space (4) - disk space requirement file df df (1) - report file system disk space usage df df (1gnu) - report file system disk space usage ...on a real UNIX, manual pages are THE resource, they are very comprehensive because they were written by professional documentation departments, respectively professional technical writers in those departments working with the actual engineers who developed the software. The manual page system on a real UNIX is designed to locate exactly the type of information you would be looking for quickly, efficiently and most importantly, consistently. It's GNU/Linux manual pages that are utter garbage, ergo switch to a system like SmartOS and never look back.

adwn 6y ago
> real UNIX [...] real UNIX [...] real UNIX Yes, we get it, you hate Linux. Your user profile page says as much. Get over it.
- Annatar 6y ago
  Never! And Linux will go out of fashion soon anyway, as is the norm in IT.

vbsteven 6y ago

Does something like `apropos` in emacs exist for the shell? I've always seen that as a command to find a function or feature based on some keywords.

slightwinder 6y ago

> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate I think that's more a design-problem than actual trait of GUIs. GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells. > TUI/console is very good for interoperability/automation/muscle memory, TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript. > If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.

SPBS 6y ago

Text-based interface with fuzzy contextual autocomplete is the best of both worlds. Think of an IDE's autocomplete popups, but for terminal commands. Or how the Command Palette in means I almost never have to memorise where some obscure setting because I can just type the first few letters and find it as a top match. No such UI exists for terminal emulators because they don't work that way, but I'm convinced if someone made a program entirely around text with autocomplete it would be just as accessible to non-technical people.

bregma 6y ago

>GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file... You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable. My wife, for example, grew up before Windows 95 and its descendents were invented, holds multiple post-secondary degrees, and works with computers every day. She has no idea a second mouse button exists let alone that she can use it to perform file manipulation operations. She doesn't quite get the idea of "home directories" or "nested folders" or anything that is hidden like menus (or, frankly, tabs in the browser.. or multiple browser windows in fullscreen mode). Those things are not intuitive or discoverable in any way if you haven't been trained in their use. I, too, often forget the context menu is there although with practive I'm getting better. I certainly would never forget the `df` command though because it's second nature to me after over 40 years of use. People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar.

ryanbrunner 6y ago
You're right that there's some irreducible aspects to even GUIs that isn't intuitive and you just need to be told how to use it once, but GUIs have an advantage in that the overall 'language' of those things is far more limited at a basic level. Once you've figured out that mouse movements correspond to moving the pointer, clicking your left button usually means you want to do the primary interaction with whatever you're clicking on (opening a program, pressing a button, checking a checkbox), and right click gives you additional things you can do with the thing you're right clicking on, you've figured out enough to be able to at least use the system (I agree you're by no means proficient in it though). To get comparable proficiency with a command line requires a much larger set of things to remember for even basic usage.
jodrellblank 6y ago
> "People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar." That is not the argument they made, they said right-click acts as a "tell me what I can do with this file" discoverability tool, not that right-click is itself discoverable. There is approximately no way to discover this on a command line, but if you right-click and "play with Windows Media Player" is there, it tells you something useful. But I'm going to make the argument that it is discoverable. Why isn't the context menu second nature to you after over 25 years of use? You put your hand on the mouse, it has two buttons, you click one of them in ordinary operation, what kind of hyperbole is it to say that "clicking the second button does things" is "not discoverable in any way"? You discover that by accidentally mashing it one day, if nothing else.

globular-toast 6y ago

> I can right-click to see everything that can be done with the file, including some third party programs Everything? Almost certainly not! That is the main problem with GUIs. The "everything" is defined by the programmer, not the user. Sometimes that works for you, sometimes it doesn't. It's important not to confuse TUI with "console". TUIs are essentially the same as GUIs in this discussion. CLI (console) is completely different. CLIs use a language to describe what you need. To use an analogy, imagine ordering food in a restaurant. You could get away with pointing at the menu as long as you're happy with getting the default configuration. If you want to ask for no cheese, or less mayonnaise, you have to use language.

herbst 6y ago

Interestingly enough i have no idea how to see free space with an UI on my desktop. Once df is momorized there is no reason to ever use an UI

yabudemada 6y ago

I'm surprised there is a distinction between the two at this point. What we have are "user interfaces" and both are graphical, whether it's interacting with text or graphics. I think the main issues of usability are paradigm-independent—how do you make the UX more discoverable for text interfaces? How do you make the GUI more powerful and accessible to scripts? GUI development was introduced to make computers more tactile, and feel more life-like and accessible; and it works. The reason Text-UIs work better for automation is that programming languages these days are text-based. How might one shift to a more graphical-programming paradigm? Machine learning I think has a lot of potential in this area and I would love to see some new work in this space.

marcosdumay 6y ago

> f I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it. No OOP language can have a search feature as useful as Hoogle: https://hoogle.haskell.org/?hoogle=%5BMaybe+a%5D+-%3E+%5Ba%5D&scope=set%3Astackage https://hoogle.haskell.org/?hoogle=%5BMaybe+a%5D+-%3E+%5Ba%5...

Geezus_42 6y ago

I feel like the autocomplete offered by fzf with <command> * is a step in the right direction. I don't think it supports flags atm but that could probably be done with a script.

Geezus_42 6y ago
https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an...

dllthomas 6y ago

> `man -K "free space"` isn't very fruitful "free space" doesn't turn it up, but on my system only turns up one result that obviously isn't it, no big loss. "free" also doesn't turn it up, which seems like a missed opportunity. Going through the 40ish results before you're confident it's none of them is needlessly painful, but not crazy. Both "disk" and "space" do turn it up, though, and also surface du (amongst about 50 other things). I don't think scanning through <100 text items is clearly worse than digging through (say) the Windows control panel GUI. ~~~ I'd also note that TUI encompasses two kinds of thing - the utility in the shell (like df) and the captive interface that takes you away from your shell for an extended time as you navigate possible actions in some other manner. The latter has more of the benefits and drawbacks of a GUI. ~~~ In any case, I don't think your thesis is too far off, and I certainly welcome improvements to composability and discoverability across the board.