I really hate the way the "Gah" wording feigns shock, as if Mozilla are also inconvenienced alongside me. Then the meat of the error implies I am at fault. It's my tab that crashed, and I caused it to happen by doing whatever I did on whatever page I was choosing to visit. Any blame is deflected away from Firefox itself.
Then it makes me feel doubly bad because I immediately realize I'm getting upset at something incredibly trivial, but man it annoys me!!
Honestly, as an engineer "Gah" is generally what I do say. When I experience difficulty with software others create, when I discover frustrations with software I create, and when I discover that a customer experiencing an issue that made it out the door that clearly shouldn't have.
It's a very caveman-esque "gah, thinky box no work" type expression, or surprise "gah! wtf just happened!?"
Not trying to invalidate what you feel - just trying to share a different perspective. Perhaps a nudge to give the devs the benefit of the doubt that they don't want you to feel bad things when using what they've poured a lot of energy into.
I don't get shock from "Gah." I get embarrassment and disappointment, which seems appropriate for the situation. Firefox is ashamed that it screwed up.
Then again, I'm from the age when the internet was still fun, and everything didn't have to be corporate, uniform, serious, and boring.
I'm from that age too, but it groomed me to cringe when a $XXM international corporate brand tries to be casual and fun. It doesn't feel authentic. It doesn't feel like it speaks from some relaxed, hacker culture at Mozilla. It feels like somebody in a designer hoodie with an ocean view conference room wants to brand Firefox as the fun alternative. It only makes me miss those old days more.
I get fatuous inauthenticity. It's a computer program not a person, and no single person wrote it or actually feels any aggrieved embarassement for that mishap, since they aren't manually performing the task that went wrong. They may say "gah" sincerely sometime later when they read a bug report, but that is some entirely seperate thing.
I think you're highlighting the issue on why this is a bad choice. Words like "gah" mean different things to different people. They may not even mean anything at all to non native English speakers.
If you're just trying to call a friend, and you put in a wrong digit, the fun response might be a brief chance to have a good laugh at yourself, but, if you are doing something like say trying to call a doctor to ask for lab results on a cancer screening, or you're trying to call the bank to report a stolen credit card, and you get the wacky "Whoops! Looks like you you need to get a dialing wand! lol"[1] response, it is not going to be well received.
I guess what I'm trying to say is that a joke message can have a certain place, but I think that it means the developer has to take some time to consider "Is this ever going to be used for something serious or time sensitive?" If it's just a small project, who cares? But if it's going to be used by more than a friend group, or a niche circle of 100-500 users, it's probably better off left in as a joke comment, instead of a user-facing error message.
I don't need "corporate, uniform, serious, and boring."
I generally just want things to be genuine. With error messages, that should be no-nonsense - when software crashes, I'm not interested in how verbally clever the vendor can be.
Remember your cutsey expression of your individuality might be cute the first time your software crashes, but after the 100th crash, doesn't come across quite the same way.
Kind of like how Windows' first-time boot-up greets you with a flat (and totally inappropriate) "Hi"
Like fucking seriously, not even "Hello"? "Hi" is how I greet the coworker I don't really even like that much. Whenever I see this I think of the Argonian NPCs from Oblivion, who would also greet you with a very flat "Hi"
"Greetings," "Salutations," even "Welcome!" would be a better choice here.
Windows XP used to have "Welcome". It was a better choice... in the English version, that is. Apparently properly translating that word was difficult because e.g. in Russian version it said something that'd be roughly equivalent to "a welcoming" in English: they've used the word that means "greeting" but can not by itself serve as a greeting. The overall effect was that you were left mildly puzzled: "did they just forget to put an actual greeting in there or?.."
Also, that animation looks 100% like how they portrayed your computer being hacked in movies. You know, when the UI completely disappears and the only thing you see on the screen is the message that the hacker wants you to see.
That might be specific to where you are from. I can only speak for Australia and New Zealand, but "Hi" is perfectly acceptable. Unnecessarily formal speech can come across as disingenuous, and maybe a little patronizing. Although the same is true for overly familiar speech as well.
I mean, your work computer is usually a co-worker you don't like that much (because it never quite does the thing I want), isn't it? Heck, I'd say that about my home computers too.
The computer for me is like the co-worker that does almost, but not exactly what I'd like it to do except when they do, the guy thats a little awkward when you run into them in unexpected situations, but he works pretty hard and works at least as many hours as you do.. except when they don't.
the importance of "hi" vs. "hello" is so low, so far down the list of bad messages that it's on the part of the long strip of paper that it is located about halfway back from its trip to the moon.
this is what you choose to complain about? your life must be exceptionally trouble-free.
Also stop treating your users like idiots. The "Something went wrong" of Microsoft products is just offensive when it doesn't even show you the error code - it's basically saying that you're too stupid to understand, so we're not going to show you exactly what happened. I'd maybe understand if it was just MS Word doing this, but when an Xbox Devkit does that, which you know - by definition - only professionals can have and use, then it's worse then useless, it's actively condescending.
Nah, it's just that Microsoft doesn't understand it either. That's why it's just logged as a damn guid in the event log, that exactly one other person on the planet has encountered and no one on the Microsoft forums have responded.
I always do a double-take at the "something went wrong" messages from MS and the dinosaur browser errors in Chrome, because they trip the same part of my brain that's been trained to notice phishing emails.
Same goes for redditors who need to end their sarcastic messages with /s tag. Okay, so you passively assumed I am too much of an idiot to miss your sarcasm. I will always downvote these posts.
Perfectly expressed in this tweet[0], which originated the "Oopsie Woopsie" meme back in 2018:
> "Can websites please stop the trend of giving error messages that are like "OOPSIE WOOPSIE!! Uwu We made a fucky wucky!! A wittle fucko boingo! The code monkeys at our headquarters are working VEWY HAWD to fix this!" And just give me a fucking error code so I can try and fix it"
I completely disagree with the tweet. Apps usually show this kind of message when the user can’t do anything to fix the problem.
If the “code monkeys” are working on it, what’s the user going to do about a crashed database or any other server-side error? If you can do something to fix the issue, the app will usually give you that information.
Of course, the app might be clearer and tell the user to retry or contact the administrator. But a generic error message usually implies server-side failure anyway.
Perhaps this person expects to receive server credentials as well?
The vast majority of the time I've run into programs and apps giving me a vague error message, you can look behind the scenes at logs and Event Manager and similar. It's almost always a dumb software dev made a dumb assumption about a specific file being in a specific place and just chose to not check the return value for errors and it dies.
If you log the API calls and debug it yourself, you will be able to find the stupidity and delete/fix/move whatever errant file is causing the issue.
So often, literally returning the raw API return value in the "Something went wrong" window would be the best information to provide.
It's laziness, it's devs thinking "Users are stupid". It's NOT hard to put a checkbox in the settings somewhere that says "show advanced error details" if you are so damn terrified of average people seeing "Scary" error messages.
I remember the first time we came across this back then and everyone losing their minds. We used to open tickets with fucky wucky all the time when we knew the ticket was gonna be exchanged within our group lmao
I think this article is great but it buries the lede. The cutesy errors are indeed bad but more important is being informative about what actually went wrong and how to resolve it. A while ago I introduced a new error class hierarchy at <JOB> which introduced three distinct families of errors - one that was considered a user error (that would be thrown in response to some action that we can predict happening but not totally prevent), one that is considered to have a user friendly message but be generally unexpected, and anything else. If you try and insert something invalid into the DB you'll get a user unfriendly message - if, within the calling function, you know why your call to the DB would fail with a key collision (for instance) you can create a new chained exception off the original and rethrow with a human readable message - when it hits the top level of execution (assuming nothing catches it) then the error printing logic will iterate through the full chain and print everything human readable and dump the full traces of any errors not marked as user side.
This lets us quickly triage new errors (since known user errors are kept out of the main error log) and presents an easy way to convert logged errors to unlogged ones when we've determined the source of the issue (assuming it's an exception we're comfortable with - a lot of our "user" errors are server-side validation that should be prevented by client-side code).
It also forces any errors that we haven't specifically marked as human-readable to render as "Internal Server Error" which we hate along with supplying an easy route to provide a more meaningful error message.
I never, in my life, want to read an error message that starts with "GuzzleHttp encountered a malformed response from aws. ..." nor do I ever want to see "[SQL1002] The newly inserted row would violate constraint widgets_name_key" - write good errors.
This was a twitter thread, so not too surprising, but the concluding tweet went there too: "Good error messages explain what’s gone wrong, and give clear instructions for what to do next – and being cutesy rarely helps." and there's a link to https://alexwlchan.net/2020/10/the-importance-of-good-error-... as the dedicated writeup (also from tweets) for that specific point.
I disagree with nearly every response in this thread (not yours). The 'cutesy' error messages are step 1 to providing a better user experience.
'This is awkward! Something went wrong and it's probably our fault :-('
is much better for users than
'Unexpected error occurred in logTicketResponse'
And no, it isn't sufficient, but it is better. Providing useful error messages is really hard (and it sounds like your application does a good job of it), and we as software developers are not very good at it.
For everyone who complains about the cutesy error messages, how much time are you spending in your own code to provide useful error messages that explain the problem and suggest resolutions?
Absolutely not. A cryptic error message still provides value to the user even if they don't understand it. Not only can they search and ask about it (maybe someone else does know), but they can also figure out a workaround by observing the system and under which conditions the error arises. You don't necessarily need to know what "Error 0x12345" means, but if you notice that it only happens under certain conditions, you can now work around it by not running the system under said conditions.
A bullshit error message on the other hand not only makes searching useless but also prevents the user from exploring towards a solution since they can't even tell different errors apart if they have the same generic message.
> 'Unexpected error occurred in logTicketResponse'
I prefer this one, despite the fact that users might like the "cutesy" option better. If the user creates a bugfix ticket, the more information the dev receives the better. When you receive a ticket that says "_____ didn't work" and nothing else, how are you supposed to act on that?
When possible, error messages should include _something_ anything to make it actionable. An error code, a descriptive message. Your example tells me exactly where to look in the codebase. I don't care about the verbiage, but generic error messages are almost impossible to reproduce in many cases, and should only be used as a last resort.
“There was a problem loading the QR code. Show this error to a member of staff and they will let you on the train”
Would be pretty cool.
Follow up email with say $1 credit and and explanation later “our technical team is looking right now to fix the problem you had today caused by our systems” would be cool too.
I am glad I read the post to make me think more about errors.
Errors are tricky: an exception can happen in so many different ways in the app and you have to write code to convert some unexpected thing into a bold plan for the user. It is like codifying a crisis leader!
There's a fairly ubiquitous pattern, these days, with mega-corporations, using "folksy" or humorous, language (Slack/Salesforce comes to mind).
I think that it has its place, but, like so many cultural artifacts, needs to be done very, very carefully.
Humor and colloquialism doesn't usually translate. That's not just between languages, but also between cultures. Canadian humor may be lost on Americans, and vice-versa.
The users of a product are often of a drastically different culture from the creators. It's quite possible that "folksy" stuff from the creators, meant to be comforting and approachable, is perceived as "condescending," or "patronizing," to the end-user.
Also, error reporting is an extremely sensitive area. Often. the user is under a lot of stress, and can feel intimidated by the product (and, by extension, its creators).
Some developers may feel that "puts the user in their place," but I'd argue that may not be a desirable outcome. I like the users of my stuff to feel comfortable, and in control of their user experience.
I have noticed that there's a pervasive disrespect for users, in our industry. In some cases, it comes down to naked hatred.
I guess, if we look at the users of our products as cattle, to be fattened, sold, and slaughtered, it's inevitable.
As a non-native English speaker, this isn't a big worry for me. I apply a heavy "I have no idea what the intention was" filter. This happens equally with humour and non-humour, and the probability that something doesn't translate is about equal between humour and non-humour, I think.
I couldn’t believe the first time I saw the sad smiley blue screen. It seemed like such a ridiculous thing for Microsoft to have done.
Then I remembered fiddling on Macs as a kid, if you screwed up you’d see a bomb. If you did something really wrong you’d get the mac icon with Xs for eyes.
The point being: cutesy errors are about as old as personal computing, but they do seem to becoming more prevalent.
One I recall from the early Mac era was the Kermit file transfer tool. [1] You'd run it on two computers. On one you'd tell it to SEND some file. Then on the other you'd type RECEIVE. A colleague of mine got absolutely fucking livid when he instead typed RECIEVE and it replied "I before E except after C".
He did have a point; the programmer obviously knew what was intended, but instead of just leaving it to a generic syntax error he went out of the way to have the computer be snotty. But the rage still seemed wildly disproportionate to me.
Years later, John Scalzi had a good way of putting it: "The failure mode of clever is asshole." [2]
I felt the same way the first time I saw the new BSoD. It did at least have an error code displayed. But I couldn't agree with the article more, after a bug just ruined my day the last thing I want to see is an insincere cartoon trivializing my problem.
Last night and this morning I was locked out of my email because Duo wouldn't text me a 2FA code. There were no other options shown, just "we sent you a new code" and a phone number for the help desk. It was frustrating and I was upset, but at least they didn't show a sad cat with a bandaged paw. At least I was able to talk to a human, because my problem was important to me.
It's not just that they're more prevalent, but as computers become increasingly necessary it's more and more likely that bugs are causing damage. We should be more conscious of that fact.
Honestly, the new BSOD has everything I need - the stop code that happened and the module name so that I can start thinking about the problem while it gathers the dump. Not really looking for a stack trace or register info until it restarts and I can load the debugger.
> I couldn’t believe the first time I saw the sad smiley blue screen. It seemed like such a ridiculous thing for Microsoft to have done.
What's much worse is that it shows the screen for all of three seconds before automatically rebooting (at least for some errors), so you need to go through at least two or three boot cycles just so you can read the goddamn fucking error message. I used Windows for the first time in over a decade last week and had some issue with the disk, and it just kept rebooting and I had to quickly snap a picture so I could read the message because by the time I could orient myself on the screen it was too late. I cannot comprehend how anyone thought this would be a good idea. I cannot even comprehend how someone could comprehend it. :( indeed.
Yeah. You can actually change the behavior, so that the default is to just stay on the blue screen until the user manually reboots. Why someone ever thought automatic reboot was a good idea, or how they haven't bothered to change the default for 30 fucking years, is beyond me.
Came here to say the same. The problem is they seem to be hiding information (for some reason):
Instead of being able to search "errornumber appname", you're stuck with a pastel picture of some cartoon character shrugging and text of "whoops! something happened. why don't you try restarting?"
Instead of being able to search "errornumber appname", you're stuck with a pastel picture of some cartoon character shrugging and text of "whoops! something happened. why don't you try restarting?"
Are you referring to Teams, by any chance?
I don't mind them being artsy, but if that's a replacement for the actual detailed error message, it both makes the user and the people trying to help helpless.
Imagine helping someone over the phone or in person; e.g. if you can see "error 10060", you know instantly that it's a network connection problem. If it's an access violation ("illegal operation" was unfortunate but still far more informative terminology) or a c0000005, the application probably messed itself up. You can ask people to read you error codes or search them yourself (being sure to quote them --- the horrible vagueness of search engines is another rant I won't get into here, although it also adds to the problem...). If all the application says is "something wrong", no one can help. All but the extremely perceptive could as a result be easily mislead into reinstalling the application, reinstalling the OS, and all manner of other stupidly destructive and ultimately futile actions, only to find out that the problem was ultimately due to something else entirely.
> Came here to say the same. The problem is they seem to be hiding information (for some reason):
Back when I worked at a computer shop I've had customers come to the shop with a hand-written report of the Windows XP BSOD message; like, all of this.[1] They were always very nice people by the way.
Also, all the text is boilerplate and 100% irrelevant to the actual error (UNMOUNTABLE_BOOT_VOLUME). It's not going to be fixed by a Windows update (which you can't install since you can't boot the thing) or disabling "caching" BIOS options. Not showing any text instead of that is probably better. It wouldn't be too hard to make a error message → useful description map for common problems like this, but good error messages/help was never Windows' strong point...
I think prevalence is important here. Everyone seems to be injecting cuteness into everything today. Blog posts or README files overflowing with emojiis and meme images. I'd really like to banish the rocket emoji. The metaphor is exhausted. The corporation-as-a-friend is everywhere.
Interestingly, some errors started out life as deadly serious and only became humorous later. "lp0 on fire". Printers used to really catch fire. Unix really was suggesting that maybe you want to look into that. The message still exists in Linux (as far as I know), but today seems rather funny to some people. Or can read like PC LOAD LETTER[1] to others.
I hated that bomb. It tended to appear at 11:00 PM when trying to print from Adobe PageMaker (pre-Indesign) at the end of a long sprint to get master prints to a publisher. That bomb meant I wasnt't going home for a few hours because MacOS had chosen that as the moment where some extension, previously playing nicely, was in conflict with another. It meant I'd get to do a binary search through deactivating /reactivating extensions to find the offender.
Keep in mind that each iteration required a reboot, and this was at a point in computing history where booting a computer filled with specialized publishing & editing programs each with their own hooks into the OS was a task that could be measured by the length of an extremely generous bathroom break.
And all I had to go on for error messages was a bomb and the number "-10 error". I hated that bomb. I don't think I fully recovered from the trauma & stress caused by unstable OS's until well into OS X's life and a few years of Windows 7 on the MS side of things.
And yes, this is my digital equivalent of the previous generation's "I had to walk 10 miles to school in the snow up hill, both ways"
I think the difference is that the two errors you described are very severe errors in which the machine may not know exactly what is wrong, and there isn't really any information to show to an end user other than a bunch of error logs or something. A cutesy error here is somewhat more appropriate, and can be kind of funny if you think about it like "welp, I really broke it this time lol."
However, the author described a case where an app messed up its auth flow. It knows exactly what went wrong, and it could easily present a much more helpful description. Who knows what a token is, or what headers are? Maybe it could even just try the request again, all while keeping the client informed. Instead, the app seems to have a simple try/except that handles the error by alerting the user with a cutesy message and dev-speak and nothing else, which is pretty annoying.
I also think any image is better than an ironic/snarky iphone alert.
> It knows exactly what went wrong, and it could easily present a much more helpful description.
Could it? The error in question sounds like a programing error. Either the client application did not provide a token the backend was expecting, or the backend lost it. What usefull error can be provided here other than “pray someone prioritises this bug and fixes it in the next release”? Or perhaps “think hard about what is so unusual about your usage or setup that you have fallen off the happy path and reached a state QA didn’t catch yet”
For anybody else wondering, this means you need to visit that URL by hand, e.g., by copying it to the clipboard and pasting it into the location text widget then pressing Return or whatever. Don't click it.
EDIT: wait, wtf, I did the above once - and now it works when I click it. Go figure
> “Token not provided in guest headers.” I have no idea what this means, or what I can do about it.
At least this example gives you something that you can report to support of you do contact someone about the issue. It if you are a bit techie you might be able to judge for yourself if trying again is worth it or a waste of time. Many issues don't even give you that much.
Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. Some users might be savvy enough to take a screenshot, but that isn't likely a good support plan.
I have come to believe that many (most?) engineers and user experience designers actually hate people. I was recently in the western U.S., attempting to get information from a ski/bike resort about mountain biking there for the day. This was no two-bit, small town resort. The website was absolutely terrible. Links to basic information led to 404 pages. And today, my wife and I were looking for information about our local museum's free teen membership program. On the info page, there was a large button with text "Apply Online." Clicking that button led to a form that could only be printed. There was no way to actually "apply online."
I've been working in the industry for almost 25 years. One of the most important things I've learned is that no matter "intuitive" the user interface seems to me, an engineer who likely has the various workflows burned into memory, you either need to have someone with NO experience look at the UI or, at the very least, have the ability to look at the user experience through the eyes of a non-tech-savvy user. Or, even just an engineer who just wants to download a trail map, or apply so his kid can get into the museum for free.
> Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. Some users might be savvy enough to take a screenshot, but that isn't likely a good support plan.
Do you really intend to put links into error dialogs ?
Faced with that dialog you're already pissed, the software disappointed you and you now have to take an extra action (push the button) to even continue using the app or try again.
Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it.
I find the author deeply disingenuous in that we have the emotional rant, but not what they actually did next as a user to solve that issue. Did they just refresh the page, the request resent and everything went well ? Did they send a "WTF?" angry message to support, who tracked their session from their username and made it all good for them ? (and yes, Trainline has really good support for the industry they're in)
I mean, it might as well be that the app auto-resent the request and solved the issue without the user doing anything, and we'd have not idea. That error message probably was there just to state it failed at a specific try, and further action depends on what's happening next in the app.
> Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support.
This is true, even of other devs which is particularly annoying¹². But these days I have the luxury of not dealing with clients directly so can just close things with insufficient information as CNR and move on, and have the joy of colleagues who make better use of the brains they have!
Sometimes the only solution is ample telemetry and hoping that the user can give your a reasonably accurate time of the incident when making a support call so you can reference that information. Though this can't help as much with client side problems that block the telemetry getting through, what information you do get can help greatly with reproducing, or just walking through with reference to the code, the issue, to work out what has gone awry.
> I have come to believe that many (most?) engineers and user experience designers actually hate people.
While I do occasionally work on front-end matters I'm usually not a UX person these days³ so I can't speak from that angle, but yes I do dislike a lot of the general populous! I think the problems you describe come from a position of disinterest rather than hate though, and a sign that a more varied team is needed. You need someone who is passionate about providing a good UX rather than playing with clever things and making stuff technically work. You also need a culture of taking care over your work too rather than doing minimal happy-path testing then throwing it out there⁴.
> One of the most important things I've learned is that no matter "intuitive" the user interface seems to me
I can't remember who said it, but I've always liked the quote “the only truly intuitive interface is the nipple, everything else has to be learned”. As you suggest, it is important to try put yourself in the mind of someone who is hitting your work for the first time without any of your experience, which can actually be quite difficult to do reliably. The other difficulty is the range of users any given application might encounter: sometimes you have to balance guiding the inexperienced, without hindering those who don't want to be bothered, preferably without effectively having two complete UIs to maintain.
--
[1] being interrupted with “I'm trying to X and I'm getting errors” “What errors?” “Something about the database, I didn't take a note” (to which the answer is “well reproduce it and come back to me when you've got useful information”, but by this point I may have lost concentration on what I was working on).
[2] One of the most annoying people I've worked with once said in response to me asking for the usual details, in an exasperated tone, “you always ask that” - the idiot was well aware that the information would be required and got irritated at it being needed instead of actually bothering to note it.
[3] I used to do a bit of everything in smaller companies, as things have grown I've specialised more towards database work, and infrastructure to support other devs.
[4] Though we have a full QA resource, we spend plenty of time doing “devtest” and making/updating/checking automated tests. QA (or in companies without that resource, the users) shouldn't be finding glaringly obvious issues because I rushed through one test case and didn't even think about anything closer to the edges.
These days, if something is print only or has similar stupid hurdles, I suspect that the purpose is market segmentation. Some people will prefer to avoid the hassle and just pay full price or go without. Which means the company can offer that much more value to the people who are willing to go through the hassle.
Gone away? You mean like it packed its bags and hopped aboard a train to another town? Surely you're not trying to say that the connection timed out or anything more specific.
In this case it might be hard to improve. It's a message generated by the client which means that it was expecting something from the server and instead the connection was terminated.
It's a sign that something has gone wrong on the server side, but it's impossible for the client to know what that is. Especially because most of the time MySQL connections are each a thread and there may be time between when something server side terminated the thread and when the client tries to talk to the server again. It's better for the server to release all the resources immediately instead of waiting for the client so it can return a more helpful error message.
I actually from a less technical person's perspective, "cute" error messages humanize errors, showing them that there was indeed someone who made that page they are currently on and not just some soulless computer and thus making solving the problem much more approachable!
Example 1: Chrome's dino page is actually great! Grandma doesn't fear it or call me out of panic the moment she sees it. Imagine if she got something like the default Apache 500 error webpage.
Example 2: the new BSOD. I saw on some other thread that some people hate it, but I think it's clear and directs the inexperienced user to what they could at least try to do
Here I was thinking that the very same group of people that think sl is a funny command line program wouldn't appreciate humanized error messages...
> I actually from a less technical person's perspective, "cute" error messages humanize errors, showing them that there was indeed someone who made that page they are currently on and not just some soulless computer and thus making solving the problem much more approachable!
Yeah, I don't have any problem with "cute" error messages as long as they also contain all the info someone would need to identify the problem and if possible solve it. it's not the "cute" that's the problem really, it's the frustration and the lack of direction that usually comes with them.
In the python shell, `exit` is a string containing a message to the effect of "You can leave the shell by sending EOF (CTRL-D)".
I've seen HN commenters express extreme outrage over this ("They obviously know what you want to do, so why not just do it?!?!?"), but I love it. The first time I got that message, I considered it incredibly helpful, because sending EOF will work on any tool that reads from standard input, not just python. I hadn't known how to do that before the python shell taught me!
Readit News
I really hate the way the "Gah" wording feigns shock, as if Mozilla are also inconvenienced alongside me. Then the meat of the error implies I am at fault. It's my tab that crashed, and I caused it to happen by doing whatever I did on whatever page I was choosing to visit. Any blame is deflected away from Firefox itself.
Then it makes me feel doubly bad because I immediately realize I'm getting upset at something incredibly trivial, but man it annoys me!!
It's a very caveman-esque "gah, thinky box no work" type expression, or surprise "gah! wtf just happened!?"
Not trying to invalidate what you feel - just trying to share a different perspective. Perhaps a nudge to give the devs the benefit of the doubt that they don't want you to feel bad things when using what they've poured a lot of energy into.
Then again, I'm from the age when the internet was still fun, and everything didn't have to be corporate, uniform, serious, and boring.
None of that matters, though. We're looking at this like developers do: From a distance while not being personally affected by it in the moment.
The article discusses this point:
> What seems fun and light-hearted in your office may read very differently when you’ve just ruined somebody’s day.
They use examples of transport, telephony, and finance; all three of which may involve the browser.
The author also acknowledges it's okay to be fun:
> There’s a place for humour and levity in software, and my code has plenty – but error messages are rarely it.
You dial a wrong number. Which do you prefer to hear
This, https://www.youtube.com/watch?v=aTNthUcvyEM
Or this, https://www.youtube.com/watch?v=6qzr-V-ttZ8
If you're just trying to call a friend, and you put in a wrong digit, the fun response might be a brief chance to have a good laugh at yourself, but, if you are doing something like say trying to call a doctor to ask for lab results on a cancer screening, or you're trying to call the bank to report a stolen credit card, and you get the wacky "Whoops! Looks like you you need to get a dialing wand! lol"[1] response, it is not going to be well received.
I guess what I'm trying to say is that a joke message can have a certain place, but I think that it means the developer has to take some time to consider "Is this ever going to be used for something serious or time sensitive?" If it's just a small project, who cares? But if it's going to be used by more than a friend group, or a niche circle of 100-500 users, it's probably better off left in as a joke comment, instead of a user-facing error message.
[1] https://youtu.be/npSVS9CJyPc?t=20
I generally just want things to be genuine. With error messages, that should be no-nonsense - when software crashes, I'm not interested in how verbally clever the vendor can be.
Remember your cutsey expression of your individuality might be cute the first time your software crashes, but after the 100th crash, doesn't come across quite the same way.
>When I was a child, I spoke as a child, I understood as a child, I thought as a child: but when I became a man, I put away childish things
The current generation of engineers didn't get the memo.
The file/edit/etc menus are data. Concise, clear errors are data. "Gah. Your tab just crashed" is copy.
Like fucking seriously, not even "Hello"? "Hi" is how I greet the coworker I don't really even like that much. Whenever I see this I think of the Argonian NPCs from Oblivion, who would also greet you with a very flat "Hi"
"Greetings," "Salutations," even "Welcome!" would be a better choice here.
And this is why HN shouldn't be taken seriously for user-facing design decisions.
If the greeting is going to be tonally inappropriate, why not go all in, right?
Interesting. Sounds like I should stop saying "hi." That is the default in my native language but I work in an American company.
The "All your things are just where you left them" during a major upgrade? That gives me the shits.
The computer for me is like the co-worker that does almost, but not exactly what I'd like it to do except when they do, the guy thats a little awkward when you run into them in unexpected situations, but he works pretty hard and works at least as many hours as you do.. except when they don't.
this is what you choose to complain about? your life must be exceptionally trouble-free.
"Just run dism and sfc /scannow. It will surely fix your problem. Kindly mark my response as the answer."
I think it shouldn't be done for dev tools of course, because devs are the ones that need to see the errors.
Deleted Comment
> "Can websites please stop the trend of giving error messages that are like "OOPSIE WOOPSIE!! Uwu We made a fucky wucky!! A wittle fucko boingo! The code monkeys at our headquarters are working VEWY HAWD to fix this!" And just give me a fucking error code so I can try and fix it"
Tweet is SFW, but artist draws NSFW furries
0. https://twitter.com/cherrikissu/status/972524442600558594
If the “code monkeys” are working on it, what’s the user going to do about a crashed database or any other server-side error? If you can do something to fix the issue, the app will usually give you that information.
Of course, the app might be clearer and tell the user to retry or contact the administrator. But a generic error message usually implies server-side failure anyway.
Perhaps this person expects to receive server credentials as well?
If you log the API calls and debug it yourself, you will be able to find the stupidity and delete/fix/move whatever errant file is causing the issue.
So often, literally returning the raw API return value in the "Something went wrong" window would be the best information to provide.
It's laziness, it's devs thinking "Users are stupid". It's NOT hard to put a checkbox in the settings somewhere that says "show advanced error details" if you are so damn terrified of average people seeing "Scary" error messages.
This lets us quickly triage new errors (since known user errors are kept out of the main error log) and presents an easy way to convert logged errors to unlogged ones when we've determined the source of the issue (assuming it's an exception we're comfortable with - a lot of our "user" errors are server-side validation that should be prevented by client-side code).
It also forces any errors that we haven't specifically marked as human-readable to render as "Internal Server Error" which we hate along with supplying an easy route to provide a more meaningful error message.
I never, in my life, want to read an error message that starts with "GuzzleHttp encountered a malformed response from aws. ..." nor do I ever want to see "[SQL1002] The newly inserted row would violate constraint widgets_name_key" - write good errors.
'This is awkward! Something went wrong and it's probably our fault :-('
is much better for users than
'Unexpected error occurred in logTicketResponse'
And no, it isn't sufficient, but it is better. Providing useful error messages is really hard (and it sounds like your application does a good job of it), and we as software developers are not very good at it.
For everyone who complains about the cutesy error messages, how much time are you spending in your own code to provide useful error messages that explain the problem and suggest resolutions?
A bullshit error message on the other hand not only makes searching useless but also prevents the user from exploring towards a solution since they can't even tell different errors apart if they have the same generic message.
I prefer this one, despite the fact that users might like the "cutesy" option better. If the user creates a bugfix ticket, the more information the dev receives the better. When you receive a ticket that says "_____ didn't work" and nothing else, how are you supposed to act on that?
When possible, error messages should include _something_ anything to make it actionable. An error code, a descriptive message. Your example tells me exactly where to look in the codebase. I don't care about the verbiage, but generic error messages are almost impossible to reproduce in many cases, and should only be used as a last resort.
I believe software should explain itself to the user. Even if the user may not understand.
If you feel uncomfortable telling the User What you're doing, and Why you're doing it, you probably Shouldn't Be Writing It!
If everyone did as much, there'd be entire classes of software (and the ethical bad juju that comes therewith) that wouldn't have been written.
Would be pretty cool.
Follow up email with say $1 credit and and explanation later “our technical team is looking right now to fix the problem you had today caused by our systems” would be cool too.
I am glad I read the post to make me think more about errors.
Errors are tricky: an exception can happen in so many different ways in the app and you have to write code to convert some unexpected thing into a bold plan for the user. It is like codifying a crisis leader!
I think that it has its place, but, like so many cultural artifacts, needs to be done very, very carefully.
Humor and colloquialism doesn't usually translate. That's not just between languages, but also between cultures. Canadian humor may be lost on Americans, and vice-versa.
The users of a product are often of a drastically different culture from the creators. It's quite possible that "folksy" stuff from the creators, meant to be comforting and approachable, is perceived as "condescending," or "patronizing," to the end-user.
Also, error reporting is an extremely sensitive area. Often. the user is under a lot of stress, and can feel intimidated by the product (and, by extension, its creators).
Some developers may feel that "puts the user in their place," but I'd argue that may not be a desirable outcome. I like the users of my stuff to feel comfortable, and in control of their user experience.
I have noticed that there's a pervasive disrespect for users, in our industry. In some cases, it comes down to naked hatred.
I guess, if we look at the users of our products as cattle, to be fattened, sold, and slaughtered, it's inevitable.
Then I remembered fiddling on Macs as a kid, if you screwed up you’d see a bomb. If you did something really wrong you’d get the mac icon with Xs for eyes.
The point being: cutesy errors are about as old as personal computing, but they do seem to becoming more prevalent.
He did have a point; the programmer obviously knew what was intended, but instead of just leaving it to a generic syntax error he went out of the way to have the computer be snotty. But the rage still seemed wildly disproportionate to me.
Years later, John Scalzi had a good way of putting it: "The failure mode of clever is asshole." [2]
[1] https://en.wikipedia.org/wiki/Kermit_(protocol) (I'm pretty sure it was this. It has been a while!)
[2] https://whatever.scalzi.com/2010/06/16/the-failure-state-of-...
Last night and this morning I was locked out of my email because Duo wouldn't text me a 2FA code. There were no other options shown, just "we sent you a new code" and a phone number for the help desk. It was frustrating and I was upset, but at least they didn't show a sad cat with a bandaged paw. At least I was able to talk to a human, because my problem was important to me.
It's not just that they're more prevalent, but as computers become increasingly necessary it's more and more likely that bugs are causing damage. We should be more conscious of that fact.
What's much worse is that it shows the screen for all of three seconds before automatically rebooting (at least for some errors), so you need to go through at least two or three boot cycles just so you can read the goddamn fucking error message. I used Windows for the first time in over a decade last week and had some issue with the disk, and it just kept rebooting and I had to quickly snap a picture so I could read the message because by the time I could orient myself on the screen it was too late. I cannot comprehend how anyone thought this would be a good idea. I cannot even comprehend how someone could comprehend it. :( indeed.
Instead of being able to search "errornumber appname", you're stuck with a pastel picture of some cartoon character shrugging and text of "whoops! something happened. why don't you try restarting?"
Are you referring to Teams, by any chance?
I don't mind them being artsy, but if that's a replacement for the actual detailed error message, it both makes the user and the people trying to help helpless.
Imagine helping someone over the phone or in person; e.g. if you can see "error 10060", you know instantly that it's a network connection problem. If it's an access violation ("illegal operation" was unfortunate but still far more informative terminology) or a c0000005, the application probably messed itself up. You can ask people to read you error codes or search them yourself (being sure to quote them --- the horrible vagueness of search engines is another rant I won't get into here, although it also adds to the problem...). If all the application says is "something wrong", no one can help. All but the extremely perceptive could as a result be easily mislead into reinstalling the application, reinstalling the OS, and all manner of other stupidly destructive and ultimately futile actions, only to find out that the problem was ultimately due to something else entirely.
Back when I worked at a computer shop I've had customers come to the shop with a hand-written report of the Windows XP BSOD message; like, all of this.[1] They were always very nice people by the way.
Also, all the text is boilerplate and 100% irrelevant to the actual error (UNMOUNTABLE_BOOT_VOLUME). It's not going to be fixed by a Windows update (which you can't install since you can't boot the thing) or disabling "caching" BIOS options. Not showing any text instead of that is probably better. It wouldn't be too hard to make a error message → useful description map for common problems like this, but good error messages/help was never Windows' strong point...
[1]: https://neosmart.net/wiki/wp-content/uploads/sites/5/2013/08...
I think prevalence is important here. Everyone seems to be injecting cuteness into everything today. Blog posts or README files overflowing with emojiis and meme images. I'd really like to banish the rocket emoji. The metaphor is exhausted. The corporation-as-a-friend is everywhere.
Interestingly, some errors started out life as deadly serious and only became humorous later. "lp0 on fire". Printers used to really catch fire. Unix really was suggesting that maybe you want to look into that. The message still exists in Linux (as far as I know), but today seems rather funny to some people. Or can read like PC LOAD LETTER[1] to others.
[1] https://www.youtube.com/watch?v=5QQdNbvSGok
8===D
I feel like I don't see this emoji very often in READMEs
Keep in mind that each iteration required a reboot, and this was at a point in computing history where booting a computer filled with specialized publishing & editing programs each with their own hooks into the OS was a task that could be measured by the length of an extremely generous bathroom break.
And all I had to go on for error messages was a bomb and the number "-10 error". I hated that bomb. I don't think I fully recovered from the trauma & stress caused by unstable OS's until well into OS X's life and a few years of Windows 7 on the MS side of things.
And yes, this is my digital equivalent of the previous generation's "I had to walk 10 miles to school in the snow up hill, both ways"
However, the author described a case where an app messed up its auth flow. It knows exactly what went wrong, and it could easily present a much more helpful description. Who knows what a token is, or what headers are? Maybe it could even just try the request again, all while keeping the client informed. Instead, the app seems to have a simple try/except that handles the error by alerting the user with a cutesy message and dev-speak and nothing else, which is pretty annoying.
I also think any image is better than an ironic/snarky iphone alert.
Could it? The error in question sounds like a programing error. Either the client application did not provide a token the backend was expecting, or the backend lost it. What usefull error can be provided here other than “pray someone prioritises this bug and fixes it in the next release”? Or perhaps “think hard about what is so unusual about your usage or setup that you have fallen off the happy path and reached a state QA didn’t catch yet”
https://static.wikia.nocookie.net/ipod/images/3/39/Sad_mac.j...
(Link works without referer only.)
EDIT: wait, wtf, I did the above once - and now it works when I click it. Go figure
At least this example gives you something that you can report to support of you do contact someone about the issue. It if you are a bit techie you might be able to judge for yourself if trying again is worth it or a waste of time. Many issues don't even give you that much.
I have come to believe that many (most?) engineers and user experience designers actually hate people. I was recently in the western U.S., attempting to get information from a ski/bike resort about mountain biking there for the day. This was no two-bit, small town resort. The website was absolutely terrible. Links to basic information led to 404 pages. And today, my wife and I were looking for information about our local museum's free teen membership program. On the info page, there was a large button with text "Apply Online." Clicking that button led to a form that could only be printed. There was no way to actually "apply online."
I've been working in the industry for almost 25 years. One of the most important things I've learned is that no matter "intuitive" the user interface seems to me, an engineer who likely has the various workflows burned into memory, you either need to have someone with NO experience look at the UI or, at the very least, have the ability to look at the user experience through the eyes of a non-tech-savvy user. Or, even just an engineer who just wants to download a trail map, or apply so his kid can get into the museum for free.
Do you really intend to put links into error dialogs ?
Faced with that dialog you're already pissed, the software disappointed you and you now have to take an extra action (push the button) to even continue using the app or try again.
Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it.
I find the author deeply disingenuous in that we have the emotional rant, but not what they actually did next as a user to solve that issue. Did they just refresh the page, the request resent and everything went well ? Did they send a "WTF?" angry message to support, who tracked their session from their username and made it all good for them ? (and yes, Trainline has really good support for the industry they're in)
I mean, it might as well be that the app auto-resent the request and solved the issue without the user doing anything, and we'd have not idea. That error message probably was there just to state it failed at a specific try, and further action depends on what's happening next in the app.
This is true, even of other devs which is particularly annoying¹². But these days I have the luxury of not dealing with clients directly so can just close things with insufficient information as CNR and move on, and have the joy of colleagues who make better use of the brains they have!
Sometimes the only solution is ample telemetry and hoping that the user can give your a reasonably accurate time of the incident when making a support call so you can reference that information. Though this can't help as much with client side problems that block the telemetry getting through, what information you do get can help greatly with reproducing, or just walking through with reference to the code, the issue, to work out what has gone awry.
> I have come to believe that many (most?) engineers and user experience designers actually hate people.
While I do occasionally work on front-end matters I'm usually not a UX person these days³ so I can't speak from that angle, but yes I do dislike a lot of the general populous! I think the problems you describe come from a position of disinterest rather than hate though, and a sign that a more varied team is needed. You need someone who is passionate about providing a good UX rather than playing with clever things and making stuff technically work. You also need a culture of taking care over your work too rather than doing minimal happy-path testing then throwing it out there⁴.
> One of the most important things I've learned is that no matter "intuitive" the user interface seems to me
I can't remember who said it, but I've always liked the quote “the only truly intuitive interface is the nipple, everything else has to be learned”. As you suggest, it is important to try put yourself in the mind of someone who is hitting your work for the first time without any of your experience, which can actually be quite difficult to do reliably. The other difficulty is the range of users any given application might encounter: sometimes you have to balance guiding the inexperienced, without hindering those who don't want to be bothered, preferably without effectively having two complete UIs to maintain.
--
[1] being interrupted with “I'm trying to X and I'm getting errors” “What errors?” “Something about the database, I didn't take a note” (to which the answer is “well reproduce it and come back to me when you've got useful information”, but by this point I may have lost concentration on what I was working on).
[2] One of the most annoying people I've worked with once said in response to me asking for the usual details, in an exasperated tone, “you always ask that” - the idiot was well aware that the information would be required and got irritated at it being needed instead of actually bothering to note it.
[3] I used to do a bit of everything in smaller companies, as things have grown I've specialised more towards database work, and infrastructure to support other devs.
[4] Though we have a full QA resource, we spend plenty of time doing “devtest” and making/updating/checking automated tests. QA (or in companies without that resource, the users) shouldn't be finding glaringly obvious issues because I rushed through one test case and didn't even think about anything closer to the edges.
> "MySQL server has gone away"
Gone away? You mean like it packed its bags and hopped aboard a train to another town? Surely you're not trying to say that the connection timed out or anything more specific.
It's a sign that something has gone wrong on the server side, but it's impossible for the client to know what that is. Especially because most of the time MySQL connections are each a thread and there may be time between when something server side terminated the thread and when the client tries to talk to the server again. It's better for the server to release all the resources immediately instead of waiting for the client so it can return a more helpful error message.
Example 1: Chrome's dino page is actually great! Grandma doesn't fear it or call me out of panic the moment she sees it. Imagine if she got something like the default Apache 500 error webpage.
Example 2: the new BSOD. I saw on some other thread that some people hate it, but I think it's clear and directs the inexperienced user to what they could at least try to do
Here I was thinking that the very same group of people that think sl is a funny command line program wouldn't appreciate humanized error messages...
Yeah, I don't have any problem with "cute" error messages as long as they also contain all the info someone would need to identify the problem and if possible solve it. it's not the "cute" that's the problem really, it's the frustration and the lack of direction that usually comes with them.
I've seen HN commenters express extreme outrage over this ("They obviously know what you want to do, so why not just do it?!?!?"), but I love it. The first time I got that message, I considered it incredibly helpful, because sending EOF will work on any tool that reads from standard input, not just python. I hadn't known how to do that before the python shell taught me!