Learn More
Resend Email
1
adante
4y

Settle an argument for our development team. We have infrastructure to report crashes when they occur, via a simple online form submission. The form provides basic fields for a description and an email address, and also posts some basic telemetry (rebuilding what it can of call stack, variables etc). Currently the email address is optional (you can submit the form and leave it blank). The form is not mandatory (the user can hit 'send' to submit online, 'save' to save the crash report to transfer in other ways, or 'cancel' to just ignore it entirely (irregardless of their choice, depending on where the crash has occurred, they may be able to continue using the application or it might exit).

A suggestion has been put forward to make the email address mandatory. Surprisingly, this has kicked off an incredibly polarising debate, so I thought I would put it to devRant to see what is the consensus here.

I'm trying not to bias the discussion by stating with the considerations at play, but would encourage you to think about them before chiming in!

question

crash email
Favorite
Ranter
Comments
  • 2
    4y
    I'd say to keep it optional. It increases the friction for the user, so it would likely increase the chance of the user pressing ignore. Also, why ask the email? If I got an email about a crash on an app I'd just ignore it.
  • 1
    4y
    I’m curious to hear the justification for an email address. I can’t think of a reason it’s needed. Why do you need anything other than a usage description? Why don’t you automatically send the crash report in the background immediately, and just allow the user to submit a description and no identifying information? What is the gain to you as a developer for gathering that data? It’s very likely your response rate will drop dramatically too.
  • 1
    4y
    If it's internal, maybe. If it's external, no way.
  • 1
    4y
    @ItsaMeTuni @Diactoros primarily, it is so we can contact them to (a) notify them when that crash is fixed, (b) providing them with workarounds and (c) asking for further information to replicate the crash when it is not clear.

    To provide some context we write fairly niche software used by engineering professionals. Our userbase is actually currently small enough that personally know and often work in close conjunction with the majority of our users. Odd as that may seem (and the challenges it presents with scaling notwithstanding), this has been consistently cited as our one of our greatest competitive strengths so is something we think carefully about.
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment