Drawing a circle isn't a new feature, the feature already exists in the program. It is just that the workflow to use the feature is very burdensome, all they need is a button that does several of the steps at once. It wouldn't implement any new behaviour, it is just a quick button.

Now, it would take some work to implement those quick buttons, sure, but that is purely an UX change it doesn't add any new capabilities to the program, it just makes some actions easier to do.

Basically, the feature lacking in the program are those "quick buttons" which would make adding these simple UX fixes easy rather than burdensome engineering work.

And I'm saying you're mistaken, that feature never really existed. Trying to hack the ellipse tool into "quick buttons" to draw circles would not be what is expected, would not match the capability of other vector drawing tools, and would probably create other UX issues in the process. But of course, if you thought that was a good idea, you could easily make a plugin that does that, and test it out for yourself.

You’re both right.

Zxzax is correct that GIMP is an alternative to Photoshop, so the tool pallet is appropriate for editing photos. The typical workflow is: (1) stack layers, (2) mask layers, (4) composite. It’s rare to draw a circle on top of a photo. Usually it’s most efficient to select an area of a photo with a rectangle to isolate it on a layer, then use masking to refine the non-rectangular edge. If your goal is to draw a 2D illustration & work with gradient meshes, then Inkscape is an alternative to Illustrator. Both those programs are for illustrating in 2D and there are purpose-built features for drawing & editing shapes.

That said, GIMP does have real UX issues. For example, the controls and GUI elements don’t scale well to high resolution screens and could be much better on tablets like the Surface. They’re also missing CMYK color space support. But, I always assume they’re waiting for Adobe patents to expire to add those features.

I've used photoshop, its UX wasn't nearly as bad. Me as a user had a pretty good experience with photoshop, but a really bad experience with gimp. Hence gimp has bad UX and photoshop has ok UX, according to me and most people I've seen. People trying to convince me and the other people that our experience wasn't all that bad with Gimp is the problem here, that attitude ensures Gimp will always have bad user experience.

Just to clarify, GIMP definitely has issues, and I'm not trying to convince you otherwise. But they are not issues that can be solved with more UX research or what you would typically call "UX work." That's what I think the misunderstanding here is, please don't misinterpret what I'm saying. The UX issues that are there are already known, what's left is to do the (hard) work of fixing it.

I'd argue that UX requires a lot of engagement and work by software engineers. Sure it isn't work people with the title of "UX designer" or whatever would do, which is why the UX role is usually bullshit, but it is still work needed to fix the UX. And small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.

You are correct that it does, but not every change made by engineers is a UX change. But even if you want to think of it like that, the backend changes still need to happen first in order to get any significant UX change going.

>small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.

The GIMP developers are aware of this pitfall and want to avoid it, there is even a FAQ entry about it: https://www.gimp.org/docs/userfaq.html#i-dont-like-gimps-use...

Out of curiosity, what task were you using gimp/photoshop for: (a) edit a photo, (b) draw an illustration, (c) draw a diagram, (d) annotate an image or map?

The DPI scaling issues should be mostly fixed in GIMP 3.

CMYK support is not a UX issue, that is another thing that's missing on the backend. I don't think it has anything to do with patents, the problem is more because of lack of manpower.

I think this discussion highlights perfectly why Gimps UX sucks. It is because the people who made it has a view on UX like you do and refuse to put in the work to fix it, with arguments such as "That isn't an UX issue" and so on. Fact is that Gimps UX sucks and people will have to live with it since it is a free product so the developers don't have any reason to do what you want.

Anyway, you might be right about this issue, I am not an expert on image editing. However I do understand UX and your view on development will lead to horrible UX like what you have in Gimp. It might work great in enterprise products where you sell features and not UX, but a product intended to be used by normal users needs more work on UX for people to like them.

I'm saying this as some who's done UX and is familiar with the problems in GIMP, there really is no quick fix that can be done here. If you view everything as a UX issue that can simply be solved by moving things around, then we can't really have a discussion because there is no meaningful distinction we can make. The major issues with GIMP are mostly on the backend. The work is being put in to fix it, but it's slow going because there are not enough people working on it. I agree with you that people would really see it as a UX improvement if there were good shape tools like photoshop has, but my point is you can't just get that by changing around the ellipse select tool. If it were that easy, somebody would have done it by now. The GIMP people I've known have said they would love to fix a lot of things but it's harder than it seems and they don't have infinite time.

Just to make it a little clearer what I mean here: if there were actual shape drawing capabilities on the backend then it would be pretty easy to make any kind of circle/ellipse tool that you wanted, or set up the circle tool to do what you want by default, but those don't exist right now.

> If you view everything as a UX issue that can simply be solved by moving things around

That isn't what UX is about. I am making games, and stuff that isn't simply moving things about is a core part of user experience. For example consider a game where you want to move around armies on a map. You can implement that by moving around the armies using numpad only, or you can calculate a shortest path on a mouse click to a location and show it to the user. Both allows the same kind of movement, but the second offers way better user experience which is why all modern big strategy games uses it over one step at a time movement.

> but my point is you can't just get that by changing around the ellipse select tool

I never said that a good UX was easy, I just said that the developers of GIMP didn't want to put into the work to make GIMP have good UX, and a lot of that work is redesigning the technical architecture or implementing those features the tedious ugly way. It is possible to make it decently easy to make easy to use tools for gimp, I just don't know all the details of what those tools should do exactly but I know how to build that sort of things. When making games you don't have as patient users as you have in GIMP, so you'd never get away with that kind of UX, so from my perspective when your product has GIMP's level of UX then it isn't complete as a product since it would basically ensure business failure.

I'm not much of a gamer but what you are describing doesn't seem to be relevant, for example there are simpler games where moving using numpad is perfectly usable and desired. There is not really anything specific you're designing for there, you just chose to make that type of game.

>the developers of GIMP didn't want to put into the work to make GIMP have good UX

From what I have heard from GIMP developers, this is not correct. There is plenty of desire to fix issues, the main issue is lack of contributors. Please help if that's what you're interested in.

You're talking about "getting away with the UX" but I'm also not sure what you're talking about there, GIMP is not a commercial product that is trying to get customers. It's an open source project driven by volunteers who improve it in their free time because they feel like it.

From experience I am almost certain the issue has to do with architecture, the original developers didn't properly consider UX when making the first steps and that has shaped how everything else was implemented in it, and this is the end result. Fixing it at that stage is way too much work as you said, rewriting all tools and the UI from scratch would probably be the easiest way to fix the UX at this point. If it was easy then it would have been fixed as it is an open project as you said.

That's true to an extent, but the backend changes should make it more feasible to refactor the UI or to build alternative UIs with other feature sets.