"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".

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.

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"

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.

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 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!

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.

"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"

  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.

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".

So we go either helpful or quirky on error messages most often and apologetic if the situation demands it.

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.

It worked for Microsoft, it will work for you

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.

    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 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.

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.

"HN commenter" is already a much tighter bubble than "the West".

I'm administrator! :'-(

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

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".

Funerals must be bewildering for them. How do they phrase "I'm sorry for your loss"?

"I apologize for your loss".

I'm not a native speaker but I feel like Americans would say that too.

Every time an error happens, you get a popup with an AI version of our boss bowing down in shame.

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.

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.

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.

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.

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.