Just look, for instance, at FPGAs: almost all the tooling is proprietary, very expensive, and very buggy too. Or look at PCB design: Altium seems to be the standard here still, despite Kicad having made huge advances and by most accounts being as good or even better. It took decades (Kicad started in 1992) for the FOSS alternatives here to really catch on much, and only really because PCBs became cheap enough for hobbyists to design and construct their own (mainly because of Chinese PCB companies), and because CERN contributed some resources.
I'm not sure what the deal is with engineers hating collaboratively-developed and freely-available software, but it's a real thing in my experience. It's like someone told them that FOSS is "socialism" and they just reflexively dismiss or hate it.
The commercial software vendors do a great job of marketing to engineering schools and students. Once you learn some software it's a lot of work to relearn. So if you get people accustomed to your proprietary ecosystem early in their schooling and during the start of the career, you have pretty much hooked them for life.
Apple and NVIDIA are using Allegro (or customized versions thereof.)
> or even better
KiCad is faster, absolutely not better.
> very expensive
Vivado is free for a great number of devices (not just the "lite" version, either, depending on the board - U50, U55, etc.)
No open source tooling can even remotely compare in ASIC implementation flow or FPGA implementation.
Pure Software has a lot slack when it comes to delivering incomplete or (in the FOSS world ) even partially incorrect releases. Many issues can be fixed after the fact (even in production) and you can inch closer to a better version as time come goes on.
Mechanical engineering oftentimes can't work that way. An "80% solution machine" usually doesn't work at all and iteration costs (outside of 3d prototyping) can be staggeringly high.
Example: My company produces heavy "things" (20tons+) that have tight tolerances in some places. If the design is off by 2mm because of a CAD bug or unexpected/unknown UI the part could be scrap or require an expensive (read manual) rework.
There go all your software savings.
So why management would love to reduce the staggeringly high costs it's not worth the risk until an alternative is very proven.
In many projects customers contractually require is to use a specific solution.
Most of the incredibly well used robust open source packages are sponsored by large tech companies. The embedded space just hasn't had that kind of sponsorship.
Probably because if you complain about bugs or problems in open-source software, a legion of trolls comes to tell you "erm, it's open source, you can just implement it yourself" no matter how skilled the user is at programming.
Like, for example, the lead dev of Inkscape, who used to (not sure if he still does) go around on twitter looking up complaints about how slow Inkscape is on macOS and then complain about them being entitled.
No wonder they don't want to use it, then, if it's considered rude to even expect the software to work.
Often the support is worth it, because I can have a conversation with someone early in the process. If I commit to open source then I either need to hire an expert (this does not get the same guarantee as a support contract) or live with much more uncertainty.
To get a EDA tool to a useable condition, and debugged to the point where it is reliable enough to actually use, is just a ton of work. As someone who wants to design circuits, why should I do that work? How will it help me design more circuits? I understand why beginners and casual users don't like them because the EDA tools do have a huge learning curve, but once you're there, they are very productive.
For professional engineers the software license is not really a significant barrier. Compared to the cost of labor, materials and equipment it's basically a noop.
I think if there were good quality open source equivalents they would be considered, but they pose a huge risk, possibly even an existential risk, if they derail our development plans unexpectedly. Paying a lot of money for seriously good quality tools reduces that risk dramatically.
I've had a brief look at FreeCAD, and it's got a lot of potential. But when you compare it with SolidWorks, OnShape or SolidEdge, there's clearly a huge gap in usability and capability which needs closing before a lot of people will be able to consider it seriously. I'm sure it will eventually get there, like KiCAD did, but it will take many years and a lot of investment to get the usability, polish and featureset up to parity. It looks like Ondsel did a really good job to make some progress along that path.
FreeCAD's UI is "a bit crap". The "workbench" metaphor is fine as a metaphor, but the specific way the workbenches are put together in FreeCAD is oriented more towards the way the functionality is implemented than what the user wants to do with it. You have no choice but to understand technical implementation details.
That's just one example, but that attitude to UI in FreeCAD is absolutely pervasive.
I think that's a general problem in the space. The user interfaces in general aren't designed, they're an outgrowth of the direct implementation of the underlying functionality.
That seems like a matter of taste. We switched from Altium to KiCad and I very much prefer it. We don't do any RF stuff, so there might be things that don't quite work in KiCad, but for what we do - power electronics - it works perfectly well.
Anyone who sincerely thinks GIMP can replace Photoshop or is otherwise good will never understand why professionals eschew open source software when there's work that needs doing.
The problem is that usually open source solutions are really, really rough around the edges from UX perspective - and it could be minor edge cases for programmer! - but for engineer they are a dealbreakers.
Look at it from the engineer PoV - they could learn industry standard CAD solution that works, has relatively good(depending who you ask and which version they started with) UI/UX .. and it's something they employer pays for.
I worked with civil engineers that tried multiple different 2D CAD software packages and frankly, all of them hate Autodesk as a company, but they still did pick AutoCAD. They did have different preferences for specific AutoCAD version though.
Honestly the core problem is that there's no pressure from clients on open source software to have a good UX, because there are no clients - just users and developers.
Not what I've heard, and CERN seems to think it's good enough for their particle colliders.
>No open source tooling can even remotely compare in ASIC implementation flow or FPGA implementation.
Yes, FPGA tools are a very different matter. I do wonder if this is really lock-in from vendors more than any preference by users, but still, sufficiently motivated users could reverse-engineer things to try to make a single open-source toolset that works with all vendors' FPGAs. Of course, the feasibility of this is questionable, but we've seen really impressive reverse-engineering efforts in other places in FOSS. Just look at how futile it is for YouTube to try to prevent people from downloading their videos.
You could say that about many other fields too, but then why do we have great tools like Blender, Krita, Audacity, etc.? Artists and musicians have great software skills, but electronics engineers don't? There's always been a huge overlap between EE and CS degrees, with "computer engineering" degrees coming about as a merger of the two fields decades ago, so I find this statement hard to believe.
Well if you're dealing with projects worth 7 figures (or more), it absolutely makes sense to go for a commercial project with SLAs on support. Last thing you want is to hit some showstopper bug, holding up people who earn 4-digit daily compensation, and been told to "figure stuff out yourself".
If you as the author of a FOSS project that isn't a household name already for historical reasons (like, say, OpenSSL or cURL) and you want it being used by anyone else than hobbyists and universities, you won't get around establishing some sort of corporate infrastructure to sell support contracts.
I'm an EE. I can code. I think I'm pretty good at it. But there's a reason I didn't major in CS, I don't enjoy it all that much and I don't do it as a hobby either.
If you believe that those who contribute to FOSS is a small percentage, then I think for non-SW folks you're looking at a small percentage of a small percentage, which means sparingly few contributors which means sparingly few FOSS EDA tools.
The old meme from 10 years ago about: “Linux being free if your time is free” is largely false for personal usage, but in the corporate environment somebody will have to provide support and with the open source software this is going to be you.
People selling B2B software know that so they will usually price things in a way that it is just a bit cheaper to pay them rather then support and retrain staff.
Until very recently, this was not the case in hardware world. In many cases it’s still not the case. You will meet all sorts of purists here that will tell you FreeCAD is good enough, for instance. Well, I tried using FreeCAD to build a hardware product. And eventually switched to proprietary software because FreeCAD could not satisfy my use case. I made a genuine effort to use the FOSS variant, but it was not usable for me.
I’m more inclined to listen in hardware when someone says the FOSS tools are not good enough after that experience.
https://www.eenewseurope.com/en/cern-selects-cadence-service...
"The CERN physics department is deploying the Cadence analog and digital end-to-end solutions as well as the Cadence verification and Allegro PCB solutions throughout the support of its CERN IT department."
I don’t think this is universally applicable. I think you can differentiate software by how important it is.
Some software is at the very core of your business. A CAD, a ECAD, some lab software or a video editing program. Realistically, if you cannot justify the expensive of that software for your business, you probably don’t have a business. Many of those apps require substantial R&D to get right, something you can only afford if you make real money by building it.
But there are other supporting applications that are not as close to your value add as your core apps, but they can still sleep you over real bad if the vendor goes bust or raises prices into the sky. That may be a teams chat app, a mail client, a wiki software. Most of those apps are essentially the infrastructure of any business nowadays and are relatively solved problems. In this area OSS really shines and reduces a lot of the vendor risk.
All 3 of these are using the same geometry kernel - siemens parasolid.
Most open source CAD software is using OCCT (cascade).
It’s the kernel that brings a lot of the capability. Check out “plasticity” (https://www.plasticity.xyz/ ) for an example of a single developers implementation of the parasolid kernel
Even if a brand new UI is objectively better, to someone who's invested thousands of hours in becoming fluent, fast and efficient with an existing UI (however quirky or obtuse it might be) the new UI will be an impediment to productivity.
> a) have a working mental model of software functioning, so they reason about interfaces differently
You're 100% correct, they do reason about interfaces differently, and thus have wants and needs which are different from those of non-technical users. Those wants and needs are not met by mainstream software, but are met in some OSS software, so it should come as no surprise that such types want to defend that software against the incursion of those who want to make it just like the mainstream offerings!
Like you I have a slightly different perspective here, having been a hobbyist software developer for some years, but having worked in print and design as a day job.
But I still bemoan such things as the awful keyboard handling of the current GTK file dialog, when compared with the old GTK1.2 file dialog. The old one was truly hideous to look at, but handled filtering files by keystroke far better than any current file dialog.
Which is a massive improvement and the result of many hours of fixing "boring" bugs, improving UX and all the other chores nobody wants to do.
But for most commercial work it's not yet there.
It's very much the case that everyone in the supply chain switches over, or nobody does.
They also have a service contract with KiCad Services Corporation. [2]
[1] https://ohwr.org/project/macbeth [2] https://cernandsocietyfoundation.cern/news/significant-miles...
But then a friend reminded me of the Fusion 360 hobbyist plans, and I decided to give it a try, just to see. It blew my socks off! It's just a lot more refined. The first 12 minute tutorial took me further than I'd gone in the ~2 hours I did with Ondsel.
FreeCAD is an amazing piece of software to be available for free. But in the end Fusion just operated a little more smoothly in lots of little ways. I have really limited time to do 3D modeling, so it's pretty valuable to me to get more done quickly.
One temporary thing that's making FreeCAD a bit hard to get started with is that there's not much content out there for learning 1.0, and sifting through out of date content to find it took some work. That'll improve as time goes on.
Most of the open source CAD stuff is just Not That Good.
I'd frame it as: people who want to get stuff done and who can't or don't want to have to fight or troubleshoot their software or the system it runs on will often have to choose non-open-source options.
Some examples, from my perspective of being an enthusiastic and reasonably tech-savvy hobbyist:
* Linux is almost always a huge pain to get running well. In contrast, MacOS almost always just works, and while Windows can be a bit more janky, it very rarely needs countless hours spent on e.g. Ubuntu forums or Stackoverflow trying random fixes until one does (or doesn't) work. Of course there are reasons for this, but it is true. (Will next year be the year of Linux on the desktop?)
* Python is something I fundamentally love and use frequently, but I'm not the first to notice the terrible UX when it comes to managing different versions of Python itself, and its packages. Note that virtually every Python-based project on Gibhub (which is lots, thanks to ML) comes with a different set of instructions to get it running, usually based on a different distribution or package manager, thanks to an n+1 problem-solving approach [0] from the Python community. You can often run into huge issues simply installing a single popular package (looking at you, OpenCV).
* FreeCAD... I'm an enthusiastic mid-level CADder, and have used several different commercial packages without a problem. FreeCAD is just awful currently - fundamental issues/incompatibilities betewen the different modules within the base system, a terrible ugly UI, an unncecssarily steep learning curve (even for someone well-versed in CAD). And of course the answers to (some of) these problems are suited to the limux hacker - "oh just install so-and-so's fork instead". Really? And you're surprised it doesn't take off with the hobbyist community?
* Dearpygui.. a lovely, performant GUI for Python, but with such terrible documentation that for anything beyond the (sparse) examples, you have to resort to asking questions on Discord. (They are reponsive and friendly, though.)
* GIMP - powerful... and just crappy to use.
My basic premise is that most open-source products are designed and coded by hardcore programmers/Linux experts, who are great coders but either don't care about or don't have skills in optimising UI/UX/usability. Maybe it's the much-derided product managers (i.e. not hardcore programmers/Linux experts) who bring usability to a project. Maybe open source needs to work on attracting non-coders to its projects, and be open to listening to their criticism?
Python’s ecosystem looks like a trash fire and sits along nicely with JavaScript (they burn brightly in subtly different ways). Neither are concerned with adoption at this point though.
> Maybe open source needs to work on attracting non-coders to its projects
I think Python is proof that the economic realities are more nuanced than this.
The functionality wasn't even the biggest problem. And JFTR, I'm not talking about anything that came to Photoshop in the last... 15 years or so, I was just slicing PSDs for table layouts and making wallpapers, not actually editing photos like a pro :P
But that's the thing about open source software you run in production - you don't need one of a dozen enlightened people on the planet who understand it, most often, you will find one on your team who is competent enough to backport a fix, or come up with a fix after debugging it. I see it as more of a safety access hatch.
Google tells me the average salary for a Mechanical Engineer is $95,675/year.
The cost of a single-user SolidWorks Standard license is $2,820/year [1]
You don't need to get big and negotiate a discount - if the engineer says they're 3% more efficient using SolidWorks, it'll pay for itself at list price.
[1] https://www.solidworks.com/how-to-buy/solidworks-plans-prici...
One of the reasons chefs rarely have anything to do with cookbooks they write past the initial set of recipes is because it’s really hard to see things from an inexpert perspective. People ask us things like “how long do I cook [something] and we often have no idea how to answer that question. Knowing how much that can change depending on the heat source, initial ingredient temperature, how long it’s been unrefrigerated, the water content of the pieces you’ve got, the shape of the pieces, etc etc etc, we just say “uh, until it’s done?” But it takes a lot of skill and experience to realize when most things you need to cook are done, so recipe developers and cookbook writers do a ton of testing to figure out about how long it takes to get you 80% of the way there and then give some simple ways to approximately gauge doneness in that context. If they’d learn a few simple things that “aren’t that hard”, they’d have precise, bang-on results like I do, every time. But unless you cook the same things so the time, you’d need to repeat that across all of the different cooking scenarios that require specialized knowledge. Chefs run into that because people want us to tell them how to cook things all the time, so the skill gap is apparent, and we see the value in someone who knows how to address that. It was never really shown to me like that as a developer, so I see why so many get stuck in the “come on, it’s not that hard” mindset, generally.
Interface design is conceptually harder, because you need to really consider many skill levels that have different needs. The answer isn’t developers reading some article to “make nicer looking interfaces” or “dumb things down”— which we’ll just piss people off in the end and many of them will be developers assuming it’s an interface designer’s fault. The answer is to deliberately enfranchise designers into the FOSS process to figure out who would benefit from the software, and make an interface that can serve everyone’s needs: inexpert and advanced users alike, if that make sense. You do not have remove advanced functionality to make it useful to non-developer users.
So the first step is to put aside the dev nerd machismo for a minute and recognize that designers serve a crucial purpose that isn’t “dumbing things down” or “making things look nice” and that most developers have no idea how to do it themselves. Once that’s a thing, figuring out how to enfranchise designers into FOSS will be the next step.
Also notice that all compilers for scenarios where liability is actually imposed, like in physical goods, most compilers are closed source, proprietary, and certified.
Well, it's pretty good for multi-monitor setup. Dedicating the whole monitor for the image without endless panels in the way is convenient.
I've spent a lot of time at this point with both toolkits. I use the open source tooling extensively for my own designs. But you tell some grizzled RTL person there's no power analyzer or native SDC support or that UTM was only recently supported in some simulator, and they're going to laugh at you. They've been doing that stuff for 20 years. I know this because I've done it several times (though other people find particular things, like free RTL verification tools, much appreciated.)
I think FOSS/software people paint some very rose-tinted picture in their mind where the mere availability of something for $0 would make it an obvious choice, even at only 10% of the functionality. But that's not how people see it in reality. Many people, including engineers, think of it the other way: if it's so good, why is it $0 and how do I know it will keep being developed? They've made their peace with the fact that the $5000 tool will exist practically for as long as they need, get the job done, and be supported.
Having said that, no one owes anyone anything. If Emacs wants to be a power tool, let it. I don't expect a construction crane to be safe and easy for me to operate.
Yes. Answers like "until it sounds differently" just cause more questions while being the actual answers. How the hell am I supposed to explain "that different sound". After some time you just start to feel it.
I get why developers are perplexed by everyone's insistence that designers take the lead in creating interfaces, but leaving Gimp aside to look at another problematic FOSS UX, consider Mastodon: folks around these parts were proudly and rightfully touting Mastodon as an interface for Activity Pub as an amazing piece of software and technological achievement, but incorrectly claiming its UX was polished enough to replace Twitter. When I'd bring up the near impossibility of non-technical users being willing to figure out how federation worked when there are free options, the dismissals were fast and furious "I explained federation to my [toddler/grandmother/nontechnical coworker, etc]: it's not that complicated", "there's a (ten million word) beginner friendly onboarding doc that explains it all." "Users don't even need to know how federation works if they just pick an instance and sign up." I'll bet a lot of friends of developers did a lot of polite smiling and nodding in those weeks, and Opera's Tweets(!) about not being able to find any of her friends on Mastodon was all the evidence you need to prove that most people's most basic use cases-- connecting with and keeping up with friends over the internet-- aren't easily satisfied by Mastodon's UX.
If my Grandparents decided they were going to branch out from "the Face Book" to try that hot new Mastodon a few years ago during the spike, the likelihood of their progressing through the "beginner friendly" wall of text on their onboarding website is about zero. If they did, the first time some mind-bending hentai popped up on their screen, they'd have taken their computer outside and burned it. They would not have taken it as an opportunity to get the prerequisite knowledge they needed to even understand what instance shopping was. My parents would have gotten further, but given how frustrated my engineer father gets with much less confusing ideas because he's used to a whole different sort of technology, I say they'd last about 5 days.
You don't get a much simpler task than making a classical French omelet. It's got three ingredients. I can do it in my sleep now-- it all seems very simple. But it was YEARS after culinary school before I got my perfect omelet success rate past like 70%. Being blind to our existing knowledge is natural. That's a good thing when we're working by ourselves, but it's murder when you're figuring out how someone without it approaches the same problem.
Yeah and I think most UX designers would consider that a bad design though-- developers are users and if it's tough for developers to use, then it needs to be optimized. As someone who's created a few APIs, I know that developing friendly interfaces for developers-- APIs are interfaces that humans need to understand and use-- involves the same blind spots as developing for end users. At first, Microsoft concentrated on developer experience a lot, but I think Apple is probably doing a better job of it now. Their programming environments are products they sell to developers, so they concentrate on making their interfaces smooth(ish) for developers.
Additionally, in the discipline of interface design, the visual polish should be a secondary or tertiary concern. Things like gestalt, implied lines, negative space, and type hierarchy are obviously core tools to orient users, especially in very complex interfaces, but the higher-level look-and-feel stuff is often not even handled by the same people in larger design organizations. Even things those higher-level designers might be concerned with-- interaction designers using the subtlest animations to indicate action or intent, for example-- still meaningfully affect software usability, though.
It's unfortunate that FOSS projects generally just aren't set up to accept design contributions, but it's not anyone's fault, per se. It just isn't the way the standard FOSS organizational structure evolved-- it was basically like a commercial software dev organization but the lead developer was also the product manager. Without a product manager to balance the design and development needs, design will obviously fall to the wayside. Unfortunately, that's left a pretty hostile environment for designers in FOSS. A lot of FOSS developers get defensively arrogant or combative when I even bring it up, but at this point, I'd rather set my beard on fire standing next to a gas pump than go deep into a usability analysis for a great FOSS tool, all of which I'm willing to implement myself, only to have a defensive dunning-kreuger echo chamber of design "expertise" tear my work to shreds without even considering that they might be conflating what they're used to with what's actually good, and they'd almost certainly benefit from change. I get why that happens-- it's just standard social cohesiveness, ego etc. and is not unique to software dev, and it's not their fault that dev culture developed that way.
But even though it's not FOSS maintainers fault, if they want non-technical users to use their software, it's certainly not anybody else's responsibility to enfranchise UI designers into their projects if they care about non-technical user adoption.
Everyone takes many of the interfaces they use for granted. I certainly do-- I regularly take my phone's simple, clean mail client for granted despite my first mail client being mutt, but it's really, really clean and gives far more features than mutt ever could. (And a phone is one of the few places I would not prefer using vim style editing.) Having had hundreds of discussions with dozens of developers about interface design, I can assure you that they are no different. It's just that developers often have competing needs in software projects, so it turns into a point of contention. In a regular development organization, the product manager or whoever has the final say. In FOSS projects, the maintainers do. If they're not keenly aware of how much more valuable a good, expertly defined interface brings to a piece of software, they're going to make a worse piece of software, unnecessarily. I've served in both roles professionally and have seen these issues from both sides, many times. An organization controlled by designers would probably be even worse.
So with the amount of shit I've had slung at me when acting as a software designer, I think what I wrote is a pretty measured addition to a conversation that is very important to me. I see most end-user-facing FOSS software getting absolutely no adoption among non-technical users because it sucks for them to use, and I see a lot of developers not entirely sure why that is and coming up with a bunch of folk explanations like "commercial software has advertising" or "their version is dumbed down and looks pretty and end users are dumb and refuse to read docs." I've got important insight into the real reasons why, and as someone that's probably contributed 10k hours of my time to writing FOSS code (admittedly, some of it was paid,) I think I'm entirely justified in sharing it. If you disagree, I'd be interested to hear why, but even if you're not interested in explaining why, I respect your stance on the matter.
I apologize if I bothered you with my wording or even just the what I was expressing (seriously), generally, but I failed to bring attention to these ideas presenting them meekly. The Mastodon situation is exactly the sort of thing I was trying to prevent. Not only did Mastodon repel a giant influx of users with it's usability problems-- big and small-- it gave many, if not most of those users the impression that FOSS software is weird, confusing, and exclusively for nerds, and that's the sort of thing that's going to keep open source alternatives alternative instead of having commercial alternatives to the default, free option.
> Everyone takes many of the interfaces they use for granted.
For example, I've seen many people in the HN comments over the years cite the HN interface as evidence that interfaces are better without designers involved, or something similar. In reality, HN has some of the best interface design out there. It does exactly what it needs to do, simply and intuitively, is much easier to visually orient yourself and navigate than a paged forum discussion, despite being compact it's completely obvious where individual elements begin and end using implied lines, type hierarchy, and gestalt rather than adding a bunch of boxes and lines, works great on multiple screen sizes, needs nearly no documentation beyond policy docs... it's a brilliant, clean, polished interface. It even keenly takes its audience into account-- many end users would be fatigued by the loooong lines of text when you fully expand the window and generally prefer a limited width for text blocks, but users that look at a computer text all day long prefer the flexibility of stretching out the lines horizontally to reduce the vertical footprint and get more on their screen at once. That doesn't just happen-- it was deliberately designed that way. Good interface design is very different from good branding and identity design, or similar-- it should be invisible. The choices should seem natural, or even obvious... but how many sites were set up like HN before HN did it? Compare it to Slashdot, the gold standard when HN got up-and-running. HN is incomparably cleaner and more focused on its core use case, even though it has fewer features and visible controls, which is usually what developers lament the lack of. HN is a great mix between newsgroup/email chain type visuals worked into a forum format, and I hadn't seen anyone else doing that. Many of the interfaces we use that look obviously designed and function poorly were either made by purely visual designers, or developers trying to make something look "designed" and using inspo from dribbbbble or whatever. Beautiful looking is quite distinct from optimally usable, and interface designers generally concentrate almost entirely on the latter.
Sure, the company might not blink an eye at spending $2820 on a software license for the engineer to use at work, but the engineer himself probably isn't going to be able to fit that into his own budget if he wants to work on any personal mechanical projects at home.
That's true, but also remember that not all designers are actually competent, or in agreement with your preferences. I'm definitely no MS fan, but look for instance at Windows 7, or better yet, Windows Vista: IMO, Vista was the peak for the Windows UI (forget about the performance problems it had at the time): it was pretty, but pretty easy to use most of the time too, with a highly discoverable interface. Now look at modern GNOME, which its backers tell us is created by "UI experts". It reminds me of Scientologists calling themselves "mental health experts". Calling yourself an "expert designer" doesn't make you one, and even any professional field, there's frequently wide disagreement. A lot of design is subjective anyway, so you can't just point to one self-appointed "designer's" opinion and use that as gospel. Even back in MS land, somehow the "experts" went from the highly-attractive Vista UI to the butt-ugly flat UI "Metro" UI in Win8, and that's at the very same company!
Moving the start menu from the corner, or otherwise wasting corner or edge space, is one of them.
And not all developers are competent developers, and not all bus drivers are competent bus drivers. That doesn't say anything about the profession itself.
> or in agreement with your preferences.
These things aren't art projects. Using research and testing within your core user bases to remove as much 'preference' as possible is a core tenet of interface design. I see lots of developers scoff at that idea, citing a million popular interfaces that they hate. But, look how many UX Researcher (as opposed to UX Designer) positions there are out there, which usually require a data-focused graduate degree: their entire field is devoted to basing design decision in reality rather than going with the whim of the designer.
Having a working mental model of software changes the way people look at interfaces, and the sorts of interfaces most developers like, most non-developers absolutely hate, so unless the core audience is software developers, it's probably not going to cater to their unusual usage style like FOSS often does. You can design for both. It's a lot more difficult, but if that's your audience, your only other option is to be less useful to some of them. As we can see from adoption, very few end-user-facing FOSS applications get any attention from non-technical users for that exact reason.
> Now look at modern GNOME, which its backers tell us is created by "UI experts".
Last I checked, GNOME was being designed mostly by one guy that didn't have any formal interface design training, but even if they did get a bunch of experts for a later version, it's not like they have carte blanche to make changes. I outright refuse to contribute design work to FOSS projects because you spend 80% of your time justifying your existence and defending every tiny contribution from a ton of misguided technical design criticism from people who don't realize they don't know the technical concepts in design. It's like a bunch of copy-and-paste wordpress plugin 'reviewing' an architectural refactoring by an experienced software engineer based on two minutes of a priori thought experiments and some stuff they read in some articles over the years. Good design always comes from feedback, pushback, and iteration, but that doesn't work if most people involved have no idea what they're talking about. If you asked me to revamp the GNOME UI, I'd run away as fast as I could.
Also 2004: HOW DO I RECOVER LAYERS FROM JPEG?
2024: STOP TELLING ME YOU ONLY SAVE TO XCF AND I NEED TO EXPORT TO JPEG!
Also 2024: crickets
I'm not kidding you. That is exactly what I've been witnessing all these years. Project loss complaints went from daily routine to almost zero. But there's a price to pay.
That approach warns less knowledgeable or hurried users when it looks like they're aiming the gun at their foot, but it still lets expert users follow through unimpeded. Figuring out how to communicate the risk to the user while not removing functionality is proper interface design. Simply not letting people do it is "dumbing it down," and one of many examples of why Gimp is not an appropriate choice for high-volume professional users despite its on-paper feature list.
And I resent the fact that I'm expected to pay that price when I'm not the one who was losing projects.
And as I said, carrying out the instruction but then telling me that I should be using Export instead would be acceptable. Refusing to carry out the instruction, even though the software has identified and understood the instruction just because I failed to say 'Simon Says' is not acceptable.
(Hi, by the way! I think you did some translations for PhotoPrint and CMYKTool some years back?)
Yes, I understand the frustration. The team didn't come up with anything better although maybe they could. I think another suggestion in this thread could very well be posted to GIMP's issue tracker.