[squeedles]

Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

[DrewADesign]

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.

[makeitdouble]

> creating good interfaces (for people that aren’t developers.)

This is the part where people get excited about AI. I personally think they're dead wrong on the process, but strongly empathize with that end goal.

Giving people the power to make the interfaces they need is the most enduring solution to this issue. We had attempts like HyperCard or Delphi, or Access forms. We still get Excel forms, Google forms etc.

Having tools to incrementaly try stuff without having to ask the IT department is IMHO the best way forward, and we could look at those as prototypes for more robust applications to create from there.

Now, if we could find a way to aggregate these ad hoc apps in an OSS way...

[finghin]

It’s also about keeping things simple, hierarchical, and very predictable. These do not go hand in hand with the feature creep of collaborative FOSS projects, as others point out here.

[LtWorf]

> Overall, the development world does not intuitively understand the difficulty of creating good interfaces

Nor can the design world, for that matter. They think that making slightly darker gray text on gray background using a tiny font and leaving loads of empty space is peak design. Meanwhile my father cannot use most websites because of this.

[dhosek]

In the 90s I did a tech writing gig documenting some custom software a company had built for them by one of the big consultancy agencies. It was a bit of a nightmare as the functionality was arranged in a way that reflected the underlying architecture of the program rather than the users’ workflows. Although I suppose if they’d written the software well, I wouldn’t have had as many billable hours writing documentation.

[ozgrakkurt]

IMO they just don’t care enough. They want people to use it but it is not the end of world if it stays niche

[max51]

>Overall, the development world does not intuitively understand the difficulty of creating good interfaces

I think it's because they are not using the product they are designing. A lot of problems you typically see in modern UIs would have been fixed before release if the people writing it were forced to use it daily for their job.

For example, dropdown menus with 95 elements and no search/filter function that are too small and only allow you to see 3 lines at a time.

[hilong2]

One thing I still struggle with is writing interfaces for complex use cases in an intuitive and simple manner that minimizes required movements and context switching.

Are there any good resources for developing good UX for necessarily complex use cases?

[zahlman]

> I think that can give developers a mistaken impression that other peoples work is far less complex than it is.

Not at all. Talented human artists still impress me as doing the same level of deep "wizardry" that programmers are stereotyped with.

[dayvid]

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

[BinaryIgor]

True; that's why we have companies with paid product who devote a lot of their time - arguably majority - to make the exact interfaces people want and understand:) it's a ton, a ton of difficult work, for which there is little to no incentive in the free software ecosystem

[psunavy03]

And this is precisely why desktop Linux has not knocked off Windows or MacOS.

[port11]

After reading so many apologist comments dismissing the article's points with whataboutism, yours is the first comment that I think addresses the situation properly. As a developer, it's very hard to not mistake the forest for the trees, which is why I'm usually very happy to work with a good UX researcher.

[zeroq]

> contributors of free software tend to be power users

or, simply put, nerds

it takes both a different background, approach and skillset to design ux and interface

if anything FOSS should figure out how to attract skilled artists so majority of designs and logos doesn't look so blatantly amateurish.

[duxup]

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.

[graybeardhacker]

I always tell clients (or users): "If you bring your car to the mechanic because it's making a noise and tell them to replace the belt, they will replace the belt and you car will still make the noise. Ask them to fix the noise."

In other words, if you need expert help, trust the expert. Ask for what you need, not how to do it.

[jaredhallen]

I think what you're driving at can be more generalized as users bringing solutions when it would be more productive for them to bring problems. This is something I focus on pretty seriously in IT. The tricky part is to get the message across without coming across as unhelpful, arrogant, or obstructive. It often helps to ask them to describe what they're trying to achieve, or what they need. But however you approach the discussion, it must come across as a sincere desire to help.

[dmd]

You are describing a form of the XY problem. https://en.wikipedia.org/wiki/XY_problem

[nerdponx]

Don't fall into the trap of responding to the user's request to do Y a certain way. They are asking you to implement Y, and they think they know how it should be implemented, but really they would be happy with Y no matter how you did it. https://xyproblem.info/

[uticus]

