Hacker News Reader

Comment by YorickPeterse | Hacker News Reader

Over the years I've learned there's a class of users that simply don't read.

Example: for GitLab we stopped using the repository that used to host the code for GitLab CE. All issues were closed, and when you create a new issue there's a template active that basically says "Don't create issues here". In spite of that, people still create issues here, and in some cases don't even bother changing that template.

View on HN

I've spent more than a decade in customer/user-facing roles, and that class of users is actually "almost all of them."

But it's worse than that. Most people do not have the reading fluency to read more than a few words in a sentence without getting frustrated and confused. If your work peers and social groups consist of the 3-5% of people who aren't in that category, it can be easy to forget that.

Any time you can make something's function clear with one or two words and design, opt for that over explanation.

Then you get people like me who prefer to read words, but are utterly baffled by the user experience on modern social platforms... like, how do I log out? Oh, the smiley button, duh.

And this is why UI/UX experts are so valuable in software projects!

If "almost everyone" fails some expectation, is the problem with the people or the expectation?

The average user might not be super invested in the application, they just know that something doesn't work, which is frustrating. If their only outlet for that is a bug report, the developers get overwhelmed with bad bug reports and users get the expectation that the developer is going to fix all their problems for them.

If the outlet is a feedback form instead, maybe the user can feel listened to in a small way and move on. The developer doesn't have to sift through a bunch of issues, they can just follow up if there seem to be any hot-spots that are causing a lot of frustration.

Exactly; the problem here is that there's a repository that allows issues to be filed, when the owners don't want issues reported there. Issues should just be turned off on that repository (and if you can't do that, I'd consider that a big missing feature).

You need to guide people to do the right thing based on the interface itself; people overwhelmingly don't read instructions.

That's my point. Things have to be designed with the understanding that "people who won't read the instructions" are the rule, not the exception. That has to be the expectation if anything is ever going to improve.

Unless you know you're dealing with a very specific subset of the general population who loves reading, design around things that don't need to be read.

I don't see how replacing "sift through a bunch of issues" with "sift through a bunch of feedback forms" makes the developer's job any easier.

This sounds like an UI problem. Why can't the system just disable the issue creation button?

Yeah. It's literally one checkbox lacking on GitHub.

So (1) Scrape the old, closed issues to a static website, link it from README.md. (2) Disable Issues in GitHub's repo settings.

Part 1 is somewhat complicated, because issue-to-issue linking.

Same feeling, the fact that one has to assume people will not take 5s to read and understand a message has nothing to do with the project being open-source & free or not.

I feel that it must be even more annoying when you're offering free great work to these people. But I believe it to be a fact about all users (I include myself, though I'm trying to work on it).

Reply on news.ycombinator.com