Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug Blindness

danluu.com

Post reply on HN
Print view View original

231–240 of 259 posts

Re: Bug Blindness

#231

Post by OJFord »

foxglacier wrote: post #217
OJFord wrote: post #103

Earlier quoted context omitted.

That's even worse than the "I'm getting an error when I ..." type! ("...ok... What's the error? ")

Developers should adapt to human behavior not laugh at users for using their precious thing wrong. It's not precious to the user. A probably misremembered quote from Joel Spolsky is users don't love your software, they tolerate your software because it's the least annoying obstacle in the way of doing what they want to do.

The person I replied to described their frustration with a colleague dismissing an error message without reading, not a user. I'm not shaming users not providing clear actionable feedback with stack traces and reproduction steps. I've known fellow software engineers throw their hands up and ask for help because they're 'getting an error', that's what's annoying (because they should know better, ok what have you done before asking me, etc.) not users.

Re: Bug Blindness

#232

Post by kmoser »

socalgal2 wrote: post #36
kmoser wrote: post #20

Earlier quoted context omitted.

I had this same discussion on another HN thread a while back. I prefer lines to run as long as possible; I find it difficult/distracting to move my eyes to the beginning of the next line every few seconds. I'm sure I'm in the minority, but I have to believe I'm not the only one out there who feels this way. Rather than having the website author wrap lines at a width that works for the average user or use case (which…

> I find it difficult/distracting to move my eyes to the beginning of the next line every few seconds. You must find it difficult to read books, magazines, newspapers, as all of them have short lines

To some degree, yes. Not to the point that I can't or won't do it, but I would certainly prefer books to be printed much wider. I can mitigate some of the issue by keeping my index finger along the left margin as I read, so I have a better idea of where my eyes need to jump to the next line. That technique is impossible with my computer screen, which is more than arm's length from me.

Part of the issue is that I read fairly quickly, so I find myself spending a relatively large percentage of my time skipping to the next line, and it's that frequent context switching that is annoying.

Re: Bug Blindness

#233

Post by DrewADesign »

atmavatar wrote: post #45
DrewADesign wrote: post #42

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…

> 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…

Well, software doesn’t exist for its own sake, the sake of the people that made it, or the sake of some kind of exclusive smartypants club. The purpose is to solve problems or accomplish tasks for people— some of whom are not cognitively gifted. A good interface will take everybody that needs it into account, including people that need less handholding if the usage is different enough.

Re: Bug Blindness

#235

Post by m3047 »

Sniffnoy wrote: post #122

Responding to something from the linked Patreon post: > Blackboard (as well as Epic and SharePoint) are classic examples of software where the user and the purchaser are different and the purchaser basically doesn’t care about the user, so you don’t expect the software to be good and it would be a bit of a surprised if the software didn’t deliver a bad user experience. But it was even more surprising to me that someo…

A close acquaintance was on Medicaid, and then got a new job and was moved off of Medicaid onto an insurance plan they were paying for. Medicaid is administered by insurance companies; the same company administered both their Medicaid plan, and the plan they were now paying for.

As it so happened, within a week of this occurring they needed urgent care, badly, no joke. We have basically three choices here (at least, which would take this insurer), and none of the three would see them, and the reason was the same in all cases: 1) they no longer had Medicaid, and 2) the provider couldn't let them pay cash and sort it out with the insurance company themselves.

It took three days calling the insurer, providers, the State health exchange, finally getting the insurer on the phone DIRECTLY with one of the providers... at a clinic rather than in admin... the insurer directly telling the clinic administrators that the person was insured and the insurance company would give them a claim number right now, or something like that... before we could get them in to see a doctor.

When we got to the clinic they looked them up and STILL told them they couldn't see them we had to demand to speak to an administrator and basically THEY COULDN'T CHECK THEM IN TO THEIR APPOINTMENT in their computer.

All of these providers used Epic. I made some additional phone calls and had some additional conversations, made a writeup, and sent it to the insurer, the benefit exchange, and the provider who ultimately saw us. Never heard anything from anyone.

Re: Bug Blindness

#237

Post by pixl97 »

Xymist wrote: post #186
eru wrote: post #132

Earlier quoted context omitted.

> 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. In the 2010s Mathworks, the company that makes Matlab, had a policy that everyone started in frontline support. Including developers. (They probably still have thi…

The shaping isn't necessarily productive, though. My company has a policy wherein a the dev team are on a rota to assist the support team (and by extension clients) with technical queries. The net effect has been to make me hate customers with a passion usually reserved for opposing political regimes and childhood bullies.

>The net effect has been to make me hate customers

So what every support person lives thru on every day of work.

And really being a good support person involves figuring out what bucket the customer belongs in.

"Customers that are smarter than you and if they are talking to you, your shit is wrong somehow"

"Customers that are smart in general, but need some guidance accomplish more complex tasks"

"Customers that aren't very smart, but handholding works to solve their problems"

"Customers that are dumb, realize they are dumb, and persistent at being dumb"

and finally the worst

"Customers that think they are smart and are belligerent if their intelligence is questioned as they are doing something horrifically stupid"

Re: Bug Blindness

#238

Post by nicoburns »

jdm2212 wrote: post #77
bsder wrote: post #19

Earlier quoted context omitted.

Applications like Blackboard exist because of the genre of "Checkboxware." A University must comply with Laws and Regulations X, Y, Z, P, D and Q and a host of other regulations the University never heard of and Blackboard went through the process to "comply" with those checkboxes. So, if you deploy Blackboard, you tick all the checkboxes automatically. The fact that Blackboard was a garbage content management system…

It's not really regulation-driven. It's just what happens when the people buying software and the people using it are different. This is the standard problem of enterprise software is marketed to the IT department (which cares about cost, box-checking, vendor relationships, lock-in risk, bureaucratic turf wars, headcount preservation, SLAs, etc) with little or no regard for responsiveness to end user needs. It is def…

Part of it is also that universities mostly already tried building their own bespoke software in the 90s using 90s era technology and development practices, and got bitten by ending up with legacy software that they couldn't afford to maintain.

Re: Bug Blindness

#239

Post by pixl97 »

remus wrote: post #88
prmph wrote: post #56

Earlier quoted context omitted.

At what point does search quality degrade to the point where is becomes a bug? A bug is when actual behavior does not match stated or intended behavior. If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned. Or maybe you mean to say we should reserve the word bug for deviations that are unintentional?

For me the idea that poor quality search results are a bug muddies the idea of what a bug is. It's like saying the colour of the paint in my living room is buggy because I don't like it. It might be an ugly colour that I don't like, but it is what it is. A bug would be if the colour doesn't match what was shown on the tin. > If the search bears little connection to what was searched for, then it is a bug, as far as t…

That's because as computer people we're very invested in the idea of bugs, while your users are not.

In products your users are stuck with it doesn't matter much, they'll have to suffer with what they think are bugs.

In products that users can switch easily, you can get dropped for a product that you would consider crappier if the user believes it's less 'buggy'.

Re: Bug Blindness

#240

Post by matkoniecz »

carlosjobim wrote: post #225
Jach wrote: post #68

Earlier quoted context omitted.

There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.

Designing for the stupid users also makes life easier for the smart users. No matter what you are designing. It makes your product better.

Sometimes, not always.

It may result in power users losing some features.

Post reply on HN