9 ms·

(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 Inf

(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 website somehow. It was horrible from a support perspective, and if the user was new to the web it sometimes made them very anxious about using the web in the future. Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing.

falcor84 3y ago
When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?
- Raed667 3y ago
  Opening the dev tools and looking at the network tab is easy enough for power users.
  - bmacho 3y ago
    It is not working in Firefox or in Edge though, only if you already had your dev tools open before you navigated to the website.
    - rhaway84773 3y ago
      Create a chrome shortcut that auto opens dev tools for you. You can replace your regular chrome with this instead. https://developer.chrome.com/docs/devtools/open/#auto https://developer.chrome.com/docs/devtools/open/#auto
    - recursive 3y ago
      You also have to hit the reload button.
- riedel 3y ago
  Why not use extensions for this like (quickly searching firefox add-ons): https://addons.mozilla.org/de/firefox/addon/http-status-code/ https://addons.mozilla.org/de/firefox/addon/http-status-code... ? I think we just have fight for poweruser options to be available via APIs and support the add-on ecosystem.
- unmole 3y ago
  This sounds like inconsequential quibbling over terminology. There's nothing stopping a browser power user from opening up dev tools to look at error codes.
  - falcor84 3y ago
    It's not inconsequential in my mind because as a power user I don't a-priori care about the site enough to have a reason to open the dev tools. What I'm missing is the indication that there even is a problem of some sort, and that if I wanted to see the problem details, I could open the dev tools. In other words, as a power user, I want to know if the site has a "You problem", and the only explanation I fully accept for why the modern web doesn't notify users about website errors is that it allows companies to save on QA costs.
  - fruitreunion1 3y ago
    Their point I think is that often (to varying degrees), 'power user' things are less convenient to do or behind configuration options or menus and so on nowadays.
- onion2k 3y ago
  When did we stop building software for the "Power User" persona? I think the change was very simple - we stopped bothering with middleground. "Power Users" were treated like "users, but a bit more", so we had 'users', 'power users', and 'developers'. All that happened is that we just accepted that power user can have the same access to tools as developers. We didn't stop giving power users extra power. We gave power users more power.
  - CapsAdmin 3y ago
    Interesting perspective, you could flip the parent question and ask "when did power users become so lazy?"
    - troupo 3y ago
      Power users haven't become lazy. The middle ground for power users has disappeared. Now it's a split between "everything is so dumbed down and hidden behind fifteen layers of clicks" and "setting up and caring for your system is a second job in addition to your regular job".
      - rhaway84773 3y ago
        Dev tools in every browser is a 1 level menu in the main hamburger menu deep or available via 2 possible KB shortcuts (at least in Windows).
        mike503 3y ago
        That assumes you're in a browser context. I think overall the complaint is every type of experience. Including native apps. You can't simply dev tools inside of a native app. Even with Charles proxy or something you'd be grasping at straws trying to figure out what may be the actual issue (and at that point you probably can't work around it anyway)
      - CapsAdmin 3y ago
        Sometimes when I put my power user hat on I find myself thinking that the software I'm currently using is not meant for power users and instead I need to look for the alternatives. Now it's not just a few clicks away but I need to install some new type of software. So the options for power users are still here, but they just aren't front and center as they used to as you said. This reminds me a little bit of the discussion around the iphone not being customizable and the response being that you have the option to just get an android phone instead. At some point in the spectrum here one must become lazy when they can't be bothered to click on a few things or find an alternate product, and you become entitled when you demand power user features to become front and center when the vast majority won't ever need to use the features. I've always had the opinion that it's possible to have a middle ground. User friendly defaults, the ability to dig deeper and the ability to make advanced features more readily accessible. It's not easy though, picking one or the other is definitely a lot easier.
- imperialdrive 3y ago
  At first we agreed; having a future with primarily "Power Users" in mind would be pretty empowering. Then, At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work. At third: include all the error detail you like, simply put it behind a "click here for more details" side door.
  - pseudalopex 3y ago
    > At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work. What?
- reportgunner 3y ago
  > When did we stop building software for the "Power User" persona? The moment they(i mean we) started blocking ads I think.
  - pseudalopex 3y ago
    Much software is not ad supported web sites.
    - IggleSniggle 3y ago
      Much of my web experience is broken by default due to blocking Google or occasionally Microsoft ad analytic data. Many flows expect these to load even if it is not necessary for the functioning of the site. Many other sites break just due to strict enforcement of anti-cross-site tracking. I'm not just talking about ad supported sites, although I guess you could say that Google Drive is indirectly ad supported. Since I do most of my ad blocking at the network layer rather than in my browser, it's not always obvious to me as the user whether it was a "my blocking broke the site" error or a "The site is broken" error.
- Sebb767 3y ago
  I don't see how this is related to an error code. Most of the time, if you get a non-200, the website is broken in some way and it's not your problem to fix. If it is (because you develop an extension, for example), it's easy enough to open dev tools. But for the most part, status codes aren't relevant even for power users, as you have no idea whether the page handles the error or is silently failing.
  - brabel 3y ago
    > Most of the time, if you get a non-200, the website is broken in some way That's completely wrong. 1xx codes are all INFORMATIONAL (usually used for switching protocols). 2xx codes are all SUCCESS. 3xx codes are all REDIRECTs. 4xx codes are all CLIENT ERROR. Only 5xx codes are SERVER ERROR. See https://datatracker.ietf.org/doc/html/rfc7231#section-6 https://datatracker.ietf.org/doc/html/rfc7231#section-6
    - pseudalopex 3y ago
      I didn't agree with their conclusion. But the quoted part seemed correct. Some response codes are much more common than others. Redirects are followed by some other code unless the web site is broken in some way. 410 means the web site removed something. Most of the time 404 means the same. Or a link was generated incorrectly.
    - erikerikson 3y ago
      OPs assertion checks out. Users won't see a 1X or a 3X. 2Xs are the success case. 4Xs are usually caused by an error in the website that the user didn't define but was served them. The exception is bad data formatting that the UI has probably flagged to them so they never send it to get the 4X. 5Xs are clearly a break in the website.
    - BrandoElFollito 3y ago
      And? 1xx you do not care 2xx you are fine and do not care 3xx you are redirected and do not care 4xx crap, the client is wrong, you cannot do anything because the app is wrong 5xx crap, the server is wrong and you cannot do anything either. "You hit a problem, it was reported to the devs, sorry. Try later" is the only reasonable message for normal users
- rhaway84773 3y ago
  Every user, with a single KB shortcut or a click in the main hamburger menu, can access dev tools. That’s pretty power user friendly.
- somat 3y ago
  Related: the boot scroll. most of the time the scroll of boot messages is harmless and when the system fails to boot it is very very useful to see where. yet the design types hated it. and now no desktop orientated OS shows a boot scroll, opting for a near useless spinner instead. Opinion: I quite like the scroll, I think it comforting to see what the machine is doing. I think this is why sim city put a fake one in their loader(reticulating splines anyone). I wonder if the sim city messages tied into actual load events and could be used by the programmers to debug the loader. I think the later ones were random, but 2000 might of had an order to it.
  - adamsb6 3y ago
    I like the standard way that most Linux distros do this: default to a pretty loading graphic, but you can hit esc to see the boot scroll.
  - dwaite 3y ago
    The boot scroll was/is actively harmful in that it requires process-of-elimination troubleshooting to recognize deviations from a "normal" boot process. The individual subsystems should be able to recognize their correct state and output a clear diagnostic when they are not in that state. I shouldn't have to step back through e.g. several broken services to find out my second ethernet port didn't initialize.
- account-5 3y ago
  Isn't the power user served perfectly fine with the devtools? I mean if a website breaks a normal user is going to leave it the power user will open devtools?
- babypuncher 3y ago
  That user is who the dev tools are for? It's not a big deal for a power user to hit F12 then click the network tab...
- NoMoreNicksLeft 3y ago
  > When did we stop building software for the "Power User" persona? 1996 or 1997. I can't narrow it down further. Shortly after that, they actively became hostile to power users. Just play with your dumb little consumer appliance like you're supposed to.
- mcronce 3y ago
  My current pet example for the trend of hiding more and more details from users is an issue I recently had with Doordash. I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages) Pop open dev tools ... the server is returning something about a graphql error. Support had no idea what was wrong. The problem ended up being that my saved credit card had expired. For fuck's sake, that is a user-actionable error; tell me what the problem is. At least tell me it was a payment problem, since that's probably all the payment processor told you.
  - kube-system 3y ago
    This is probably not the result of internationally dumbing down the message, but lazy error handling.
    - pomstazlesa 3y ago
      It's probably both. Since you want to obscure it from the end user, you can also afford to be lazy and have sloppy implementation.
      - Guvante 3y ago
        That isn't true, laziness will punch straight through a tight definition of error code handling. After all if you have three API layers realizing in this situation the second layer isn't forwarding that error code because it erroneously thought it was one you hide behind a generic one is pretty common.
    - WirelessGigabit 3y ago
      This is just a general try catch. Build happy path, get VC money and deploy. We'll fix it later.