In my experience, this is a communication issue, not a logical or technical or philosophical issue. Nor the result of a fixation caused by an idea out of the blue.

In my experience it may be solved by both parties spending the effort and time to first understand what is being asked... assuming they are both willing to stomach the costs. Sometimes it isn't worth it, and it's easier to pacify than respectfully and carefully dig.

[amatecha]

Yeah, I've had now a couple decades of experience dealing with this, and my typical strat is to "step back" from the requested change, find out what the bigger goal is, and usually I will immediately come up with a completely different solution to fulfill their goal(s). Usually involving things they hadn't even thought about, because they were so focused on that one little thing. When looking at the bigger picture, suddenly you realize the project contains many relevant pieces that must be adjusted to reach the intended goals.

[rcxdude]

In general the advice I've heard it that users are absolutely going to be right about when there's a problem (which you ignore at your peril), they can usually identify where the problem is, but they are terrible at coming up with ways to fix it.

[cosmic_cheese]

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.

[vayup]

Spot on. Defending simplicity takes a lot of energy and commitment. It is not sexy. It is a thankless job. But doing it well takes a lot of skill, skill that is often disparaged by many communities as "political non sense"[1]. It is not a surprise that free software world has this problem.

But it is not a uniquely free software world problem. It is there in the industry as well. But the marketplace serves as a reality check, and kills egregious cases.

[1] Granted, "Political non sense" is a dual-purpose skill. In our context, it can be used both for "defending simplicity", as well as "resisting meaningful progress". It's not easy to tell the difference.

[jacobr1]

The cycle repeats frequently in industry. New waves of startups address a problem with better UX, and maybe some other details like increased automated and speed using more modern architectures. But feature-creep eventually makes the UX cumbersome, the complexity makes it hard to migrate to new paradigms or at least doing so without a ton of baggage, so they in turn are displaced by new startups.

[rcxdude]

Yes. I think the crux of good interface design is coming up with a model that is simple and flexible enough to be understood by the user but also allow them to achieve their goals by composing operations and options, as opposed to special-casing each possible use-case. This allows you to address the needs of a large number of users without drowning in complexity, but it's really hard to come up with the right model and in general if there's something that will make you unpopular with your users it's changing around the UI after they've gotten used to it, so you don't really get to evolve this as the product develops.

