Completely agreed on all points. In particular two key points:
Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject.
I actually have studied human-computer interaction, though I'm not an expert, and the number of times I've seen people in F/OSS projects strongly advocate for things that user studies have repeatedly shown to be bad for discoverability or correct use is depressing. Part of the problem here is a general one of not respecting expertise in fields other than your own, which is often quite strong in F/OSS communities but by no means exclusive to them.
There's also the problem that, if something ships with a bad UI, the active developers will use it a lot. Familiarity is something that you often optimise for in good UI design[1]. People already know how to use a bunch of things when they encounter a new tool (physical or software). If, when doing things other tools do, they interact with your tool in the same way, that's less to learn. But if someone has five years of experience working with a specific bad UI every day, they will have learned to work around all of its limitations. Changes will objectively make them less productive, even if they would make every other new user in the future more productive.
Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
I really cannot emphasise this one enough. Windows is a showcase of terrible design and it's depressing to see people copy them (including in trivial to fix things, like putting the buttons the wrong way around in dialog boxes). Apple generally did a lot better (though recently they've lost the plot entirely) but the really important thing about the Apple UI was that it solved a lot of problems that relate to the specific abstractions that they exposed. Trying to expose the same UI for different abstractions doesn't work. They also fitted a bunch of their abstractions around the limitations of early hardware (this shows up, particularly, in how some of their abstractions scale when you go from dozens of documents to tens of thousands on a computer). Their more modern UIs include things that try to address these limitations but also retain the old ones, often in confusing ways. Unless you understand why the choices were made, you will almost certainly build something worse even if you do a fairly faithful copy.
[1] I'm not going to say 'UX'. Today, even people who know what they're talking about say 'UX', which is sad. When this article was written, 'UX' was a very useful filter word. Anyone who actually understood the bits of psychology behind good UI design and how to measure usability talked about HCI. Failed artists who wanted to push their 'vision' in spite of not bothering to think about how the thing was used and who called themselves 'designers' in spite of not understanding what design actually is, talked about UX.
To nit a bit about 'UX' - it's intended to encompass the whole user experience, which UI design is only part of. Making sure your code is optimized so the user doesn't have to wait is part of UX, for example.
Knowing that, it's still useful because you can raise an eyebrow when someone says UX but really means UI.
That was certainly the claim. Unfortunately most of the people who used it early on were using 'we're caring about the whole experience!' as an excuse for ignoring all of the research on how to build that experience.
Changes will objectively make them less productive, even if they would make every other new user in the future more productive.
I think this is the most important sentence of your comment. There is a real conflict of interest!
Windows is a showcase of terrible design and it's depressing to see people copy them (including in trivial to fix things, like putting the buttons the wrong way around in dialog boxes).
Maybe the first question is which software is incentive aligned with which users.
the number of times I've seen people in F/OSS projects strongly advocate for things that user studies have repeatedly shown to be bad for discoverability or correct use is depressing.
Do you have a list of specific things you see a lot that fit this?
Windows is a showcase of terrible design and it's depressing to see people copy them (including in trivial to fix things, like putting the buttons the wrong way around in dialog boxes).
You say "wrong" like there's an obvious, universal answer. (and there is an obviously, universal, correct answer.... OK/Cancel. OK is the next step when filling out the form, it should immediately follow the form. Let me press tab then enter right now on this comment form and see what happens. If it cancels, I guess you're right.)
and there is an obviously, universal, correct answer.... OK/Cancel. OK is the next step when filling out the form
And that’s exactly the reason why Ok should be placed after cancel. Research has shown that users scan their options before choosing one, i.e. on Windows attention goes Ok, Cancel, and back to Ok, which is one unnecessary move.
It’s also why the labels shouldn’t be ‘ok’ and ‘cancel’, because users read the buttons before the informative text and click based on what they expect the prompt is. Which is why even in the ‘80s, Apple’s HIGs said to put verbs on the buttons (e.g. ‘Save’ and ‘Quit without saving’).
And twenty-four years later you could nearly re-run this article verbatim, just changing the names of the referenced browsers, and maybe adding a link to the XKCD spacebar heater in the section about users developing workarounds for the incremental bad designs.
Gruber also wrote about this back in the day too. My feeling is a lot of free software UX comes from essentially Conway's Law - the frontend reflects the structure of the backend, and the backend tends to be designed first and frontend an afterthought.
Or my pet peeve: error messages which say little more than Failed.
OK, what failed? Why? What was the program trying to do? What went wrong?
Messages intended for user consumption should be informative and actionable. You shouldn't need to know the internal workings of the program, in order to decipher the error message.
AI systems are terrible at this. The software they produce tends to produce error messages which describes the code failed in function foo(), file foo.c, line 14. That's because this is the information they have. They don't know the users intent, and the person prompting the AI system didn't help.
the developers are engineers (or software developers) not UI / customer interaction experts
A developer is not just "too close" to the subject matter, often their entire approach is wrong. I've seen developers write APIs and documentation which are hard to use, hard to understand, etc. The approach seems to be to write something the developer wants to use, based on information the developer knows.
The result is an interface (GUI or API) which is utterly opaque to everyone other than the developer.
A good interface solves the users needs, not the developers needs. For one example of how to address user needs, see https://www.kristineyuen.com/bart-kiosk
david_chisnall | 18 hours ago
Completely agreed on all points. In particular two key points:
I actually have studied human-computer interaction, though I'm not an expert, and the number of times I've seen people in F/OSS projects strongly advocate for things that user studies have repeatedly shown to be bad for discoverability or correct use is depressing. Part of the problem here is a general one of not respecting expertise in fields other than your own, which is often quite strong in F/OSS communities but by no means exclusive to them.
There's also the problem that, if something ships with a bad UI, the active developers will use it a lot. Familiarity is something that you often optimise for in good UI design[1]. People already know how to use a bunch of things when they encounter a new tool (physical or software). If, when doing things other tools do, they interact with your tool in the same way, that's less to learn. But if someone has five years of experience working with a specific bad UI every day, they will have learned to work around all of its limitations. Changes will objectively make them less productive, even if they would make every other new user in the future more productive.
I really cannot emphasise this one enough. Windows is a showcase of terrible design and it's depressing to see people copy them (including in trivial to fix things, like putting the buttons the wrong way around in dialog boxes). Apple generally did a lot better (though recently they've lost the plot entirely) but the really important thing about the Apple UI was that it solved a lot of problems that relate to the specific abstractions that they exposed. Trying to expose the same UI for different abstractions doesn't work. They also fitted a bunch of their abstractions around the limitations of early hardware (this shows up, particularly, in how some of their abstractions scale when you go from dozens of documents to tens of thousands on a computer). Their more modern UIs include things that try to address these limitations but also retain the old ones, often in confusing ways. Unless you understand why the choices were made, you will almost certainly build something worse even if you do a fairly faithful copy.
[1] I'm not going to say 'UX'. Today, even people who know what they're talking about say 'UX', which is sad. When this article was written, 'UX' was a very useful filter word. Anyone who actually understood the bits of psychology behind good UI design and how to measure usability talked about HCI. Failed artists who wanted to push their 'vision' in spite of not bothering to think about how the thing was used and who called themselves 'designers' in spite of not understanding what design actually is, talked about UX.
DustyFuzzy | 17 hours ago
To nit a bit about 'UX' - it's intended to encompass the whole user experience, which UI design is only part of. Making sure your code is optimized so the user doesn't have to wait is part of UX, for example.
Knowing that, it's still useful because you can raise an eyebrow when someone says UX but really means UI.
david_chisnall | 14 hours ago
That was certainly the claim. Unfortunately most of the people who used it early on were using 'we're caring about the whole experience!' as an excuse for ignoring all of the research on how to build that experience.
k749gtnc9l3w | 17 hours ago
I think this is the most important sentence of your comment. There is a real conflict of interest!
Maybe the first question is which software is incentive aligned with which users.
adam_d_ruppe | 8 hours ago
Do you have a list of specific things you see a lot that fit this?
adam_d_ruppe | 15 hours ago
You say "wrong" like there's an obvious, universal answer. (and there is an obviously, universal, correct answer.... OK/Cancel. OK is the next step when filling out the form, it should immediately follow the form. Let me press tab then enter right now on this comment form and see what happens. If it cancels, I guess you're right.)
diktomat | 12 hours ago
And that’s exactly the reason why Ok should be placed after cancel. Research has shown that users scan their options before choosing one, i.e. on Windows attention goes Ok, Cancel, and back to Ok, which is one unnecessary move.
david_chisnall | 8 hours ago
It’s also why the labels shouldn’t be ‘ok’ and ‘cancel’, because users read the buttons before the informative text and click based on what they expect the prompt is. Which is why even in the ‘80s, Apple’s HIGs said to put verbs on the buttons (e.g. ‘Save’ and ‘Quit without saving’).
jcelerier | 3 hours ago
so why do i get it wrong so many times and press ok when I wanted to press cancel and conversely ?
klardotsh | 23 hours ago
And twenty-four years later you could nearly re-run this article verbatim, just changing the names of the referenced browsers, and maybe adding a link to the XKCD spacebar heater in the section about users developing workarounds for the incremental bad designs.
Time is but a circle.
calvin | 12 hours ago
Gruber also wrote about this back in the day too. My feeling is a lot of free software UX comes from essentially Conway's Law - the frontend reflects the structure of the backend, and the backend tends to be designed first and frontend an afterthought.
alandekok | 5 hours ago
Or my pet peeve: error messages which say little more than
Failed.OK, what failed? Why? What was the program trying to do? What went wrong?
Messages intended for user consumption should be informative and actionable. You shouldn't need to know the internal workings of the program, in order to decipher the error message.
AI systems are terrible at this. The software they produce tends to produce error messages which describes the code
failed in function foo(), file foo.c, line 14. That's because this is the information they have. They don't know the users intent, and the person prompting the AI system didn't help.The result is frustrated users.
Sanity | 19 hours ago
So, what can be done?
technomancy | 8 hours ago
Stop devaluing the skills of potential contributors whose skills are in areas other than programming, would be a start.
alandekok | 5 hours ago
I would add an additional item:
A developer is not just "too close" to the subject matter, often their entire approach is wrong. I've seen developers write APIs and documentation which are hard to use, hard to understand, etc. The approach seems to be to write something the developer wants to use, based on information the developer knows.
The result is an interface (GUI or API) which is utterly opaque to everyone other than the developer.
A good interface solves the users needs, not the developers needs. For one example of how to address user needs, see https://www.kristineyuen.com/bart-kiosk