8 ms·

The web is sorely lacking a thorough “Best Practices for Reporting Errors to Users” reference document. Nielsen Norman Group has a decent short page with some s

by fwlr 4y ago

The web is sorely lacking a thorough “Best Practices for Reporting Errors to Users” reference document. Nielsen Norman Group has a decent short page with some suggestions https://www.nngroup.com/articles/error-message-guidelines/ https://www.nngroup.com/articles/error-message-guidelines/ but there is definitely more to be said on the matter. Oft-suggested is “human readable description instead of arbitrary error code”. Disagree; you should probably include the error code in the message (ERR0231), because that helps make the error message unique to this specific error situation and thus makes it functional as a “gathering point”. If you Google the error message and find others talking about the same error you experienced, that’s useful; if you Google the error message and find others talking about different errors on the same site, that is useless at best and could be harmful. (Concrete example: a multiplayer gaming platform reports a checksum of game files to a remote server to ensure all players are using the same version of the game. Scenario 1: The files are corrupt, the checksum is wrong, the error message is “Unable to validate game files”, the fix is to reinstall the game. Scenario 2: The user’s internet connection is temporarily degraded, the game is unable to get a response from the remote server, the error message is “Unable to validate game files”, the fix is to wait until connection improves. The unfortunate user from Scenario 2 is going to google their error message and get told to try the fix from Scenario 1. Now they’re re-downloading the game on their spotty connection.) Something I haven’t seen suggested is telling the user what parts of the process did and didn’t happen. Take the case described in the article. “We were unable to charge your card. The system has not created a ticket. The app has no ticket to generate.” (Something is wrong with my card, I can check my bank balance and try the purchase again.) vs “Your card has been charged. The system failed to create a valid ticket to be associated with your account. The app has no ticket to generate.” (Something is wrong with their server, I should not try to purchase again.) vs “Your card has been charged. The system has created a valid ticket but failed to associate it with your account. The app has no ticket to generate.” (Something might be wrong with my account, or something is wrong with their server. I can check my account page to see if there’s anything I need to update, but if I don’t see anything then I shouldn’t try the purchase again.) vs “Your card has been charged. A valid ticket has been created in our system and associated with your account. The app failed to generate this ticket.” (Something is wrong with the app on my phone. I should not try the purchase process again but I could try re-downloading the app and going to My Tickets.) The user by default has a mental model of the state of the world after a successful process, and you need to inform them which parts of their mental model need updating because of this error.

IIsi50MHz 4y ago
Every one of those is confusing. (1) Third sentence seems redundant. It adds no useful information, unless maybe you're privy to internal workings of the system (and maybe not even then). (1,2,3,4) If "the system" creates tickets, why is the app trying to generate them? 'Generate' and 'create' are too close in meaning, for me. (1,2,3) Why am I charged if the charge+ticket (which should be inexorably linked) did not succeed as a whole? I'd expect the charge automagically reversed (or better: prevented) as a consequence of rolling back the broken transaction. (3) If a 'valid' ticket was created, how is it not associated with my account? That seems like an invalid ticket to me! (4) Seems like the entire transaction (charge+ticket) completed, but mysteriously the app is informing me it doesn't need to or possibly has failed to do…who knows what, be cause 'the system' already has my ticket. The first scenario is the only one for which I agree with the suggested conclusions.

by fwlr 4y ago

IIsi50MHz 4y ago

Every one of those is confusing. (1) Third sentence seems redundant. It adds no useful information, unless maybe you're privy to internal workings of the system (and maybe not even then). (1,2,3,4) If "the system" creates tickets, why is the app trying to generate them? 'Generate' and 'create' are too close in meaning, for me. (1,2,3) Why am I charged if the charge+ticket (which should be inexorably linked) did not succeed as a whole? I'd expect the charge automagically reversed (or better: prevented) as a consequence of rolling back the broken transaction. (3) If a 'valid' ticket was created, how is it not associated with my account? That seems like an invalid ticket to me! (4) Seems like the entire transaction (charge+ticket) completed, but mysteriously the app is informing me it doesn't need to or possibly has failed to do…who knows what, be cause 'the system' already has my ticket. The first scenario is the only one for which I agree with the suggested conclusions.