- BrandoElFollito 3y ago
  Probably because power users are en insignificant fraction of users for a general public application. I drive a car and only care about the speed, how far I can drive and to be warned that I have to stop if something is wrong. I do not care about the temperature of the oil or water, about the tension on the thffr which powers the louhguh or why zgfnkvgv failed. I know that if something goes wrong I will call the road assistance number. If someone wants to learn more there is the hidden bus they can plug into, aka Dev Tools For Cars
CapsAdmin 3y ago
There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action. I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because extensions can throw errors. On top of that a user might not be comfortable with you collecting errors that happen in their browser.
- richardwhiuk 3y ago
  "Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" }) "TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get). Anything else is expensive, and probably doesn't gain you anything.
- delecti 3y ago
  Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.
  - CapsAdmin 3y ago
    Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?" It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect? In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.
    - 3y ago
bawolff 3y ago
Tbf, 500 is the appropriate error message for user has broken the server.
- jeroenhd 3y ago
  5xx means the server messed up, if the user should've done something different you'd see a 4xx error. A good web server validates the user input, throws a 4xx error if the input is bad for the current state, and if something still goes wrong (which is a server bug) the 5xx range becomes appropriate.
  - david422 3y ago
    That's what he just said though. User breaks the server is a 500. Server prevents the user from breaking the server is a 400.
    - jeroenhd 3y ago
      But a 500 isn't the user breaking the server, it's the server being broken before the user ever came in. Users and client software cannot (or rather, should never) be held responsible for 500 error codes, which "user breaks the server" implies.
      - bawolff 3y ago
        400 is a client error. 500 is server error. A server error induced by a client action (e.g. triggering an unexpected exception) is still a server error.
