It would be nice if you were more specific. Most of the serious complaints I see artists making about GIMP are about lack of non-destructive editing features, or about lack of support for specific workflows, which are technical issues, not UX ones (and ones that are being addressed, slowly).
I want to do a basic thing in gimp, draw a circle. How do you do that? First you click the rectangle button, then you select "elipse select", then you select an area, then you click edit and fill with color. This flow is much more unintuitive compared to anything else I've seen, why would you click on the rectangle to draw an ellipse? And then suddenly that button is no an ellipse, so next time you want to draw a rectangle you now have to click on the ellipse button and switch it back to a rectangle.
And that is just one thing, the whole program is littered with small obnoxious design decisions like that. Maybe you can learn to get used to it after a while, but if you have to go through a tutorial and get lost the first 20 times you try to draw a basic shape then your drawing program has bad UX. In the end you will learn that the ellipse button and rectangle button are the same things etc, but until you learn all those things the program is just frustrating to use.
That again is not a UX issue, that is a lack of shape tools for that particular workflow. Like, this is not something you can fix just by moving some buttons around or by changing the name of the ellipse tool to circle draw tool and having it fill automatically (i.e. bugfix-type things that a UX person would do), somebody has to implement an entirely new feature for that to work the way you are expecting, and then it would need to be redesigned as well. And GIMP historically has not been focused on shape drawing. If you want an open source program that focuses on shapes and vector drawing, you may want to use Krita or Inkscape. Or you can try developing what you're looking for as a GIMP plugin, and the going from there and trying to get it merged upstream if it's popular enough.
UX is User Experience, not User Interface. Lack of tools to do things quickly and easily with discoverability is a huge UX issue.
And then the rectangle button changing to an ellipse button just because that was the most recent sub tool you used is a UX issue that is purely in the UI. I probably lost several hours to that until I understood what happened, because I couldn't find the buttons I wanted to click on and then assumed I had to look for them elsewhere etc. And it still is bad even after I learned that since everywhere I look at tutorials how to do stuff the menu looks different since they had different previously active tools so it is a pain trying to figure out what to click.
What you're saying doesn't really make any sense to me, that's like saying you bought a sedan and found that it didn't have a pickup bed, so now it's a UX issue because you couldn't quickly and easily figure out how to move a refrigerator with it. Not everything is going to have the same tools, or support the same workflows. Maybe that's a problem that needs solving but it can't be solved by UX designers trying to redesign the sedan -- you would just get a trailer and put the refrigerator in that.
You're right about the tool menus, those are an actual UI issue, but they can be disabled. Maybe they should be disabled by default? I can't say.
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.
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.
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.
