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

71–80 of 255 posts

Re: Bug Blindness

#71

Post by recursivecaveat »

DrewADesign wrote: post #42
sgentle wrote: 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…

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

Nobody reads the docs. This will be even more true soon as LLM generated docs become more popular. I once read a user report "would be nice if I could move large Xs to uncover Y", filed a bug report myself to add the feature, and then realized that feature was already added and documented months ago, by me! I just updated it with an unobtrusive prompt/instruction to the UI when relevant. I definitely get lazy sometimes, but if you don't take the extra step to make sure a feature is easily discoverable and understandable in the UI, you're wasting almost all of its potential benefit.

Re: Bug Blindness

#72

Post by lelanthran »

sgentle wrote: 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…

> "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".

Well, Jira does that too in many of its input widgets: anything you type while the page is loading is cleared after the page is loaded.

At this point users have been conditioned to accept this sort of react crap.

Re: Bug Blindness

#73

Post by lelanthran »

watermelon0 wrote: post #69
meling wrote: post #64

Interesting topic, and funny that I personally consider the text width and font size of danluu’s blog to be a “bug”. It is well known that we can read faster with narrower text columns (remember newspaper columns when they were printed on paper). This is why I always read this particular blog with Apple’s Reader mode, which renders the text using larger font and narrower width.

There is no CSS configuration for text/font on the website, so it's using browser defaults. Seems like reader mode is needed due to bad defaults.

That's a cop out in this specific instance: he knows the defaults are a bug, he can change it with maybe 2x lines of CSS, but he is blind to the fact that it's a bug.

After all, he is complaining about the defaults in other software, but he is blind to the defaults he presents the user.

Re: Bug Blindness

#74

Post by wodenokoto »

>And, sometimes, the issues are severe, to the point where one might even say the thing actually doesn't work.

>I find this last category a bit mysterious, as when I look up discussions on how the thing got into this state ...

I'm currently on the dev side of such a product and can tell you one way it can end up like this.

Leadership decides a new feature is required, but refuses to commit to writing what they want. Through a bunch of meetings and calls developers have learned a number of vague requirements to the product, many which are conflicting, just as many are unclear if they are long term features or needed immediately.

The result is something that implements - to the letter, but not the spirit - of what the developers can agree on from this vague mountain of requirements.

The feature is returned to leadership in the hopes that having something tangible will make it clear what leadership actually wants.

However, leadership returns with a "Looks great, can you add?" and they sign off and we begin the next sprint.

Re: Bug Blindness

#75

Post by swiftcoder »

hypfer wrote: post #65
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…

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…

> 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 is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc

Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.

Re: Bug Blindness

#76

Post by bryanrasmussen »

ghastmaster wrote: post #62

>I thought this had something to do with how I use computers but, over time, I've realized that it's mostly that people are hitting the same bugs and don't notice. I suspect I know why they do not notice. See below. >it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds. I suspect most people are so inept at navigating…

>I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.

This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still are obliged to provide the possibility of doing.

As a general rule I think I am pretty good with finding out things about software, for example in pretty much every company I've worked at I'm one of the only devs who learns Jira's query language, and how to make my own dashboards to organize things, but I do at times experience UIs that I either must believe are malicious or buggy, and I stand by that interpretation no matter how they people who work at the company like to claim it is working as intended.

But I have also experienced some times when I think the way this UI works must be a bug, because otherwise the people who designed it must be incompetent idiots and also, given laws about accessibility requirements, potentially on the hook for some monetary payments in court soon.

My interpretation has been that I am often to quick to think things are bugs and not worthwhile using because I am familiar with how buggy things can be and still "work" somewhat, and also that normal uneducated users will try to soldier through things I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?

Re: Bug Blindness

#77

Post by jdm2212 »

bsder wrote: post #19
nicoburns wrote: post #10

Blackboard is definitely a really strong contender for the worst software I've ever had to use. When I was in uni, I went so far as to write an alternative that scraped the content from blackboard and published it on a site that I could actually browse sensibly. They were paying exorbitant amounts of money for the license too.

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 definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.

Re: Bug Blindness

#78

Post by arjie »

Fun post. Enjoyed it.

Haha it’s just that the things these devices enable for us are so valuable. But life is full of suboptimal things just because that’s how it is. Some other constraint causes it.

I was at Oren’s Hummus years ago with a friend and I remember thinking that there was this heat lamp outside by the window that was very close to the glass. We were halfway through our meal when we heard a loud snap and a large crack formed in the glass. Error in process, my failure to report it, and costly consequence. Bug, eh?

It’s just that the world is full of detail and things are full of interactions. And complexity is something we’re all constantly grappling with.

Every time I do the 5 finger gesture to bring up launchpad (I think that’s what it’s called) on a Mac the text field doesn’t focus fast enough for the text. Every time I type then backspace backspace backspace and type again. That’s just life. Somewhere someone shipped something that does this. It didn’t use to be this way but it is now. I can’t really change it so I just live with it.

The world of software is complexity upon complexity created from the fact that the virtual world admits arbitrary amount of interaction at much lower cost than the physical world. Yep, the world is full of bugs. But you really have to care a lot to stop them and no one really wants to pay you to do that.

Re: Bug Blindness

#79

Post by ramraj07 »

encomiast wrote: post #5

I had to give up when the first example of a "bug" that the author could see, which others are blind to, was search results. "In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see" Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, i…

Dan isn't necessarily Bertrand Russell so ill give him a pass for not using the perfect word in every place.

But this article is in my opinion one of the best attempts at explaining a fundamental problem in software product work that has never (in my experience) been laid out this well. I will implore you to finish it.

Post reply on HN