I agree with you. More often, what I've seen is that engineers aren't interested in it. It is tedious in ways that are not interesting, often involving working with non-technical people.
Most engineers I've worked with find things like "yes, it really matters that those labels are lined up pixel perfect" to be annoyances at best. We tend to work at a deeper level, thinking behind the screen, so we don't often see the screen.
Most engineers I've worked with find things like "yes, it really matters that those labels are lined up pixel perfect" to be annoyances at best. We tend to work at a deeper level, thinking behind the screen, so we don't often see the screen.
This statement suggests to me that you missed the entire point of Gruber's essay. To whit:
This idea, that the hard work of development is in building the underlying foundation, and that the easy part is writing a “GUI wrapper”, has been the Linux/Unix way all along...
UI development is the hard part. And it’s not the last step, it’s the first step.
I'm with Gruber. Good UI is not aligning pixels after the fact. Aligning pixels is to usability as formatting source code is to programming. I abhor the idea that programming is a "deeper level" than usability. In fact, it's the other way around: Usability is a deeper level than programming.
Let me give you an example. Dave Winer had to edit a lot of hierarchal text in the form of Pascal programs. He then got the idea of editing hierarchal text in the form of outlines, and an entire category of software was born. That category was later subsumed by other programs, to the point where nearly everything we use today has some sort of outline editing capability.
UI design was not arguing about which symbols represent collapsed and expanded headlines, or whether the target of dragging an outline should highlight the parent or hilight the space between elements where the dragged outline will go.
UI design was thinking up the idea of editing outlines instead of editing characters and words.
p.s. That being said, I agree with you as well. Many so-called UI designers don't get Gruber's point either, and they will natter endlessly about pixels and colours and CSS grids while having nothing but tired cliché opinions about the actual mental model and functionality of software.
When a "designer" is really a stylist, it is very tiresome to work with them. Since they have nothing else to contribute, they become infuriating nitpickers over trivia just as you suggest.
This statement suggests to me that you missed the entire point of Gruber's essay.
You are right that I made my point overly trivial. It was supposed to be the extreme case of understanding the importance of UI design: how it looks and works is very important.
I've designed many interfaces, but I am not a designer. Understanding the user, how they use the system, and how the system needs to react to that use is what matters.
You can build a great UI without being pixel-perfect, but, in my experience, engineering teams who fight pixel-perfect will fight the effort that it takes to understand what a great UI for their system is.
It's not so much that it's not interesting, or that involves working with non-technical people, or that it requires pixel perfect alignment, or that the screen isn't a deep enough level. It's that it is all about working with other people as human beings. It's about empathizing with people who are different than you are, learning to see through their eyes, giving them what they need, and not getting any payoff in terms of interesting technical problems to solve. It's probably the exact opposite of what draws most people, myself certainly among them, to programming in the first place.
That said, I also agree that pretty much anyone can learn to be a good UI designer, just as anyone can learn to draw well. As in any field, talent helps and the very best people will always be the ones with talent, but it is much more important to want it enough to put in the necessary work. If you are a programmer who only cares about technical mastery then you will never be a good UI designer, and, as you said, there are a lot of programmers out there who are mostly interested in technical mastery.
I agree. However, if you won't do the easy stuff (which is critical to making a good interface), how likely are you to do the hard stuff (understanding the user to know how they are going to use the software)?
Most engineers I've worked with find things like "yes, it really matters that those labels are lined up pixel perfect" to be annoyances at best. We tend to work at a deeper level, thinking behind the screen, so we don't often see the screen.