Why Free Software usability tends to suck (2002)
28 points by isagalaev
28 points by isagalaev
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.
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?
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.
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’).
Research has shown that users scan their options before choosing one
so why do i get it wrong so many times and press ok when I wanted to press cancel and conversely ?
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.
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 result is frustrated users.
So, what can be done?
Stop devaluing the skills of potential contributors whose skills are in areas other than programming, would be a start.
This cannot be a start.
I know their contribution will make things worse for me, I know their contribution will make things worse for people who generally think like I thought before I touched the internals, and I know the contribution might make things better for the users least likely to contribute — or maybe not, I hear enough complaints about basically interaction design from people thinking very differently from me, I cannot vet this specific proposal.
To have contribution in the interests of least-developer-like users be valued, you need first a way of convincing that this is actually aligned with user interests, ideally in a way that won't be immediately abused (because invasive telemetry sounds quite similar to the research methods on HCI, except that it has worse disclosure/consent/data-control properties).
(Even then a conflict of interests will remain, though!)
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
However, I have seen things where as a developer not involved with the project (not necessarily FOSS) in any way, in the user role I really need «what developer needs» UI (is this design literally taken from OO Design textbook then wrapped into an UI directly? I can't rule out and I have no objection) more than «what user needs UI» based on figuring out most frequent user actions and user personas and building an UI around this knowledge.
This might be a direct conflict of interest: to do anything slightly more complicated I need to navigate not just a mental model of the subject domain, but a mental model of their mental model of a user (whether it is correct or not — I cannot judge this). Which puts me into opposition with people who want to navigate things without building a mental model, I guess.