131–140 of 212 posts
That was a mistake.
Earlier quoted context omitted.
> Users have no business seeing error codes Ah, yes, I love remote troubleshooting. "What does the site says?" "Hell I know but there are funny badgers singing about mushrooms!"
Sentry, Rollbar, etc are your friends.
Earlier quoted context omitted.
On the flip side, how difficult is it to open dev tools, flip to the network tab, and look at your status code return(s) as a power user? As a power user, it never struck me as a high vertical.
The problem is, now I have to do this every time for shitty dumbed down apps. Prime example: Twitter always responds "oops, something went wrong" even if the backend returns `{ error: "Video aspect ration is not allowed. Try 16:9" }`
People's heads aren't going to explode if you treat them like functioning adults.
Earlier quoted context omitted.
I mean ... cars have had different error lights for decades. Doesn't seem like that much of a stretch that people would be able to use a little critical thinking when looking at computer error messages too.
In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode". Cars show error codes every few months or years and there's nothing the average driver can do to fix them. Computers show errors on a daily basis and most of them are trivially fixable.
> Computers show errors on a daily basis and most of them are trivially fixable
As they say, "citation required". How do I fix my Windows Update 0x80070422 error? (And yeah, I know, don't use Windows -- but I have plenty of *ix examples as well...)
Earlier quoted context omitted.
I mean ... cars have had different error lights for decades. Doesn't seem like that much of a stretch that people would be able to use a little critical thinking when looking at computer error messages too.
In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode". Cars show error codes every few months or years and there's nothing the average driver can do to fix them. Computers show errors on a daily basis and most of them are trivially fixable.
But then, I'm a dev, not a normal person.
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
>Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…
I think what's been lost -- or perhaps never been gained -- is an art of dual tiering error condition messaging.
Highest visibility messaging should be the simple & for the most general audience: "You Gave us Bad Information, here's how to fix it" for cases where that applies, with more information available for training users if they want it.
When it's an application or systems failure: "Something went wrong on our end, not your fault" should be the high visibility message. Then maybe "here's a request ID, you can contact this support channel about it if the problem persists". Then somewhere low visibility "here's some detail about what's going on under the hood if you want to look."
This is part of a general sin in product / UX as far as I can tell: the "don't make me think" mantra became something itself people stopped thinking about and transformed effectively into "don't LET me think."
Earlier quoted context omitted.
>Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…
>Somehow the people at Apple thought an error code and a brief description would be scary, so they opted for this absolutely terrifying icon instead This is why interfaces made by programmers tend to be impossible to use. Our minds simply work differently than normal people. In the 99% case, that icon will tell a user precisely the same information as any kind of detailed error log, which is "Oh no, something is brok…
Earlier quoted context omitted.
>Somehow the people at Apple thought an error code and a brief description would be scary, so they opted for this absolutely terrifying icon instead This is why interfaces made by programmers tend to be impossible to use. Our minds simply work differently than normal people. In the 99% case, that icon will tell a user precisely the same information as any kind of detailed error log, which is "Oh no, something is brok…
I mean ... cars have had different error lights for decades. Doesn't seem like that much of a stretch that people would be able to use a little critical thinking when looking at computer error messages too.
Users' critical thinking skills can be fine, but sometimes they choose not to apply them for things they don't want to think about. That's totally normal if computers are outside their purview or they just want technology to work.
No small amount of people just take their car to the shop and don't try to interpret the errors. Knowing when to make your users think comes with the product territory and knowing your audience, and also considering "how important is surfacing that error detail, really?"
If you want the dirty secret for why, it's because we can be lazy about things we don't care about and/or critically thinking about everything is exhausting and sometimes you have more important things to do. They just want it fixed.
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
This is an opinion that, on a personal preference level, I share. It's not, however, a universal truth. An optimally useful computer should be a human interface to information or control of something. The best computer is one that interprets a messy human command, produces the information or action that the human actually wanted, and requires no training at all to use.
Such a machine would be anathema to me, personally, but it would be objectively the best possible general purpose computing device.
The web today is full of silent failures. I've noticed this all the time at work and in my personal business. If loading some resource runs into trouble, it's simply not feasible for the Node.js or React or PHP to surface an error to the user. Chris says that the loading of sub-resources is a different matter. Well, the most common silent failure I have is not due to status codes per se , but because of my DNS-based…
"The Web is an error condition": http://deirdre.net/programming-sucks-why-i-quit/ > See also Richard I. Cook's "How Complex Systems Fail": https://how.complexsystems.fail/ > (Latter is an HN perennial, with 55 sumbissions presently: https://hn.algolia.com/?q=how%20complex%20systems%20fail >. Most recent 10 months ago, so not quite ready for a re-up: https://news.ycombinator.com/item?id=32895812 >.)