Thanks for noticing — I hope to be on a project of yours soon.
I don't think this means open source desktop programs are a great place to look for top-notch UI/UX inspiration.
Electron is basically the digital equivalent of coal-rolling in my opinion, technologies like React Native are a much more elegant way of achieving what Electron tries to.
You're setting a really low bar there. If you compare open source UX to the UX of closed source applications pre-iphone, you'll find that their incomprehensibility was frequently criticized. Case in point: GIMP.
What's changed is that closed source UX has gotten worse faster than open source UX (unless you count GNOME, which has set world records for how fast it degraded).
You apt-get install it, you double click on your photo, you use a pretty standard WIMP interface to edit it.
Compared to modern Adobe software that's fucking amazing.
Hell, even Paint.NET has a better interface than GIMP.
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.
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.
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.
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.
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.
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.
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.
>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.
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.
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.
>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...
This is not the same thing as bad UX.
Nearly every time design becomes political and every change needs to be conformant to even the most minute standards even if they may not have any material effects on the product. I think the field just has a lot of shitty “leaders”, most of the “grunts” I’ve worked with have been incredibly helpful and willing to think out of the box to make UX easier.
"Is this component really that shitty for the user?" is how you end up with...hell, insert any Enterprise software here.
Many of who use the argument "Apple/Google does it this way" I'm not saying your now right it's just been my experience that they aren't engineers or Computer Scientists.
The problem is that they often don't know the constraints of the system you're working with, something that only comes with actually working on the implementation.
E.g. I was working on a display. The graphics were designed by a UX Team. However the display only had 256 colors, had to be readable outside, had a 320x240 resolution. They had designed everything as vector graphics with highest color settings on really good Eizo monitors. The customer thought the designs look cool, and I wasn't given any freedom in improving them.
I tried discussing the constraints with them, but because they were "on top" they wouldn't listen.
In the end the customer saw the prototype and said it looked terrible. But I had all the communication with the UX Team and them that I wasn't allowed to make it work for this display.
In the end it cost everyone an extra month and a lot of frustration to arrive at basically what I suggested when I first checked the hardware.
The problem isn't to learn about UX, it's that you have a "UX person" that may not know about UX and dictates the terms.
If one's priority is design freedom or whatever, a good working relationship with your higher ups is the best chance to enable that.
Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
True, the problem is more when companies become more and more top-heavy over time. These intermediate layers are created. With every layer it becomes less likely that the people that can actually decide won't ever hear valuable feedback until it's too late.
>Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
In the end I showed them what had to be done to make it look decent on this kind of display. Because all layers of management were in the room, they managed to decide to do these changes. It's just a very inefficient way to get to this point.
People not listening come in all forms. UX, dev, MBA.
Unless you have valid reason to think the user would prefer your way, this sounds like the correct chain of command for a strong product.
Repeat the above for as long as you want.
Of course, the kind of place the GGP is complaining bout won't let peasants like developers to take part on that phase, so win-win, I guess.
It’s like that guy that said: “it’s easy to be a good investor in god times, it’s when recession hits that the pros really shine”
No true Scotsman would ignore the technical specs!
The fact is that many UX designers are designers first and foremost and maybe even entirely non-technical when it comes to specs. The existence of "true professional" UX designers does not mitigate the vast quantities of average skill UX people most teams will encounter.
I don't think that's much of an excuse. A graphic designer needs to know about page bleed and colour spaces. A product designer needs to understand the strengths (literally sometimes) and weaknesses of the materials they are working with. And a UX designer for a tech product needs to understand the technical constraints of the medium they designing for, or be able to talk proficiently to someone who does.
How can you design a user's experience (lest we forget what UX stands for) if you don't understand to at least some level the medium through which it will be conveyed. Designing something that a user will never see because the colour depth of the display they be using can't convey it is not designing the user's experience at all.
Right. Most designers are not UX designers, they are graphic designers hired to do UX because they can make pretty pictures in Illustrator.
A UI is essentially the highest layer of abstraction we build and thus should follow the same principles as any other. Namely respecting both the lower and the upper abstraction barriers.
UX designers are responsible for the language on top of all these layers. They need to understand the human side of things (often through data or through direct interaction such as workshops), but also the technical and artistic side of UI implementation. Direct interaction, written documentation and learning are paramount.
The good thing is that we programmers also want to understand the layer above us, so there is a natural pull for programmers and designers to communicate and to refine that communication.
Everything else was out of my hands.
Who said you did?
UX person suggests a design that is sprinkled with choices that clearly are from someone that has not been on the web that long, like wrong icons.
We do a meeting and explain what is going on, what the user wants to see on the page, and the UX comes back (usually that same day - how quick of them) with another version, but this version shows that the UX person did not understand the problem again. And again. And again.
I've seen the UX person showing a wireframe to the user and asking 'Will this cover all scenarios?'. Client said yes, we delivered the feature monday, and tuesday client was 'hummm, without the hability to do scenario X, this won't be used'.
The reason the UX person is so beloved between a bunch of devs is only because of the UI aspect of it - it looks good, something we devs could not come up with. But damn, I would love to work with an UX that I feel that knows what she's doing.
In fact I've seen several engineers trying to migrate to UX but the gatekeeping and prejudice made them give up.
I find "graphic designers" to be enormously helpful in solving problems related to user interaction and judgment with regard to use of color, typeface, and effective use of limited screen real-estate.
There are good ones and bad ones. The key is to assess where they are, and learn how to communicate with them with regards to any technical impacts.
The last thing I'd want to do in collaborating with a team-mate is summarily judge them as "my inferior". But that's (unfortunately) just me.
most organizations that tend to have office politics and are very politically-correct in their behaviour tends to end up with people in roles calling shots, despite those shots not being great.
graphics designers is just one example of this that i've seen, where a poor UI or bad UX is mocked up, but because you're an engineer, you do not get to have much input or your input is regarded as irrelevant (because your role is to code, not do UX design).
That's what i mean by the "inferior" comment - that the UX/UI designer isn't as good at their craft as you are in implementing code.
UX people, UI designers and PO/PMs who see developers purely as interface xerox machines don't really deserve much respect.
1) I've never met a UX person who is a programmer. Most of them are from graphic design background, sometimes for vouchers or magazines and they don't necessarily understand that the computer screen is not the same kind of medium as a piece of paper.
2) Having a professional relationship entails pushing back and questioning. Being a "yes man" to the UX people is not a good working relationship. The implication of your comment is in order to push back and provide feedback I must first acknowledge my subservience to their whims and only once they approve of my work I may humbly submit some suggestions for their kind consideration.
What I do find frustrating is when they only concern themselves "happy path", and developers don't have the authority to fill in the gaps. It creates a waterfall-like experience where you are often stuck waiting to hear back from product/design to make a decision because they didn't consider a scenario where the user might submit a form with an incorrect field or some other seemingly obvious path.
Another bad practice is product people who assume screenshots or Figma files are technical requirements; not realizing these only give you clues as to how something will look, not how something will work, so flows and business logic go under-examined by product, which can lead to more "let's hold off on that, let me think about it" after telling you to start something ASAP.
IMHO, loading states and error states are one of the more important parts of the design since they'll be seen often (for loading) and when the product isn't working for a user (error states).
At the point we have a functional prototype, go through it with UX so they can understand all of the pieces before they do the design. Sometimes it leads to minor improvements on what the engineers already came up with. Other times it leads to an overhaul.
But as long as all of the core functionality is built first, iterating on the design will just be moving a few things around.
I also find that backend people tend to have extremely good ideas when it comes to UX (better, even, than a lot of UX people), they just don't enjoy or aren't good at executing these ideas (or aren't allowed to). The takeaway is to take your backend engineers' opinions seriously and let them touch the frontend when they want to.
It often seems like there is more verification of that than whether it does what was intended.
"Here's a mockup - we spent a lot of time on this".
"OK... what does it look like on tablet, mobile, what are the failure states, what should error handling look like?"
"We spent a lot of time on this - make it look like the mockup".
Had a project years ago that was... almost as bad as that sounds.
The problem of course is that it's too easy to focus on pixel perfection at the cost of other things.
Recently, I've worked on a project and we had to force ourselves to 'not care' about those things until the very end when we did clean up.
I long for the days of building a simple site for my company. No fancy wizards, bifurcating flow, or complex animations. I unfortunately don’t think we’re going back to that time though.
E.g. this job add was on my feed right now: https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-a...
My first startup made an application that tried to control changes to projects and stop scope creep, and this reminds me why I thought there was a market for it. :)
In well functioning product teams everyone should be working together to make a better product, recognising the roles and strengths of each other. If this isn't the case, then your org has bigger problems.
That's rarely the top priority for everyone on the team at the same time. Design folks want to 'design', and agreeing that 'feature X' doesn't need to be in the screens - even if it's "the better product", doesn't align with their career need to have showcase material for the next job interview.
Similar with tech/dev folks - an update feature might just need simple poll mechanism, but that doesn't give them experience with building a full pub/sub scalable architecture platform, or testing out the newest messaging libraries.
The more people on that team, the more conflicting priorities there will be.
This doesn't sound like a great team, and doesn't really align with my (sure, admittedly limited) experience. I've only really worked once with someone who had strongly personally motivations that worked against the teams goal, and it was recognised that they were a wanker.
That is completely true. To work together to build a product, to have everybody understanding what is what needs to be achieved, and collaboration in general is the way to go.
In organizations where business does not trust engineering, engineering does not trust design ... things are never going to work. It is a collaborative effort, one point of view is insufficient to create an attractive product in a cost-effective way that is not full of tech-debt.
While you may be able to build a working page, can you ensure that every engineer builds it with the same interactions, flows, language, and even colors? Will you build and test it for the users the UX team has researched, or will you build it for yourself?
I can keep consistentancy by just having a JS library that has our components.
As for flow no I can't because different situations and objectives require different workflows to force them all to be the same is the kind of thing that sounds like a good idea until it is clearly not.
But the funny thing about all of that is that everything listed above has to be done either way, and usually the UX guys will shove it off on engineering to implement so where is their value add....?