Live data from Hacker News

Why users cannot create Issues directly

github.com

301–310 of 320 posts

Re: Why users cannot create Issues directly

#301
post #288

Earlier quoted context omitted.

> people who don't read error messages One of my pet peeves that I will never understand. I do not expect users to understand what an error means, but I absolutely expect them to tell me what the error says . I try to understand things from the perspective of a non-technical user, but I cannot fathom why even a non-technical user would think that they don't need to include the contents of an error message when seekin…

> Instead, it's "When I do X, I get an error". Worse still, just “it doesn’t work” without even any steps. I sometimes gave those users an analogy like going to the doctor or a mechanic and not providing enough information, but I don’t think it worked.

My wife’s a doctor. Trust me, this isn’t unique to technical pursuits.

Patient: My foot hurts.

Wife: Which part of it?

Patient: It all hurts.

Wife: Does your heel hurt?

Patient: No.

Wife: Does your arch hurt?

Patient: No.

Wife: Do your toes hurt?

Patient: This one does.

Wife: Does anything but that one toe hurt?

Patient: No.

Wife: puts on a brave smile

Re: Why users cannot create Issues directly

#302
post #204

Earlier quoted context omitted.

How does different count affect search? You can use a bookmark to change the view, and if using bookmarks is too much, ok, but that's not a bold universal reason. (also, what is "huge success" in methods of organizing issues?) bookmark: (and if your browser supports shortcuts, it can be as easy to open as remembering to type a single char) https://github.com/ghostty-org/ghostty/issues?q=is%3Aissue%2...

Here is an abridged set of reasons, just because it quickly turns into a very big thing: 1. The barrier to mislabel is too low. There is no confirmation to remove labels. There is no email notification on label change. We've had "accepted" issues accidentally lose their accepted label and enter the quagmire of thousands of unconfirmed issues. Its lost. In this new approach, every issue is critical and you can't do th…

Sounds like maybe the next project should be a better bug report/issue tracker

Re: Why users cannot create Issues directly

#303
Works for large projects with active communities (Ghostty has both). The filter pays off when volume is high. Doesn't work for smaller projects where every report matters and you want to lower barriers. The brutal honesty ("80-90% of you are wrong") is refreshing but may alienate contributors. A middle ground would be issue templates with mandatory checklists, filters without adding an extra step.

Re: Why users cannot create Issues directly

#304

Earlier quoted context omitted.

Most (all?) photo apps include a crop function, allowing your mom just crop out everything else.

I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.

I wasn't being sarcastic. This is not a case of not being capable of doing something, it's about not knowing the functionality exists. Cropping is very simple. I assumed the GP didn't know about it either or he would have taught his mom already.

Could the manufacturer solve this in a better way? Probably but that won't solve the issue the customer has now.

Re: Why users cannot create Issues directly

#305

Earlier quoted context omitted.

> I do not expect users to understand what an error means I'm not sure I agree. Reason ? The old adage "handle errors gracefully". The "gracefully" part, by definition means taking into account the UX. Ergo "gracefully" does not mean spitting out either (a) a meaningless generic message or (b) A bunch of incomprehensible tech-speak. Your error should provide (a) a user-friendly plain-English description and (b) an er…

This is not about understanding the message, but switching user mental activity. I go myself in the similar situations many times. One example: I tried to pay my bills in online bank application, but got into error. After several attempts, I did read message and it say "Header size exceed..." . It give me clue that app probably put too much history into cookies. Clear browser data, log in again, and all got works. Ev…

> This is not about understanding the message, ...

99% of the population have no idea what "Header size exceeded" means, so it absolutely is about understanding the message, if the devs expect people to read the error.

Re: Why users cannot create Issues directly

#306
post #276

Earlier quoted context omitted.

There are people that when using a computer, if anything goes remotely wrong, they completely lose all notions of language comprehension. You can make messages as non-technical as possible and provide troubleshooting steps, and they just throw their hands up and say "I'm not a computer person! I don't know what it's telling me!" 20 years ago, I worked the self-checkout registers in retail. I'd have people scan an ite…

>completely lose all notions of language comprehension I see this pretty often. These aren't even what should be called typical users in theory. They are people doing a technical job and were hired with technical requirements, an application will spit out a well written error message in the domain they should be professionals in and their brain turns off. And ya, it ends up in a call to me where I state the same thin…

I think part of it is that most users at some point encounter an error message that is just straight up wrong. For example, a login page that says "wrong password" when in reality the user is typing EXACTLY what they typed on account creation, but the site silently truncated the password. Even one such frustrating experience is enough to teach many users that as soon as they see any error message, they should stop trusting anything the system tells them, including the error message. It's extremely difficult to rebuild user trust after this sort of UX contract violation, particularly because less technical users don't mentally differentiate separate computer systems. All the systems are just "the computer."

