4 ms·

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 su

by 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.
legalcorrection 4y ago
These days, if something is print only or has similar stupid hurdles, I suspect that the purpose is market segmentation. Some people will prefer to avoid the hassle and just pay full price or go without. Which means the company can offer that much more value to the people who are willing to go through the hassle.
makeitdouble 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. Do you really intend to put links into error dialogs ? Faced with that dialog you're already pissed, the software disappointed you and you now have to take an extra action (push the button) to even continue using the app or try again. Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it. I find the author deeply disingenuous in that we have the emotional rant, but not what they actually did next as a user to solve that issue. Did they just refresh the page, the request resent and everything went well ? Did they send a "WTF?" angry message to support, who tracked their session from their username and made it all good for them ? (and yes, Trainline has really good support for the industry they're in) I mean, it might as well be that the app auto-resent the request and solved the issue without the user doing anything, and we'd have not idea. That error message probably was there just to state it failed at a specific try, and further action depends on what's happening next in the app.
- autoexec 4y ago
  > Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it. Putting links in error dialogs seems like a set up for a situation where clicking that link produces another error with another link that also won't work followed by another and another etc.
  - zerocrates 4y ago
    Just reminding me of all the times I've seen "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request"

by bmj 4y ago

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.

legalcorrection 4y ago

These days, if something is print only or has similar stupid hurdles, I suspect that the purpose is market segmentation. Some people will prefer to avoid the hassle and just pay full price or go without. Which means the company can offer that much more value to the people who are willing to go through the hassle.

makeitdouble 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. Do you really intend to put links into error dialogs ? Faced with that dialog you're already pissed, the software disappointed you and you now have to take an extra action (push the button) to even continue using the app or try again. Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it. I find the author deeply disingenuous in that we have the emotional rant, but not what they actually did next as a user to solve that issue. Did they just refresh the page, the request resent and everything went well ? Did they send a "WTF?" angry message to support, who tracked their session from their username and made it all good for them ? (and yes, Trainline has really good support for the industry they're in) I mean, it might as well be that the app auto-resent the request and solved the issue without the user doing anything, and we'd have not idea. That error message probably was there just to state it failed at a specific try, and further action depends on what's happening next in the app.

autoexec 4y ago
> Imagine on top of that putting a link that pushes you to either your phone dialing popup (which will take you out of the app and you'll be on the phone while trying to get back to your previous screen to explain what happened), or a link that throw you into a page, and you'll be trying to understand why, and what you're supposed to do with it. Putting links in error dialogs seems like a set up for a situation where clicking that link produces another error with another link that also won't work followed by another and another etc.
- zerocrates 4y ago
  Just reminding me of all the times I've seen "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request"