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

211–220 of 275 posts

Re: Bug Blindness

#211

Post by rmunn »

lukan wrote: post #175
dcminter wrote: post #172

Earlier quoted context omitted.

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.

Having giving support with windows and linux - I don't think so. Recently things got way better with hardware support - but just making a printer work, used to be a unsolvable problem for my dad for example, who has a electro engineering background (but doesn't speak english, and error messages in linux are very seldom localized). In windows he put in the CD that came with the printer and it worked.

For the longest time, I had far more trouble getting printers to work in Windows (where I had to download a driver and hope that it worked right, and sometimes the only drivers offered were the ones for a different version of Windows than I had) than on Linux (where I just plugged in the USB cable and voila, the printer was autodetected). And I mean over a decade.

Since Windows 7 or so, I have seen the ease of installing a new printer driver in Windows rise to the level that Linux had always been at in my experience (I realize other people's experiences have differed). But it was shocking to me how easy Linux printing was for so long, vs how much I struggled when I had to install a Windows printer driver.

Re: Bug Blindness

#212

Post by fhars »

tim1994 wrote: post #155
nextaccountic wrote: post #135

Earlier quoted context omitted.

There's an idea in this book, that when using a mouse, smaller buttons are harder to click because you need to stop the cursor inside its hitbox, but moving the cursor to the edge of the screen is easy because it's effectively a huge button whose height is infinite (or infinite width for lateral edges). And hitting a corner is even easier because it effectively has both infinite width and height! This means that if t…

Padding is typically part of the hitbox, margin is not. What you are describing sounds like margin to me. Especially for Firefox since their UI is made with web tech. But besides being overly pedantic I agree with your general point. If their is a small gap between hitbox and edge of the screen it is very annoying. But the worst thing IMO is Windows 11 windows which you can grab by the titlebar but not the content ar…

Also, more than 90% of the title bar are active UI elements like menus and close buttons, and you have to guess which few pixels are actually inert enough to allow dragging.

Re: Bug Blindness

#215

Post by foxglacier »

silvestrov wrote: post #202
JimDabell wrote: post #101

Earlier quoted context omitted.

I have experienced this in person with a developer who was failing to debug something. An error message was popping up on screen and he was reflexively clicking it away faster than anybody could read it. Even after being told “an error message is popping up, don’t dismiss it”, even after being told “[do the thing that triggers the bug] and then completely stop without doing anything else”, and a whole bunch of other…

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 incorrect code but we think users are somehow less deserving of respect and ready to drop everything to deal with some stupid notification telling them they did it wrong or the software is broken like a crying child demanding his mother knows that he hurt his finger.

Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful. It is often easier to mindlessly trial-and-error your way around obstacles than waste your attention on them.

Re: Bug Blindness

#216

Post by yorwba »

thaumasiotes wrote: post #145
munch117 wrote: post #121

Earlier quoted context omitted.

Skeuomorphism didn't fail. It feel out of fashion with designers. We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible. But skeuomorphic iconography works:…

> Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable. Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D

Are you sure they don't represent drum memory: https://en.wikipedia.org/wiki/Drum_memory

Re: Bug Blindness

#217

Post by foxglacier »

OJFord wrote: post #103
JimDabell wrote: post #101

Earlier quoted context omitted.

I have experienced this in person with a developer who was failing to debug something. An error message was popping up on screen and he was reflexively clicking it away faster than anybody could read it. Even after being told “an error message is popping up, don’t dismiss it”, even after being told “[do the thing that triggers the bug] and then completely stop without doing anything else”, and a whole bunch of other…

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.

Re: Bug Blindness

#218

Post by generationP »

Those habitual mitigations go a long way. Just like there is defensive programming, there is defensive usage.

Under Windows: Don't put your files into "My Documents" or similar folder hierarchies; you never know if old software will correctly deal with the abstraction.

Working with files in general: Avoid nonstandard unicode names or long paths so your external hard drive doesn't choke on them. Avoid case sensitivity even when it is allowed on Unix systems, since you can't assume Windows won't ever touch them. Avoid whitespaces in names because sooner or later, some script won't escape them.

On the internet: Never draft long comments in the browser; always use a local text file. Anything can happen in the browser.

In games: Never save your game during what looks like a complex scripted scene even if the game does allow saving.

Using search engines: Avoid keywords that are likely to confuse/distract the search.

With dropbox-likes: Give it some time to sync even after the icon is green; god knows what is being predictively shortcutted under the hood.

Everywhere: Restart the program or system if certain signs of corruption appear. You don't know what's going wrong, but you know something is, and barring some unusually careful compartmentalization, a piece of software is still a state machine which, once it has strayed from the right path, cannot be trusted at all. OSes nowadays are adapted to this, but much of software is not, and you do not want to have it corrupt your file.

Re: Bug Blindness

#219

Post by lukan »

rmunn wrote: post #211
lukan wrote: post #175

Earlier quoted context omitted.

Having giving support with windows and linux - I don't think so. Recently things got way better with hardware support - but just making a printer work, used to be a unsolvable problem for my dad for example, who has a electro engineering background (but doesn't speak english, and error messages in linux are very seldom localized). In windows he put in the CD that came with the printer and it worked.

For the longest time, I had far more trouble getting printers to work in Windows (where I had to download a driver and hope that it worked right, and sometimes the only drivers offered were the ones for a different version of Windows than I had) than on Linux (where I just plugged in the USB cable and voila, the printer was autodetected). And I mean over a decade. Since Windows 7 or so, I have seen the ease of instal…

Yeah well, I don't usually print anymore, but just recently I did try to connect a printer that worked flawlessly on windows did not worked on my linux devices out of the box - and then I decided I rather do other things than printer troubleshooting.

Re: Bug Blindness

#220

Post by ksec »

sakjur wrote: post #159
crabbone wrote: post #137

Earlier quoted context omitted.

I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong. So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectation…

> So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? Good thoughts and framing, thank you for that. I think I'm in the former camp, because I think fixing bad expectations is a matter of thoughtful redesign that should follow a slightly different process to fixing bad implementations (what I would call a bug). Not eve…

I am in latter camp. Although I also agree with you on >escalate "works according to spec".

But let me use Steve Job's phase, "you must start with the customer experience and work backwards to the technology".

A bug to developers is work according to spec, but a bug to a user is that is it has mismatched expectations. And it really should be someone's job to make sure this is corrected. But as parent said, there hasn't been one in most if not all companies.

And perhaps that is what makes old Apple such a success. They have a low pay $1 dollar salary beta tester to test out literally everything.

Post reply on HN