Free software scares normal people

Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With interface design, everybody knows what a button does and what a text field is for, and developers know more than most about the tools used to create interfaces, so the language seems simple. The problems you need to solve with that language are complex and while failure is obvious, success is much more nebulous and user-specific. So much of what good interfaces convey to users is implied rather than expressed, and that’s a tricky task.

It always amazes me how even just regular every day users will come to me with something like this:

Overly simplified example:

"Can you make this button do X?" where the existing button in so many ways is only distantly connected to X. And then they get stuck on the idea that THAT button has to be where the thing happens, and they stick with it even if you explain that the usual function of that button is Y.

I simplified it saying button, but this applies to processes and other things. I think users sometimes think picking a common thing, button or process that sort of does what they want is the right entry point to discuss changes and maybe they think that somehow saves time / developer effort. Where in reality, just a new button is in fact an easier and less risky place to start.

I didn't say that very well, but I wonder if that plays a part in the endless adding of complexity to UI where users grasp onto a given button, function, or process and "just" want to alter it a little ... and it never ends until it all breaks down.

The contributors of free software tend to be power users who want to ensure their use case works. I don't think they're investing a lot of thought into the 80/20 use case for normal/majority or users or would risk hurting their workflow to make it easier for others

> It takes a single strong-willed defender, or some sort of onerous management structure...

I'd say it's even more than you've stated. Not only for defending an existing project, but even for getting a project going in the first place a dictator* is needed.

I'm willing to be proven wrong, and I know this flies in the face of common scrum-team-everybody-owns approaches.

* benevolent or otherwise

It's my belief that much of this flavor of UI/UX degradation can be avoided by employing a simple but criminally underutilized idea in the software world (FOSS portion included), which is feature freezing.

That is, either determine what the optimal set of features is from the outset, design around that, and freeze or organically reach the optimium and then freeze. After implementing the target feature set, nearly all engineering resources are dedicated to bug fixes and efficiency improvements. New features can be added only after passing through a rigorous gauntlet of reviews that determine if the value of the feature's addition is worth the inherent disruption and impact to stability and resource consumption, and if so, approaching its integration into the existing UI with a holistic approach (as opposed to the usual careless bolt-on approach).

Naturally, there are some types of software where requirements are too fast-moving for this to be practical, but I would hazard a guess that it would work for the overwhelming majority of use cases which have been solved problems for a decade or more and the required level of flux is in reality extremely low.

It does shed light on a possibly better solution though that gives the user a list of simple, common use case options or access to the full interface.

I do feel quite strongly that this should be implemented in the app though.

There must be examples of this approach already being used?

Good points, but to add to the sources of instability ... a first time user of a piece of software may be very appreciative of its simplicity and "intuitiveness". However, if it is a tool that they spend a lot of time with and is connected to a potentially complex workflow, it won't be long before even they are asking for "this little extra thing".

It is hard to overestimate the difference between creating tools for people who use the tools for hours every day and creating tools for people who use tools once a week or less.

> to prevent the interface from quickly devolving back into the million options

Microsoft for a loooong time had that figured out pretty well:

- The stuff that people needed every day and liked to customize the most was directly reachable. Right click on the desktop, that offered a shortcut to the CPL for display and desktop symbols.

- More detailed stuff? A CPL that could be reached from the System Settings

- Stuff that was low level but still needed to be exposed somewhat? msconfig.

- Stuff that you'd need to touch very rarely, but absolutely needed the option to customize it for entire fleets? Group Policy.

- Really REALLY exotic stuff? Registry only.

In the end it all was Registry under the hood, but there were so many options to access these registry keys depending what level of user you were. Nowadays? It's a fucking nightmare, the last truly decent Windows was 7, 10 is "barely acceptable" in my eyes and Windows 11 can go and die in a fire.

One summer in middle school our family computer failed. We bought a new motherboard from Microcenter but it didn’t come with a Windows license, so I proposed we just try Ubuntu for a while.

My mom had no trouble adjusting to it. It was all just computer to her in some ways.

