I feel like the severity of the error warrants different responses. The more critical the error, the more apologetic? Seems like unnecessary bloat in most cases.
Given the reference to "your administrator" the user-facing sorry seems fine.
IMNSHO, dev-facing error messages bifurcate:
- errors for unsuitable input should not be apologetic:
"inconsistent def'ns at foo:42 and bar:69"
- errors for implementation limitations may be apologetic:
"sorry, at foo:42 node bar has 69 attributes; this implementation supports at most 63"
it depends in large part on who you impute the speaker of the error message to be, and who the listener
if i say to you 'i'm sorry my email was so long' that question doesn't arise; you know who the speaker is and who the intended listener is. similarly, if your browser says to you 'i'm sorry my email was so long', as it is doing as you read this, hopefully the surrounding context contains enough information to identify the purported speaker and intended listener. (i'm sorry my email was so long!) it is 'quoted speech', as when lisa says, 'and tanya was all, "i'm sooo drunk right now! oh my god, i'm like sooo sorrryyy!" and we laughed'; lisa is not apologizing, tanya is.
but what agent does a running computer program represent? or, on whose behalf are its error mesages speaking?
— ⁂ —
in the case of, for example, a built-in macos program, this is clear: it represents apple, the corporation, a fictitious collective identity like the dread pirate roberts, anonymous, or bourbaki. in exchange for your money, apple is providing you a service by allowing you to run that software on the computer you nominally bought. the computer program, written or at least patched together by apple programmers, speaks with apple's voice
therefore, if apple cannot fulfill your request, it would be polite for apple to express regret, in the program's error message, for letting your hopes down. perhaps it could include a link to the web site where you can purchase the permission to use 'your' computer to think the thoughts you are not currently licensed to think in it. this applies generally to proprietary software that you are not allowed to fix, as vanderZwan suggests. (even if you can figure out how to fix it, apple is responsible for making that unnecessarily difficult by, for example, not supplying you source code and checking executable signatures.)
— ⁂ —
traditionally, though, on conventional timesharing operating systems like unix, the programs are considered to be an extension of the user's mind, as a bicycle is an extension of their body, and thus they represent the user's agency; they carry out the user's own will, not the will of their programmers. a program that carries out the will of its programmer, where it conflicts with the will of its user, is considered a 'trojan horse' or 'malicious', with narrow exceptions; and strong social sanctions are attached to distributing such programs. the protection mechanisms in the operating system simply assume they don't exist
so, in that social context, if a program is speaking to you, it is speaking to you on your own behalf, like a note you have left yourself in your day planner. perhaps tex does not have enough string space to interpret a given document, because you compiled it to have less string space than that, or perhaps you chose to use a copy of tex a colleague of yours compiled, to save the time and disk quota of compiling it yourself. that is no different from your example of contradictory declarations in the input; all that is needed is pointers to the mutually inconsistent limits (ran out of string space at bar.tex line 5329, string space size is defined in foo.web line 30213, compiled on 01994-10-31 from the source tree in /u3/schaker/new-tex)
should cannondale apologize to you when you fall off your bicycle, or arrive late to a meeting, or ride into a slum and get mugged? if you open the kitchen cabinet to get the table salt, and find that you have left it in the dining room, will you apologize to yourself? when you reserve time in your day planner for a meeting you expect to be unpleasant, does the calendar entry begin with "i'm sorry"? should don knuth apologize for not making the string size allocation larger? surely not. even schaker probably should not; if you want a larger string size allocation, you can recompile tex yourself ...
IMHO, super users are annoyed by the humanized responses. I don't want to see the error almost teasing me after I tried to accomplish something. Feels condescending. Especially the ones that start with Oops, Oh No etc.
“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 don't think users should be mollycoddled either, because that would be patronising more advanced users. It's just a matter of not making them sound too terse and abrasive.
Better still, have a failure condition that is symbolic in some way, or enforces certain intuitive interaction via the UI, instead of pushing error messages in people's faces. A good example of this, typing the wrong password in the macOS login shakes the password field, rather than displaying "INCORRECT PASSWORD!". That sort of thing.
I really wish it didn't need to be asked. Be polite, professional, respectful, succinct, and for the love of god don't try to be cute. Is that so hard?
Honestly, no. An error message shouldn't apologize. A good error message has the following conditions:
* Concise. ("You need to enter a number in this field, not text" = Good, "we're very sorry but we can't understand it if you write your age in text" = Bad).
* Clearly telling the user what went wrong without relying on technical jargon. The line number where something went wrong doesn't need to be in an error message; it's not something the user can do much with - keep that in the crash dump. The DLL name you're missing probably should be if it's from a runtime.
* Providing a means on where to find a more detailed error message/who to call to fix it if the user can't fix it themselves, with the right information to supply that person. ("Please call your administrator for help and use code ERR_CRAPSHOOT (128)" is good, "We're very sorry" with a ton of warranty warnings and a way too vague error code that can indicate a ton of similar errors is bad.)
* Avoid the notion of just reporting everything to some backend endpoint and giving the users no indications of what went wrong; this is only frustrating to the user, no matter how many apologies you put in the message. It's an answer that amounts to "your message is very important to us, please hold the line".
Do you imply ill intent upon the program? Because I read this as a violation of tone.
I interact with the program because I want/need to. It's in my interest to follow through the *instructions* to interact with it correctly and efficiently. I can follow instructions and view it as a helpful hint.
How about entering, say, a printer configuration. These fields accept only SSIDs, IP addresses etc?
> "You need to enter a number in this field, not text."
Error messages this general become slightly annoying when the app doesn't respond intelligently to all possible scenarios that its wording might imply.
For example, if the field only parsed numeric digits, and failed on inputs like "12.5" or "3e1" because they contained the characters "e" or ".", then they should have written something like "Only numeric characters are accepted," or "The number must consist only of digits (0-9)," since it rejected valid numbers. The app is saying I need to enter a number, but I did enter a number, and it's just too primitive to recognize it.
I actually find these to be irritating if not kind of offensive. (Like the "we are experiencing larger than normal call volume" that literally always plays.) Who exactly is sorry here? The computer? It doesn't (yet?) have feelings. The engineers? They're not telepathic, they have no idea anything just happened to you, let alone feel sorry for it. It seems to be at best a random guess as to how some group of people is feeling, and at worst a lie.
Clearly the engineers do know that something happened to the user- they are thinking about the circumstances that would have triggered the error message as they wrote the message
They don't know something happened. They only know that if something were to happen, then this message should pop up. That's not the same thing. People don't get feelings for events that they're not aware of having ever happened.
(Also, chances are good the people who authored the message aren't even the same ones currently at the company by the time you see them. Which ones would the message even apply to?)
I'm talking about the authors' feelings (who are purportedly feeling sorry), not the users'.
Do I feel sorry that my user didn't have access to some file? Not really? Maybe it was the right thing? If they were malicious I would feel glad. If not, I have no idea what to feel, it depends on the context.
Never met an app that could actually feel sorry (maybe someday?).
This type of behaviour just feels artificial and inauthentic in most products.
If your making an error message effort I'd focus first on being clear, concise and actionable. Try to establish some expectations for the user so they know how and when things will be resolved, ensure you're monitoring and alerting is appropriate to hold yourself accountable to those expectations.
If you really need to apologize, a human should do it.
The app didn't write the error message, the people implementing the app did. Any error message is just as much a form of communication between them and me as it is between the app and me.
Yes, there is a difference in the two examples you gave, although it would have been nice if you had been more specific about what you meant. What I notice is that the first option the apology comes from the company and the people in it, and intended to imply they see it as their responsibility to fix things. The second would imply that Alice is personally to blame for the cancellation and taking responsibility. Either are technically possible, although the latter seems very unlikely to ever happen.
What I fail to see is what this has to do with the error messages. The example given was "Sorry, you do not have permission to access this feature. Please contact your administrator for assistance", which falls under the first form. This seems appropriate for a message representing a team of people who wrote the program, as well as the administrator. It also is quite representative of the apology style seen in such messages.
Your remark was "The app didn't write the error message, the people implementing the app did". I responded by saying that you can't tell who the human is.
> it would have been nice if you had been more specific about what you meant
It's the very first sentence: you can't identify the human. I showed an example of why it's different when you can tell that there is a human involved working with you specifically.
Are you suggesting that the hypothetical anonymous apology by the flight company in your example is insincere and shouldn't have been given? Because if not it changes very little about the actual point, which is whether such apologies make sense or not.
For me an apology requires one party listen and understand the problem the other party experienced. They then convey that understanding back to the other party along with taking some amending action.
The author of the error message is communicating in a unidirectional manner to the the receiver with limited context of the overall interaction. That is a difficult scenario to attempt to apologize from.
It depends on the message, but a "Sorry" can set the right tone so a user doesn't feel "yelled at". Omitting the pleasantry might make things seem too terse.
Sorry, your e-mail failed to send.
Your e-mail failed to send.
I much prefer the first one. Software intended for typical end users should have a respectful tone and avoid sounding like it's blaming the user. On the other hand, something like strerror()'s output (eg. "Bad file number") is appropriately terse due to being meant more for programmers.
Both these error messages fail the "where do we go from here?" test - disrespecting the user with requiring open ended work on their part.
Having some breadcrumbs to get back to the right track is much more valuable than flowery wordings. Eg: Message too large - failed to send email. Network unavailable - failed to send email. Subscription expired - failed to send email. Unexpected service outage - https://email.io/status - failed to send email.
The details of the error weren't the point of my example. And being that terse sounds like you're barking orders at the user. Once again, shortness is fine for programmer communication, but personally for an end user just going about their day I would avoid such an impertinent tone.
A lot of software copy writing becomes so much easier when you ditch the silly facade of ‘the computer’ saying things. Instead treat the whole scenario as the software acting as an agent of the organisation, with the copy being written by a human on behalf of the organisation. So, a lot of “we…”.
This in my opinion makes software a whole lot more friendly, human, and overall just…usable. It gives way more opportunity to convey things in a way that doesn’t leave people scratching their heads and reaching for the knowledge base, where a lot of orgs are a lot less scared of writing like robots.
The issue though is the amount of software written by people in America, or should I say California, where there is a very distinct ‘fake-politeness’. I genuinely can’t tell whether or not they know how much it sticks out like a sore thumb to everyone else. In this case, the software being more human backfires, because allowing the human to shine through is just allowing us to see the shitty fake-happy way that humans at the organisation think that the organisation should be talking to customers.
TL;DR: writing like a human is good, unless your humans are bad.
> it would be more appropriate to "apologize" for something that would be considered solely the "fault" of the application
Is this in part a US vs English difference? I used to work with somebody from Texas who was confused and irritated by the english use of 'sorry' for things they weren't responsible for. In english I suppose we use it out of politeness to express some sympathy, rather than necessarily as an apology.
the ambiguity exists in us english as well as english english, but i feel that in us english the implied acceptance of responsibility in 'i'm sorry' is somewhat stronger
wow, I just dove into this via chatgpt and it was very interesting. I also found the use of sorry to mean something other than fault admission to be odd, never realised it was 2 cultures clashing
--
They often say "You and your family are in our prayers."
In Texas, the expression "You and your family are in our prayers" is commonly used at funerals instead of "sorry for your loss." This reflects the strong faith and community support present in the culture. Additionally, Texans might use phrases like "They're in a better place now" or "We're here for you," emphasizing spiritual comfort and solidarity.
I think a true apology should include, among other things, a plan on how you are planning on ensuring that the thing you're apologizing for doesn't happen again. So my rule would be: if you're not planning on ensuring that this doesn't happen again (either because the system is working as intended or because you have no plans on fixing the issue) then any apologize will sound insincere (because it is).
When is an apology okay: "The site is down temporarily. We are working to bring it back online. Sorry for the inconvenience"
When is an apology empty: "Your train has been canceled. We apologize for the inconvenience", more so when you hear the exact same message thrice a week.
Same with slack when it congratulates you for catching up on messages. Each app/service assumes you are able to take the afternoon off if you happen to have 0 widgets in your widget list.
"Sorry, you do not have permission to access this feature. Please contact your administrator for assistance."
Is not an error message, in the sense that it is not displaying an error state of the application. It is informing the user that some feature they have somehow reached (maybe through a link sent by someone else?) is not available to them. The apologetical tone is not for a mistake that was made (there was no mistake made by the application in this case) but for the action of preventing them from accessing something that is available to others.
I think an appropriate apology should address the overall situation, not a particular event. Say you're loading some data over the network, and it's taking unusually long. You decide to display a message, "sorry that it's taking so long". But what if the user is not even in front of their computer? The intent and effort behind the apology seems wasted.
What if the user was on a fast, but metered connection, and the data loaded very quickly, but wasted half of their monthly data package? How do you intend to apologize if you didn't even bother to call the OS or ask the user if it's OK to start a huge download?
I feel like blanket apologizing in any, except the most clear-cut scenarios, is going to feel excessive in one way or another. If you're just writing an error message, focus your attention on making it more informative instead.
I suspect there are cultural preferences here, there's no reason to believe there's one correct answer for all of humanity.
I'm from the US but I've traveled to places where it's considered rude to say "no" directly and apologies aren't common. Like when trying to order an unavailable item from a menu:
- I'd like the beef burger
- The chicken burger is very good
- That's OK, can I have the beef burger?
- Our hot dogs are also very good
I'd guess that text like "Access denied" or "You don't have access" would feel too direct and may come off as rude in that context. A "sorry" would feel out of place. Perhaps "This page is access restricted" would be best, as it alludes to the user not having access without directly saying it.
Conversely, I much prefer quick and direct communication with or without the apology: "[Sorry,] we don't have the beef burger."
I'd love to hear opinions of non-US and non-Westerners on this. We're in a thought bubble otherwise.
One time in Japan I met with the local bike repairman. He was an ojiisan and I had a friend to translate.
Instead of him saying something like "fixing your bent spokes on a $120 bike isn't worth my time or your money" he just said "there is no problem" over and over again
In addition to the other couple of replies that mention Japan, I would suggest, just start paying attention to this in the sense of deliberative practice, and you may find that your brain has been doing more editing on your social interactions than you may have realized. Sometimes the hardest things to see are the things we deal with all the time because our brains just read them as baseline. There's only a handful of cultures that are so blunt as to just say "no", bare and unadorned. Almost all cultures wrap a "no" in something to soften it. And I take a broad definition of "culture" here, including not just national, but company, family, other organizations, all sorts of cultures. You'll find it's quite a spectrum, and there's all sorts of inputs too, like positions in various hierarchies (perceived, formal, cultural, etc.).
You may also start doing this and realize that you personally have a mismatch with one of the cultures you participate in, which may even help resolve some small social problems you didn't even realize you were causing by bucking the particular culture's practices.
A similar effect: the imperative (giving orders). It is nearly as taboo in English, to just use the imperative, as it is in Japan. For example, if you have a dinner guest, you will ask "Would you like some more? Could you pass the salt?" It's always very indirect, put as a request that may be refused, or a suggestion. In other cultures, it may just be the bare imperative - "Eat more! Give me the salt." - and this is perfectly polite, contextually.
If this is a fun question for you, the book The Culture Map covers a lot of differences in how different cultures communicate, set expectations, express disagreement and displeasure, etc.
People who speak English and frequent this website will inevitably follow US culture or news coverage and have been tainted by it in some way. At the same time cultures are growing closer together, in part this is visible in poor internationalization of programs. It's becoming hard to draw the line.
I really don't want my software to be polite, I think that many Linux CLI tools do a good job with this:
cat: /etc/whatever: No such file or directory
No nonesense, no politeness, just the pure, searchable error. I've noticed that some MS CLI tools do the exact opposite, and print out an entire paragraph to say something very simple, gpupdate comes to mind, spitting this out if the domain is unreachable:
The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success Message for several hours, then contact your administrator.
A much more sensible error in my opinion would be:
For something as simple as cat that may work fine. But that message actually fails to say why it failed. It just gives you a fact that is presumably related to the exit code. In fact it doesn't even say it failed at all!, if your shell doesn't show the exit code you may read this as a warning or other non-critical information..
While it is hard to argue with succinctness of an error from such a simple program it may be better to say something like:
Fatal error: Couldn't open /etc/whatever. No such file or directory.
There's also, "[Sorry,] we're out of the beef burger. The chicken is very good though." This maximizes useful information.
While I understand it "just works" in those cultures, simply redirecting while avoiding a negative response is one of those things that only works in a cultural context where it's expected... to me, it would be pretty confusing. I don't think that's because my culture promotes directness, but more that I lack the cultural background of expecting avoidance.
Autistic people in those cultures must have a pretty tough time.
> simply redirecting while avoiding a negative response is one of those things that only works in a cultural context where it's expected... to me, it would be pretty confusing
It was confusing to me as well. But I am left wondering, is the directness of software frustrating people who culturally prefer indirect communication. I haven't seen anyone weigh in on that yet.
If such evasive speech is the cultural norm, then it should be handled in localization. After all it is about adapting a software to local language and preferences. It is not merely running strings through Google Translate.
Taking that evasive speech approach, which is considered polite in one culture, to another culture may very well be rude. I usually consider it rude if some direct question is evaded instead of answered.
No. I'm tired of machines trying to be friendly and cute with me. Be short, curt, and polite. Like a Star Trek original series computer. We're not friends, and you're not my equal, you're a damn program. Act like it.
I think, error messages should put way more focus on what can be done to make it work - rather than on what went wrong.
The user wants to achieve something, and the general job of the software is to help the user achieve their goal.
If the goal of the user is to book a flight - then the software throwing an error about the request form not being filled out correctly, basically constitutes a bureaucratic hurdle.
"You will not be allowed to book your flight, unless you ask for it in exactly the right way!"
Sadly, software often has to be bureaucratic about it's input - but that's not actually helpful to the user. So you could argue, when the software rejects the users request because of not meeting bureaucratic demands - the software is failing it's primary job: to help the user.
A perfect software would not have to show an error message ever - because it would be so good at guiding the user, that everyone would intuitively know how to do it correctly. But "Perfect" does not exist.
So any software will at some point inevitably fail to guide the user to their desired outcome and be forced to display an error message.
There's nothing inherently wrong with being apologetic in tone for failing to guide the user and putting such bureaucratic stumbling blocks in their way.
But the error message should be focused on helping the user. On making things work. It should not be condescending nor assigning blame. It should also be short and concise, and respect the user's time.
And that means that there's no space for polite verbiage and apologetic phrases.
So, apologetic tone is fine, if it can be done without increasing the length of the message.
> If the goal of the user is to book a flight - then the software throwing an error about the request form not being filled out correctly, basically constitutes a bureaucratic hurdle.
> "You will not be allowed to book your flight, unless you ask for it in exactly the right way!"
> Sadly, software often has to be bureaucratic about it's input - but that's not actually helpful to the user. So you could argue, when the software rejects the users request because of not meeting bureaucratic demands - the software is failing it's primary job: to help the user.
The booking software could provide a link that preserves the user entered from fields and creates a new session on this booking platform. That way it would reduce the friction created by the error. That is way more helpful than an apologetically phrased error message.
A proper apology, to me, is the admission of a fault that the apologiser is able to, and will, rectify next time. Therefore most error-message-apologies sound very insincere to me. I prefer computers to stay curt, true to their nature.
| Sorry, you do not have permission to access this feature. Please contact your administrator for assistance.
What is the feature? What permission do I need? Who is my administrator? How do I contact them?
These are the more important points to assist the user with then adding a "sorry".
I'd argue that this should be a button with 'request read access to FooViz from your administrator' that facilitates the corrective action on the users behalf. Similar to clicking on a Google docs link that you don't have access to.
I've been working in what might be called "UX" for some time, although mostly in technical and scientific environments, which are quite different compared to the garden variety consumer applications designed for retention and profit, and I wouldn't want to be thrown into the same pot as the usability crowd with their 90% business of self important shit that's just useless dribble for the incompetent middle management caste. The whole UX specialty can be summarized perfectly by the linked uxmag.com article which disqualifies itself automatically by having the most annoying, anti-usability "AI" bullshit modal over the article that's pathetically begging for the attention of gullible morons - of which there are plenty in UX, of course. It's a bullshit-job profession, and it shows. In reality you can boil down most questions of usability to using simple heuristics: Who are you dealing with and what's the useful interaction in this context? E.g. the useful interaction with UX people in any context is to let them know how little worth their professions actually has.
261 comments
[ 2.5 ms ] story [ 287 ms ] thread“You broke Reddit”
Come on, I don’t think so!
https://stackoverflow.com/questions/68129684/what-does-this-...
IMNSHO, dev-facing error messages bifurcate:
if i say to you 'i'm sorry my email was so long' that question doesn't arise; you know who the speaker is and who the intended listener is. similarly, if your browser says to you 'i'm sorry my email was so long', as it is doing as you read this, hopefully the surrounding context contains enough information to identify the purported speaker and intended listener. (i'm sorry my email was so long!) it is 'quoted speech', as when lisa says, 'and tanya was all, "i'm sooo drunk right now! oh my god, i'm like sooo sorrryyy!" and we laughed'; lisa is not apologizing, tanya is.
but what agent does a running computer program represent? or, on whose behalf are its error mesages speaking?
— ⁂ —
in the case of, for example, a built-in macos program, this is clear: it represents apple, the corporation, a fictitious collective identity like the dread pirate roberts, anonymous, or bourbaki. in exchange for your money, apple is providing you a service by allowing you to run that software on the computer you nominally bought. the computer program, written or at least patched together by apple programmers, speaks with apple's voice
therefore, if apple cannot fulfill your request, it would be polite for apple to express regret, in the program's error message, for letting your hopes down. perhaps it could include a link to the web site where you can purchase the permission to use 'your' computer to think the thoughts you are not currently licensed to think in it. this applies generally to proprietary software that you are not allowed to fix, as vanderZwan suggests. (even if you can figure out how to fix it, apple is responsible for making that unnecessarily difficult by, for example, not supplying you source code and checking executable signatures.)
— ⁂ —
traditionally, though, on conventional timesharing operating systems like unix, the programs are considered to be an extension of the user's mind, as a bicycle is an extension of their body, and thus they represent the user's agency; they carry out the user's own will, not the will of their programmers. a program that carries out the will of its programmer, where it conflicts with the will of its user, is considered a 'trojan horse' or 'malicious', with narrow exceptions; and strong social sanctions are attached to distributing such programs. the protection mechanisms in the operating system simply assume they don't exist
so, in that social context, if a program is speaking to you, it is speaking to you on your own behalf, like a note you have left yourself in your day planner. perhaps tex does not have enough string space to interpret a given document, because you compiled it to have less string space than that, or perhaps you chose to use a copy of tex a colleague of yours compiled, to save the time and disk quota of compiling it yourself. that is no different from your example of contradictory declarations in the input; all that is needed is pointers to the mutually inconsistent limits (ran out of string space at bar.tex line 5329, string space size is defined in foo.web line 30213, compiled on 01994-10-31 from the source tree in /u3/schaker/new-tex)
should cannondale apologize to you when you fall off your bicycle, or arrive late to a meeting, or ride into a slum and get mugged? if you open the kitchen cabinet to get the table salt, and find that you have left it in the dining room, will you apologize to yourself? when you reserve time in your day planner for a meeting you expect to be unpleasant, does the calendar entry begin with "i'm sorry"? should don knuth apologize for not making the string size allocation larger? surely not. even schaker probably should not; if you want a larger string size allocation, you can recompile tex yourself ...
we deeply regret this error
I'm administrator! :'-(
It worked for Microsoft, it will work for you
— <https://twitter.com/cherrikissu/status/972524442600558594?la...>
Better still, have a failure condition that is symbolic in some way, or enforces certain intuitive interaction via the UI, instead of pushing error messages in people's faces. A good example of this, typing the wrong password in the macOS login shakes the password field, rather than displaying "INCORRECT PASSWORD!". That sort of thing.
* Concise. ("You need to enter a number in this field, not text" = Good, "we're very sorry but we can't understand it if you write your age in text" = Bad).
* Clearly telling the user what went wrong without relying on technical jargon. The line number where something went wrong doesn't need to be in an error message; it's not something the user can do much with - keep that in the crash dump. The DLL name you're missing probably should be if it's from a runtime.
* Providing a means on where to find a more detailed error message/who to call to fix it if the user can't fix it themselves, with the right information to supply that person. ("Please call your administrator for help and use code ERR_CRAPSHOOT (128)" is good, "We're very sorry" with a ton of warranty warnings and a way too vague error code that can indicate a ton of similar errors is bad.)
* Avoid the notion of just reporting everything to some backend endpoint and giving the users no indications of what went wrong; this is only frustrating to the user, no matter how many apologies you put in the message. It's an answer that amounts to "your message is very important to us, please hold the line".
No. Never tell me what I "need to" do.
There are any number of ways to get this message across without telling me what I need to do.
One example off the top of my head, probably not the best, but certainly an improvement because it doesn't blame me:
> This field only accepts numbers
For bonus points, put that message next to the field modelessly at the moment I type a non-numeric character.
Many users will have no clue what a field is.
Do you imply ill intent upon the program? Because I read this as a violation of tone.
I interact with the program because I want/need to. It's in my interest to follow through the *instructions* to interact with it correctly and efficiently. I can follow instructions and view it as a helpful hint.
How about entering, say, a printer configuration. These fields accept only SSIDs, IP addresses etc?
Error messages this general become slightly annoying when the app doesn't respond intelligently to all possible scenarios that its wording might imply.
For example, if the field only parsed numeric digits, and failed on inputs like "12.5" or "3e1" because they contained the characters "e" or ".", then they should have written something like "Only numeric characters are accepted," or "The number must consist only of digits (0-9)," since it rejected valid numbers. The app is saying I need to enter a number, but I did enter a number, and it's just too primitive to recognize it.
(Also, chances are good the people who authored the message aren't even the same ones currently at the company by the time you see them. Which ones would the message even apply to?)
Do I feel sorry that my user didn't have access to some file? Not really? Maybe it was the right thing? If they were malicious I would feel glad. If not, I have no idea what to feel, it depends on the context.
This type of behaviour just feels artificial and inauthentic in most products.
If your making an error message effort I'd focus first on being clear, concise and actionable. Try to establish some expectations for the user so they know how and when things will be resolved, ensure you're monitoring and alerting is appropriate to hold yourself accountable to those expectations.
If you really need to apologize, a human should do it.
Every time an error happens, you get a popup with an AI version of our boss bowing down in shame.
> Flight UA569 has been canceled. We apologize for the inconvenience and we will rebook you on the next available flight.
and one that says:
> Flight UA569 has been canceled. I apologize for the inconvenience and I will rebook you on the next available flight. — Alice
Yes, there is a difference in the two examples you gave, although it would have been nice if you had been more specific about what you meant. What I notice is that the first option the apology comes from the company and the people in it, and intended to imply they see it as their responsibility to fix things. The second would imply that Alice is personally to blame for the cancellation and taking responsibility. Either are technically possible, although the latter seems very unlikely to ever happen.
What I fail to see is what this has to do with the error messages. The example given was "Sorry, you do not have permission to access this feature. Please contact your administrator for assistance", which falls under the first form. This seems appropriate for a message representing a team of people who wrote the program, as well as the administrator. It also is quite representative of the apology style seen in such messages.
Your remark was "The app didn't write the error message, the people implementing the app did". I responded by saying that you can't tell who the human is.
> it would have been nice if you had been more specific about what you meant
It's the very first sentence: you can't identify the human. I showed an example of why it's different when you can tell that there is a human involved working with you specifically.
For me an apology requires one party listen and understand the problem the other party experienced. They then convey that understanding back to the other party along with taking some amending action.
The author of the error message is communicating in a unidirectional manner to the the receiver with limited context of the overall interaction. That is a difficult scenario to attempt to apologize from.
I see no reason why one would not be able to anticipate unavoidable inconveniences in advance and write an automated apology for it.
Sorry, your e-mail failed to send.
Your e-mail failed to send.
I much prefer the first one. Software intended for typical end users should have a respectful tone and avoid sounding like it's blaming the user. On the other hand, something like strerror()'s output (eg. "Bad file number") is appropriately terse due to being meant more for programmers.
Having some breadcrumbs to get back to the right track is much more valuable than flowery wordings. Eg: Message too large - failed to send email. Network unavailable - failed to send email. Subscription expired - failed to send email. Unexpected service outage - https://email.io/status - failed to send email.
This in my opinion makes software a whole lot more friendly, human, and overall just…usable. It gives way more opportunity to convey things in a way that doesn’t leave people scratching their heads and reaching for the knowledge base, where a lot of orgs are a lot less scared of writing like robots.
The issue though is the amount of software written by people in America, or should I say California, where there is a very distinct ‘fake-politeness’. I genuinely can’t tell whether or not they know how much it sticks out like a sore thumb to everyone else. In this case, the software being more human backfires, because allowing the human to shine through is just allowing us to see the shitty fake-happy way that humans at the organisation think that the organisation should be talking to customers.
TL;DR: writing like a human is good, unless your humans are bad.
Is this in part a US vs English difference? I used to work with somebody from Texas who was confused and irritated by the english use of 'sorry' for things they weren't responsible for. In english I suppose we use it out of politeness to express some sympathy, rather than necessarily as an apology.
I'm not a native speaker but I feel like Americans would say that too.
We don’t have those here!
Sorry to drop by like this.
Funerals must be bewildering for them. How do they phrase "I'm sorry for your loss"?
--
They often say "You and your family are in our prayers."
In Texas, the expression "You and your family are in our prayers" is commonly used at funerals instead of "sorry for your loss." This reflects the strong faith and community support present in the culture. Additionally, Texans might use phrases like "They're in a better place now" or "We're here for you," emphasizing spiritual comfort and solidarity.
You don't apologize, you sympathize and empathize. You say what you actually mean. It depends on if you know the deceased as well, but if you don't:
- I was so sad to hear about your loss.
- I am sending you my deepest condolences for your loss.
- I am keeping you in my thoughts and prayers.
- May their memory be a blessing.
- May they rest in peace.
- They will be missed.
- I know you must be hurting. I am here for you if you need me.
"I apologize for your loss".
That was all in the snappiness of the wording, great little joke.
"APPLICATION ERROR. SAVE YOUR WORK AND QUIT. YOU LOST EVERYTHING. WAY TO GO, GENIUS."
When is an apology okay: "The site is down temporarily. We are working to bring it back online. Sorry for the inconvenience"
When is an apology empty: "Your train has been canceled. We apologize for the inconvenience", more so when you hear the exact same message thrice a week.
I feel the Chrome dinosaur kicked those off, and I do (did?) like the dino. But "it's not you, it's us" is very annoying. "We made a booboo UwU".
When something has gone wrong I really don't want to feel I'm being marketed to, I just want information!
Well that's great if you worship Inbox Zero. But what about me?
Maybe I'm anxiously waiting for news on a family member's illness and hospitalization.
Maybe I'm waiting for my lawyer to get back to me on an important case.
It's not hard to imagine any number of circumstances where I would not say "hooray!" when I see my inbox is empty.
> 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!
(https://knowyourmeme.com/memes/oopsie-woopsie)
"Sorry, you do not have permission to access this feature. Please contact your administrator for assistance."
Is not an error message, in the sense that it is not displaying an error state of the application. It is informing the user that some feature they have somehow reached (maybe through a link sent by someone else?) is not available to them. The apologetical tone is not for a mistake that was made (there was no mistake made by the application in this case) but for the action of preventing them from accessing something that is available to others.
What if the user was on a fast, but metered connection, and the data loaded very quickly, but wasted half of their monthly data package? How do you intend to apologize if you didn't even bother to call the OS or ask the user if it's OK to start a huge download?
I feel like blanket apologizing in any, except the most clear-cut scenarios, is going to feel excessive in one way or another. If you're just writing an error message, focus your attention on making it more informative instead.
I'm from the US but I've traveled to places where it's considered rude to say "no" directly and apologies aren't common. Like when trying to order an unavailable item from a menu:
I'd guess that text like "Access denied" or "You don't have access" would feel too direct and may come off as rude in that context. A "sorry" would feel out of place. Perhaps "This page is access restricted" would be best, as it alludes to the user not having access without directly saying it.Conversely, I much prefer quick and direct communication with or without the apology: "[Sorry,] we don't have the beef burger."
I'd love to hear opinions of non-US and non-Westerners on this. We're in a thought bubble otherwise.
"HN commenter" is already a much tighter bubble than "the West".
Where, "That is very difficult," really means in English, "Yeah, no."
Often proceeded by a short sharp inhale.
Instead of him saying something like "fixing your bent spokes on a $120 bike isn't worth my time or your money" he just said "there is no problem" over and over again
You may also start doing this and realize that you personally have a mismatch with one of the cultures you participate in, which may even help resolve some small social problems you didn't even realize you were causing by bucking the particular culture's practices.
Example:
"Do you want to turn on the fan?"
(Standard imperative equivalent: "Turn on the fan.")
While it is hard to argue with succinctness of an error from such a simple program it may be better to say something like:
This says:1. What failed. (Couldn't open /etc/whatever)
2. Why it failed. (No such file or directory)
3. How this was handled (Fatal)
While I understand it "just works" in those cultures, simply redirecting while avoiding a negative response is one of those things that only works in a cultural context where it's expected... to me, it would be pretty confusing. I don't think that's because my culture promotes directness, but more that I lack the cultural background of expecting avoidance.
Autistic people in those cultures must have a pretty tough time.
It was confusing to me as well. But I am left wondering, is the directness of software frustrating people who culturally prefer indirect communication. I haven't seen anyone weigh in on that yet.
Taking that evasive speech approach, which is considered polite in one culture, to another culture may very well be rude. I usually consider it rude if some direct question is evaded instead of answered.
The user wants to achieve something, and the general job of the software is to help the user achieve their goal.
If the goal of the user is to book a flight - then the software throwing an error about the request form not being filled out correctly, basically constitutes a bureaucratic hurdle.
"You will not be allowed to book your flight, unless you ask for it in exactly the right way!"
Sadly, software often has to be bureaucratic about it's input - but that's not actually helpful to the user. So you could argue, when the software rejects the users request because of not meeting bureaucratic demands - the software is failing it's primary job: to help the user.
A perfect software would not have to show an error message ever - because it would be so good at guiding the user, that everyone would intuitively know how to do it correctly. But "Perfect" does not exist.
So any software will at some point inevitably fail to guide the user to their desired outcome and be forced to display an error message.
There's nothing inherently wrong with being apologetic in tone for failing to guide the user and putting such bureaucratic stumbling blocks in their way.
But the error message should be focused on helping the user. On making things work. It should not be condescending nor assigning blame. It should also be short and concise, and respect the user's time.
And that means that there's no space for polite verbiage and apologetic phrases.
So, apologetic tone is fine, if it can be done without increasing the length of the message.
“ERROR: Database query returned 0 rows”
versus
“ERROR: Database query returned 0 rows but need 2 or more rows for this operation. Ensure $other_etl has successfully ingested the data.”
> "You will not be allowed to book your flight, unless you ask for it in exactly the right way!"
> Sadly, software often has to be bureaucratic about it's input - but that's not actually helpful to the user. So you could argue, when the software rejects the users request because of not meeting bureaucratic demands - the software is failing it's primary job: to help the user.
The booking software could provide a link that preserves the user entered from fields and creates a new session on this booking platform. That way it would reduce the friction created by the error. That is way more helpful than an apologetically phrased error message.
What is the feature? What permission do I need? Who is my administrator? How do I contact them?
These are the more important points to assist the user with then adding a "sorry".
I'd argue that this should be a button with 'request read access to FooViz from your administrator' that facilitates the corrective action on the users behalf. Similar to clicking on a Google docs link that you don't have access to.