I ran into this a few months ago. To show off my StyleGAN-generated anime faces, I made https://www.thiswaifudoesnotexist.net/ to load random samples. It went viral in China. After about 450,000 unique people visited (according to my Google Analytics), with the overwhelming majority being on mobile, I thought I'd better double-check how it looked in mobile as opposed to just desktop to see if it could be improved. Turned out it could - it was almost totally unusable because the image wasn't resized appropriately etc. Not a single person pinged me about it.
It reminds me of something Neal Stephenson noted in "In The Beginning was the Commandline": one of Debian's advantages was that it had a open public bug database (still not universal! eg Apple), and you could very easily and conveniently file a bug with 'reportbug' from your terminal.
Perhaps a solution could be to have a button that simply says “something is broken,” and while it could open up a form for a user to submit a brief error report, just the click alone could send fingerprint information about the browser, so you could determine from the fingerprinting that most issues happened on mobile, from China, etc.
That way if a user doesn’t end up submitting useful information, or it’s in an unfamiliar language, or if they don’t even submit the form itself, you still have data to work with.
That's an excellent idea! Call it "drive-by bug report"? Or "casual bug report"?
I am now thinking how to combine the two channels - one is the regular support channel where everything gets tracked and answered (we put a lot of work into it), and one is for drive-by reports (so we just collect them and make statistical inference but don't work hard on each incident). Most of my users are logged in so I know who they are.
How about this:
1. Is something broken on this page? [button]
2. [button clicked] We've made a note of your report! We analyze all such reports periodically. Would you like to expedite this particular issue? [yes/no button]
3a. Form abandoned, no further UI action.
3b. [No] Ok, we will treat this as a low-priority issue. If you have any details to share please put them here (optional field).
3c. [Yes] Ok, we will treat this as a high priority issue. Once you fill out this form someone will get in touch with you asap. (What were you trying to do) (What was the desire outcome) (Is it something that used to work but no longer does) (...).
So 1-2-(3a|3b) is the casual path, and 1-2-3c is the firm path...
Adding a Do Not Send button to the form would be nice so that you could choose not to send back telemetry if you care about that type of thing and you accidentally hit the button.
Reducing friction for reporting bugs is key. In Slack for example, you can report bugs via slash-command: "/feedback my X breaks when I do Y" opens a ticket and subscribes you to it via email.
I have a label in my Gmail with tens of thousands of unread autogenerated email bug reports from a long abandoned Windows Phone app. Before it was abandoned they were useful enough without much more parsing than can be applied with a gmail filter
The user still needs to consent to an agreement with a list of all collected data for this to be legal. Otherwise, this is likely a violation of the user's privacy.
Fingerprinting is done all the time with zero notification or repercussions.[1] Still a violation of privacy, but perhaps if it only happened for a bug report, it could be opted out on with a button on the form.
Slightly off-topic, but I never thought I'd come across the guy behind that site in a HN thread - especially since I just found it today. Baader-Meinhof, I guess.
It reminds me of something Neal Stephenson noted in "In The Beginning was the Commandline": one of Debian's advantages was that it had a open public bug database (still not universal! eg Apple), and you could very easily and conveniently file a bug with 'reportbug' from your terminal.