(Commercial software is far from immune to this as well: professional tools like CAD are notoriously arcane and often have a huge number of special-purpose features, and they're not incentivised to improve their UI model because it would alienate their existing users, as well as not show up on the feature lists which are often used to drive purchasing decisions)

[patrakov]

While working for one of the previous companies, I hit a regrettable counterexample for the point in the article.

Developers built a web UI for creating containers for the labs, taking the advice from this (then future) article too literally. Their app could only build containers, in the approved way. Yet, not all labs were possible to run in containers, and the app did not account for that (it was a TODO). Worse, people responsible for organizing the labs did not know that not all labs are compatible with containers.

Lab coordinators thus continued to create containers even in cases where it didn't make sense, despite the explicit warning "in cases X, Y, Z, do not proceed, call Alexander instead".

So if you make one button you better make that it is always the right button. People follow the happy-but-wrong path way too easily if there is no other obvious one.

[nemomarx]

Having to read a label and go out of the tool to do something else is basically impossible UX, yeah. You'll never get users to do that, and little in line warnings also won't work unless you block the buttons at the same time I think.

In this example I wonder if the tool was too "MVP" and they didn't evaluate what minimum viable would mean for the users?

[PaulDavisThe1st]

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.

[SoftTalker]

Right. For most people, gimp is not only overkill but also overwhelming. It's hard to intuit how to perform even fairly simple tasks. But for someone who needs it it's worth learning.

The casual user just wants a tool to crop screenshots and maybe draw simple shapes/lines/arrows. But once they do that they start to think of more advanced things and the simple tool starts to be seen as limiting.

[galagawinkle489]

And why exactly should free software prioritise someone's first five minutes (or first 100 hours, even) over the rest of the thousands of hours they might spend with it?

I see people using DAWs, even "pro" ones made by companies presumably interested in their bottom lines. In all cases I have no idea how to use it.

Do I complain about intuitiveness etc? Of course not. I don't know how to do something. That's my problem. Not theirs.

[aidenn0]

Not only is it hard to figure out the use-case, but the correct use-case will change over time. If this were made in the iPod touch era, it would probably make 240p files for maximum compatibility. That's ... probably the wrong setting for today.

[SwtCyber]

Simplicity has an expiration date if it's too rigid

[miki123211]

To design a good user interface, you need a feedback loop that tells you how people actually use your software. That feedback loop should be as painless for the user as possible.

Having people to man a 1-800 number is one way to get that feedback loop. Professional user testing is another. Telemetry / analytics / user tracking, or even being able to pull out statistics from a database on your server, is yet another. Professional software usually has at least two of these, sometimes all four. Free software usually has none.

There are still FLOSS developers out there who think that an English-only channel on Libera.chat (because Discord is for the uneducated n00bs who don't know what's good for them) is a good way to communicate with their users.

What developers want from software isn't what end users want from software. Take Linux for example. A lot of things on Linux can only be done in the terminal, but the people who are able to fix this problem don't actually need it to be fixed. This is why OSS works so well for dev tools.

[user205738]

Those who have been using Linux for a long time have very useful terminals with syntax highlighting, auto-completion, typo correction and many other bells and whistles.

In addition, muscle memory has been developed and there is experience.

They don't realize that newbies don't have any of this, and it's very inconvenient to type commands in the terminal without it. You may not be able to copy and paste them the way they are used to (right mouse button or Ctrl-V)

The terminal in linux makes people hysterical and angry.

The problem could be partially solved by adding auto-completion and auto-correction to the default iso.

[apitman]

I suspect in the short term users are going to start solving this more and more by asking ChatGPT how to make their video work on their phone, and it telling them step by step how to do it.

Longer term I wonder if complex apps with lots of features might integrate AI in such a way that users can ask it to generate a UI matching their needs. Some will only need a single button, some will need more.

[uticus]

> 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

[rekabis]

> figuring out what that use case is difficult.

Which is why observability is so damn important.

Observability allows you to grock what your users in aggregate are doing, and adapt your product accordingly. You can take the lower-40% of features and squirrel them away off the main UI. You can take the lowest-10% of features and stick them in a special tools panel that needs to be explicitly hunted down and enabled. You can carve the UI up into three different levels - focused, simple, expert - that hide certain functionality and features, and explicitly expose others in certain ways, and allow the user to switch between them at will.

There is just so many ways that this particular cat can be skinned, you just need to collect the information on how the users are actually using the product. You just need to get permission in ways that encourages your users to participate.

Because without that data, you’re just stabbing in the dark and hoping you aren’t stabbing yourself in the foot. Or worse -- metaphorically ripping open your entire femoral artery by alienating the majority of your users.

[SwtCyber]

Simplicity isn't just a design challenge, it's a discipline problem

[mschuster91]

> 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.

[Cotterzz]

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?

[abustamam]

I could see the case for having multiple front-ends to do exactly one thing.

In the case of handbrake, I'd just see how I personally use it. Am I doing one thing 99% of the time? Maybe others are too. Let's silo that workflow.

[m463]

I think it is like simplified wikipedia. It is possible, but not mainstream enough to get good coverage.

https://simple.wikipedia.org/wiki/Main_Page

It would be interesting to have a "simplified linux", or "linux for kids" or similar.

[cellular]

This is why i developed GatorCAM for CNC.

FreeCAD is too complicated. Too many ways to accomplish the same task (nevermind only certain ways work too.)

So everything is simple and only 1 way to create gcode. No hidden menus. No hidden state.

[alistairSH]

Eh, not sure I agree.

Taking the Handbrake example, providing a default "simple" interface (as Magicbrake does) would be trivial to implement, maintain, and defend. The existing default "super user" interface could be just a toggle away (and make the toggle sticky so a power user doesn't have to touch it but once).

I used to work with an engineer who loved to remind us that a "perfect" interface would have a single button, and that button should be delivered pre-pushed. Always seemed like wise words to me.

[iwontberude]

It’s “the tyranny of the marginal user” as Ivan Vendrov coined it