There's a million things with manuals to read. I would rather grab something that just works in an obvious way.

This is oddly sad to me. It's like hearing somebody say that you don't need to read a book when you can just watch the movie adaptation. You're missing out on so much depth and growth potential by just settling for the easiest option.

Maybe I'm just a weirdo. I love reading manuals and discovering interesting nuances in the things I use every day. Or picking some new software at random and learning about it just because it's fun and interesting.

It’s oddly sad to me that you (and so many others) see interfaces adopting more intuitive and inclusive idioms and reducing the barriers to entry while becoming even more powerful as regressions.

Software is interesting and fun in different ways to different people; most people find tools accomplishing their goals with as little overhead as possible far more fun than reading technical docs. Not saying you’re wrong to like reading manuals, but it’s not a moral failure to have a cognitive profile, or heck, even a schedule that’s meaningfully hindered by your daily toolbox having reading prerequisites.

They are not inclusive. They are dumbed down, and by dumbing them down they are less powerful. Or at least less powerful than they could have been.

I don't get that allergy to reading. For a long time it has been accepted that you had to read a manual before using something relatively complex, as not everything can be expressed intuitively, and because intuition is not really universal.

> For a long time it has been accepted that you had to read a manual before using something relatively complex, as not everything can be expressed intuitively, and because intuition is not really universal.

Do you know how many pages of software documentation the average person will read in their entire life? Zero. Why? They don't have to, and imposing that requirement yields no benefit. I'm always astonished by the perennial hubris required to glibly assert chemical engineers or historians or teachers or physicists or lawyers or doctors or librarians or literature professors (or even other developers who want to concentrate on other tasks) only avoid software tools with prerequisite study because they're too lazy to read.

The purpose of software is to help people more easily solve their problems. The bigger the barrier to entry— prerequisite study for example— the harder it is for most people. That's acceptable if the complexity is genuinely necessary to afford or augment expert usability in purpose-built software, but it almost universally compensates for ham fisted interface design. Interfaces that stop expert users from doing things efficiently and only afford beginner workflows are also poorly designed. Expert vs dumbed down is a false dichotomy.

For many FOSS developers and users, tolerating counterintuitive interfaces turned into a badge of honor, and that turned into an aesthetic preference. It's not the default state of software, it does exclude non-technologists, and is why FOSS alternatives are still alternatives for every application not specifically designed to be used by technologists, even though they're free. Every single one. Every professional photographer on the planet who relies on Adobe Photoshop would jump for joy if Gimp even came close to being a sufficient replacement. That preference is also why developers don't generally make significant interface decisions in any professionally managed software project.

Not having a technologist's domain knowledge or priorities isn't a contemptible moral failure. Having it doesn't come with design expertise— learning design takes a lot of study and practice, but I'm guessing you have other things you'd prefer to concentrate on learning. Which is fine. Just realize that assuming documentation is sufficient to guide users through software is primarily informed by your not understanding software usability rather than everybody else misgauging the importance of software documentation.

The dumbing down has other reasons, mainly mobile ones. It's sad to see.

Fwiw, there's a pretty decent discussion of the "expert/trained" interface vs the "beginner" interface in Theirry Bardini's book about Douglas Engelbart.

Engelbart assumed people wanted an interface for "trained experts" -- the idea being computer applications were important enough for people to invest time in learning new concepts to make their work more efficient.

Larry Tessler and others argued you should present a beginner's interface based on existing metaphor. Larry eventually went on to work at PARC and Apple where his work inspired (and frustrated) generations of computer users.

Boarding noted that Tessler (and others in PARC) needed a raision d'etre inside the Xerox organization and partially used "building document handling systems for secretaries" to justify their budget. Kay was well known at the time for wanting to use computers in education, so it's no wonder the interface Jobs saw at PARC was one tweaked for beginners.

Interesting anecdote, but a vast oversimplification of beginner and expert needs that was formed in the infancy of computer interfaces.

Not op but I’ve got 25 years of daily computer use under me. I’m tired of having to read manuals and try to figure out the latest popular app. Software should be better these days, more intuitive to use, more interoperability between applications, data should be even more portable.

This isn’t to say I don’t enjoy learning apps anymore, I just have to guard my time more wisely.

Congratulations on the daily use. I think the point of this article is exactly the opposite of having to read new things every day. It is to read the old things once with the insinuation that the skill will translate to other things as well.

I've used Emacs for 30 years, and still do. I know enough keybindings to get by. Under the hood, everything I do is Linux. I love i3wm and Pop Shell. My main rig uses Linux as the base os (which is mostly used as a hypervisor, for security reasons).

Still, as front-end, I find myself mostly working through Windows VM's, on top of KVM. I pass through most of the hardware (usb controller, the main GPU), and get a native windows experience. Most work happens through Chrome, VS Code and Windows Termnal. I use PowerToys to get some kind of tiling window manager.

There are two reasons for this. One is that my workplace has security setups for Windows and Mac, but not linux. I can grant them full control over the VM I use for work, and can use the standard setup for vpn, etc, as well as ability to use all corporate resources with no pain or hacks.

The other is that a lot of things are more painless. Working across multiple monitors requires less setup, scaling 4k "just works", most hardware and front-end software I use behave as-well or better than on linux (particularly webcam + Teams, that I depend on heavily).

Also, as editor, I still use emacs for some things, when I just want to edit some file in a random directory.

But for development work, I've switched to VS code. The ability to ssh into any remote VM, container, etc, and be able to work directly on a remote server, complete with gitlens, debuggers, file browsers, shell access, etc, is a killer app for me. I also love the pane management, which provides the tiling window manager functionality I love from i3/Pop Shell. (Power Toys is ok, but not quite as efficient for me as i3.) Emacs CAN be set up to do those things, but that takes more effort, I feel, and still not the same user experience.

+1. I use emacs as my daily driver. Plus some tools I wrote myself to evaluate C# and JavaScript. Every now and again I hop over to a jetbrains tool.

I was slightly disappointed by i3 and xmonad and built my own WM in lisp.

In the old days we used to write our own tools by extending and combining existing tools. Now people seem to just download python and use whatever library comes with it after a day or two of experimentation

Or you could read the manual for one app and use it for a long time.

I don't see the comparison holding water. The difference is between a tool that servers a purpose and reading or watching something is that sometimes I just need the tool to get out of my way. The added depth available takes up time and mental resources to learn, potentially far in excess of how regularly I use the tool or how critically I need that functionality.

This is especially true where there's a selection of tools that all work within a similar "market" space for X functionality - some are going to be less complex, some more intuitive for me personally, some fulfill a one-off need and their other functionality is duplicated by another system I know much better (and have put the time into learning).

That shouldn't take away from your enjoyment of reading through minutiae of various systems, but you can't reasonably expect a lot of people to match your enthusiasm for doing so.

Meh. My tools aren't written for other people. They can do whatever they want. But bitching about how a tool they didn't pay for that was originally written for a different purpose requires them to read something is kind of funny.

It's entirely possible there's a community of people out there who don't mind reading about abstractions exported by tools. Especially if it means you'll save time in the long run.

The original post seemed to me to be a mild introduction to the concept that maybe you can get your job done more efficiently with extensible / combinable simple tools rather than waiting for someone to add a feature to Gnome.

It's totally fine if you don't want to do that. If the person in the cube next to you does that, how is this an insult to you?

Maybe you're not the audience for this article.

I prefer both. I like when something works right out of the box. And then I read the manual and find out about all those moments when the defaults were saving me from my foolishness. And then I can unfold the thing's real potential.