justsomehnguy 3y ago
> 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!"
- onion2k 3y ago
  Sentry, Rollbar, etc are your friends.
  - justsomehnguy 3y ago
    If I'm on the phone with the user then Sentry et al. already failed. More so, problem maybe somewhere else so S. wouldn't even help here
  - rypskar 3y ago
    The worst is sites that fails when Sentry is blocked as part of tracking protection
Am4TIfIsER0ppos 3y ago
> users have no business seeing anything People like you are the reason users cannot work a file system, download an image, or even read a short text message. You retard the users' progress.
- AniseAbyss 3y ago
  [dead]
- onion2k 3y ago
  If I wield that much power then I really ought to be paid more.
  - DangitBobby 3y ago
    People _like_ you, not you specifically.
- gbalduzzi 3y ago
  If a user is using your web application normally and ends up with an error, it is an application error. Be it a 401, 403, validation error, 500, 429, whatever, it is not an actual user fault but it is a problem within the application. Once you have this realization, what's the advantage of showing the proper error code to the user? Whatever it is, it's not in his power to fix it
  - DangitBobby 3y ago
    There may be an issue with the application, but if you tell them what ballpark the issue is in they might just work around it.
  - yuliyp 3y ago
    Because application errors are not one-size-fits-all. Sometimes it's because of some specific flow being broken. Sometimes it's "the site is down". Sometimes it's a "there's an error condition that needs to be bubbled up to the user". And sometimes it's a poor internet connection being mishandled. While code fixes are not in their power to do, changing their behavior, or waiting for a better internet connection (i.e. "something went wrong" actually means "go log in to the hotel wifi") are things in their power.
rvba 3y ago
> Users have no business seeing error codes. Those are for devs. This is an Anti-pattern called mushroom management (keeping users in the dark). Not telling users what went wrong is just plain wrong. Breaking the termomether to hide fever. When you get an error message you can at least google it, or make a ticket.
- onion2k 3y ago
  Users are told what's wrong. They get a friendly "Page not found" or "Server error" page. They're not denied access to the cryptic error code that means nothing to them.
  - DangitBobby 3y ago
    Cryptic error codes that mean nothing to a layperson can result in online discussion in community support where users or devs can actually help each other. Or they might just glean enough information to work around the problem themselves. Zero information is not empowering.
yonatan8070 3y ago
Yet Windows still frequently shows Error "0x0000F001" without elaborating at all
- Hamuko 3y ago
  Something happened Something happened
