Live data from Hacker News

Bug Blindness

danluu.com

191–200 of 263 posts

Re: Bug Blindness

#191

Earlier quoted context omitted.

Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives. Still, they get it. Some icons outlive their era, some don’t. > In the 90s everybody knew how a paper book worked I hope that’s still the case!

> Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives. It's hard to call this an example of "skeuomorphism". Those icons were introduced on physical buttons with a certain meaning that everybody had to learn. They have exactly the same meaning on software buttons; the interaction that people have with them now is the same interaction that everybody has always…

> the interaction that people have with them now is the same interaction that everybody has always had with them

Right, that was my point. What does it matter what a diskette used to be? Unless something more obvious to convey storage/saving comes along, it’s hardly “crashing down” anytime soon.

Re: Bug Blindness

#193

> Almost nobody objected to my characterization of Google and Bing search results, but people told me that I was wrong about Kagi. Paying for a product makes you defensive, especially if there are free alternatives.

More significant I think is paying for software indicates you are more selective - inc. against defects.

Re: Bug Blindness

#194
post #65

Earlier quoted context omitted.

> a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't re…

I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here. Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible. This makes for bette…

A developer sees an application as a toolkit to help them solve a problem. The more flexibility and power, the better it is. They’ve become comfortable with complex tools on the computer, over the years, because they enjoy learning about and using computers.

A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.

When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.

To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.

Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.

It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.

Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.

Re: Bug Blindness

#196
post #27

I think there are two opposite causes here: either an overly-aligned or completely unaligned mental model. For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into…

> You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.

Things like this just infuriate me. The user just learns that things are unreliable. To me that's unacceptable for something to be presenting a text box to type text, let you type it, then wipe it out. Sometimes you have to wait a second after typing something before clicking search, or it searches for your incomplete query a half second before. I don't blame users for just concluding that typing is unreliable.

Re: Bug Blindness

#197

I've had to live with shipping software with really poor quality that had loads of small bugs. My Product Manager forced me to. However, at the end, the customers seemed happy, and I have to admit that I was partially wrong. The QA guys flushed out the big bugs and many of the small ones. Without any proof, I imagine something like 99% of the customers would hit only a few bugs, that they are used to compensate for (…

Matches my experience. I think that 98% of the people that used our software were using only 2-3 battle-tested happy paths, and just never hit any bugs, not because there weren't any (there were hundreds of bugs in JIRA spanning 3+ years of development) but simply they didn't trigger the non-hot code path ever.

The software was crap, but it made money, so it wasn't crap.

Re: Bug Blindness

#198
post #54

Earlier quoted context omitted.

> They’re smart enough I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better. I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's…

One of my favorites is spending nearly 10 minutes trying to get someone to read a single word on their screen correctly, in a dialog box that was blocking them, containing fewer than 10 words, so I could find the cause of their problem. After nearly 30 minutes to figure out that they had a popup blocking them, and not "the computer doesn't work". What eventually worked was getting them to spell it to me backwards. Th…

Reminds me of how people learning to draw/paint are told to flip the subject upside-down, to bypass their interpretation getting in the way of seeing.

Re: Bug Blindness

#199
post #65

Earlier quoted context omitted.

I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here. Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible. This makes for bette…

A developer sees an application as a toolkit to help them solve a problem. The more flexibility and power, the better it is. They’ve become comfortable with complex tools on the computer, over the years, because they enjoy learning about and using computers. A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it…

Respectfully, I ain't reading all that with this opener. UX failed

Re: Bug Blindness

#200
post #144

Earlier quoted context omitted.

That is the reason why too many nerds recommended Linux as a "easy" windows alternative. What for us is easy to fix and often not even worth thinking about it, is impossible for a normal person.

Maybe? I think you may be underestimating how many papercuts of the same kind are there on Windows and on Macs. They're just harder to see when you're used to them.

No, when they hit a problem with Windows, they blame Microsoft and/or their hardware. When they hit a problem with Linux, they blame the person that recommended it to them.
Post reply on HN