[deleted]
Bug Blindness
241–250 of 293 posts
Re: Bug Blindness
#242Earlier quoted context omitted.
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.
Sure, but whenever you can make life easier for those who have are having hard time without making life harder for those who aren't, you should do it.
For example, no power user benefits from having to use work arounds to make a product function. It's an annoyance to them, and it's an insurmountable obstacle to others.
Re: Bug Blindness
#243Earlier quoted context omitted.
I think this comes from the same problem as notifications on iPhones: if you dismiss them accidentally then it is very difficult to find out what it was. It is missing the equivalent of the "history" in e.g. browsers and YouTube. If a user dismisses an alertbox on desktop, why isn't there an history menu item that shows the previous 100 alert messages?
That may be an issue for messages from people but almost anything that pops up because the computer wants to tell you is useless and certainly doesn't need to be findable later. If you want to work on the problem, you can do that when you're ready, at your own initiative, not in the middle of what you're actually trying to do. Programmers wouldn't stand for a language that pops up a modal dialog when you type incorre…
> Programmers wouldn't stand for a language that pops up a modal dialog when you type incorrect code
I have no idea why you think this. The only reason I wouldn't like it is because I might be doing something that requires incorrect code as a placeholder, but if the modal didn't come back after being dismissed (and just sat in a history) I'd be pleased as punch. It's why I moved to rust - I wanted the compiler to stop me.
Not only do you think this, but you think it's somehow a sign of being egotistical and disrespectful that anyone would like to know when they're screwing up. Weird.
> they're almost always unhelpful.
Sounds like you found the real problem.
Re: Bug Blindness
#244I 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…
> often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software.
The older I get, the more annoying I find this habit in the SWE community. It's not even a well earned condescension. Software is often horrible! Physical hardware products are not put out into the world with the kind of defects that software so regularly is.
We get away with it because we say we can patch it later, though often all we do is move defects around.
It's amazing picking up pre-internet connected era electronics from 30/40/50 years ago and they just.. work.
Meanwhile software decays at a faster and faster rate each year. I am coming around to the idea of keeping air gapped old-OS machines around just to maintain pieces of software that otherwise auto-update themselves into oblivion.
Re: Bug Blindness
#245Earlier 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…
> there is cohort of users who are absolutely not smart enough
The average IQ is 100, half of people are below that. Being surprised that customers may be of different intelligence is the kind of thing that comes out of people who have never had to work a retail/restaurant job in high school growing up. If someone has made it that far in life before finding this out, they've lived in a bubble.
People of varying intelligence levels can operate a motor vehicle and yet software can't be designed well enough for them? The failure may be on the SWEs.
Re: Bug Blindness
#246Earlier quoted context omitted.
The flip side of this is the pleasant surprise of working with a near-retirement age grandma who assures you that she "isn't technical" and "doesn't know how to use a computer", but will studiously write down every keyboard shortcut on little post-it notes and add it to their collection like they're porcelain cats she found at the Sunday markets. I've watched some of these people operate a computer in a manner remini…
This sounds like "Smart person who has little technical experience and might have cognitive decline from age". The world is fully of people who's intelligence is legitimately lower than you might expect.
Cognitive decline from age is something the SWE community also neglects to think about.
You may feel superior to the average IQ person right now, but we're all going to regress to that point & worse at some point.
Design software & plan your life accordingly.
Re: Bug Blindness
#247Earlier 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.
Wild to me and speaks volumes of HN/SWEs that this is getting downvoted.
Re: Bug Blindness
#248Earlier 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…
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.
Smart users forced to use work arounds may also find the workaround is to switch to your competitors product !
Re: Bug Blindness
#249Earlier 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…
[deleted]
Re: Bug Blindness
#250Earlier quoted context omitted.
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…
So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug? What about if B has no connection to A whatsoever? Still not a bug? If it is not, then we may have discovered a software domain (the first for me I should say) where bugs are not possible. Should a be a nice market to launch products for, then.
> So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug?
It depends. There could be a bug in the system like query = query.replace(A,B), or it could be that there are no good results for A. Returning nonsense results is a bad design, but not necessarily a bug.
I guess my underlying point is that bugs are about software not conforming to some specified behaviour, and trying to specify behaviour like "i should type in a search and get great results" is too loose of a spec to be meaningful so we should avoid saying things which don't meet that criteria are bugs. To use a concrete example, perhaps the set of search results returned for a query look useless to you but are actually useful for someone else.
Compare that with something like a calculator app where part of the spec is "Must handle integer addition with for inputs i,j where -10,000 Bugs vs. bad design is a useful distinction to make imo.