- ElectricalUnion 3y ago
  Those are usually structured HRESULT values, Win32 error codes, and NTSTATUS values. So in a way, they are already "elaborating" the type of error - as well as a single 32-bit integer in C can "elaborate" over an error, that is, not a lot. For all their faults dotnet and java make it really easy to not mangle up the stack trace.
  - nullindividual 3y ago
    You want err.exe [0]. [0] https://www.microsoft.com/download/details.aspx?id=100432 https://www.microsoft.com/download/details.aspx?id=100432
mekoka 3y ago
Right. To which category belongs the user that is curious enough to open "Page Info", but destabilized when they see a status code there?
wmidwestranger 3y ago
Absolutely true. Especially now that the server is more likely than ever to have an in-browser application as the actual client. That client is the interface to the user and it should be responsible for communication the issue. I draw the line at nice urls though, I think that's valuable to the client app and the user. At the very least, bookmarks work. Even with all the other state than can exist, it's a solid and useful reference point.
notRobot 3y ago
For anyone interested, here's a bookmarklet to view the current page's HTTP status code (makes a new request): javascript:(function()%7Bjavascript%3A(function()%20%7B%0A%20%20var%20xhr%20%3D%20new%20XMLHttpRequest()%3B%0A%20%20xhr.onreadystatechange%20%3D%20function()%20%7B%0A%20%20%20%20if%20(xhr.readyState%20%3D%3D%3D%204)%20%7B%0A%20%20%20%20%20%20alert('HTTP%20Status%20Code%3A%20'%20%2B%20xhr.status)%3B%0A%20%20%20%20%7D%0A%20%20%7D%3B%0A%20%20xhr.open('GET'%2C%20window.location.href%2C%20true)%3B%0A%20%20xhr.send()%3B%0A%7D)()%3B%7D)()%3B
- dtgriscom 3y ago
  For suspicious types (including me): javascript:(function(){javascript:(function() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState === 4) { alert('HTTP Status Code: ' + xhr.status); } }; xhr.open('GET', window.location.href, true); xhr.send(); })();})();
  - deleted 3y ago
    [deleted]
  - sopooneo 3y ago
    And to recurse on more level: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/readyState https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...
- recursive 3y ago
  This assumes a GET.
  - mike503 3y ago
    Also firing a second request would break restful behavior and could wind up really messing stuff up worse. Maybe it places an order twice? Who knows. Not a good idea.
    - 3y ago
orev 3y ago
Those barebones ‘XXX Error’ pages are sent from the server and rendered in the browser just like the post talks about. Browsers have always handled the html returned with the error code in the same way (by showing it to the user). The only difference from the old days is that now sites show a nicer page instead of using the default barebones error pages.
DangitBobby 3y ago
What if the error is a problem the user can actually address and continue using the service? I don't think we should stop trying to make useful error messages because some people are completely helpless.
ilyt 3y ago
I still remember how Chrome decided to do it if 500 message was too short...
isodnhionio 3y ago
>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 users something underpowered that is going to break anyway, or acknowledge that computers are complicated, and build tools and resources to help users navigate them. And users should recognize it as folly to try to use the most complicated tools on the planet today without any understanding of how they work. This doesn't really apply to HTTP status codes. They're largely useless. It does apply to the way my Macintosh told me of a misconfiguration after I reinstalled the operating system. 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: https://i.stack.imgur.com/Y1teY.jpg https://i.stack.imgur.com/Y1teY.jpg (Not my picture, by the way.)
- ramesh31 3y ago
  >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 broken, I should go to the Apple store."
  - david422 3y ago
    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.
    - isodnhionio 3y ago
      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.
idiotsecant 3y ago
>Using computers is a skill. It takes study. 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.
zlg_codes 3y ago
I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical. Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as books go with illiteracy. It takes effort to be computer literate, and hiding the information will make that journey to literacy more daunting than it needs to be.
- sopooneo 3y ago
  My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even that any meter detected my oil was wearing out.
  - rurcliped 3y ago
    Years ago, many decisions to hide error details were a cargo cult reaction to CVE-2012-4929. To review, CVE-2012-4929 works like this: 1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com 2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message 3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser 4. example.com compresses response data before encrypting it 5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data 6. after enough requests, the attacker knows the authentication data to login to example.com as the victim One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.) There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.
bombcar 3y ago
The very same users will drive their cars with the dashboard lit up like a Christmas tree.

