Which file?!?!?!
Anyway, I disagree strongly on the technical jargon. Ok, if it's not really an error and the user can retry or similar sure.
But if it's bad times, an exception or similar, don't care about the user. Instead include as much detail as you need. A non-technical user won't be able to do anything anyway, and a sanitized error message means support or a technical user has a much harder time figuring out what the real issue might be, in order to work around it.
Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.
So don't say "InvalidArgumentException xyz", say "Expected a number but got 'hello'".
This doesn't always work, but essentially hide tech details from users. If you must, include a bit of extra information (a request number or whatever) that helps you log dive.
I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.
what i have is a string. how do i turn my string into a relevant number?
If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly.
“Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
In fact I would generally bet thousands of dollars against that.
Oh good, I guess I’ll expect to hear back never.
I think it’s a good thought but we’ve been conditioned that these things are black holes. User should have all agency in escalating or continuing troubleshooting rather than implied wait for deus ex machina from the support team.
What support team? The ones that were all not hired in the first place, and if they were hired then they were replaced by AI? The same support team that customers simply cannot reach at all?
Sounds very useful.
With how powerful Ghidra is now, I'm not sure that it matters much any more.
As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/
Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
I work on desktop applications. Tech stack is visible to anyone who can see the error message.
If you got a web-based SaaS sure I understand your position, but then you spit all that good stuff into a log and have the error message include the relevant log ids so support can easily find it. If something bad happens while loading a file, include the filename in the logs, and so on.
In the logs: detailed technical message with uuid.
I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible!
Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
If it's not something I can fix as the user, weigh the options: do I even need to know there's an error? Can you just cache the operation and try again later? Maybe an indication that it's happening in the background?
Current favorite peeve: Uber Driver app for deliveries complains "couldn't upload the photo" of the drop off. It's because this customer lives somewhere off the signal map. I can't do anything about it until I drive a mile back in the other direction. So, instead of blocking further operation, just hold that pic until we get back to civilization, ok? I need the map to get to the next pick up or dropoff, and this nonsense is in the way.
Regarding the proposed "good" alternative, it has less actionable information than the original "bad" message, depending on what the product is and who its users are. In particular, you can't determine whether "fetch data" is impenetrable jargon without looking at the product itself and its users.
I also frequently see people use the designation of a user as non-technical as an excuse to dismiss their intelligence. It's true that tech folks generally underestimate how confusing computers and software are to the average person, but erring too heavily in the other direction also has negative impacts for accessibility. Either way, you can at least hide away that extra detail, with jargon and all, using that link tip she mentioned.
Finally, this writer seems to overestimate the extent to which most users view "contact Customer Care" as "giving them a way out" and not an invitation for further aggravation.
First, appropriate tone depends heavily on the product or service in question. A bank or otherwise serious business should probably not be giving messages like "whoops, something went wrong". But an entertainment product could have those sorts of messages, and treat it as part of the overall experience.
Secondly, I'm not a huge fan of error messages that don't give actionable feedback for how to fix the issue. Yes, a lot of users don't need that sort of information, but some sort of error code or technical reference can be handy for more involved support processes.
So, if the product or service is business orientated, maybe have that info in a dropdown box or something, where a support agent can ask the user to find it if an issue keeps occurring. And of course, if the product or service is aimed at technical people (like an open source infrastructure project), maybe just skip the casual language and just get to the point.
I didn't break it!!! Reddit is down and your server is overloaded.
"No headset audio" -- displayed by the Oculus desktop app, in regards to not having audio on the headset. There's a "learn more" link, which would send you to the general troubleshooting FAQ.
So, the program knows something is wrong with the audio, but completely refuses to say what. Is it a headset problem, a driver problem, a restart needed!?
Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is:
[{"error":"Attachment is too large. Limit 20 megabytes."}]
I still have a screenshot from a long time ago from a Microsoft product and the error message reads something like that:
"Possible causes: xxx, yyy, your computer may be off".
That one is so dumb I took a screenshot back in the days and still have it somewhere in my backups.
What they meant was "the computer you're trying to contact may be off", not "your computer may be off". I honestly think that one takes the icing on the cake.
But I've got another contender screenshot, still from a Microsoft product, saying something like this: "We suggest you write the following password down: z_7-9$HqR2_vM5$pL8-wN1_bX4$kZ7-jT0_yC3$fS6-uG9_aD2$hI5-rP8_eQ1$mW4E8_oQ1$tV4-6_x$K9_j-2$G5_s-8$W1_b-4$N7_m-0$Z" [1]
This was pre-ubiquitous QR code days.
[1] and, yes, it was so dumb I preferred to take a screenshot of the password than be "secure", so I could make fun of that message forever. And I gotta say, that screenshot did age like fine wine.
I was writing code for AT&T (in the 1980s), and we were our own customer. So I wrote the error routines to check an environment variable and provide different error messages for different types of users: developers, testers, and a few power users got very detailed error messages, ordinary users got friendly, simplified messages (and weren't told about the environment variable).
Prev discussions, Oct 2022, 250+ comments: https://news.ycombinator.com/item?id=33261125
* I thought at first they meant "later" was too vague, but omitting the word only makes the message more terse, not more specific. It's as if they decided ahead of time that the old message was bad and embodies certain qualities (which they highlighted) and the new was good and embodies certain other qualities (also highlighted), and they didn't bother to rethink the new one after seeing almost the same phrase used as examples of bad and good.
* "Your changes were saved": yeah, if the change is connecting your account to a third-party service, and they were unable to connect...did they save the intent to connect? How do you resume it? Or was this part of a greater set of changes? The reassurance works best if it's consistently true, but I'm doubtful.
But it turns out they were completely full of it, and have absolutely no idea what separates a good/bad message. Quite disappointing.
If its possible, just do it?