Should error messages apologize? (2013)
ux.stackexchange.com
ux.stackexchange.com
"We couldn't find that site."
"We're just updating your computer."
Perhaps I'm just an old fogey, but passive voice feels like the only right choice:
"The site could not be found."
"Your computer is being updated."
The insertion of "We" feels like an imposition; the company who wrote the code reaching in and enacting their will with your equipment, using your screen as their soapbox. It's icky.
And without "we", there can of course be no "we apologize".
Love the proposed solution. And yet Linux will never be ready for the desktop because you need the command line to fix problems...
Some years ago, the Google Voice app for Android would put a message in the notification bar whenever there was even the most brief connectivity issue (which in the early days of 3G on android was frequent) starting off with "We have a problem ... <connnecting to your google voice account or something>". Considering that I used that GV number for two highly regulated activities with potential high liability, my heart would skip a beat every time a pull out my phone and see "We have a problem".
>"Your computer is being updated."
But without the we, it is all passive voice. My English professors in college all hated passive voice.
"site not found"
"software updating"
edit: better: "update in progress"
"site cannot be found"
"software is updating"/"updating is in progress"
- a gerund form which is always the same as the infinitive,
- a different gerund form (verb-'ung', kind of cognate to verb-'ing', both derived from a Latin construct I believe), and
- a present participle
...in addition to the other declensions. It's fascinating to me how Dutch and English can be seen as two parallel derivatives of the old High German language, where as what we now call German has developed along a largely different path!
It's also interesting to think of how to describe the semantic difference between the -en and -ung nouns when both do exist. I think one case is that the -ung can often describe the result of completing the action of the verb or in some sense refer to a "complete instance" or "complete occasion" of the verb's action, but this is generalizing from just a few examples...
> forms nouns from verbs, usually describing either an event in which an action is carried out, or the result of that action.
> Note that the -ung suffixed form is different from the gerund which is formed by simply capitalizing the first letter of the verb. The gerund usually refers to the activity in general rather than a specific instance or result.
I tried this to get all of the dictionary pairs for comparison:
import re
german = set(open("/usr/share/dict/ngerman").read().split())
english = set(open("/usr/share/dict/words").read().split())
tech_de = "ung"
gerund_de = "en"
tech_en = "tion"
gerund_en = "ting"
for word in sorted(list(german)):
if word[0].isupper() and word.endswith(tech_de):
gerund = re.sub(tech_de + "$", gerund_de, word)
if gerund in german:
print(word, gerund)
print()
for word in sorted(list(english)):
if word[0].islower() and word.endswith(tech_en):
gerund = re.sub(tech_en + "$", gerund_en, word)
if gerund in english:
print(word, gerund)
I put a sample output of this up at https://sethschoen.com/gerund-comparison.txt in case anyone wants to look at it (not promising to keep it there forever!). (Note the default character encoding from the web server is wrong so you may have to change encodings manually, or download the file and reopen it, to see German umlaut characters correctly.)
"Whoops, sorry! This wasn't what you were looking for!"
"Oops! You broke the internet. We are trying to fix it."
"Are you lost? Let us help you home (link to home page)"
https://www.callbruno.com/en/404
Just treat me like an adult and tell me what's wrong. Preferably with a googleable error code.
Related discussion: https://news.ycombinator.com/item?id=34812857
What kind of shallow charicature of a tough guy do you have to be that seeing colours makes you feel like a baby and that cheerful is a bad thing, something to be stopped?
> "Besides the obvious inappropriateness"
Obvious?? All tools should be monochrome, and everyone should feel like they work in a funeral parlour? If it was supposed to be cheerful it wouldn't be called work? It must have been the colourful offices[1] which stopped Google from making any money, I guess?
[1] https://duckduckgo.com/?t=ffab&q=google+offices&iax=images&i...
Is it so surprising that people expect tools they use for business to look and act professionally?
Actually, that was a pretty reasonable translation of this line into low-brow speech:
> a broader, ongoing software infantilization process. Colors can't be sober either, everything has to be colorful, cheerful
The connection between these sentences is fairly clear: software is being infantilized and part of that is that everything has to be colorful and cheerful. Hence OP's translation into "seeing colours makes you feel like a baby and cheerful is a bad thing".
The translation into more casual language was rhetorically valuable in that it accentuated their broader point about how stuffy the original author sounds.
(And yes, I'm intentionally using stuffy language here because the casual language OP used seems to have whooshed.)
Seems both more likely and more charitable.
> "may go hand in hand with designs that treat the user as inept"
May, may not. Is orthogonal to.
> "I don't like being treated as inept or incapable."
What a chain of reasoning. "I don't like being treated as inept (fine), so to remind myself how capable I am I need to not look at colours otherwise I will fantasize that other people are laughing at me (not fine)".
First, it's not that the UI is colorful, it's that many designers seem unwilling to make UIs that are monotone or subdued. That's different from disliking color for whatever reason.
The designer choosing that certain (more monotone) color schemes are not permitted could be conflated with designers making other decisions on behalf of the user, such as assuming the user would prefer fewer options for the sake of simplicity. ("Treating the user as inept")
I don't know what the OP meant exactly, but I still find your 'translation' uncharitable.
I personally like both brightly colored things, as well as more muted color schemes, depending on the situation. I don't personally think colors equate to childishness.
I can however empathize with someone unhappy that their personal aesthetic preference seems underrepresented, and feels that UI designers are making more choices on their behalf than they'd prefer.
That needs some citations. "Dark mode" is the theme du decade. Most things have dark modes or night modes - operating systems, productivity tools, websites, chat programs, game menus, developer tools, browser chrome, mobile and desktop, traditional and apps.
> "The designer choosing that certain (more monotone) color schemes are not permitted could be conflated with designers making other decisions on behalf of the user, such as assuming the user would prefer fewer options for the sake of simplicity. ("Treating the user as inept")"
If you're exhorting me to have a charitable interpretation of the above comments, why aren't you taking a charitable interpretation of the designer's intent? [And why is fewer options connected to 'inept'? Do you feel inferior when there's only one lightswitch in a room instead of 8? Because somehow more options automatically means more competence? In any situation, the amount of possible options is enormous and the amount of useful ones is a tiny part of it; the most likely thing is that more options are acreted by lack of design and kitchen-sink driven development and are useless or time wasting, rather than considered and useful].
> "I don't know what the OP meant exactly, but I still find your 'translation' uncharitable."
> "I don't personally think colors equate to childishness."
Then why are you defending the claim that they do?
[1] as much as I used to
Without wanting to put words into gp's mouth. I assume because he understands that different people have different preferences. And some don't want to get forced into other peoples preferences. Actually, gp said it directly:
> I can however empathize with someone unhappy that their personal aesthetic preference seems underrepresented, and feels that UI designers are making more choices on their behalf than they'd prefer.
The worst offender I have found is Lemonade Insurance which doesn’t even tack on the obligatory “bug fixes and performance improvements” at the end.
https://apps.apple.com/us/app/lemonade-insurance/id105565364...
Honestly it was fine enough for a YouTube error, "we couldn't find that video." But then everyone started copying it, including Microsoft who, in Windows 8, updated the blue screen of death to have a "whoopsie poopsie! Your computer has a widdle boo boo!" type message, accented with a :( sad face emoticon.
Which I can guarantee was presented to countless people who lost real work. I'm sure they found that real reassuring.
This predated the annoying :( which I think would have led him to break the computer after the second try
Back then the I-cannot-program-my-VCR crowd used to call tech support and scream about all the "egghead nonsense gobbledygook" on their screen. And since there's orders of magnitude more of them than there are people ready to fire up their kernel debugger and make use of that info, guess which tack the UX took?
Your client does not have permission to get URL / from this server. _That’s all we know._
But yeah, it also feels like "we (Google) don't care that much about your problem here, because nobody is going to improve this software to give you a more meaningful explanation".
You don't get tempted to talk in terms of "we" when you are doing software that is controlled by its user. But policing the language won't achieve anything either.
However, I can also see a case for the other point of view. In working on large enterprise systems that are being used by users who are not technical, the "we" helps reinforce the idea that things aren't outside of the users locus of control. There is an whole group of people employed by the organization behind the scenes that are part of the way the overall system works. So the "we" emphasizes that the system, the error, the people who write the system, the person trying to use the system, are all part of whatever they are trying to do together.
This is particularly annoying when error messages are written from the point of view of an entity or fictitious person, e.g. "Sorry, I wasn't able to..." but things on screen are labeled "My..." Is "me" the user or the software?
I think that using "we" and "apologizing" is fair for most user-facing applications. It's kind of like the old adage: the customer is always right. Obviously the user wanted to accomplish something, and tried something to achieve it, but your software couldn't figure out what they wanted or didn't have enough information to do it, etc. So, it's kind of like a store clerk saying "I'm sorry; we're all out of that color dress."
Now, I would say this kind of "polite", human-centric, UI is not appropriate for e.g., sysadmin stuff like coreutils. I think it's perfectly fine if `cat /some/file` errors by saying "That file doesn't exist. Get bent."
Also, just to inject some unrelated cynicism... To your example about updating, I think with how pushy companies like Microsoft are with updates, it might actually be more accurate for them to say "We are updating your computer and enacting our will with your equipment."
And that BS is exactly why we have all those entitled adult babies now.
If I visit a website, "They" broke.
If my phone crashes, "It" broke.
My phone shouldn't say "we" - I don't grok the idea of people in there.
The website should say "we" - It's an organization presenting data, and I do believe there are people behind it.
My car shouldn't say "we" - My car is an "it", a thing that lives in my garage and I drive around.
NVIDIA drivers shouldn't say "we" - I'm running the program. I'm the agent. If anything, when I check for drivers, it should say "they have an update ready". The program is executing on my machine. It's mine. "They" are the people who publish updates. "We" (program and I) go fetch and install them.
But programs don't have agency - so if "it" can't fetch "their" update, then "Update could not be fetched" conveys all the info I need to know.
Then there's the "simpy" problem of always apologizing. For this reason I like TFA's final recommendation:
> Use the word “sorry” only in error messages that result in serious problems for the user (for example, data loss or inability to use the computer). Don’t apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).
Rubs me up the wrong way, because there would be no way to identify who the individual apologising is.
However, I think error messages should apologise in the rare situation that there is no constructive, helpful, language-neutral way to convey an actionable response in an error.
I'm curious to know which line/operator you've heard this on.
I've got my own pet-peeve automated announcement though: "This is a National Rail security announcement..." Oh no! Is there a riot on the platform? Was someone assaulted? No, listen further: "...If you see something that doesn't look right, text the British Transport Police on 61016".
Like, that's not even a real announcement, and doesn't every passenger know the number by now??
P.S. I feel that it's right to note for those unfamiliar with the English railways that GWR are probably the most effective train operator in England, and that the delay I had wasn't their fault. Eurostar, having almost exclusive use of HS1 and the Channel Tunnel, don't have that excuse available, but they were still impeccablely professional.
What about passive voice for the software error, then apologize with we in the name of whoever developed that software?
I still use "we" whenever I'm emailing clients, except now it's to sound like there is more than just me in this dept.
Amidst cyberspace vast,
Site elusive, lost in void,
Unreachable code.
(I could swear that one of these appeared in BeOS' NetPositive browser if you visited a site without network access... but now I'm not so sure.)
Edit: now I'm sure: https://8325.org/haiku/
"Errors have occurred.
We won't tell you where or why.
Lazy programmers."
Thank you for sharing them :)
Strictly professionally, of course.
But they are reaching into your computer and enacting their will. The passive voice strikes me as even ickier when it is used to amorphously shift blame into the ether. I would much rather read "sorry, we fucked and formatted your harddisk because we suck at programming" than "an error occurred and all your data is gone". Take some damn responsibility.
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
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.")
cat: /etc/whatever: No such file or directory
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.
Group Policy update failed: domain.tld: Destination host unreachable / Destination network unreachable / timeout / ...
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.
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.
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"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 almost as easily as schaker can
but it depends on the social context. perhaps if schaker is responsible for maintaining the tex installation all the math professors use, the error message should include his email address so they can request a dilation of their tex
— ⁂ —
in general, in free software† the app's programmers are not responsible for its behavior, unless they have somehow contrived to conceal it. you, the user, are fully empowered to modify the app to manifest your own agency, and responsible for doing so. so the traditional timesharing situation holds
a precondition for a sincere apology is accepting responsibility for the situation being apologized for—which implies that the intended recipient of the apology does not have that responsibility. in free software, a maximally uncharitable interpretation of an error message (other than for an internal bug) saying 'i apologize for' (or, worse, 'we apologize for') is a red flag that the developer is a renegade who rejects this social contract; they are attempting to arrogate the right to determine what you may and may not do with your computer, by virtue of having written some of the software you are trying to use to do it. like ayn rand, they consider themself an atlas on whose shoulders the mere user is generously permitted to ride, as long as they do not shrug. they consider 'trojan horses' to be normal software. this is not a collegial or collaborative relationship
but that is a maximally uncharitable interpretation. perhaps the programmer is apologizing because they felt that they left a job half done, or they would have liked to find a smoother way to handle a different situation, and just couldn't figure one out. or perhaps the "sorry" is not really an apology, accepting responsibility, but merely an expression of sympathy for the users who find themselves in an unfortunate situation, without respect to whose responsibility it is
but, with respect to error message design, it is an immense blunder to generalize from the social context of proprietary software like xcode to the social context of free software like gcc
of course, in some situations, free software on a shared computer is instead an instrument of some office administrator or similar, who is the agent responsible for the unfortunate situation that might merit an apology. in that case the desk phone number and email address of that administrator ought to be included in the error message, in the interest of solving the problem as expeditiously as possible if it is urgent to the user
— ⁂ —
while it can be amusing for computer programs to present us a theater in which various personages portray different personalities—some servile, some compassionate, some aggressive—artistically that can be done well or poorly, and it is important for the user to understand that these personages are fictional, and that a conventional computer program is merely an instrument, not an agent
different users' tastes in such theater may vary; judging from popular novels, movies, tv shows, video games, and rap music, most prefer fiction containing passionate, aggressive personages who struggle to the death. portraying such personages in error messages would surely be entertaining (japanese video games often do this, launching insults at the player character when the player suffers a misfortune they could have avoided) but it might occasionally cause difficulties when a user appears who does not understand that the program is not itself an agent, and anyway if done without artistic skill it will not be entertaining at all
on the other hand, the stackexchange thread seems to recommend always portraying agents in error messages and always making them servile. this compounds that risk rather than ameliorating it: it is commonly done without enough artistic skill to render it entertaining; it adds the extra challenge of making a servile personage sympathetic rather than merely irritating; and the motivation given in the stackexchange thread insults the user by the unspoken implication that they are unable to distinguish the fictional personage portrayed in a computer program from a real sentient agent—an implication that may not be apparent from a single error message, but which will surely become evident over time unless the user is very small or socially handicapped
______
† perhaps we should rename free software 'nontoxic software', given that the movement to rename it 'open source' has not been as successful as was hoped, and 'free software' was always unavoidably a very confusing term
we deeply regret this error
I'm administrator! :'-(
Tell me what went wrong so I can figure out how to fix it. I don’t care whose fault it is or how very sorry they are for the mistake. Even saying “the website you are trying to contact is down” can be misleading, maybe it’s not down, maybe I’ve lost my internet connection or the ip changed and dns hasn’t updated, or I have some rule locally that is redirecting me incorrectly. Guiding someone into an assumption is harmful and a waste of time, if not dangerous.
I understand that consumer stuff is all about dumbing down the experience so that an idiot can do the thing (we should strive for the most idiot proof interface possible), but that design principle is useless when things go wrong and you need to fix it.
Linux is maintained by power users that want to give the same power to every users but nowadays, the vast majority of users don't need and don't want those powers.
I guess you never had to deal with the flow of complaints whenever an update was installed and the icon for the app changed. Many users couldn't start "the application".
It was even customary in some organizations to create their own shortcut with their own icon to start iexplore or excel.
I know that whenever a site "can't be found", it's been blocked by my pihole. But to anyone else connected on my network, it's "the internet is down".
> Linux is maintained by power users that want to give the same power to every users
Look at the assumptions behind "UX is dumbing down" and "idiots". Good UX is about making the same power more consistent to waste less of your finite brain power to use it, leaving more free for other things. Good UX is about keeping the same power but making it easier for intelligent people without experience to come in and pick it up and predict how it will work. Good UX is about making the abstractions cleaner and the tools more extensible to allow the same power to be used in more situations. Good UX is about settling the existing tools to allow even more power to be added, or built on top of them, without them collapsing. Good UX is about making the same power lower activation effort to use so you can focus less on setting up the tooling and more on the problem space. Good UX is about making it easier for idiots to use it, but not at the expense of experts. Good UX is about making a problem go away completely so nobody needs any tooling or to waste any time on it.
> "I know that whenever a site "can't be found", it's been blocked by my pihole. But to anyone else connected on my network, it's "the internet is down"."
That's a terrible UX. There's nobody helped by you feeling clever for understanding an inaccurate error message and looking down on people who don't understand it. Putting a clear and accurate error isn't "dumbing down". That's the fear that you would feel dumb if you didn't have to work hard and know secret incantations to achieve results.
Can we agree that whenever you wrote "Good UX _is_ about ..." you actually meant "Good UX _should be_ about ..."? In practice many things that happened in the name of user friendliness did remove a lot of power from the users. Good counter examples not withstanding.
I can agree that many things actually do get worse, but I'm arguing against the implicit connection "this thing has some power and it is complex. The only way to make it nicer to use - easier, simpler, more approachable, less mental effort - involves removing or restricting the power, always and necessarily".
Take a piece of metal, flatten and grind the end, and use it as a flathead screwdriver and a small knife. Now you say "that's my powerful and useful multitool, don't you dare dumb it down for idiots or you'll remove my power!". It makes a poor knife because the blade has to be small enough to fit in a screwhead and keeps being blunted by using it as a screwdriver, and it makes a poor screwdriver because the blade is thin holding a knife edge which makes it weak and brittle, and it's a poor tool because you're trying to grip a small slippery piece of metal. Put a rubberised large grippy handle on it, it's improved - easier to hold, less likely for your grip to slip and end up hurting yourself or damaging what you are working on, and looks more visibly like a tool to someone coming in afresh if they're looking for a screwdriver - and the same power. Split it into a knife and a screwdriver, each can be better at their task - stronger screwdriver blade, bigger sharper knife blade, custom shaped handles for turning vs slicing - that's easier to use, easier to learn, and overall more powerful.
Yes someone could round off the end for 'safety for normal people' and that would remove the power, but we can't agree that's ever "good design". Particularly I won't agree "consumer stuff is all about dumbing down the experience so that an idiot can do the thing" --> "any change which improves ease of use or convenience or comfort necessarily rounds off the power" (not necessarily true) or "only idiots want or need tools to be easier to use" (not true).
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".
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!
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.
"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 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.
"Ooopsie! Looks like you clicked on a picture that doesn't exist!" Instead of "We fucked up and served you an invalid link"
I am not sure if the additional complexity that would stem from teasing those scenarios apart and serving them with different messages is worth it.
Please enter your name.
Name:
Error: null.
I think UIs should apologise if something that's not the user's fault happens (no network connection); be polite when giving orders (please do this or that); and be very precise when indicating input errors and suggest a course of action.
https://godbolt.org/z/GMxz5c339
"sorry, unimplemented". It really felt out-of-place when I first encountered it, but I think it messages intent a bit more than a simple "unimplemented" error message. It at least suggests that this is a shortcoming of the current implementation, so it might get implemented in a later version.
Having said that clang also doesn't implement this, and the error message doesn't apologize: "error: cannot compile this lambda conversion to variadic function yet"
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.
• Immediately try again
• Wait some time and try again
• Change my input and try again, or
• Give up and walk away
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.
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.
* 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.
So we go either helpful or quirky on error messages most often and apologetic if the situation demands it.
Then again, that was nearly 30 years ago. Maybe we didn't have as many studies on users back then.
https://stackoverflow.com/questions/68129684/what-does-this-...
A library discovering a mismatch between a configuration setting and a value it received by API isn't in a position to make a decision on which is wrong: is it misconfigured, or is the value it received via API under the control of the user?
The caller of the API isn't necessarily in a better place to make a decision. The higher up the stack you go, the more context you have on the action the user is trying to perform but the number of potential errors increases exponentially. It's usually not feasible to contextualize every possible error condition, particularly for things like configuration which are side-loaded while executing code and are a library implementation detail from the perspective of the application writer.
Consider access denied to a file: is this a user mistake or a permission mistake? Should the user change the file permissions, or not try to access that file?
Consider quota exceeded while writing to a file: should the user free up space, create a smaller file, or ask their administrator to give them more space?
What if the quota was exceeded due to a configuration setting in the application specifying where to put scratch files?
It gets very complicated very quickly, and even the simplest of actions - like writing a byte out to a file - have errors that require global knowledge to give good actionable feedback on.
So, yes, it's an uphil battle, but one that needs to be fought. I keep looking around at well established projects that don't even try, and as a user they are incredibly frustrating, because improving the status quo wouldn't require introducing global analysis, it might be as simple as adding an extra sentence with some internal state, a description with a few keywords to Google for, or a link to the docs.
I'm well aware of the effort needed to have great error messages. I'd be happy if the average error message was passable, instead of terrible.
Part of the problem (in open source) is that developers write tools for themselves first, so they are intimately knowledgeable about the internal state of the application, so they provide enough context for themselves. So little more is given unless enough people complain and the original developer agrees to change. In that ecosystem we constantly interact with tools written like that, so that's "the bar" we're used to. All our tools end up taking the approach of "The user did something stupid, I don't know", so that's what we do in our tools. And I completely reject that framing. I take the approach of "The user did something that didn't met the applications, sometimes implicit, preconditions." and take if from there. Maybe what they did was wrong due to a misunderstanding caused by bad docs, maybe the user did something wrong because we're missing a feature implied by the rest of the features, maybe the user hasn't done a necessary configuration step. All of those things can be checked for!
I can't think of any tool that isn't necessarily an error reporting tool. But few projects takes that into consideration and approaches it as "this is an error reporting tool first, and the actual thing it does is secondary". If the user cannot accomplish their task, it doesn't matter if it is the fastest tool in the West.
"Syntax error on line 1" is very different to "missing WHERE condition after AND on line 1 column 45".
A lot of the examples you have have alternative courses of action. Great, enumerate them in order of likelihood. Don't even claim to be right, just throw your users a bone. If you're right with any of them, you just saved them time and anguish. If you're wrong in all cases you mention, then you have a bug in your output. You can even get away with "these two things might be happening, but there might be other problems, can't help you more if so". "IO error", "couldn't to disk", "couldn't write to file", "couldn't write to file '/tmp/foo-bar'", "couldn't write to document metadata file '/tmp/foo-bar' because the file already exists and their permissions dont permit this user to write to it; you can change the path with '--metadata-path=/path/to/file" are all the same error, but I'd much rather get the last one, over the first one.
In practice, instead of describing the error, a policy for actionable error messages all too frequently results in something along the lines of
Action failed. Go to https://example.com/foo?code=E123 for more details.
I prefer an error message that isn't necessarily actionable, but tells me what the code was trying to do that failed, even if it's very low level.
Error: Disk quota exceeded while trying to write to "D:\scratch\ABCEF.tmp"
And of course these two approaches can't be easily melded without transmitting config, detailed failure information including disk free space etc. back to home base.
PS: I use Windows paths here because I noticed a significant degradation in error messages from Microsoft software in the early 2000s, which made it harder to fix problems locally without searching the internet for error codes and randomly trying out fixes from various forums.
I also believe that an industry-wide pull-back from exceptions as an error transmission mechanism resulted in worse error messages. Without runtime polymorphism to encapsulate context from the point of failure, the higher level parts of the app no longer have enough information to even give a descriptive error message, the way a top-level UI exception handler used to.
Edit: And actually I think this is a case that illustrates why error messages shouldn’t apologize. It would only make them less concise and beside the point.
For example by clicking a button that says "I'm sorry. I'll try to do better next time."
It worked for Microsoft, it will work for you
— <https://twitter.com/cherrikissu/status/972524442600558594?la...>
You know what's cyberpunk to me? Cyberpunk isn't about having robotic body parts and netrunning in cyberspace through your brain implants in a chrome-and-neon-encrusted arcology. Cyberpunk is owning a Taiwanese bargain-basement PC and booting Linux on it in 1995. Because like real punk rock, Linux was DIY and it showed -- it was messy. When you booted it up, there was no sugarcoating -- no warm and friendly bootup sound, no happy Mac smiling back at you. The various bits and bobs that made up a working Linux system started chattering to you -- all at once: first the drivers and kernel subsystems, then the init scripts, then some of the user-space daemons, all telling you unbidden how their day is going. Every component of the system told you what was going on with it, for good or ill. It would've been quite alarming to a normie; 1995 was far from the year of the Linux desktop. But I appreciated it.
And I resent error messages that try to mollycoddle me as a user. Apologies, "Something went wrong :(", and so forth. Just tell me, in the most rigid machine-like way, what happened. A stack trace would be helpful if the failed bit is open source.
Unfortunately some American companies are starting to cheapen out on translations by having them made in Mexico even for software used in Spain so the sorries and the pleases and some other spanglish terms are coming here.
When you present a user-facing error message, it's akin to admitting a failure of some kind. Whether it's a user error or a system error, the customer-centric position to take is that the responsibility always rests with the business. If the user made an error, then in theory it was the business's failure to prevent them from attempting to take that action. In practice of course, that's not always the case, but it's good practice to assume it by default. So I always like to include a "sorry", even if hypothetically it's not warranted.
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.
jtm@socrates ~ $ dotnet new -o foo console >/dev/null 2>&1 && cd foo && cat > Program.cs && dotnet build >/dev/null 2>&1 && dotnet run
String? bar = null;
bar.GetHashCode();
^D
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
at Program.<Main>$(String[] args) in /Users/jtm/foo/Program.cs:line 2
When user get "Sorry! Something went wrong." he has no handle to complain on the internet. He has no kewords to search for other users complaints and mitigation strategies they came up with.
You as a developer you seriously limit you capacity to react to the things you didn't anticipate if you don't give your users relevant information about which unhappy path your software took in their case.
Unless you have full default telemetry on a piece of always connected software you should give your users informative messages. Not necessarily immediately informative to them but letting them have a keyword for further inquiries.
(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.
Should error messages apologize? - https://news.ycombinator.com/item?id=7561139 - April 2014 (45 comments)
Should error messages apologize? - https://news.ycombinator.com/item?id=5012203 - Jan 2013 (46 comments)
They are like in the middle between formal and informal, or maybe I feel that way because in not native English.
A quick internet search tells me that "it seems" can be used in many context with many slightly different interpretations, so _it seems_ that it's not a good option after all.
"Sorry, Dave. I can't do that."
I don't know why we do it frankly - when there are real humans one can talk to, rather than pretending one is having a meaningful exchange with a website or advert.
++?????++ Out of Cheese Error. Redo From Start.
The error should be concise, assertive, objective.
"No. Your email won't be sent. The mail server at smtp.somewhere rejected the message."
"No. Whatever is in your address bar does not exist on this site."
"No. The update package file has a checksum mismatch, and the system will not apply it."
"No. The remote server dropped the network connection, leaving the update file only partly downloaded. The system has already retried the download 10 times and failed, so you will need to rerun the update."
"No. This program is compiled for a different kind of computer and won't run here."
"No. This is not a document file. You need to open it with another program."
"No. You supplied an incorrect username or password."
"No. You are trying to open a file too large to fit in the memory."
"No. Your form is missing required fields X, Y, and Z. Please fill them out before submitting."
"No. Your request encountered an internal error. Someone in charge of servers will eventually notice it."
"No. Just leave. Touch grass."
"No."
"NO!"
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."
“You broke Reddit”
Come on, I don’t think so!
No wonder the world is falling apart.