Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aarongustafson opened this issue Mar 6, 2020 · 14 comments
Assignees
Labels
discussing want Incoming requests from the community

Comments

@aarongustafson
Copy link
Member

@aarongustafson aarongustafson commented Mar 6, 2020


title: I want a smart browser that is able to determine the sites coding errors are producing a failed end user experience.
date: 2020-03-06T13:49:05.932Z
submitter: PRIVATE
number: 5e6254d17b0c456276b5753e
tags: []

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.

@aarongustafson aarongustafson added the want Incoming requests from the community label Mar 6, 2020
@marcoscaceres
Copy link

@marcoscaceres marcoscaceres commented Mar 8, 2020

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

@aarongustafson
Copy link
Member Author

@aarongustafson aarongustafson commented Mar 9, 2020

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

My thoughts exactly!

@aarongustafson
Copy link
Member Author

@aarongustafson aarongustafson commented Mar 9, 2020

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…

F97D7AA6F2D04CD08FF3E23004E64271

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
Copy link

@marcoscaceres marcoscaceres commented Mar 10, 2020

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
Copy link
Collaborator

@captainbrosset captainbrosset commented Mar 11, 2020

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
Copy link
Member Author

@aarongustafson aarongustafson commented Mar 11, 2020

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
Copy link

@marcoscaceres marcoscaceres commented Apr 14, 2020

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
Copy link
Member Author

@aarongustafson aarongustafson commented Apr 15, 2020

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

@igrigorik Do you mind chiming in on this?

@igrigorik
Copy link

@igrigorik igrigorik commented Apr 18, 2020

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
Copy link
Member Author

@aarongustafson aarongustafson commented Oct 20, 2020

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 aarongustafson added the question Further information is requested label Oct 20, 2020
@aarongustafson
Copy link
Member Author

@aarongustafson aarongustafson commented Oct 23, 2020

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

@jstillings1
Copy link

@jstillings1 jstillings1 commented Dec 23, 2020

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
Copy link

@jstillings1 jstillings1 commented Feb 23, 2021

  • 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.

@WebWeWant WebWeWant deleted a comment from github-actions bot Mar 30, 2021
@WebWeWant WebWeWant deleted a comment from github-actions bot Mar 30, 2021
@aarongustafson
Copy link
Member Author

@aarongustafson aarongustafson commented Mar 30, 2021

@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.

@aarongustafson aarongustafson added discussing and removed question Further information is requested labels Mar 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussing want Incoming requests from the community
Projects
None yet
Development

No branches or pull requests

6 participants