I think of this in the same way I think of documentation. I try to write documentation that is as clear as it is concise and well structured. But sometimes that’s just not realistically possible, and expressing information often _has_ to assume some level of familiarity with the underlying concepts.

I’ve never considered DNS to be a complicated technology, and I’ve never considered that tools like dig and the abbreviations they use need to change much. If there’s something that isn’t clear, it’ll be in the man page, a mailing list, Internet based documentation, StackOverflow, etc.

Personally, I value information density, and I don’t mind terseness at all.

That doesn’t necessarily mean I would design some of this stuff the same way, but after more than a decade using it, I feel like changing it now is just an appeal to futility. A tool like dig more or less looks and works the same today as it did 15 years ago, and there’s value in that kind of stability.

> but after more than a decade using it, I feel like changing it now is just an appeal to futility

And that's why your learning to use these tools a decade ago was as painful as it was for me 20+ years ago, and so on. Nobody improves it because the only people with the clout to make the changes is too set in their ways to change it, and have come to believe the ridiculous notion that it's beneficial for people to learn it, despite not being related to the actual problem.

I worked in technical roles for the better part of 25 years, including 10 as a back end developer. One of the reasons I got into design was to try and break chains like this, but talking to the FOSS community about design gets nearly zero traction and a whole lot of pushback from folks who think they know a lot more about design than they do. Nothing you do matches the information density of a train schedule in a large city, and those designs are so ubiquitous and intuitive that we take them for granted. That was not always the case— someone decided to lay things out like that at some point because they knew it works be easier and more intuitive for the majority even if it might take some adjustment for existing everyday users. And designers still work to make them better, to this day.

I wrote a tutorial teaching non-technical folks to use a rest API. It required no knowledge beyond familiarity with using web browsers, and ended with people making useful queries with curl. It was short, visual, and effective- I learned that multiple non-profits at the time used it in their materials to teach folks technical literacy. Just because using a bunch of terse jargon is easier for developers to write and acceptable for other developers to read doesn't mean it's optimal... Or even good. Especially when the realm world be much more accessible to non-technical people if it was designed better.

I disagree.

The CLI is inherently a super-user oriented interface. The CLI needs to let an experienced user be as productive as possible.

If you need a pretty UI with everything spelled out, you should go on GitHub and find a GUI that someone built on top of the core tool. But dumbing down the core tool is not the way to go.

The --help message should be good, and the man page needs to be good, but the tool itself should favor power and productivity over handholding someone who doesn't want to Google a how-to.

This is full of false dichotomy. Making things more understandable isn’t “dumbing them down”. There isn’t necessarily a trade-off. An application being CLI-based is not a get out of jail free card for UX critiques, nor is it an implication that it’s for power-users. You can’t just put the minimum viable effort into considering how someone will use your software without any thought to intuitive mental models and cry “it’s for power users”.

Old-school FOSS nerds have a hard time admitting that they tend to be absolutely useless at considering user experience, because then that’s something On Computers that they’re not good at. The best they can do is shoo it away by claiming that the sort of UX concerns I’m talking about only apply to software used by Lesser Beings and not Smart Computer Boys such as themselves.

It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

> nor is it an implication that it’s for power-users.

Yes it is. As an administrator being a CLI tool means that I can automate configs and deployment with ansible or Nix OS. I would argue doing these sorts of automation what are what “power-users” would do.

GUI’s often lack any sort of automation capability or have some half-cocked API that usually lacks features or endpoints that would be trivial if the thing was just a CLI tool with a config file.

Good interface design absolutely does not require a gui. When I first encountered a BSD distro that used ports, that was a huge interface improvement. Then Deb or whatever beyond that.

Using sane labels and coherent layouts isn't dumbing anything down. You can make things easier for humans while having sane interfaces for scripting. Redirecting the output of `ls` and similar commands automatically change the layout to something easy for cli i/o manipulation.

We realized long long ago that the API and human-facing interfaces are often better when separated, which is why I don't browse the web with curl... or maybe telnet.

> Old-school FOSS nerds have a hard time admitting that they tend to be absolutely useless at considering user experience, because then that’s something On Computers that they’re not good at.

New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running. What I need are tools that give me the exact information I need quickly and get the fuck out of my way for everything else.

> It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

I've been using Linux for 25 years, spent 6 or so years doing administration type work on large Unix systems and spent 10 years in a back-end developer role. I've somewhere in the high five figure range of hours spent contributing to FOSS software. More recently, I've gotten formal interface design education and worked in design roles. I am not a 'new school' FOSS nerd by any measure.

