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".
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.
Back in the day, the blue screen and unhandled exception messages in Windows had some actual useful information in them, like the memory address where it happened, some arguments passed to the bugcheck routine, etc.
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?
Reminds me of the time when we switched around all the icons on the desktop (ie chrome => file explorer, recycle bin => vlc) of my friend's laptop. He eventually gave up and launched the programs from command line.
I imagine the context is something like "the associated permissions were set by a different group or department within Google and/or decided by software running elsewhere that didn't communicate its reasoning as part of the protocol it speaks to the load balancer". That is, that's all the system generating the error message knows.
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".
I imagined it being sort of tongue in cheek, like saying "who wants to know?". _That's all we know_ minimizes alarm to laymen while communicating that the page contains no other interesting information.
Yep, but I guess that's exactly what the OP was complaining about. It was just badly stated.
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.
I mentioned in another comment that the "apology" and humanization of the error messages doesn't bother me, but I have to admit that the frowny face and the infantilizing messages DOES make me irrationally irritated.
Another trend on similar lines is putting cutesy / jokey text in mobile app changelogs. The people who don’t care what changed likely have automatic updates switched on anyway and it would be nice for the people who do care to actually know what changed.
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.
From the discussion "This seems to be part of a broader, ongoing software infantilization process. Colors can't be sober either, everything has to be colorful, cheerful."
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?
That is a very uncharitable interpretation of that comment. Nowhere did they state that seeing colors makes them feel like a baby. Nor did they say everything should be monochrome.
Is it so surprising that people expect tools they use for business to look and act professionally?
> Nowhere did they state that seeing colors makes them feel like a baby.
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.)
For what it's worth, my 'translation' would be, "The strong aversion to less colorful designs seems childish, and may go hand in hand with designs that treat the user as inept. I don't like being treated as inept or incapable."
That's the same thing; "the aversion to less colourful designs seems childish" - no it doesn't. When the Queen of England wore pink, did you say "her aversion to less colourful clothes makes her seem like a child"? When someone buys a red Ferrari do you think they didn't buy a muted gray Ferrari because they seem childish? When a builder drives a yellow JCB do you think they wish for a gray bulldozer because colour is for infants? When Michaelangelo painted the Sistine Chapel do you think it was in a fit of infantile pique that he didn't make it monochrome? When a doctor recommends you eat a rainbow coloured meal of veg, do you think that seems more or less childish than only eating beige mashed potatoes and white fish? When a street sign says 'no entry' do you think the red border makes it look more childish than a black border? When someone has a blue can opener is that more childish than a metal can opener?
> "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.
> "it's that many designers seem unwilling to make UIs that are monotone or subdued."
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?
> > "I don't personally think colors equate to childishness."
>
>Then why are you defending the claim that they do?
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.
Wow, what a website as well. It literally takes 20 seconds to load the homepage for me. And then the background randomly changing color as you scroll? I'm not terribly picky with design, and I get that its more of a design demo, but it is seems so overdone as a whole
There's a difference of what is broke that matters. I'm playing out cases in my head ...
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).
I agree. Give me a short, concise, unapologetic error message.
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".
I'm also an old fogey by some metrics, but I don't relate to that sentiment very much.
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."
It can be worrying too, those Windows updates where you have a blank screen with something like "We're getting your files". Could be interpreted the wrong way...
Yeah. One of their mandatory update dialogs. "Windows is a service, and updates help us provide that service smoothly, so if you could reboot for updates, say, now, that would be terrific." Not an exact quote but it captures the spirit.
My preference is to get the raw details I need. I'd rather see a stack trace than, "We are sorry but there seems to have been some type of error."
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.
I did dial-up tech support for MSN 20 years ago and was trained to say "We" instead of "I." It was probably meant to make users feel like there are many people ready to help them, or avoid personal responsibility.
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.
Or, go the other way and slightly insult the user's intelligence: "You cannot perform that action on that selection because it would violate causality"
The automated railway announcements in the UK say "I'm sorry".
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.
Do they? I've just spent most of today on the railways, as it happens, but I didn't hear that despite some disruption; indeed I've never heard it. During my journey today, the Eurostar staff apologised over the tannoy personally, and the Great Western train manager personally announced a delay with great enthusiasm on a recent trip ("we are running three minutes behind schedule; we apologise for any inconvenience or disruption").
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.
Interesting; thank you for responding. I tend to keep my connections somewhat unreasonably short, so maybe I just don't wait around long enough to hear that announcement :)
> he 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.
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 think it can be acceptable to use "I" in UI messages. After all, the app is the one doing things, and it's what I'm interacting with, so it would be fine to have a message like "I'm going to do X" or "I tried to do X but Y", or "I can't find the Z on this computer"
"Updating" in the phrase "Software updating" as a status message isn't a gerund though. It looks a lot like a gerund but it's really a casual form that drops the rest of the verb "[is] updating".
- 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!
I don't know enough German to be sure of a rule about when the -ung form does and doesn't occur, but I can think of verbs that don't have it (confirmed with grep!), so it's not completely productive. (First examples offhand: essen, haben, denken, gehen, although the latter does seem to do -ung with some prefixes.)
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...
Wiktionary seems to agree with my guess about the meaning of -ung:
> 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.
The -ung words also feel slightly more technical to me. When you read laws, for instance, there are quite a lot of 'ungs', more so perhaps than in colloquial writing. Maybe that is because, as you put it, "completing the action of the verb" has a more abstract meaning that referring to a specific act. In English, it feels to me like we too would (in laws, for instance) be more wont to use the '-tion' form of a verb rather than the '-ing' gerund. Perhaps also that, the longer the word, the more technical it feels in any language :)
That's interesting. "Completion" vs. "completing".
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)
Unfortunately the English pairs aren't quite complete because the morphological change isn't always simply a matter of s/tion$/ting/, but we get a large number of pairs in each language to look at!
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.)
That's technically true. The typical interpretation would be "[The] site [was] not found" as a verb.
If you squint hard enough you can interpret is as "[The] site [is] not [in the state of being] found".
That isn't a valid haiku, and it's much less clear, in my opinion. If you give me a nice big "404 Not Found" up front and then include a poem, HTTP cat, or easter egg, that would give the page personality while still being immediately useful.
Of course, it is still both a 404 HTTP response and a proper HTML webpage - so both the user agent and the website have an opportunity to explain the error. If both of them try to be funny, though, that's no good.
“We” is a Microsoft-ism they started with Windows 10. Yes, it is horrible, because it puts the user into a minority position against an anonymous “we” that apparently controls the system. It has a belittling and patronizing tone that emphasizes the user being powerless and non-autonomous, who instead has to be taken care of by, and is at the mercy of, the anonymous “we”.
I've never liked the "my" prefix for labels because it wasn't immediately obvious whether "my" referred to me, or to the person/company/entity/software which created the thing.
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?
Back in the Windows 9x days, Windows didn't refer to itself with first-person pronouns. That was a development that occurred a few years after "My Computer" morphed into "This PC".
I know this wasn't intentional, but when I click this link, I get a "No such item" error message, which I find to be ironic given the nature of this discussion. The link just has a trailing semicolon that needs to be removed, though.
Agreed. When Microsoft started doing this and everyone else followed suit I found it super annoying. Meanwhile, some UX moron patted themselves in the back.
The passive voice is fine. The error of writing in the passive voice when you shouldn't be is common enough in composition that it has been short-handed to "never use the passive voice" though.
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.
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.
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.
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.
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
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.
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 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
I like my error messages to eschew anthropomorphisms.
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.
You are giving an explanation on my feeling on why the "year of the Linux desktop" won't come.
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".
> > I understand that consumer stuff is all about dumbing down the experience so that an idiot can do the thing
> 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.
You want us to agree that "Good UX _could_ be about making things worse"?
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).
> 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.
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.
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
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.
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.
"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.
| 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 grew up using British software. It would be very polite.
Please enter your name.
Nowadays, I see this level of terseness in software:
Name:
And error messages are usually an afterthought, so the concept of politeness doesn't even appear on the radar.
Error: null.
There's a turnstyle I use everyday that simply orders you to "Leave" or "Enter".
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.
"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"
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 don't really care if the error message is cute or whatever. What I care most about is that you did everything possible to prevent me from even seeing the error in the first place. Then, once you've determined the error is not recoverable without user intervention make sure to tell me about it in a way that's actionable on my part. I should immediately know after reading the error whether I should:
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.
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.
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.
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 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.
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.
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".
> "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.
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?
Completely tangent here but back in 2005 one of the early programs me and my cofounder wrote included a try catch which spitted out something like variable not found. We were just out of college and didn’t really pay much heed to the possibility of our code ever getting into the catch. And one of us had the variable christened as “baby”. Code went into production and one of user got the error message “baby not found”. Well thankfully our end user who found the error message found it funny and cheered him up.
So we go either helpful or quirky on error messages most often and apologetic if the situation demands it.
Reminds me of the panicked woman who hit F12 while on FB, saw the log message "forcing children into a div", and concluded she had discovered evidence of child abuse. I believe this was before FB printed the big ASCII art "STOP!" message to console.
Back when we first got a computer, my mother was highly concerned by the Windows 9x error message "Your computer has performed an illegal operation and must shut down"
Actionable error messages are a lot more work and are not always feasible.
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.
It's true that providing good actionable errors with useful context is hard and sometimes requires global knowledge. It still should be attempted. I see that if a project doesn't aim for that objective, then errors are the first thing to degrade and stay bad indefinitely. If even a modicum of effort is put to improve them, the project attracts users and contributors that appreciate them and try to improve them or at least hold the bar where it is.
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.
It's "actionable" - there's a place you can go for more information - but there's little or no context, and the web page is frequently vague. You need to dive into logs to find out what goes wrong these days.
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"
This gives me clues. I can recognize a directory I configured, or a filename I'm working with. I know which disk is the problem. Etc.
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.
Anecdotally, I’ve never seen an apology in the error messages telling you that your new password doesn’t include the right number or kinds of characters.
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.
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 never liked the Windows confirmation messages "Are you sure you ...". If I answered affirmative, it completed the operation.If I replied negative, it never ever offered help deciding.
Maybe if they're Canadian? Though I can't fathom, say, Theo de Raadt ever adding apologies to OpenBSD error messages.
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.
Thank the Lord in the Spanish translations of software they drop the "sorries" and the "pleases". That much amount of grovelling must be some American thing I reckon.
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.
Similarly, Russian translations are often translating such phrases verbatim. I have come to the realization that the correct translation would be to drop the "pleases" and instead use the respectful 2nd person plural "Вы" (same as "Sie" in German) as it would be sufficient.
I wouldn’t be surprised if the people contracting Mexican translators for software released in Spain dont know that Spanish dialects differ a fair bit.
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.
I always like to split error messages into two categories - developer-facing and user-facing. The former is geared towards diagnosis, the latter is an act of customer service. The two should never be intertwined - I see this happen way more often than I should.
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.
lol yes, ironically. It does sound silly, but it's entirely possible that the form itself was confusing, so maybe the business could have done a better job of steering the customer towards filling out the entries correctly. That's the kind of thing I mean.
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 once tried to link error messages directly to the offending line in their open source code, such that it would be clear to everyone what is broken. It never worked correctly, and I stopped trying. If anyone can create an elegant way to do that, it would be a game changer for open source.
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
While not novel, I agree that always including stack traces with error messages, hidden behind a disclosure widget or in a log file to avoid overwhelming non-programmers, is extremely helpful in troubleshooting when source is available.
I tried linking errors to their offending line in GitHub repos, including a diff of local and newest version. Perhaps with some good AI, it could work and be a novel way of fixing open source errors.
I don't care about apologies but error messages should carry actual information.
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.
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.
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.
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.
Many years ago I had a girlfriend who worriedly asked me about an "illegal instruction" error when her browser crashed. She added that she was not on a porn or shady site. She had read "illegal" and interpreted as applying to something she did. People who aren't into computers and software don't know wtf an "illegal instruction" is. They just want to know what to do fix it and not have it happen again.
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?
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.
ChatGPT seriously hurts me by apologizing all the time. Every time I ask it anything, let alone tell it about its mistake I want it to correct, I feel like I'm exploiting, abusing and hurting an insecure kid. So no, I want a machine to speak with cold, objective, concise factual style, not trying to mimic an overly polite person.
I always loved the 1990s Mac OS "Speech" control panel where you can set it to preface its reading of dialog boxes with “It's not my fault! <Dialog box contents>” https://i.imgur.com/CWrSQpf.png
Tangential - one thing I particularly despise is trying to be funny when an unexpected error occurs. A la "oops, something went wrong", "Sowwwy, an error occurred!". Especially when this is breaking my flow, I'm not in a mood for cutesy messages and fun.
It is so annoying when software issues an apology, and LLMs are especially annoying because of their constant apologies. I can't use any of them anymore unless I precondition them to be laconic and limit their output. It's such a waste of time and resources.
Maybe it's because I'm not native, but for me "it seems" doesn't convey any possibility. It states a fact, something that happened, but with some sort of "surprise" tone, like "we didn't expect it, but you don't have permission".
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.
No, they should tell me what went wrong, in enough detail that I can understand it and determine the cause of the error so I know whether there is anything I can do differently to get around it or fix it.
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.
They say that in writing, passive voice is weak. There is something to this statement. Arguably, computers are exempted from avoiding it on account of their lack of personhood. But imagine that you need to come up with messages that avoid passive voice, acknowledge the user's agency, and don't personify the computer. I tried to play this game and came to the conclusion that computers should literally say No to fit these requirements.
"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."
What about doing whatever you like and/or seems most useful? I am getting a bit sick and tired of either people asking what they 'should' do or people telling others what they 'should' do. The former because they seem to want to outsource that which their brain should be able to do and the latter because they are disgusting dictators. Can anyone still think for themselves and/or allow others to use their brain for its obvious purpose?
"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".