falcor84 3y ago

When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?

Raed667 3y ago
Opening the dev tools and looking at the network tab is easy enough for power users.
- bmacho 3y ago
  It is not working in Firefox or in Edge though, only if you already had your dev tools open before you navigated to the website.
  - rhaway84773 3y ago
    Create a chrome shortcut that auto opens dev tools for you. You can replace your regular chrome with this instead. https://developer.chrome.com/docs/devtools/open/#auto https://developer.chrome.com/docs/devtools/open/#auto
  - recursive 3y ago
    You also have to hit the reload button.
riedel 3y ago
Why not use extensions for this like (quickly searching firefox add-ons): https://addons.mozilla.org/de/firefox/addon/http-status-code/ https://addons.mozilla.org/de/firefox/addon/http-status-code... ? I think we just have fight for poweruser options to be available via APIs and support the add-on ecosystem.
unmole 3y ago
This sounds like inconsequential quibbling over terminology. There's nothing stopping a browser power user from opening up dev tools to look at error codes.
- falcor84 3y ago
  It's not inconsequential in my mind because as a power user I don't a-priori care about the site enough to have a reason to open the dev tools. What I'm missing is the indication that there even is a problem of some sort, and that if I wanted to see the problem details, I could open the dev tools. In other words, as a power user, I want to know if the site has a "You problem", and the only explanation I fully accept for why the modern web doesn't notify users about website errors is that it allows companies to save on QA costs.
- fruitreunion1 3y ago
  Their point I think is that often (to varying degrees), 'power user' things are less convenient to do or behind configuration options or menus and so on nowadays.
onion2k 3y ago
When did we stop building software for the "Power User" persona? I think the change was very simple - we stopped bothering with middleground. "Power Users" were treated like "users, but a bit more", so we had 'users', 'power users', and 'developers'. All that happened is that we just accepted that power user can have the same access to tools as developers. We didn't stop giving power users extra power. We gave power users more power.
- CapsAdmin 3y ago
  Interesting perspective, you could flip the parent question and ask "when did power users become so lazy?"
  - troupo 3y ago
    Power users haven't become lazy. The middle ground for power users has disappeared. Now it's a split between "everything is so dumbed down and hidden behind fifteen layers of clicks" and "setting up and caring for your system is a second job in addition to your regular job".
    - rhaway84773 3y ago
      Dev tools in every browser is a 1 level menu in the main hamburger menu deep or available via 2 possible KB shortcuts (at least in Windows).
      - mike503 3y ago
        That assumes you're in a browser context. I think overall the complaint is every type of experience. Including native apps. You can't simply dev tools inside of a native app. Even with Charles proxy or something you'd be grasping at straws trying to figure out what may be the actual issue (and at that point you probably can't work around it anyway)
    - CapsAdmin 3y ago
      Sometimes when I put my power user hat on I find myself thinking that the software I'm currently using is not meant for power users and instead I need to look for the alternatives. Now it's not just a few clicks away but I need to install some new type of software. So the options for power users are still here, but they just aren't front and center as they used to as you said. This reminds me a little bit of the discussion around the iphone not being customizable and the response being that you have the option to just get an android phone instead. At some point in the spectrum here one must become lazy when they can't be bothered to click on a few things or find an alternate product, and you become entitled when you demand power user features to become front and center when the vast majority won't ever need to use the features. I've always had the opinion that it's possible to have a middle ground. User friendly defaults, the ability to dig deeper and the ability to make advanced features more readily accessible. It's not easy though, picking one or the other is definitely a lot easier.
imperialdrive 3y ago
At first we agreed; having a future with primarily "Power Users" in mind would be pretty empowering. Then, At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work. At third: include all the error detail you like, simply put it behind a "click here for more details" side door.
- pseudalopex 3y ago
  > At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work. What?
reportgunner 3y ago
> When did we stop building software for the "Power User" persona? The moment they(i mean we) started blocking ads I think.
- pseudalopex 3y ago
  Much software is not ad supported web sites.
  - IggleSniggle 3y ago
    Much of my web experience is broken by default due to blocking Google or occasionally Microsoft ad analytic data. Many flows expect these to load even if it is not necessary for the functioning of the site. Many other sites break just due to strict enforcement of anti-cross-site tracking. I'm not just talking about ad supported sites, although I guess you could say that Google Drive is indirectly ad supported. Since I do most of my ad blocking at the network layer rather than in my browser, it's not always obvious to me as the user whether it was a "my blocking broke the site" error or a "The site is broken" error.