Also arguably the users are kind of right. An error indicates that a program has violated its invariants, which may lead to undefined behavior. Any output from a program after entering the realm of undefined behavior SHOULD be mistrusted, including error messages.

Re: Why users cannot create Issues directly

#307
post #176

Earlier quoted context omitted.

>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features). > Do I ever make mistakes? > No. It’s the users who are wrong. This is a textbook example of being uncharitable. Framing matters a lot! If you frame somethi…

I disagree. He's just trying to educate these guys about usability. Most people by default see "user got something wrong" and respond "rtfm" or "you don't understand" or "don't make mistakes". The vast majority of people using Ghostty are not stupid. If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.

>>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).

>> Do I ever make mistakes?

>> No. It’s the users who are wrong.

> I disagree. He's just trying to educate these guys about usability.

I invite you to reconsider for these reasons: (1) Have you seen people "just trying to educate" in an uncharitable way? Many people have. Such cases of 'education' may involve paternalism and/or assuming the other person is ignorant. For example, both can manifest in the phenomenon of "mansplaining". There are more tells, also: (2) The commenter doesn't ask questions; (3) The commenter doesn't steel-man the other position; (4) The commenter uses a mocking tone. (To be fair, I've done such things in the past, but I'm striving to do much less of it.)

> The vast majority of people using Ghostty are not stupid.

No one is claiming this. Individual intelligence is not the same as «how people behave in system S compared to system S'». In other words, people do 'stupid' things all too often -- just hop in an automobile and watch our collective behavior.* Not to mention riots and mobs.

In the case of some issue tracking systems, "not-stupid" people can do things that are counter productive.

So, if project leaders have the ability, dedication, sincerity, rationale, and motivation to experiment with different systems, I say GO FOR IT. Experiment. Take a risk. Refusing to experiment is often worse.

Some people forget a key underlying principle of 'agility'† : start somewhere, gather feedback, be rational, experiment, and see where it takes you. If you see two different teams in different circumstances doing things the same way, you might take a closer look: one or both might have rigid processes that have stopped learning.

> If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.

Maybe, but that sounds like a tall claim. Remember that the Ghostty team _did in-fact_ make changes to their _process_ based on reflection.

I put much more confidence in the Ghostty team, who has shown signs of thoughtfulness, to make careful and wise decisions than someone with no skin in the game (a vast majority of the people here), especially uncharitable ones.

* I try not to 'blame' individuals or groups -- most human responses are statistically predictable and often even sensible and maybe even justifiable from a narrow point of view. If anything, I ascribe more importance to the design of roads, automobiles, and the cultural pressures we face.

† Too many forms of 'agility' forget the notion of recursive self-improvement. They instead get mired in ceremony.

Re: Why users cannot create Issues directly

#308

Earlier quoted context omitted.

I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.

I wasn't being sarcastic. This is not a case of not being capable of doing something, it's about not knowing the functionality exists. Cropping is very simple. I assumed the GP didn't know about it either or he would have taught his mom already. Could the manufacturer solve this in a better way? Probably but that won't solve the issue the customer has now.

Poe's Law goes both ways. As a matter of fact, my mom invented digital photo cropping (or "pixel array extent adjustment," because even in her prime she wasn't a marketing genius, bless her heart). We know better than to expect her to submit a bug report once she's settled down to watch TV for the evening.

Jokes aside, "upload a photo of her living room" was meant to highlight the ridiculousness of the UX. I believe the designer of that flow had an OKR to decrease the number of reported bugs.

Re: Why users cannot create Issues directly

#310

Earlier quoted context omitted.

> people who don't read error messages One of my pet peeves that I will never understand. I do not expect users to understand what an error means, but I absolutely expect them to tell me what the error says . I try to understand things from the perspective of a non-technical user, but I cannot fathom why even a non-technical user would think that they don't need to include the contents of an error message when seekin…

Just today I've had a "technical" dude complain about something "not working". He even checked "thing A" and "thing B" which "looked fine", but it still "didn't work". A and B had absolutely nothing to do with each either (they solve completely different problems). I had to ask multiple times what exactly he was trying to do and what exactly he was experiencing. I've even had "web devs" shout there must be some kind…

Your “technical guy” sounds a lot like me.

When debugging stuff with the devs at our work, I tend to overexplain as much as I can, because often there’s some deep link between systems that I don’t understand, but they do.

I’m a pretty firm believer in “no stupid questions (or comments)”, because often going in a strange direction that the devs assure me isn’t the problem, actually turns out to be the problem (maybe thing A actually has some connection to thing B in a very abstract way!).

I think just serving a different perspective or theory can help us all solve the problem faster, so sometimes it’s worth to pull that thread, even if it seems worthless in the moment.

Maybe I’m just lucky that my engineering colleagues are very patient with me (and maybe less lucky that some of our systems are so deeply intertwined), but I do hope they have more than zero expectations from me, as we mean well and just want to support where we can, knowing full well that ya’ll are leagues ahead in the smarts department.

Post reply on HN