Familiarity is massively undersold in the Linux desktop adoption discussion. Having desktop environments that are near 1:1 clones of the commercial platforms (preferably paired with a distribution that's designed to be bulletproof and practically never requires its user to fire up a terminal window) would go so far for making Linux viable for users sitting in the middle of the bell curve of technical capability.

It's one of those situations where "close enough" isn't. The fine details matter.

It's easy to make the powerful version

It's a little harder to make an easy version

Making the progressive version is very difficult. Where you can please one audience with the powerful and easy versions, you can often disappoint both with the progressive version despite it taking much more effort.

In my personal experience, you're lucky if free software has the budget (time or money) to get to easy. There's very little free software that makes it to progressive.

this is the way

If you only care about converting media without tweaking anything, ffmpeg offers the simplest UI ever.

    ffmpeg -i input.avi output.mp4

I actually think ffmpeg’s UI is simpler than Handbrake for those at all acquainted with the command line (i.e., for those who understand the concept of text-is-everything-everything-is-text). Handbrake shows you everything you can possibly fiddle with whether or not you plan on fiddling with it. Meanwhile ffmpeg hides everything, period, and you ask for specific features by typing them out. It's not great for discovery but once you get the hang of it, it is incredibly precise. One could imagine taking someone for whom Handbrake was too much and showing them “look, you just type `ffmpeg -i`, the input file, and the output file, and it does what you want”. I imagine for many people this would be a perfectly lovely interface.

At least with ffmpeg, for 99% of use cases you can just google "how do I do X with ffmpeg" and get a copypasta command line.

Whereas with complicated GUI tools, you have to watch a video to learn how to do it.

Yes. It's been a few years since I regularly used Handbrake, but I remember thinking of it as very simple, especially with its presets-based workflow. I was used to stuff like various CLI tools, mkvmerge and its GUI, and avidemux at that time.

It struck me as a weird example in the OP because I don't really think of Handbrake as a power user tool.

Handbrake's UI is in the uncanny valley for me -- too complicated for use by laymen, and way too limiting for use by people who know what they're doing...

imo LLMs make all of these UIs unnecessary, i'm happy to use ffmpeg now

It takes a lot of time and energy to refine and maintain a minimalistic interface. You are intentionally narrowing the audience. If you are an open source developer with limited time you probably aren't going to invest in that.

> The problem is that everyone wants a different 20% of the functionality.

I'm not disagreeing with your basic take, but I think this part is a little more subtle.

I'd argue that 80% of users (by raw user count) do want roughly the same 20% of functionality, most of the time.

The problem in FOSS is that average user in the FOSS ecosystem is not remotely close to the profile of that 80%. The average FOSS user is part of the 1% of power users. They actively want something different and don't even understand the mindset of the other 80% of users.

When someone comes along to a FOSS project and honestly tries to rebuild it for the 80% of users, they often end up getting a lot of hate from the established FOSS community because they just have totally different needs. It's like they don't even speak the same language.

Resources or the care, tbh. FOSS is a big umbrella and a lot of it simply isn't meant for "customers". Some FOSS apps clearly are trying to build a user base, in which case yeah the points this post makes are worth thinking about.

But many other projects, perhaps the majority, that is not their goal. By devs for devs, and I don't think there is anything wrong with that.

Pleasing customers is incredibly difficult and a never-ending treadmill. If it's not the goal then it's not a failure.

For a lot of usecases there is a strong 80% functionality. E.g. For Handbrake, 80% of the time I am reducing the size of my video screen grabs from my computer or phone. Don't need any resolution change, etc.

There are other times I want cropping or something similar, but it's really only 10-30% of the time. If people want to have a more custom workflow they can use an advanced UI

> tends to require a tight feedback loop between testers, designers, implementers, and users

Some FOSS projects attempt something like this, but it can become a self-reinforcing feedback loop: When you're only testing on current users, you're selecting for people who already use the software. People who already use the software were not scared away by the interface. So the current users tend to prefer the current interface.

Big software companies have the resources to gather (and pay) people for user studies to see what works and what does not for people who haven't seen the software before, or at least don't have any allegiances. If you only ever get feedback from people who have been using the software for a decade, they're going to tell you the UI must not change because they know exactly how to use it by now.

FOSS is ~99% developers, ask anyone in UI/UX to contribute to free projects and they'll look at you like you have two heads.