Sebb767 3y ago
I don't see how this is related to an error code. Most of the time, if you get a non-200, the website is broken in some way and it's not your problem to fix. If it is (because you develop an extension, for example), it's easy enough to open dev tools. But for the most part, status codes aren't relevant even for power users, as you have no idea whether the page handles the error or is silently failing.
- brabel 3y ago
  > Most of the time, if you get a non-200, the website is broken in some way That's completely wrong. 1xx codes are all INFORMATIONAL (usually used for switching protocols). 2xx codes are all SUCCESS. 3xx codes are all REDIRECTs. 4xx codes are all CLIENT ERROR. Only 5xx codes are SERVER ERROR. See https://datatracker.ietf.org/doc/html/rfc7231#section-6 https://datatracker.ietf.org/doc/html/rfc7231#section-6
  - pseudalopex 3y ago
    I didn't agree with their conclusion. But the quoted part seemed correct. Some response codes are much more common than others. Redirects are followed by some other code unless the web site is broken in some way. 410 means the web site removed something. Most of the time 404 means the same. Or a link was generated incorrectly.
  - erikerikson 3y ago
    OPs assertion checks out. Users won't see a 1X or a 3X. 2Xs are the success case. 4Xs are usually caused by an error in the website that the user didn't define but was served them. The exception is bad data formatting that the UI has probably flagged to them so they never send it to get the 4X. 5Xs are clearly a break in the website.
  - BrandoElFollito 3y ago
    And? 1xx you do not care 2xx you are fine and do not care 3xx you are redirected and do not care 4xx crap, the client is wrong, you cannot do anything because the app is wrong 5xx crap, the server is wrong and you cannot do anything either. "You hit a problem, it was reported to the devs, sorry. Try later" is the only reasonable message for normal users
rhaway84773 3y ago
Every user, with a single KB shortcut or a click in the main hamburger menu, can access dev tools. That’s pretty power user friendly.
somat 3y ago
Related: the boot scroll. most of the time the scroll of boot messages is harmless and when the system fails to boot it is very very useful to see where. yet the design types hated it. and now no desktop orientated OS shows a boot scroll, opting for a near useless spinner instead. Opinion: I quite like the scroll, I think it comforting to see what the machine is doing. I think this is why sim city put a fake one in their loader(reticulating splines anyone). I wonder if the sim city messages tied into actual load events and could be used by the programmers to debug the loader. I think the later ones were random, but 2000 might of had an order to it.
- adamsb6 3y ago
  I like the standard way that most Linux distros do this: default to a pretty loading graphic, but you can hit esc to see the boot scroll.
- dwaite 3y ago
  The boot scroll was/is actively harmful in that it requires process-of-elimination troubleshooting to recognize deviations from a "normal" boot process. The individual subsystems should be able to recognize their correct state and output a clear diagnostic when they are not in that state. I shouldn't have to step back through e.g. several broken services to find out my second ethernet port didn't initialize.
account-5 3y ago
Isn't the power user served perfectly fine with the devtools? I mean if a website breaks a normal user is going to leave it the power user will open devtools?
babypuncher 3y ago
That user is who the dev tools are for? It's not a big deal for a power user to hit F12 then click the network tab...
NoMoreNicksLeft 3y ago
> When did we stop building software for the "Power User" persona? 1996 or 1997. I can't narrow it down further. Shortly after that, they actively became hostile to power users. Just play with your dumb little consumer appliance like you're supposed to.
mcronce 3y ago
My current pet example for the trend of hiding more and more details from users is an issue I recently had with Doordash. I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages) Pop open dev tools ... the server is returning something about a graphql error. Support had no idea what was wrong. The problem ended up being that my saved credit card had expired. For fuck's sake, that is a user-actionable error; tell me what the problem is. At least tell me it was a payment problem, since that's probably all the payment processor told you.
- kube-system 3y ago
  This is probably not the result of internationally dumbing down the message, but lazy error handling.
  - pomstazlesa 3y ago
    It's probably both. Since you want to obscure it from the end user, you can also afford to be lazy and have sloppy implementation.
    - Guvante 3y ago
      That isn't true, laziness will punch straight through a tight definition of error code handling. After all if you have three API layers realizing in this situation the second layer isn't forwarding that error code because it erroneously thought it was one you hide behind a generic one is pretty common.
  - WirelessGigabit 3y ago
    This is just a general try catch. Build happy path, get VC money and deploy. We'll fix it later.
