> Lots of exclusively technical types don't understand why people are confused...
It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question.
> When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it.
Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.
To be fair, I’m fairly technical and I also proactively avoid reading the documentation. In the ideal scenario the interface to whatever I’m using is self explanatory, and I don’t run into any issues.
It’s only if the product has a less simple interface that I have to fall back to the documentation (and I dislike doing so).
Even then, you can kill a lot of seemingly inevitable interface complexity by thoughtful application of common idioms, hiding elements (ideally automatically) that are really never useful in that part of a workflow, consistent meaningful layout among work screens, communicating commonality and intent with color, proximity, shape, size, etc., good use of labels when necessary, and moderate use of animation to convey how the interface is changing so a user can stay oriented. You can really only make these decisions by carefully studying user workflows. How many enhancement request issues have you seen in issue trackers where a project maintainer makes an off-handed declaration that users don't really want/need that functionality? How often do you suppose it was entirely based on the way they use the software and nothing else?
I've spoken to many developers whose workflows have been stymied by oversimplified interfaces and they associate designers with pretty looking but defanged interfaces. Those are poorly designed interfaces. Usually they're put together by someone whose goal is to get featured on Dribbble where functionality is secondary. Those designs have their place as aesthetic inspiration for other designers, but they should not be seen as formal goals.
“Everything should be made as simple as possible, but no simpler.”
The reason why the interface design and graphic design degree programs are very similar at the college I'm attending is because many of the goals are exactly the same— using layout, text, graphics, animation, and other elements to communicate complex ideas as clearly and efficiently as possible. The semiotic analysis common in higher-level design has just as much application in interface design. The denotation of two separate save buttons might be exactly the same, the connotation might change drastically depending on what it's next to, what it's the same color of, the weight of the font, the weight of the stroke of the button compared to other elements, if there's an animation when your cursor gets close to it, etc.
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.
It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question.
> When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it.
Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.