Cut the cutesy errors
alexwlchan.net
alexwlchan.net
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!!
The file/edit/etc menus are data. Concise, clear errors are data. "Gah. Your tab just crashed" is copy.
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.
Sterile, professional, and uncaring is a heck of a lot better than a chunk of the user population thinking "it's worse than them not caring-- they're actively mocking our complaints/problems!"
I'm not sure which form I actually like better. The mental image accompanying the misparse amuses me.
>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.
You make poor assumptions. I was banging out code for a chemical company on a green screen Wyse terminal and sending e-mail with bang paths.
Does the Internet need to be regulated like industrial control devices? Should we get permission from AT&T to certify what we can connect to the network?
The Internet is a tool for everyone, not just gray-beard, elitist gate-keepers. There is room to experiment, make mistakes, and even harmless fun.
Keep in mind Firefox is the least corporate of all major browsers--recent CEO shenanigans not withstanding.
EDIT: > You were 12 using the hard work of a generation of engineers to surf geocities without knowing it.
Um, so? Thousands of generations of inventors toiled away for you to even touch a computing device (fire, argiculture, rule of law, professional armies, enlightenment, vacuum tubes etc.)
Either way, I don't mind cutesy messages so long as they contain at least a code which can be traced back to wherever an exception was thrown or whatever. The main problem is generic error messages which are a problem whether they're cutesy or not ('an error has occurred').
Oops, as a bunch of well-payed professionals we messed up but look at the thought that went into the copy that covers our butts...?
When software fails we failed. Stop with the lipstick on our collective incompetence.
Ah, you've seen the view from their SF offices.[1]
[1] https://earth.google.com/web/search/@37.78972221,-122.388833...
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.
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.
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.
If the greeting is going to be tonally inappropriate, why not go all in, right?
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.
Perception is a bitch.
If I had my way we'd dispense with all these stupid pleasantries. My computer is not my friend, Windows is not my friend, and Microsoft and their awful marketing droids (who almost certainly guided their choice of words here) are most definitely not my friend. Who decided that Windows needs to talk to me like a middle-aged soccer mom (or an argonian shopkeeper)?
Nothing wrong with "Welcome", "Error 404: File Not Found", "Bad command or file name", etc etc etc. (Ok, maybe the last one is a bit cryptic, but it is telling me exactly what went wrong without any fluff, which is how all software should be.)
Computers are our servants, not our friends. They should act like it, and we should stop trying to humanize them.
Why is formality any more natural for a user interface than casualness? This seems like an extremely arbitrary personal preference masquerading as reasonable criticism, no different from getting riled up about the fact that Windows default theme is blue when it should _obviously_ be green.
> Computers are our servants, not our friends. They should act like it.
I had a live-in housekeeper for a chunk of my life, which is roughly as close to "servant" as one gets in the modern West; we communicated in normal, casual English. If you are going around insisting that service workers address you like an aristocrat, you're an enormous asshole.
In fact, if you have a servant at all, YOU are an enormous asshole. Nobody should live in the shadow of someone far more privileged than they.
Is my computer my ally/confidant, or is it trying to control me from the shadows?
An ally does not behave in the way that Windows has been programmed to behave. It should be straight and narrow with me when something is wrong. Not friendly and fake-diplomatic.
Once again, we are shown an example of how business greed and the desires of average, illiterate users ruin computing for the people that understand them and are capable of making the most with them -- the power users. Of course, rather than spending the extra effort needed to elevate ordinary users to a more literate status, we happily stoop to their level as it makes obscuring the various telemetry and profit machinery embedded in Windows far easier.
I have a very hard time believing that Microsoft cares at all about avoiding giving users the appearance of a hostile relationship with their own device. So many choices they make (or take away from us) are way too user hostile for that to be their concern.
They have no problems making it painfully clear that if you are running windows then the device you paid for belongs to Microsoft and they will dictate what it does whenever they want, along with what you are or are not allowed to do with your own system.
A user shouldn't be victim to the whims of some far away UI/UX designer who only designs for what some data fortune teller thinks is their "average user". Computers are machines, designers need to stop anthropomorphizing them.
At the very least give me options to switch that crap off.
PS: But by far my main gripe with the "modern" UI philosophy is: a "No" means frigging *No*, it doesn't mean "not now" or "maybe later", I also can guarantee that I won't change my mind (and if I do I will find that option in the settings window myself, thank you). Not offering a simple "no" in a yes/no choice is an insult to the user's intelligence, it's as simple as that.
I remember getting a mac to "blue screen" back in 2008 or so, by repeatedly plugging in a Logitech mouse while pushing its buttons down.
If you're going to get all up in someone's face and demand their complete attention, there's a high bar for expected politeness, or at least some entertaining wit. "Hi" is just lazy and conceited. "Welcome. Please wait while we prepare your desktop," would be tolerable. A Maxis style status bar rambling on about "reticulating splines" would be funny.
To relate it to your experience with a housekeeper, if a housekeeper shouted your name from across the room, tapped you on the shoulder repeatedly, and then unplugged the TV you were watching to get your attention, you would expect them to say something like, "my apologies sir, the den is on fire," rather than, "lol, howdy."
A computer isn't a servant, though. It's a tool. A circular saw with a sassy personality means a trip to the hospital...
You're talking about something completely different, urgency rather than formality. In the rude interruption example you gave, you combined the two despite them having nothing to do with each other. "holy shit bro the den is on fire!" would be an infinitely more appropriate reason for a rude interruption than "my esteemed sir, how goes your day".
As I said, it's an arbitrary aesthetic preference. GP's irritation that computers dont address users as aristocrats makes just as much (little) sense as getting angry that they don't shower the user with compliments about your appearance.
Like, it's cool if they're into that, but it's super weird to describe it as a general principle of UIs
>> "Hi" is how I greet the coworker I don't really even like that much
So you're saying they nailed the pitch perfectly.
Seriously. It is the one thing that if I didn't need a Windows test system, I'd reject it every damn time just for being there. In fact, if they were a human, they'd be kindly asked to evict themselves from my domicile in perpetuity.
I had totally forgotten about how obnoxious Cortana was (I always turned that shit off first thing), or the condescending text that accompanies large updates requiring you to re-certify that no, you don't want to use Microsoft Edge, thank you
Don't even want to imagine what Windows 11 is like, none of my PCs can run it (thank god)
This piece focused on a machines appearance, but later they comment that really what's at the root of peoples issues (the people that have them) is that they resent the anthropomophizing of machines in general - which I would take to include speech.
I maintain a build system at work, and I have it display an ASCII nuclear blast when folk pass in command line arguments that are known to be "dangerous".
I realise I'm supposed to think it's charming but it's always made me cringe.
The "All your things are just where you left them" during a major upgrade? That gives me the shits.
Interesting. Sounds like I should stop saying "hi." That is the default in my native language but I work in an American company.
But seriously, hi is fine. There's nothing wrong with it. I personally think it is friendlier than hello, and it is certainly more efficient, which is why I say hi in Germany when people say "hallo" to me. Like, seriously, 2 syllables to say hi? So inefficient.
If you’re lucky, you get English string IDs (and not Chinese or numeric ones). If you’re lucky, the list is complete and in order (and not stripped down to only the untranslated parts so you don’t see how much the agency is avoiding paying you). If you’re lucky, the customer has an localizaton QA department (i.e. a couple of guys per language) which will walk through the UI to try and find the most obvious screwups (and won’t not just merge the Trados back into the source and run the resource compiler).
Every professional involved understands it’s impossible to get a good translation that way. None of them can do anything about it, because the agency will just switch to a less picky one. The good ones try to make something of what they’re given; the bad ones just give up. Almost none of them actually use localized software; almost every one of them looks on wistfully when you show them the Gnome sources with the paragraph-long TRANSLATORS: explanations for every other string. (That’s why Crowdin and Transifex drive me into such rage, BTW—they essentially reproduce the commercial broken-by-design process for hobby developers.)
You know what the most recent innovation is? Have the translator edit a machine translation.
Give your translator something to work with. And for goodness’s sake, if you can afford it, find a couple of freelancers and listen to them—that’s who is going to do the work anyway, might as well give them the whole sum and not the ≤ 30% they will get after the agencies’ cut. (Yes, a small but sizeable portion of candidates will be blatantly incompetent and/or try to screw you over. Duh. It’s a freelancer market.)
And this is why HN shouldn't be taken seriously for user-facing design decisions.
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.
However, to someone for whom computers are mysterious and capricious black boxes which seem to have been put on this Earth solely to test their patience, "friendly" messages may carry tonal information which you take for granted:
* You did nothing wrong
* This is unintended and regrettable behavior, and we apologize
* Nothing is catastrophically broken
Consider that your mild irritation with a patronizing message is possibly preferable to some poor grandma hurling her computer out the window because "This program has performed an illegal operation and will be shut down."
Fortunately, there is infinite space to play in between "Gah"/"Well this is awkward!" and "This program has performed an illegal operation and will be shut down."
(While I appreciate what you do, hopefully this doesn't encourage you to spend time away from what all else that matters to you to write better comments.)
This is unintended and regrettable behavior, and we apologize
This is what the message should be. Maybe. I'd rather the software I use be apologetic than attempt to be my friend. That said, I'd settle for "we goofed, sorry" So it's not so much the tone (casual), but the content (own your defect, don't commiserate).
"Just run dism and sfc /scannow. It will surely fix your problem. Kindly mark my response as the answer."
"Hi, I'm Greg and I've been a Microsoft MVP for 10 years. I'm happy to help you out."
<insert robotic answer that totally does not answer the question at all>
I think it shouldn't be done for dev tools of course, because devs are the ones that need to see the errors.
I have a broken installer. I get some random error. Googling suggests I need to reinstall the software... whose installer I am trying to debug. Gee whiz never could have thought of that!
The ones where you search how to resize an image, and the very helpful guide on coolmagictech.com tells you somewhere around the 2nd step to download and run the CoolMagic® MagicResizer™ tool?
I haven’t seen one of those in like 5 years… But then again, I also haven’t used nor troubleshot Windows in those 5 years. Might be a correlation there?
Time was at a premium and the one option seemed to be one of those sketchy Windows app at an equally sketchy website where you could buy the software via cc. I explained the risks to my friend who decided to give it a shot (on a clean Windows install which was later wiped, of course).
It worked, just as advertised. We got all the data in a usable enough format. Surprisingly enough.
Recently I have this issue with my energy supplier, every time I try to change tariff in the app(like they tell you to) I just get "uh oh something went wrong". Like......that's condescending to the maximum.
> "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?
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.
Obviously the dev will have some idea of which error could have occurred (hence the use of ‘catch’ at all), but it’s not straightforward to enumerate all possible exceptions in that moment, and reason about some subset that should be human-readable, and then come up with some sort of instructions about how to fix the problem.
Maybe that’s the point of the root comment - the exceptions that the dev is trying to catch and prevent from affecting the user should have those human-readable descriptions. And the rest should be silently logged?
But that still just leads to the generic “Well, this is awkward…” errors that you see these days.
It’s a tough topic, and even having the insight of (for example) Java’s ‘throws’ still doesn’t mean the developer explicitly understands the state of the application when those exceptions are thrown (in order to provide some sort of useful message to the user).
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.
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.
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!
And probably because no one else is doing it. If every bad service you got for everything got a refund then it would be normal and I would think: "meh just a $1 refund again, why don't they damn fix it... shrug".
Tipping is an example where it is really appreciated in non-tipping cultures.
Which speaks to how marketing and "PR" need to keep up with culture and people's expectations today. If you want to exceed expectations that is.
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.
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...
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”
> Will it work if I try again? Do I have a ticket for my return journey? Should I call support? Or is this ticket completely hosed?
A good error message should try to answer these questions, because that is what the client is wondering. "Token header not found" doesn't even address the client as the audience; it's a message for a developer, written by a developer. Even if it has no solution, it should at the very least say "please contact us".
Yes, a good error message should tell you that. I’m not disputing that. I use this application regularly and it provides clear and usefull error messages when the network is down, or when you made a typo with your card details. It generally works. This, what we are seeing here is some off-nominal edge case. Have you seen code where a developer commented “// this should never happen”? That code is running there.
Should there be such a state? No, there shouldn’t be. The developers should work hard to make the applications always work, and when it can’t because of no fault of their own provide a clear explanation of what is wrong. (The network is down, the backend is overloaded, card declined, no tickets available, etc etc)
But still, bugs happen. Clearly that is what is going on here. Something violated the assumptions the developers made. What I’m saying is that when that happens it is very hard to answer any of those questions. “Will it work if I try again?” Maybe? Unless it won’t for a hundred and one possible reasons. “Do I have a ticket for my return journey?” Idk, does it look like you have a ticket? You tell me. “Should I call support?” Maybe? That sounds usefull, we want to know that something that shouldn’t happen happened. Unless offcourse we fumbled big and our phones are already on fire, in which case please don’t call support.
It is easy to say that an error message should provide information like that and a very good thing to aim for, but I’m disputing if it “can” in every unexpected situation.
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
Caching.
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.
For a server, which might only be accessible remotely, it is.
For an interactive computer, I agree that it isn't.
I believe this was a heritage from the NT series --- the 9x BSoDs just sat there and waited for you to reboot (except when things got so bad that it triple-faulted...)
For 99% of the people the error message is meaningless and the only thing they can do is restart, so it makes sense to do that automatically.
Automatic reboot isn't so bad, but just change it to a minute, or 30 seconds, or "press a key to abort reboot". An intern can do this. Hell, I'd send a patch, let me just find the Windows repo on GitHub...
But automatic reboot is a setting in the Registry, the issue is just with the default being "reboot" (I believe this was changed in XP, 2K just stayed on the BSOD by default, if I recall correctly).
The correct way to troubleshoot a BSOD isn't on the BSOD screen anyway. You open up the dumpfile in windbg and click "analyze" so it can spit out some good details for you.
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.
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-...
I like joking around a lot, but reading the room is an important skill. To me it's important that the person I'm joking with actually enjoy it. A failed joke, one that annoys them is a mistake. People who persists in making jokes that the targets aren't laughing at are not really making jokes anymore; they're just being dicks. Which can also be a valid activity, but nobody should confuse it with joking around.
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 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.
8===D
I feel like I don't see this emoji very often in READMEs
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.
> "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.
That’ll do fine
This error message is still potentially wrong and useless though. Potentially wrong: the client is in no position to judge whether the server didn't respond, the server didn't receive the request, or the response got lost along the way. Useless: "timely" isn't succinct enough, what was the developer's expectation of a timely response? 5 seconds? 30 seconds? 5 minutes?
"No response received from server XYZ after N seconds" is both more accurate and more informative.
Like those news articles which breathlessly report "nobody from the company was immediately available for comment" as if that was as interesting or relevant as a comment would have been. It isn't. Wait a couple of minutes and call them back, then report what they said. Imagine you call Comcast callcenter about your account and the conversation goes:
You: "I ordered xyz deal it but I'm still seeing the old price, can you help?"
Employee: "Sure, will you hold while I check that on the computer?"
You: "Yeah, ok"
pause
Employee: "No response received from computer after 15 seconds. Click {hangs up} bzzzzzzzzzzzz".
You: "that was accurate and informative, thumbs up"
The end user doesn't need to know whether, say, waiting 15 seconds is sufficiently generous: there are software engineers for that.
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.
Putting links in error dialogs seems like a set up for a situation where clicking that link produces another error with another link that also won't work followed by another and another etc.
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.
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'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!
And from the implementation perspective, the python shell is trying to run a simple loop:
1. Read a line of python code.
2. Evaluate the code.
3. Print the result.
Defining `exit` as the name of a string slots into that loop seamlessly. Defining it as a special keyword that is recognized by the shell, despite the fact that it has no special meaning to python, means you're no longer just reading python code; now you have to implement a separate parser solely for the purpose of handling this command.
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 think the issue with error messages like these aren't so much that they are cute, it's that while the developer thinks they are being clever somehow, these kinds of messages usually come off as patronizing or condescending to the user, especially when the user DOES have the technical skill to know what's actually wrong.
Errors should certainly be as helpful and clear as possible, but no the developers are not trying to directly attack you specifically if they aren’t, or if they wrote something they thought was fun.
Yeesh, get a grip.
If I got this error message while trying to buy a train ticket, I'd be thinking "Ok, who do I talk to to get this sorted out"
I don't understand the sort of person who stops to think "How dare this error message trivialize my Very Important Problem! I feel bad now because the words on this screen are too silly!"
That's like saying getting a paper cut on your finger is just like having your arm chopped off. There's a pretty wide difference there.
I guess if you're the sort of person to hyperbolicly exaggerate every minor inconvenience you encounter, it's the same thing. It must be exhausting to be like that.
Surgeon: " :( theatrical exaggerated frowny face Something went wrong."
Exit surgeon.
Why bother spending your time minimizing the passion someone else feels about software design?
Maybe the person who wrote the post and the scores of people who upvoted it feel this way on behalf of the countless users who get stupid error messages from carelessly designed software?
I think more people should write about the things they dislike about software. And when they do, they ought to ignore the people who ask why they're getting so annoyed about something that doesn't matter.
And don't get me started on "Sign up for notifications?" where the choices are "Yes" and "Remind me later."
It's more like: "do you want to sign up for our financial newsletter?"
* Yes, sign me up.
* No, I hate making money and choose to be poor.
They are hostile towards people who simply don't want to take their spam.
Who treats people like that? And is that how they treat people they interact with in person?
edit: I always thought this tweet was hilarious. I'm definitely not a furry though, looking through OP's tweets now that I've linked one of theirs...
I'm sure there are people who, being ashamed of being something, do go out of their way to say that they aren't. However I don't think seeing someone saying it once mean they "probably" are that thing. You can be annoyed/embarrassed at the thought of being seen as something you aren't.
I don't know the type of people who follow NSFW furry artists on twitter, but I imagine a lot of them are furries themselves. If the OP doesn't want to be associated with them then I think it's reasonable to state he isn't one.
Imagine linking a tweet about a software error message and then making a followup comment "that account posts a lot of baking content. I'm not a baker btw.". Who would think you are a baker just because you linked a tweet posted by a baker? And why would you care if anyone accidentally thinks you're a baker? You wouldn't because there's nothing embarassing for you if people think you're a baker.
So the disclaimer "I'm not a furry" implicitly contains the message "being considered a furry would be embarassing because being a furry is bad". You don't need to disclaim things which society widely accepts as bad ("that account posts a lot of murder content, I'm not a murderer btw"). You may disclaim things which feel risky if misunderstood ("they Tweet medical advice, I'm not a doctor") but mostly the disclaimers are for tribal declarations of things you would feel embarassed to be associated with ("I'm not a flat-earther like they are"). People who think those things are fine push back "Why are you using X as something embarassing to distance yourself from? You think X is bad, do you? Maybe you secretly are X and hiding it and that's why it's at the top of your mind".
It's those people using X as an insult, in the sense that the original person's disclaimer made it an insult and they are mirroring it back.
If they didn't go out of their way to disclaim it probably nobody else would have commented on it; "I checked out the rest of the account you linked and you read a furry themed Twitter account?" "no, I saw it on a programming meme Reddit" and it would be a non-issue.
>You don't need to disclaim things which society widely accepts as bad Whether you think people need to or not is irrelevant. We know that people do it, so people obviously feel they need to do so. I've seen people play devils advocate, or joke themselves as an X, and be mistaken for one before. so perhaps you do need to make a disclaimer in order to fully avoid confusion.
>"Why are you using X as something embarassing to distance yourself from? You think X is bad, do you? Maybe you secretly are X and hiding it and that's why it's at the top of your mind". Or maybe it's on the top of their mind because they unwittingly linked an account associated with X. The whole "if you don't like X you're actually X" is bizarre.
>It's those people using X as an insult, in the sense that the original person's disclaimer made it an insult and they are mirroring it back. Sure, that might be true, but it's still true the other side is using it as an insult. It's just odd since they're insulting OP as an X, whilst acting as if they're in the position of defending Xism...
>If they didn't go out of their way to disclaim it probably nobody else would have commented on it; "I checked out the rest of the account you linked and you read a furry themed Twitter account?" "no, I saw it on a programming meme Reddit" and it would be a non-issue. It's ridiculous for you to realise it's possible for people to make this assumption and also complain that someone made a disclaimer to avoid the extra discussion you mentioned. Perhaps these types of disclaimers might not matter much if you anonymously posting on this site, we don't know if OP is or not though.
"We fixed the tubes that bring you cat videos" tells me nothing.
"We worked on great content; you work on watching it" is garbage.
"We made fonts the right size now. There you go" sort of change messages from Slack treat you like you're a 6 year old.
He uses a lot of strong language, so if that's not your thing I would advise not watching it https://youtu.be/k5FcL99NuB8 :)
Edit: And it's not about error messages specifically, but I believe these points apply to error messages as well.
I once read that waitresses who initially come off as rude earn higher tips, but only if their mood softens throughout the meal. There seems to be something about “winning” the waitstaff over that makes diners reward them with higher tips.
IMO, it was a feature to have Siri come off as rude when her abilities and comprehension were still in development.
I might be the target demographic for cutesy error messages. I appreciate attempts to empathize with my pain across the gulf of the internet.
What I don't appreciate are unhelpful error messages, which seems like the main issue in the article. Like someone who keeps cracking jokes in serious or stressful situations, the devs who are both cutesy and unhelpful aren't reading the room, so to speak, applying insufficient gravity to the situation.
I'd appreciate this kind of cutesy message to the circumstance described in the article: Oops! We made an error. But do not worry! Your information is saved. Try reloading the page. If that does not work, here is our customer service number.
I’d like to know my DNS is hanging rather than something completely made up, Discord.
While you're at it, stop replacing "OK" buttons with cutesy replies like "Got it!", which are even worse, IMO, because they apply the cutesiness to my own reply.
Whilst we’re at it, cut the “maybe later” passive aggressive bullshit too.
No should mean no and not some kind of some kind of “we know best and you’ll see that with time” nannying crap.
It just comes over as ploy to rob users of control.
Error -1
These could come from anywhere.If there had been a cute message associated with the error, I could have cracked open the binaries in question, locating the code posting the verbose error, and likely found the problem faster. At least it would have narrowed it down to one DLL out of dozens.
a) if the problem is something the user might be able to do something about, explain what they'll need to do (e.g. free up disk space)
b) if not, give the user everything they can to ensure if they need to go through a support channel or search elsewhere for info about the error they can get the help they need, i.e. at least some sort of unique message or code.
c) if it's a transient error that's not the user's fault, explain that and suggest at what point they should retry (and reassure them that nothing destructive/unwanted/irreversible has occurred or will occur on retrying).
Didn't you just explain how?
> c) if it's a transient error that's not the user's fault, explain that and suggest at what point they should retry
Many times when I've sent this type of error but it's not actually transient was a mistake in misclassifying the error. So if the code doesn't actually know it's a or b, it's not surprising it defaults to c.
"Something went wrong" I don't consider as a message that provides a good experience. Actually I didn't even mind the example given in the original article "Token not provided in guest headers", though that very much sounds like a b) error, where it's not transient but there's nothing the user can do about it, but at least they have some sort of unique identifying message/code that can help support figure out the problem.
And sure, classifying errors can be tricky, and it absolutely requires following best-practices throughout the codebase to ensure that errors are passed around in a reasonably consistent manner where you can distinguish transient from non-transient errors, or errors where the user can take reparative actions. But the end result makes everything vastly better for the user and developers/testers etc., so is well worth the investment.
You're unlikely to stop being a customer because an error said "Oops! Something went wrong" instead of "Error: {fb964102-bac4-4f9e-b671-62c047cb350e}".
The developers of a certain password manager used to send e-mails to users that were full of slangy, jokey text. While that may have created a positive impression of the company for younger, native-English-speaker users, I felt that it was very inappropriate for software as important to its users as a password manager. The English in recent e-mails from that company is bland and direct, which is good.
zarro boogs foundI’m fine with whimsy, but don’t treat your users like babies by hiding away all diagnostic information like logs.
I wonder what makes techie types so ornery?
Particularly when your boss is standing over your shoulder and the company is losing money, shirts and hair.
However, sometimes we can feign 'scheduled upgrades' for '503 site down'. In ecommerce you can say 'we are re-stocking the store, here is a coupon, take a screen break and see you in five'.
But actually you might be redeploying the whole codebase due to some fire.
Another problem with error messages is how concisely they are written. Cutesy is not concise. And neither is American English. British English is just a little bit more concise, e.g. 'wastepapaer basket' vs 'bin' or 'dehydrated' vs 'thirsty' or 'parking garage' vs 'car park'.
In error messages as well as success messages you often have something like 'your thing has been updated successfully' instead of 'thing updated'.
Error messages also need to make sense if indexed by a search engine. It has to be unambiguous and specific to the software, not other software. Even if the docs are not available for the error online, you want the error message to be useful when Googled.
There's a time and a place for fun. Software doesn't have to be boring, but some of it should be.
They're already spending extra mental effort just using the software as-is; while native speakers may find a cutesy error message and just go "Huh", non-natives may not even understand that it's an error at all, wasting time.
Lot of words to express frustration when a Tweet with an image attachment could convey the same.
"Well this is awkward" is just the "header" for any error you may experience during the process with that application, and is the same thing that Mozilla does (essentially) when the browser crashes.
I remember years ago I had to answer strange tech questions from a relative when their Windows app crashed with an "Illegal Exception" message and they thought someone/thing had broken the law.
This language is effective in communicating "we fucked up" to ordinary people I think.
- John Scalzi
Firefox is intended as a daily utility for serious stuff, regardless of the name of the organization that makes it.
I will add, don't take free software for granted, it doesn't owe you anything. I think the reverse is true.
You want to know how to ease the load of maintaining open source? Make onboarding easier. That means good, clear docs that aren’t cluttered with cryptic inside jokes.
Seriously, the way they work, you’d almost think they don’t want people to get involved. (In Mozilla’s case, probably because they blew their budget on the latest resume builder.)
It would be one thing if I were asking for a special feature of the product. Here, I’m asking for something that saves your support staff from being pestered by people that couldn’t understand the cryptic docs. Why wouldn’t you want that? [1] Why wouldn’t you be thanking anyone who suggests ways to save you time?
Sometimes I wonder if noticing this kind of stuff is a superpower, because it’s in really short supply.
[1] Maybe because you moonlight as an Optimism maintainer: https://news.ycombinator.com/item?id=30294065
https://github.com/search?p=3&q=zarro+boogs&type=Code
At this point it's probably insufficiently confusing to justify the change. The most valuable piece of advice I ever got regarding error messages was "Here's what users do with an error message they don't understand: they Google it." As long as the key words are unambiguous in meaning it can actually be more harmful than beneficial to change a message like that (when people are trying to figure out why their bugzilla installs are showing zero bugs, will they lose all the accreted historical knowledge on StackOverflow for fixing "zarro boogs" issues if Mozilla changes the message?).
If it's really important that the parser pick up the string "Zarro Boogs Found", then you can leave it in invisible text, and then leave the rest of the world out of your counterproductive in-joke.
[1] But at this rate, that's becoming less likely.
Probably yes. And when they see that error and have more questions about it, many will Google "Zarro Boogs" and find StackOverflow links and various other sources.
If the text is changed or made invisible, that search pathway becomes obscured. As inconvenient as it is for making changes to published UI, unique and identifiable strings serve as a sort of "soft URL" in this era of ubiquitous search engines.
The point of a help resource is that you avoid, where at all possible, making the user need other help resources.
>If the text is changed or made invisible, that search pathway becomes obscured.
That's not how text search works.
>As inconvenient as it is for making changes to published UI, unique and identifiable strings serve as a sort of "soft URL" in this era of ubiquitous search engines.
So do you think maybe there's a lesson in here about building a culture around being opaque to outsiders? Or do you take it as an indicator to be more opaque, lest we alienate those who like scaring off the users that the project exists to help?
Sorry, I don't understand. If the user can't see "zarro boogs" on the page, why would they Google "zarro boogs?" And if they don't, how are they going to find the legacy of comments on StackOverflow, for example, that would tell them that message means no bugs were found but can be caused by a misconfigured backing store?
> So do you think maybe there's a lesson in here about building a culture around being opaque to outsiders?
In an era where global text search utilities can clear up any confusion within 5 seconds, I don't think that error message teaches us a lesson one way or the other on the question of opacity. It's not a choice I would make for my own project to maximize adoption, but I've never gotten the sense it hurts bugzilla's adoption (the biggest competition I've seen for bugzilla these days are options like Jira that don't require self-hosting the installation, which is a far more significant feature axis than whether the error message is funny).
the comment section here should be renamed the "complaint section" and the "add comment" button should be changed to "add complaint".
you people complain more than I do, and that is a powerful fscking statement because I complain a LOT.
We had an error page at a previous job that had an <h1> OOPS!. Not sure who made it, but they didn’t think much of it, and a lot of users really didn’t like it.
This works especially well for parsing data, as you can write most of the parser completely oblivious of previous errors and keep on truckin'. The top-level parse routine will surface the first lexicographical error. The code is very clean but still gives really good error messages (and multiple! I used this for the Virgil parser and entire compiler).
They also had the ActOfGodException for things that should not happen…
Anything that gets near prod has errors in complete sentences which suggest what might have gone wrong, where to look, and so on.
it is annoying because I am likely reading the page because I am running into issues so I am already frustrated.
"simply" implies that the issue that I have is so simple to fix and that I'm stupid for not knowing how to do this simple thing
however, most of the time there is some backend or unexpected error and their "simply" advice just doesn't work.
I hate it
Life would be rather dull otherwise.
"GramError: Don't spend too much time thinking about where to put your commas."
"TeachError: Did you read the instructions?"
"HistError: <on this day history fact>"
"Kerror: I'd like to speak to the sysadmin."
"NetError: HSOCK_WIND_ERR_NO_BIND_4_6() expects to be understood."
"TsundError: It's not like this means anything, idiot."
No explanation for the limitation, no apology, no workaround, and no mention of what the damn limit is! Infuriating.
Don't patronize your users.
The computer isn't doing a thing. The user isn't doing a thing. The vendor is doing the thing, using the equipment they've got in your home.
"Something went wrong!" is something I see a lot of engineers do. I don't usually call it out but it bugs me whenever I see it.
Although I guess it's fitting, in a sad kind of subversive way: the technocracy's desire to infantilize and make dependent as many people as possible.
Even something simple like “the request timed out” helps the user troubleshoot and rules out entire classes of errors
That rant also focuses on the emotional state of the author upon seeing the dialog, doesn't explain how the issue was solve, nor what actually happened next in the application.
Looking at the Twitter thread the author is a software developer, and it feels kinda endearing that they're exhibiting exactly the behavior they're ranting about.
At least it contains the suggestion of being more serene about the whole affair.
1. Tell me accurately whether trying again will accomplish anything. Don't say "try again in a few moments" if the error is essentially fatal. Your summer intern's flaky microservice can't keep up? Then sure, go ahead and tell me to roll the dice and hope to get luckier on the next submit. But if my session has expired, don't keep showing me the button that you know requires a valid session to succeed.
2. Similarly, if I need to do something differently to succeed, then tell me what to do. Don't just say "Sorry, try again." If it's my auth error, then tell me to try different credentials. If it's your transient error, then tell me so. Don't make me play 20 Questions with your form submission flow. (Yes, there can be security reasons why you don't want to reveal exactly what's wrong with a bad request. You can still provide a better experience than Human Binary Search.)
3. Are you seriously going to make me press this button again and again for the next 10 minutes? Isn't repetitive activity exactly what computers are for? Sure, there's the risk of your clients DDOSing your server when something goes wrong. But that's what exponential and/or randomized backoff is for. It's insulting to distill your entire UX down to the world's worst CAPTCHA in the form of a single "press me again for an unknown number of times" button. Press it for me, and tell me when you did what I asked!
4. I'm looking at you, every smart speaker ever. "Sorry, Spotify couldn't fulfill that request." OK, but do you think that means that I changed my mind about wanting to hear the song? I feel a special kind of rage knowing my Alexa history has five consecutive "Alexa, play Dolly Parton Here You Come Again" requests, spoken increasingly stridently each time. It's like Rant #3 but making me write out the request in crayon rather than press a button. If you're actually an assistant, then assist me by hiding Spotify's endless spurious errors from me and taking care of them. Don't make me fill the 60 seconds of silence by shouting louder and louder at you. Tell me "I'm sorry, Spotify is having trouble with your request. I'm still working on it." Then play the damn song.