4 ms·

> “Token not provided in guest headers.” I have no idea what this means, or what I can do about it. At least this example gives you something that you can repo

> “Token not provided in guest headers.” I have no idea what this means, or what I can do about it. At least this example gives you something that you can report to support of you do contact someone about the issue. It if you are a bit techie you might be able to judge for yourself if trying again is worth it or a waste of time. Many issues don't even give you that much.

ravenstine 4y ago
My all-time favorite: > "MySQL server has gone away" Gone away? You mean like it packed its bags and hopped aboard a train to another town? Surely you're not trying to say that the connection timed out or anything more specific.
- Aeolun 4y ago
  I kinda wonder why that was never fixed/improved. Too many error handling dependent on that specific message maybe.
  - manwe150 4y ago
    Maybe because ‘gone away’ is the best it can know without a full network diagnostic? Else why is the connection timed out: did it do something wrong and get punished? Or did I wait too long to get a reply, or perhaps I was online too long today, or are you saying it is shareware, and I need to reset the trial clock? xD
- gtowey 4y ago
  In this case it might be hard to improve. It's a message generated by the client which means that it was expecting something from the server and instead the connection was terminated. It's a sign that something has gone wrong on the server side, but it's impossible for the client to know what that is. Especially because most of the time MySQL connections are each a thread and there may be time between when something server side terminated the thread and when the client tries to talk to the server again. It's better for the server to release all the resources immediately instead of waiting for the client so it can return a more helpful error message.
  - wlesieutre 4y ago
    > the client was expecting something from the server and instead the connection was terminated That’ll do fine
    - HelloNurse 4y ago
      More classic: the XYZ server "did not respond in a timely fashion": informal (without overly technical concepts like terminating a connection), avoiding possibly wrong or useless details, abstract (implying that the user is a mature person who understands that clients need to communicate with servers) and easily combined with high-level instructions like "check for server problems or network issues".
      - tremon 4y ago
        the XYZ server did not respond in a timely fashion This error message is still potentially wrong and useless though. Potentially wrong: the client is in no position to judge whether the server didn't respond, the server didn't receive the request, or the response got lost along the way. Useless: "timely" isn't succinct enough, what was the developer's expectation of a timely response? 5 seconds? 30 seconds? 5 minutes? "No response received from server XYZ after N seconds" is both more accurate and more informative.
        jodrellblank 4y ago
        > ""No response received from server XYZ after N seconds" is both more accurate and more informative." Like those news articles which breathlessly report "nobody from the company was immediately available for comment" as if that was as interesting or relevant as a comment would have been. It isn't. Wait a couple of minutes and call them back, then report what they said. Imagine you call Comcast callcenter about your account and the conversation goes: You: "I ordered xyz deal it but I'm still seeing the old price, can you help?" Employee: "Sure, will you hold while I check that on the computer?" You: "Yeah, ok" pause Employee: "No response received from computer after 15 seconds. Click {hangs up} bzzzzzzzzzzzz". You: "that was accurate and informative, thumbs up"