BrandoElFollito 3y ago
Probably because power users are en insignificant fraction of users for a general public application. I drive a car and only care about the speed, how far I can drive and to be warned that I have to stop if something is wrong. I do not care about the temperature of the oil or water, about the tension on the thffr which powers the louhguh or why zgfnkvgv failed. I know that if something goes wrong I will call the road assistance number. If someone wants to learn more there is the hidden bus they can plug into, aka Dev Tools For Cars

CapsAdmin 3y ago

There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action. I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because extensions can throw errors. On top of that a user might not be comfortable with you collecting errors that happen in their browser.

richardwhiuk 3y ago
"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" }) "TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get). Anything else is expensive, and probably doesn't gain you anything.
delecti 3y ago
Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases. I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.
- CapsAdmin 3y ago
  Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?" It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect? In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.
  - 3y ago

bawolff 3y ago

Tbf, 500 is the appropriate error message for user has broken the server.

jeroenhd 3y ago
5xx means the server messed up, if the user should've done something different you'd see a 4xx error. A good web server validates the user input, throws a 4xx error if the input is bad for the current state, and if something still goes wrong (which is a server bug) the 5xx range becomes appropriate.
- david422 3y ago
  That's what he just said though. User breaks the server is a 500. Server prevents the user from breaking the server is a 400.
  - jeroenhd 3y ago
    But a 500 isn't the user breaking the server, it's the server being broken before the user ever came in. Users and client software cannot (or rather, should never) be held responsible for 500 error codes, which "user breaks the server" implies.
    - bawolff 3y ago
      400 is a client error. 500 is server error. A server error induced by a client action (e.g. triggering an unexpected exception) is still a server error.

justsomehnguy 3y ago

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

onion2k 3y ago
Sentry, Rollbar, etc are your friends.
- justsomehnguy 3y ago
  If I'm on the phone with the user then Sentry et al. already failed. More so, problem maybe somewhere else so S. wouldn't even help here
- rypskar 3y ago
  The worst is sites that fails when Sentry is blocked as part of tracking protection

Am4TIfIsER0ppos 3y ago

> users have no business seeing anything People like you are the reason users cannot work a file system, download an image, or even read a short text message. You retard the users' progress.

AniseAbyss 3y ago
[dead]
onion2k 3y ago
If I wield that much power then I really ought to be paid more.
- DangitBobby 3y ago
  People _like_ you, not you specifically.
gbalduzzi 3y ago
If a user is using your web application normally and ends up with an error, it is an application error. Be it a 401, 403, validation error, 500, 429, whatever, it is not an actual user fault but it is a problem within the application. Once you have this realization, what's the advantage of showing the proper error code to the user? Whatever it is, it's not in his power to fix it
- DangitBobby 3y ago
  There may be an issue with the application, but if you tell them what ballpark the issue is in they might just work around it.
- yuliyp 3y ago
  Because application errors are not one-size-fits-all. Sometimes it's because of some specific flow being broken. Sometimes it's "the site is down". Sometimes it's a "there's an error condition that needs to be bubbled up to the user". And sometimes it's a poor internet connection being mishandled. While code fixes are not in their power to do, changing their behavior, or waiting for a better internet connection (i.e. "something went wrong" actually means "go log in to the hotel wifi") are things in their power.

rvba 3y ago

> Users have no business seeing error codes. Those are for devs. This is an Anti-pattern called mushroom management (keeping users in the dark). Not telling users what went wrong is just plain wrong. Breaking the termomether to hide fever. When you get an error message you can at least google it, or make a ticket.

onion2k 3y ago
Users are told what's wrong. They get a friendly "Page not found" or "Server error" page. They're not denied access to the cryptic error code that means nothing to them.
- DangitBobby 3y ago
  Cryptic error codes that mean nothing to a layperson can result in online discussion in community support where users or devs can actually help each other. Or they might just glean enough information to work around the problem themselves. Zero information is not empowering.

yonatan8070 3y ago

Yet Windows still frequently shows Error "0x0000F001" without elaborating at all

Hamuko 3y ago
Something happened Something happened
ElectricalUnion 3y ago
Those are usually structured HRESULT values, Win32 error codes, and NTSTATUS values. So in a way, they are already "elaborating" the type of error - as well as a single 32-bit integer in C can "elaborate" over an error, that is, not a lot. For all their faults dotnet and java make it really easy to not mangle up the stack trace.
- nullindividual 3y ago
  You want err.exe [0]. [0] https://www.microsoft.com/download/details.aspx?id=100432 https://www.microsoft.com/download/details.aspx?id=100432

mekoka 3y ago

Right. To which category belongs the user that is curious enough to open "Page Info", but destabilized when they see a status code there?

wmidwestranger 3y ago

Absolutely true. Especially now that the server is more likely than ever to have an in-browser application as the actual client. That client is the interface to the user and it should be responsible for communication the issue. I draw the line at nice urls though, I think that's valuable to the client app and the user. At the very least, bookmarks work. Even with all the other state than can exist, it's a solid and useful reference point.

notRobot 3y ago

For anyone interested, here's a bookmarklet to view the current page's HTTP status code (makes a new request): javascript:(function()%7Bjavascript%3A(function()%20%7B%0A%20%20var%20xhr%20%3D%20new%20XMLHttpRequest()%3B%0A%20%20xhr.onreadystatechange%20%3D%20function()%20%7B%0A%20%20%20%20if%20(xhr.readyState%20%3D%3D%3D%204)%20%7B%0A%20%20%20%20%20%20alert('HTTP%20Status%20Code%3A%20'%20%2B%20xhr.status)%3B%0A%20%20%20%20%7D%0A%20%20%7D%3B%0A%20%20xhr.open('GET'%2C%20window.location.href%2C%20true)%3B%0A%20%20xhr.send()%3B%0A%7D)()%3B%7D)()%3B

dtgriscom 3y ago
For suspicious types (including me): javascript:(function(){javascript:(function() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState === 4) { alert('HTTP Status Code: ' + xhr.status); } }; xhr.open('GET', window.location.href, true); xhr.send(); })();})();
- deleted 3y ago
  [deleted]
- sopooneo 3y ago
  And to recurse on more level: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/readyState https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...
recursive 3y ago
This assumes a GET.
- mike503 3y ago
  Also firing a second request would break restful behavior and could wind up really messing stuff up worse. Maybe it places an order twice? Who knows. Not a good idea.
  - 3y ago

orev 3y ago

Those barebones ‘XXX Error’ pages are sent from the server and rendered in the browser just like the post talks about. Browsers have always handled the html returned with the error code in the same way (by showing it to the user). The only difference from the old days is that now sites show a nicer page instead of using the default barebones error pages.

DangitBobby 3y ago

What if the error is a problem the user can actually address and continue using the service? I don't think we should stop trying to make useful error messages because some people are completely helpless.

ilyt 3y ago

I still remember how Chrome decided to do it if 500 message was too short...

isodnhionio 3y ago

>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 users something underpowered that is going to break anyway, or acknowledge that computers are complicated, and build tools and resources to help users navigate them. And users should recognize it as folly to try to use the most complicated tools on the planet today without any understanding of how they work. This doesn't really apply to HTTP status codes. They're largely useless. It does apply to the way my Macintosh told me of a misconfiguration after I reinstalled the operating system. 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: https://i.stack.imgur.com/Y1teY.jpg https://i.stack.imgur.com/Y1teY.jpg (Not my picture, by the way.)

ramesh31 3y ago
>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 broken, I should go to the Apple store."
- david422 3y ago
  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.
  - isodnhionio 3y ago
    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.

idiotsecant 3y ago

>Using computers is a skill. It takes study. 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.

zlg_codes 3y ago

I disagree. I think users should be aware of any breakage up front, and center. We encourage drivers to recognize warning signs in the operation of their vehicles; we should do the same with browsers. Hiding information from the user is not ethical. Then again, I also think people should be taught better than to hop on the Web without any training or knowledge. Computers and illiteracy go together about as well as books go with illiteracy. It takes effort to be computer literate, and hiding the information will make that journey to literacy more daunting than it needs to be.

sopooneo 3y ago
My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even that any meter detected my oil was wearing out.
- rurcliped 3y ago
  Years ago, many decisions to hide error details were a cargo cult reaction to CVE-2012-4929. To review, CVE-2012-4929 works like this: 1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com 2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message 3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser 4. example.com compresses response data before encrypting it 5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data 6. after enough requests, the attacker knows the authentication data to login to example.com as the victim One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.) There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.

bombcar 3y ago

The very same users will drive their cars with the dashboard lit up like a Christmas tree.