Button to generate "debug report" for users

[lurch]

Sometimes when users report problems with Etcher, it's difficult to get all the info from them we need.

Perhaps there should be an button in the Etcher GUI somewhere (ping @konmouz ) that we could ask the users to click on that would generate a "debug report" they could send to us, which would contain all kinds of useful information, like:

• Etcher version
• OS (and version) that Etcher is being run on
• Name of the image that was selected
• Name of the drive that was selected
• Output of the DevTools console
• Output of the drivelist command
• etc.

[jviotti]

We should make sure we are super clear about what information we're retrieving though.

[lurch]

Of course. We should also allow the user to view all the info in the report, before they send it to us. Perhaps we could just dump a text file in the same location as the Etcher binary (if that dir is writable) or in the user's home directory otherwise?

[konmouz]

We can have an option in settings, where user can also review report's content and choose where to save, or send it directly to us (i.e. Apple has a very similar flow for this when something goes wrong).

[taahirisaacs]

Me and @konmouz were chatting about this, and thought it might be interesting to prompt the user on initial start-up of Etcher. They could still find the option within settings.

[lurch]

Hmmm, what would it prompt the user for on initial start-up?
Hopefully most users won't encounter errors, so we won't need to bother them about debug reports... ;-)

[konmouz]

This is in case we need to always get auto-generated reports when something goes wrong. Indeed it is an extra step, but if you think it could be something useful we can explore how this can be implemented.

[lurch]

IMHO asking every user at start-up about debug reports, might give the user the wrong impression that we expect Etcher to have problems? :-S

[konmouz]

This could be indeed an issue. So for now we can have an option in settings and just a dialog when something goes wrong.

[jviotti]

I personally don't think we should bother with automatic error reporting, since as @lurch , this will be the exception rather than the rule, and we're pretty much covered in that aspect by TrackJS.

I propose to develop a button that users can click to generate a file containing all sorts of information about their system (generic stuff, no personal information), and they can send it to us by themselves (on a GitHub issue, or attaching to Gitter).

[konmouz]

I was thinking a modal with direct option to 'send to Resin' or 'just save'. Visuals will follow soon.

[jviotti]

Lets do a "just save" for now. We don't know how beneficial these reports will be to us, so lets wait for some real benefits before polishing and automating the feature.

[konmouz]

[konmouz]

The ignore button redirects back to the settings. I guess that the 'debug report' modal can also appear after an unexpected error. In this case the ignore button will just dismiss the modal window.

[jviotti]

I feel that having the "debug report" button inside the settings dialog feels a bit weird. We have this question mark icon right next to the settings that currently redirects user to https://github.com/resin-io/etcher/blob/master/SUPPORT.md. What about having that icon open a modal that allows you to either open such document or generate the bug report?

[konmouz]

This is a bit tricky. Indeed settings is not the best place to have the debug report, however, I am not sure if it a good practice to create a new modal to host basically just two options and complicate the help flow (which currently is very direct). Another concern is that normally users avoid 'help' unless they are really stuck (here we need some analytics to double check).

[jviotti]

Yeah, I agree its a tricky one. Lets go with settings if you feel that's the best thing we can do at this point!

…

On Thu, Dec 01, 2016 at 09:21:36AM -0800, Konstantinos Mouzakis wrote: This is a bit tricky. Indeed settings is not the best place to have the debug report, however, I am not sure if it a good practice to create a new modal to host basically just two options and complicate the help flow (which currently is very direct). Another concern is that normally users avoid 'help' unless they are really stuck (here we need some analytics to double check). -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #857 (comment)

-- Juan Cruz Viotti Software Engineer

[konmouz]

@jviotti do we have analytics regarding how many people use 'help' and at what stage?

[jviotti]

@konmouz We don't have any event for the icon, even though we should (maybe @Shou can handle?). What we do have is GitHub analytics of how many times https://github.com/resin-io/etcher/blob/master/SUPPORT.md was visited here: https://github.com/resin-io/etcher/graphs/traffic, and its the second most viewed page in our GitHub repository (after the landing page).

[konmouz]

@jviotti can we find out where they are coming from?

[lurch]

I guess as far as GitHub is concerned, they can't tell the difference between people clicking on the 'help' button in Etcher, and people just typing https://github.com/resin-io/etcher/blob/master/SUPPORT.md directly into the URL bar of their browser.

[jviotti]

Yeah, we can't know for sure, however its unlikely that users will open SUPPORT.md out of nowhere. I'd say at least 80% of those come from the application, but again, we don't know for sure.

[lurch]

Yeah, we can't know for sure, however its unlikely that users will open SUPPORT.md out of nowhere

Agreed. So presumably all visits with no referrer are coming direct from the application. It obviously doesn't account for the "long tail" effect, but adding up the top 10 "Popular content" views gives a total of 5,484 views, and adding up the top 10 "Referring sites" views gives a total of 4667 views, meaning 817 views have no referrer.

Interestingly, two of the top 10 Referring sites are from non-English webpages. I guess the simplicity of the Etcher interface makes it easy to use for non-English speakers :-)
(but perhaps it adds more weight to #308 ?)

[jviotti]

As proposed by @lurch in #953 (comment), lets start prototyping this as an internal feature available through DevTools.

[jviotti]

Apparently Sentry has support to generate and display error reports /cc @stefan-mihaila