5 ms·

I'd conservatively estimate 90% of the people who make core FOSS software interface decisions haven't had to learn anything technical in an entirely unfamiliar

I'd conservatively estimate 90% of the people who make core FOSS software interface decisions haven't had to learn anything technical in an entirely unfamiliar domain where there existing mental models didn't apply in decades. Beyond that, many consider having learned these arbitrary, terse interfaces as a badge of honor, and for some reason thinks that makes them better technologists. I'll bet they'd be even better had they been able to focus on the core concepts rather than trying to get into some systems engineer's head who worked at Berkley in 1984.

TheNewsIsHere 3y ago
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.
- chefandy 3y ago
  > 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.
dahfizz 3y ago
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.
- tmpX7dMeXU 3y ago
  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.
  - hitpointdrew 3y ago
    > 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.
    - chefandy 3y ago

TheNewsIsHere 3y ago

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.

chefandy 3y ago
> 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.

dahfizz 3y ago

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.

tmpX7dMeXU 3y ago
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.
- hitpointdrew 3y ago
  > 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.
  - chefandy 3y ago