4 ms·
Change the first line of your error message to, "Important: Please mention the following error number when contacting support." you told us that is what you ne
by logicallee 10y ago
Change the first line of your error message to, "Important: Please mention the following error number when contacting support." you told us that is what you need - but did you tell the user?
- drblast 10y agoDoesn't matter what the error message is. It's very unlikely they're reading the error message at all. And yes, I've tried what you mentioned. I did fib a bit though. There is one error we get emailed to us regularly. It's a 403: {"code": "Forbidden", "message": "You do not have access to this API feature because you need to be a member of role [ROLE]. To get access, follow this link to our role request page here: https://linkToRoleRequestPageWithDeadSimpleHTMLForm?role=ROLE"} THAT error reliably gets copy/pasted in an email to us with the questions "Why am I getting this error?" or "How do I get access to this?" EDIT: I'm also talking about the JSON output of an internal API whose target audience is developers and people writing scripts. This means that we are all the problem. If the target customer were average Joe user I'd completely understand.
- logicallee 10y agoSo you need to lie in your error messages and come up with a message that will get emailed to you. How about. "Forbidden. Please request access by following this link: http://internal/?requestguid=GUID&custn=CUSTNAME http://internal/?requestguid=GUID&custn=CUSTNAME Your request will be handled within 24 hours." That link? If they click the link - which they will - you have all the information they should email you (but don't.) Because you told us all you need is the GUID. Remember: Error messages are literally an API between you and the human. If the human isn't doing what you want, you need to debug your API code until the human is doing what you want. The human is like a device! It might be flaky, but you're stuck with it. So debug your API code (the error message) until you work around the flaky humans.
- fencepost 10y agoYou forgot the important extra part: "If you ignore that link and instead email this to us, we'll try to get back to you within 5 business days."
- logicallee 10y agoI don't think there's any reason to be passive aggressive. If you give users two options they'll choose the one that's worse for you and worse for them. :)
- deleted 10y ago[deleted]
- drblast 10y agoI like the way you think. I'm going to change all error messages to: "Please click this link and type the following GUID into the web page." That way, based on history, I'll at least get an email with the error copied in. They'll never click the link, but if they do one or the other, I'll have the info I need. Now if I could just stop people from submitting bug reports for 404 errors...
- logicallee 10y ago:) good luck!
- adekok 10y agoMy $0.02 is that people who submit such bug reports need to be fired. They're adding negative value to the company. I get such bug reports for my open source project. People get offended when I point out that the message says what they need to do.
- dspillett 10y agoDoesn't work. Too many people don't read the instructions, or do but don't follow them, not matter how much big, red, bold, flashing text tricks you use. The only reliable way around it we've found with our clients is to be dickish with SLAs: insufficient information means the SLA clock stops dead. No error code/message details, no SLA, and I can & do take my merry time (if I ever get around to looking at that ticket instead of the many that do have sufficient information). Though it helps that our large clients always knock down support costs by refusing to pay for first-line support because "our internal helpdesk can do that" so they should be performing at least minimal triage. It might not wash in other environments. The really irritating part is when they seem to do their level best to avoid giving any specific details: Them: some users are having a problem with a form Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error? Them: Actually it is quite a few users. Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error? Is the problem loading information or saving it? IF the latter does any of the data save despite the error? Them: More users are now reporting the error. Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error? Is the problem loading information or saving it? IF the latter does any of the data save despite the error? Lather, rince, repeat, until I state something like "we've tried with several user types and several forms in our test services, and can't reproduce the problem, unless you can produce the details requested we'll have to close the ticket as "can not reproduce", at which point they get shirty about us not being helpful but do provide the information requested. Yes, I can often work out exactly what is going on from various exception logs, and sometimes to just to get the buggers off my back so I can get on with something more useful and interesting, but I resent having to dig for details that it would take almost no effort for them to provide either up front or after my initial request for clarification. IT isn't just "lay users" either, it is often people who really really should know better. IF you find yourself on the other side of this equation: give all the detail you can FFS, help us help you (countpoint: only give us facts, don't guess or otherwise make shit up).