News for hackers. Stuff that matters.
Re:Browsers barely care what HTTP status code your web pages... by falcor84 on Friday August 11, 2023 @04:17AM (#37086315)
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?
Re:Browsers barely care what HTTP status code your web pages... by onion2k on Friday August 11, 2023 @04:25AM (#37086363)
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.

Re:Browsers barely care what HTTP status code your web pages... by CapsAdmin on Friday August 11, 2023 @04:47AM (#37086493)
Interesting perspective, you could flip the parent question and ask "when did power users become so lazy?"
Re:Browsers barely care what HTTP status code your web pages... by troupo on Friday August 11, 2023 @04:59AM (#37086575)
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".
Re:Browsers barely care what HTTP status code your web pages... by rhaway84773 on Friday August 11, 2023 @06:37AM (#37087132)
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).
Re:Browsers barely care what HTTP status code your web pages... by mike503 on Saturday August 12, 2023 @02:00AM (#37097442)
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)

Re:Browsers barely care what HTTP status code your web pages... by CapsAdmin on Friday August 11, 2023 @06:47AM (#37087199)
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.

Re:Browsers barely care what HTTP status code your web pages... by starttoaster on Friday August 11, 2023 @08:21AM (#37087859)
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.
Re:Browsers barely care what HTTP status code your web pages... by troupo on Friday August 11, 2023 @09:08AM (#37088269)
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" }`

Re:Browsers barely care what HTTP status code your web pages... by ryandrake on Friday August 11, 2023 @01:15PM (#37091161)
Those "oopsie-doopsie, website made a poopsie" infantilizing error messages are just awful. Tell the user 1. specifically what went wrong, 2. what, if anything, they can do to correct, and 3. a token (like an error message) that could be useful for tech support or reporting a bug.

People's heads aren't going to explode if you treat them like functioning adults.

Re:Browsers barely care what HTTP status code your web pages... by starttoaster on Saturday August 12, 2023 @12:19AM (#37097015)
You’ve just vastly overestimated the technical capabilities of most Twitter users.
Re:Browsers barely care what HTTP status code your web pages... by dwaite on Saturday August 12, 2023 @08:02PM (#37105300)
The meta conversation here is whether there was a decision to NOT give the user information on how to correct the problem - or if it was a process maturity, developer skill, or limited resources that caused the development to focus on the "happy path" only.
Re:Browsers barely care what HTTP status code your web pages... by funcDropShadow on Friday August 11, 2023 @09:46AM (#37088634)
Dev tools of a browser are not what a power user focused browser would need. Think more about being able change keyboard shortcuts. Being able to execute small custom scripts that do stuff with tabs, windows, and pages. Yes I know browser plugins and bookmarklets exist.

But why do bookmarklets run with the security context of the currently opened page? I have one self-written bookmarklet to capture the page title and url into emacs for storing it there. Firefox asks me every time I click on that bookmarklet on a new origin (domain, protocol tuple) whether I want to allow that. With no option to avoid that. I have written this piece of code myself I want to use it to enhance my workflow. There is no need to treat it like any javascript hosted on a CDN, or on a Facebook server.

Re:Browsers barely care what HTTP status code your web pages... by thrashh on Friday August 11, 2023 @11:18AM (#37089665)
Why? Because a lot of regular people were tricked into running malicious bookmarklets.
Re:Browsers barely care what HTTP status code your web pages... by falcor84 on Friday August 11, 2023 @12:40PM (#37090708)
So could we maybe have them not get any privileges by default, but still work?
Re:Browsers barely care what HTTP status code your web pages... by starttoaster on Saturday August 12, 2023 @12:13AM (#37096978)
No privileges by default is often at odds with the goal of having something work, at least out of the box.
Re:Browsers barely care what HTTP status code your web pages... by verall on Friday August 11, 2023 @11:32AM (#37089837)
For me personally, it's quite difficult.

My day job is C++ app and driver code for rather complex systems yet when I open browser dev tools my eyes glaze over. There is plenty of middle ground of people who are technical but are not web or browser developers.

Re:Browsers barely care what HTTP status code your web pages... by starttoaster on Saturday August 12, 2023 @12:10AM (#37096963)
I’m not a web or browser developer, the vertical isn’t quite as high as “you need to be working in the web space to understand it.”

There’s a lot to look at in there, but there’s some usual suspects tabs that people look at the majority of the time they have dev tools open. And conversely some tabs that you probably only use in the web dev scene. I’d highly recommend perusing the network and storage tabs, for things like status codes and cookies, respectively. As I mentioned, the vertical is nowhere near as high as you’re saying, you’ll figure it out if you look at it more.

Re:Browsers barely care what HTTP status code your web pages... by troupo on Friday August 11, 2023 @04:56AM (#37086559)
> We didn't stop giving power users extra power. We gave power users more power.

I don't think we did. The trend in the past few years is to dumb down all tools, especially UI tools, to the lowest common denominator.

Re:Browsers barely care what HTTP status code your web pages... by funcDropShadow on Friday August 11, 2023 @05:21AM (#37086698)
> We didn't stop giving power users extra power. We gave power users more power.

No, most software today is designed for the use case that you have never seen the software before. That is implicitly enforced by the way most companies do A/B testing. The experiments show a new part of the UI to an unsuspecting user without any upfront knowledge that they are part of an experiment. Therefore the variant that has the lowest hurdle for the most common case of the most common user is optimized. So it is basically ignored that people tend to learn how to use their tools.

Learning to learn your tools is even made harder by constantly changing UIs. Reading documentation, following tutorial, watching introduction videos is basically useless for a software that will change whenever a product manager needs to complete an increment for his KPIs.

Re:Browsers barely care what HTTP status code your web pages... by wwweston on Friday August 11, 2023 @12:55PM (#37090888)
So. Much. This.

I'm pretty sure A/B testing has become a cult whose rituals are often practiced in a way that leads people away from meaningful or productive outcomes.

Is there anywhere else you've found where people are talking about this (either from a perspective of how to do it better or what else to do instead)?

Re:Browsers barely care what HTTP status code your web pages... by nottorp on Saturday August 12, 2023 @03:24AM (#37097882)
> No, most software today is designed for the use case that you have never seen the software before.

Yep, it's fun when you go to a site where you have a log in but it expired and have to search for the tiny 'sign in' button that's mostly covered by the sign up form.

Re:Browsers barely care what HTTP status code your web pages... by unmole on Friday August 11, 2023 @04:23AM (#37086345)
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.
Re:Browsers barely care what HTTP status code your web pages... by falcor84 on Friday August 11, 2023 @04:45AM (#37086472)
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.

Re:Browsers barely care what HTTP status code your web pages... by fruitreunion1 on Friday August 11, 2023 @04:47AM (#37086491)
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.
Re:Browsers barely care what HTTP status code your web pages... by imperialdrive on Friday August 11, 2023 @04:35AM (#37086406)
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.

Re:Browsers barely care what HTTP status code your web pages... by pseudalopex on Friday August 11, 2023 @07:09AM (#37087323)
> At second; it would likely mean many folks lacking in other skills, unbalancing what little we have in the society of work.

What?

Re:Browsers barely care what HTTP status code your web pages... by riedel on Friday August 11, 2023 @04:23AM (#37086343)
Why not use extensions for this like (quickly searching firefox add-ons): 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.

Re:Browsers barely care what HTTP status code your web pages... by Raed667 on Friday August 11, 2023 @04:20AM (#37086328)
Opening the dev tools and looking at the network tab is easy enough for power users.
Re:Browsers barely care what HTTP status code your web pages... by bmacho on Friday August 11, 2023 @05:07AM (#37086620)
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.
Re:Browsers barely care what HTTP status code your web pages... by rhaway84773 on Friday August 11, 2023 @06:42AM (#37087161)
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

Re:Browsers barely care what HTTP status code your web pages... by recursive on Friday August 11, 2023 @02:07PM (#37091845)
You also have to hit the reload button.
Re:Browsers barely care what HTTP status code your web pages... by reportgunner on Friday August 11, 2023 @05:19AM (#37086687)
> When did we stop building software for the "Power User" persona?

The moment they(i mean we) started blocking ads I think.

Re:Browsers barely care what HTTP status code your web pages... by pseudalopex on Friday August 11, 2023 @07:11AM (#37087332)
Much software is not ad supported web sites.
Re:Browsers barely care what HTTP status code your web pages... by IggleSniggle on Friday August 11, 2023 @07:35AM (#37087516)
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.

Re:Browsers barely care what HTTP status code your web pages... by Sebb767 on Friday August 11, 2023 @06:11AM (#37086978)
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.
Re:Browsers barely care what HTTP status code your web pages... by brabel on Friday August 11, 2023 @06:27AM (#37087077)
> 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

Re:Browsers barely care what HTTP status code your web pages... by pseudalopex on Friday August 11, 2023 @07:29AM (#37087460)
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.
Re:Browsers barely care what HTTP status code your web pages... by erikerikson on Friday August 11, 2023 @12:50PM (#37090837)
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.
Re:Browsers barely care what HTTP status code your web pages... by BrandoElFollito on Saturday August 12, 2023 @03:36AM (#37097955)
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

Re:Browsers barely care what HTTP status code your web pages... by rhaway84773 on Friday August 11, 2023 @06:35AM (#37087120)
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.

Re:Browsers barely care what HTTP status code your web pages... by somat on Friday August 11, 2023 @06:46AM (#37087187)
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.

Re:Browsers barely care what HTTP status code your web pages... by adamsb6 on Friday August 11, 2023 @02:28PM (#37092098)
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.
Re:Browsers barely care what HTTP status code your web pages... by dwaite on Saturday August 12, 2023 @08:12PM (#37105355)
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.

Re:Browsers barely care what HTTP status code your web pages... by account-5 on Friday August 11, 2023 @11:20AM (#37089694)
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?
Re:Browsers barely care what HTTP status code your web pages... by babypuncher on Friday August 11, 2023 @11:22AM (#37089717)
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...

Re:Browsers barely care what HTTP status code your web pages... by NoMoreNicksLeft on Friday August 11, 2023 @11:44AM (#37089994)
> 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.

Re:Browsers barely care what HTTP status code your web pages... by mcronce on Friday August 11, 2023 @02:10PM (#37091897)
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.

Re:Browsers barely care what HTTP status code your web pages... by kube-system on Friday August 11, 2023 @02:51PM (#37092400)
This is probably not the result of internationally dumbing down the message, but lazy error handling.
Re:Browsers barely care what HTTP status code your web pages... by pomstazlesa on Friday August 11, 2023 @06:08PM (#37094662)
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.
Re:Browsers barely care what HTTP status code your web pages... by Guvante on Saturday August 12, 2023 @02:56AM (#37097729)
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.

Re:Browsers barely care what HTTP status code your web pages... by WirelessGigabit on Friday August 11, 2023 @06:52PM (#37095033)
This is just a general try catch. Build happy path, get VC money and deploy. We'll fix it later.
Re:Browsers barely care what HTTP status code your web pages... by BrandoElFollito on Saturday August 12, 2023 @03:32AM (#37097932)
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