Facts:
- Things like APIs and coding libraries aside, the bulk of documented interface complexity could be made obsolete in a design phase.
- Blaming users is usually what happens when developers don’t understand why their software is poorly designed.
- Most open source software doesn’t even have a design phase— it just gets built, and the warts get documented… hopefully. And if those warts change, the docs get updated… hopefully. Also, documentation is difficult to write, especially for a non-developer audience. Companies that make products with unavoidable complex interfaces or configurations have departments of technical writers who do nothing but build and refine documentation. Most of what developers consider to be carelessness in reading docs is really poorly written or constructed docs.
- Because of that, reading technical documentation is a skill. Remember the first time you looked at a man page? When you did that, you were probably vastly more technical than a typical end user. Technical documentation is just opaque to most users.
- Most end user focused commercial software is barely documented because it doesn’t need to be. Most end users wouldn’t even think to consult documentation, let alone know how to find documentation. Hell, even in the 90s the very first thing people threw away was the booklet that came with the CD ROM.
- FOSS developers embracing design knowledge can bring FOSS software to a commercial level of usability, which will vastly increase adoption. That alone is a worthy goal.
Nobody has the right to demand anything of anybody who’s volunteering their time. Never said they did. But we who develop FOSS should view usability and interface concerns just as seriously as technical concerns.
I've seen many stewards of FOSS projects treat non-blocking but ugly interface bugs as high priority issues, but terrible interfaces, workflows, wording, etc. as documentation problems or back burner issues that stay open forever.
I think it's a "when you're a hammer, everything looks like a nail" problem. Devs understand interface bugs because there's a logical difference between bug-free and buggy code. Design isn't that cut-and-dried. No matter how many times people try to quantify terrible workflow to get some sort of Big O metric— number of clicks/screens, amount of scrolling, et. al. it crumbles in opposition to empirical research. Justifying your design decisions with user research is much more difficult with open source projects, so you've really got to take the word of someone with that domain-specific interface design knowledge.
But it's important not to let these problems languish. People love the familiar— when maintainers and core users imbue their workflows with mitigation strategies, they view fixes with skepticism or even hostility. Once significant functionality gets piled on that flawed base, the chance of ever having a good, usable interface is pretty much nil.
- Blaming users is usually what happens when developers don’t understand why their software is poorly designed.
- Most open source software doesn’t even have a design phase— it just gets built, and the warts get documented… hopefully. And if those warts change, the docs get updated… hopefully. Also, documentation is difficult to write, especially for a non-developer audience. Companies that make products with unavoidable complex interfaces or configurations have departments of technical writers who do nothing but build and refine documentation. Most of what developers consider to be carelessness in reading docs is really poorly written or constructed docs.
- Because of that, reading technical documentation is a skill. Remember the first time you looked at a man page? When you did that, you were probably vastly more technical than a typical end user. Technical documentation is just opaque to most users.
- Most end user focused commercial software is barely documented because it doesn’t need to be. Most end users wouldn’t even think to consult documentation, let alone know how to find documentation. Hell, even in the 90s the very first thing people threw away was the booklet that came with the CD ROM.
- FOSS developers embracing design knowledge can bring FOSS software to a commercial level of usability, which will vastly increase adoption. That alone is a worthy goal.
Nobody has the right to demand anything of anybody who’s volunteering their time. Never said they did. But we who develop FOSS should view usability and interface concerns just as seriously as technical concerns.