New want: I want a smart browser that is able to determine the sites coding errors are producing a failed end user experience.

[aarongustafson]

Imagine with me your sites API calls are returning 401's. Imagine the data feed for your charts is now a SaaS and is no longer free and your site is pulling in 404's. Imagine the SaaS software you pay for only displays a 500 error for two days.

I want the browser to actually notify the user that their User Experience may not be what the developer has intended.

I also want the browser to notify the team who is managing the site by creating a issue ticket for the user experience fail in the search console.

How is lack of this impacting your work? Most SaaS software is coded on contract and once live the contract ends. There is no one on the help desk of the software that can fix the bad user experience that back end data feeds cause, there is also no way for the company to get a developer to go fix it without an entire new contract being drawn up.

How do you currently work around this limitation? I advise the users of the Coding Errors and tell them their is nothing they or I can do about it but to convince management to switch to some other vendors SaaS.

[marcoscaceres]

Sounds a lot like https://www.w3.org/TR/reporting-1/

[aarongustafson]

Sounds a lot like https://www.w3.org/TR/reporting-1/

My thoughts exactly!

[aarongustafson]

This is actually a duplicate and I did send a follow up email on 3/2 to ask if anything was missing from the Reporting API. Here was the follow up:

I looked that over and no, it does not do what I am referring to, which is a smart browser that is able to determine the errors are producing a failed end user experience.

IE. Open up a website that is highly dependent on many API calls and data feeds if the site has numerous JavaScript errors and the end result makes the function of the site to the user not work as intended, I want the browser to be able to send a ticket to the sites creator stating which API calls and which data feeds are down and present the USER a new type of an error page that says it is us not you type thing.

So many times I see 500 and 404 errors on data feeds on complex websites that the developer is left in the dark on and the user even worse, they just call IT and say the computer is broke when really the Websites API and Data feeds are.

Then

So instead of the user seeing a broken PC the browser sees this…

And creates a ticket to the web site creator and displays a message to user saying This is Dorked. We submitting a ticket for the developer to fix it Your experience may be horrible till they fix it.

Hope this is all clearer of what I want the browser to do. Protect the user from BAD Devs😊

Soounds to me like the Reporting API + some affordances/messaging for the user as well ("it’s not you, it’s them").

Challenges:

• Users will still get a broken experience
• Not all sites will tell us who to submit tickets to
• Not all failures in the console are indicative of the site/experience failing entirely, some may have fallbacks/failovers, etc.

[marcoscaceres]

We might need to have some of the folks from the Reporting API look this over. However, HTTP errors are developer/server error and are generally easy to debug (e.g., in the network panel, you can see who the initiator of a fetch request was).

[captainbrosset]

A thought comes to mind:

Something like https://webcompat.com/ but for sites that are broken.
This could be of interest for the web community. A place where users can report broken sites, and that companies can check to see if people are experiencing problems. So, rather than expect site owners to tell us where to submit tickets, have a place for users to do it.
This could ultimately lead to browsers doing it automatically.
I don't feel like there's a need for something to be specified for UAs to implement, but I find this want interesting.

[aarongustafson]

We might need to have some of the folks from the Reporting API look this over.

Any thoughts on who that should be @marcoscaceres?

Something like https://webcompat.com/ but for sites that are broken. This could be of interest for the web community. A place where users can report broken sites, and that companies can check to see if people are experiencing problems. So, rather than expect site owners to tell us where to submit tickets, have a place for users to do it.

I like the idea @captainbrosset. We (Edge) get some of this feedback currently via the "Send Feedback" tool.

This could ultimately lead to browsers doing it automatically.

This would be interesting, but would need to be vetted heavily to ensure user privacy is maintained.

[marcoscaceres]

Any thoughts on who that should be @marcoscaceres?
Just looking at the editor's list:

Douglas Creager (Google Inc.)
Ilya Grigorik (Google Inc.)
Paul Meyer (Google Inc.)
Mike West (Google Inc.)

I'd ping Ilya, as this is something I know he is quite passionate about.

[aarongustafson]

I'd ping Ilya, as this is something I know he is quite passionate about.

@igrigorik Do you mind chiming in on this?

[igrigorik]

Hmm.. I don't think we can involve the user in this much. Vast majority of users have no technical expertise and are not in a position to asses if+what might be broken, nor do we want to inundate them with cryptic prompts.

The onus is on the site owner and developer to get the right mechanisms to detect issues relevant to their site+users, and for the browser to surface relevant signals that they can collect. To that end, we already provide global and event specific error handlers, surface deprecations and violations via Reporting API, provide NEL for network failure notifications, etc. There may still be gaps here, but I think the core building blocks are all in place.. There are many great tools and services that unify all this: sentry, rollbar, GA primitives, etc.

[aarongustafson]

Hmm… I don't think we can involve the user in this much. Vast majority of users have no technical expertise and are not in a position to assess if + what might be broken, nor do we want to inundate them with cryptic prompts.

That’s a fair point. Some browsers do inform/interrupt the user if the browser gets locked up on a site though. I wonder if there’s some threshold in terms of the number of failed API calls that could warrant some sort of notice to the user, from the browser, that something could be wrong (irrespective of whether the developer has raised their hand to say they want to be informed of issues like this).

[aarongustafson]

@jstillings1 I wanted to loop you in on this as it is your submission. Any thoughts on the above?

[jstillings1]

I think I was thinking more like https://wave.webaim.org/ but where the browser KNOWS there is missing data and tells the user, Your view may be incomplete there was 15 blocked resources or 3 resources that could not be found. Basically it would just read the Developer tools for Errors or critical

[jstillings1]

• some affordances/messaging for the user as well ("it’s not you, it’s them").
  Is very much what is needed.
  When a header loads and the footer loads and all the react data in the middle does not, the users freak...
  just need something to tell a user that the SAAS software is not showing them what they want and the browser is aware that the service is at fault not the user's pc phone or tablet.

We sure get a lot of calls for my computer is broken when really the data feed inside a web page is not working.

[aarongustafson]

@tantek @bkardell @cwilso and I discussed this a bit today and are exploring some ideas in this regard. One concern we have is how the user is in control of processes like this. More soon.