> New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running.

The reason you find them more productive is because you already know how to use them. Needlessly reduced information density is usually a bandaid applied to a shitty, confusing interface by a non-designer because they don't know how to organize it to be easily parsable, but still dense. Maybe denser than before. You don't even realize when a good designer has done a good job because it just makes sense— it's so intuitive and useful to cite users that you don't have to think about it. If it it's a utilitarian tool that "looks designed," it was probably a non-designer trying to gussy it up, or "work on UX" without realizing that means a lot more than white space, colors, and fonts. A solid understanding of visual hierarchy would solve at list half of FOSS interface problems without changing anything other than layout. The problem is project maintainers who think any attempt to remediate their non-designed cobbled-together interface is an attack by the 'new school' or what have you and either dismiss it out of hand, or reflexively bikeshed any proposal into oblivion because they're defensive, and lack the design sophistication to knowledgeably engage. As a senior developer and someone who enrolled in art school as an adult, I know how much more defensive people get about work they're not confident in. When those people are in charge of a project AND have the misguided notion that their "design" (read as cobbled-together assembly of user-facing functionality) is more functional than an expert's design, just uglier, good luck pushing change through.

> Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

And fraternities keep paddling pledges and making them drink gallons of grain alcohol because they all had to do it too, so everybody else should. Complaining that nobody wants to spend time studying something that they wouldn't have to if it was properly designed is an asinine argument against progress. The only people here who should be chastised for refusing to learn new things are the people who refuse to consider better approaches and insist everybody else learn the same inscrutable incantations they did, because it's easier for them... Because they already know them. Just because you can't imagine productive ways to update these tools to a post-teletype world doesn't mean that nobody can.

> I've been using Linux for 25 years, spent 6 or so years doing administration type work on large Unix systems, and spent 10 years in a back-end developer role. I've somewhere in the high five figure range of hours spent contributing to FOSS software. More recently, I've gotten formal interface design education and worked in design roles. I am not a 'new school' FOSS nerd by any measure.

If you have trouble with tools like dig, you have wasted a lot of fucking time.

Edgy. Asserting that my deep consideration and professional concern with usability means that I don't understand the software is the most deliberately obtuse thing I've read this week, and I browsed Slashdot comments.

Measuring usability by your own comfort level is the reason user-facing "open source alternatives" that aren't foundation-backed with dedicated designers will remain "alternative" in perpetuity.

I disagree.

I'm a super-user and as such I have to use hundreds of tools to GTD. What you call “pretty UI” I call ergonomics. So I appreciate when the tooling is respectful of my time and don’t require me to visit the man page just because the developer was so situational myopic that thought sparing a few characters was a good idea.

It all smells like unconscious gatekeeping.

And don't get me started on undocumented parts of CLIs, which are unknown unknowns, especially when they hold core parts of the API.

RTFM is usually (not always) a way to gatekeep bad UX.

Right. There USED to be good reasons to have that be the way classic CLI utilities worked— your terminal had 80 character lines, you might be working over a 300 baud modem, you might be using a teletype terminal and you didn't want to waste paper, having machine-focused output and human-focused output was too resource Intensive... All of that is gone now.

You are seriously taking the position that writing “received” instead of “rcvd” is “dumbing down”?

Someone who knows what information to expect doesn't even need a label. Once you're past that hurdle, it's redundant.

For instance, you look at the dash of your car every time you drive, and what little is labeled is abbreviated. The expectation is that when you understand how the vehicle operates, the gauges and lights will make sense. The information is encoded behind your knowledge. dig isn't really different.

Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

KPH/MPH are ubiquitous standard abbreviations that exactly zero percent of people encounter for the first time when they drive for the first time. Occasional and brand new drivers will never not know what those things mean. Kilometers Per Hour is also 600% larger than KPH, and visual clutter while driving at highway speeds is a much bigger problem than when examining DNS records.

> Once you're past that hurdle, it's redundant.

Yeah, then multiply that hurdle times the thousand others someone has to memorize to work in *nix.

> Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

Textual output on a computer is a communication medium-- hammers and firearms are not.

A) dumbed-down interfaces are bad design; Most you see were made by developees trying to be designy. No shade— it's a different profession with relevant degrees and career paths, and most designers would make terrible code if they tried. B) Good interface design absolutely does not require a gui. I've been professionally using (and loving) these tips for decades, but many cross the border from negligent to user hostile. C) Download SideFX HOUDINI, which has a nice pretty interface and is fully scriptable with python and it's own language, vex, and tell me that's "dumbed down."

*Loving these tools for decades