bmj 4y ago
Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. Some users might be savvy enough to take a screenshot, but that isn't likely a good support plan. I have come to believe that many (most?) engineers and user experience designers actually hate people. I was recently in the western U.S., attempting to get information from a ski/bike resort about mountain biking there for the day. This was no two-bit, small town resort. The website was absolutely terrible. Links to basic information led to 404 pages. And today, my wife and I were looking for information about our local museum's free teen membership program. On the info page, there was a large button with text "Apply Online." Clicking that button led to a form that could only be printed. There was no way to actually "apply online." I've been working in the industry for almost 25 years. One of the most important things I've learned is that no matter "intuitive" the user interface seems to me, an engineer who likely has the various workflows burned into memory, you either need to have someone with NO experience look at the UI or, at the very least, have the ability to look at the user experience through the eyes of a non-tech-savvy user. Or, even just an engineer who just wants to download a trail map, or apply so his kid can get into the museum for free.
- dspillett 4y ago
  > Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. This is true, even of other devs which is particularly annoying¹². But these days I have the luxury of not dealing with clients directly so can just close things with insufficient information as CNR and move on, and have the joy of colleagues who make better use of the brains they have! Sometimes the only solution is ample telemetry and hoping that the user can give your a reasonably accurate time of the incident when making a support call so you can reference that information. Though this can't help as much with client side problems that block the telemetry getting through, what information you do get can help greatly with reproducing, or just walking through with reference to the code, the issue, to work out what has gone awry. > I have come to believe that many (most?) engineers and user experience designers actually hate people. While I do occasionally work on front-end matters I'm usually not a UX person these days³ so I can't speak from that angle, but yes I do dislike a lot of the general populous! I think the problems you describe come from a position of disinterest rather than hate though, and a sign that a more varied team is needed. You need someone who is passionate about providing a good UX rather than playing with clever things and making stuff technically work. You also need a culture of taking care over your work too rather than doing minimal happy-path testing then throwing it out there⁴. > One of the most important things I've learned is that no matter "intuitive" the user interface seems to me I can't remember who said it, but I've always liked the quote “the only truly intuitive interface is the nipple, everything else has to be learned”. As you suggest, it is important to try put yourself in the mind of someone who is hitting your work for the first time without any of your experience, which can actually be quite difficult to do reliably. The other difficulty is the range of users any given application might encounter: sometimes you have to balance guiding the inexperienced, without hindering those who don't want to be bothered, preferably without effectively having two complete UIs to maintain. -- [1] being interrupted with “I'm trying to X and I'm getting errors” “What errors?” “Something about the database, I didn't take a note” (to which the answer is “well reproduce it and come back to me when you've got useful information”, but by this point I may have lost concentration on what I was working on). [2] One of the most annoying people I've worked with once said in response to me asking for the usual details, in an exasperated tone, “you always ask that” - the idiot was well aware that the information would be required and got irritated at it being needed instead of actually bothering to note it. [3] I used to do a bit of everything in smaller companies, as things have grown I've specialised more towards database work, and infrastructure to support other devs. [4] Though we have a full QA resource, we spend plenty of time doing “devtest” and making/updating/checking automated tests. QA (or in companies without that resource, the users) shouldn't be finding glaringly obvious issues because I rushed through one test case and didn't even think about anything closer to the edges.

ravenstine 4y ago

My all-time favorite: > "MySQL server has gone away" Gone away? You mean like it packed its bags and hopped aboard a train to another town? Surely you're not trying to say that the connection timed out or anything more specific.

Aeolun 4y ago
I kinda wonder why that was never fixed/improved. Too many error handling dependent on that specific message maybe.
- manwe150 4y ago
  Maybe because ‘gone away’ is the best it can know without a full network diagnostic? Else why is the connection timed out: did it do something wrong and get punished? Or did I wait too long to get a reply, or perhaps I was online too long today, or are you saying it is shareware, and I need to reset the trial clock? xD
gtowey 4y ago
In this case it might be hard to improve. It's a message generated by the client which means that it was expecting something from the server and instead the connection was terminated. It's a sign that something has gone wrong on the server side, but it's impossible for the client to know what that is. Especially because most of the time MySQL connections are each a thread and there may be time between when something server side terminated the thread and when the client tries to talk to the server again. It's better for the server to release all the resources immediately instead of waiting for the client so it can return a more helpful error message.
- wlesieutre 4y ago
  > the client was expecting something from the server and instead the connection was terminated That’ll do fine
  - HelloNurse 4y ago
    More classic: the XYZ server "did not respond in a timely fashion": informal (without overly technical concepts like terminating a connection), avoiding possibly wrong or useless details, abstract (implying that the user is a mature person who understands that clients need to communicate with servers) and easily combined with high-level instructions like "check for server problems or network issues".
    - tremon 4y ago
      the XYZ server did not respond in a timely fashion This error message is still potentially wrong and useless though. Potentially wrong: the client is in no position to judge whether the server didn't respond, the server didn't receive the request, or the response got lost along the way. Useless: "timely" isn't succinct enough, what was the developer's expectation of a timely response? 5 seconds? 30 seconds? 5 minutes? "No response received from server XYZ after N seconds" is both more accurate and more informative.
      - jodrellblank 4y ago
        > ""No response received from server XYZ after N seconds" is both more accurate and more informative." Like those news articles which breathlessly report "nobody from the company was immediately available for comment" as if that was as interesting or relevant as a comment would have been. It isn't. Wait a couple of minutes and call them back, then report what they said. Imagine you call Comcast callcenter about your account and the conversation goes: You: "I ordered xyz deal it but I'm still seeing the old price, can you help?" Employee: "Sure, will you hold while I check that on the computer?" You: "Yeah, ok" pause Employee: "No response received from computer after 15 seconds. Click {hangs up} bzzzzzzzzzzzz". You: "that was accurate and informative, thumbs up"

bmj 4y ago

Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. Some users might be savvy enough to take a screenshot, but that isn't likely a good support plan. I have come to believe that many (most?) engineers and user experience designers actually hate people. I was recently in the western U.S., attempting to get information from a ski/bike resort about mountain biking there for the day. This was no two-bit, small town resort. The website was absolutely terrible. Links to basic information led to 404 pages. And today, my wife and I were looking for information about our local museum's free teen membership program. On the info page, there was a large button with text "Apply Online." Clicking that button led to a form that could only be printed. There was no way to actually "apply online." I've been working in the industry for almost 25 years. One of the most important things I've learned is that no matter "intuitive" the user interface seems to me, an engineer who likely has the various workflows burned into memory, you either need to have someone with NO experience look at the UI or, at the very least, have the ability to look at the user experience through the eyes of a non-tech-savvy user. Or, even just an engineer who just wants to download a trail map, or apply so his kid can get into the museum for free.

dspillett 4y ago
> Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support. This is true, even of other devs which is particularly annoying¹². But these days I have the luxury of not dealing with clients directly so can just close things with insufficient information as CNR and move on, and have the joy of colleagues who make better use of the brains they have! Sometimes the only solution is ample telemetry and hoping that the user can give your a reasonably accurate time of the incident when making a support call so you can reference that information. Though this can't help as much with client side problems that block the telemetry getting through, what information you do get can help greatly with reproducing, or just walking through with reference to the code, the issue, to work out what has gone awry. > I have come to believe that many (most?) engineers and user experience designers actually hate people. While I do occasionally work on front-end matters I'm usually not a UX person these days³ so I can't speak from that angle, but yes I do dislike a lot of the general populous! I think the problems you describe come from a position of disinterest rather than hate though, and a sign that a more varied team is needed. You need someone who is passionate about providing a good UX rather than playing with clever things and making stuff technically work. You also need a culture of taking care over your work too rather than doing minimal happy-path testing then throwing it out there⁴. > One of the most important things I've learned is that no matter "intuitive" the user interface seems to me I can't remember who said it, but I've always liked the quote “the only truly intuitive interface is the nipple, everything else has to be learned”. As you suggest, it is important to try put yourself in the mind of someone who is hitting your work for the first time without any of your experience, which can actually be quite difficult to do reliably. The other difficulty is the range of users any given application might encounter: sometimes you have to balance guiding the inexperienced, without hindering those who don't want to be bothered, preferably without effectively having two complete UIs to maintain. -- [1] being interrupted with “I'm trying to X and I'm getting errors” “What errors?” “Something about the database, I didn't take a note” (to which the answer is “well reproduce it and come back to me when you've got useful information”, but by this point I may have lost concentration on what I was working on). [2] One of the most annoying people I've worked with once said in response to me asking for the usual details, in an exasperated tone, “you always ask that” - the idiot was well aware that the information would be required and got irritated at it being needed instead of actually bothering to note it. [3] I used to do a bit of everything in smaller companies, as things have grown I've specialised more towards database work, and infrastructure to support other devs. [4] Though we have a full QA resource, we spend plenty of time doing “devtest” and making/updating/checking automated tests. QA (or in companies without that resource, the users) shouldn't be finding glaringly obvious issues because I rushed through one test case and didn't even think about anything closer to the edges.