There's some nice synergy between this idea and the now-famous xkcd about passwords from a few weeks ago:
http://www.xkcd.com/936/
The information-theoretic idea of encoding bits as words leverages the things that humans are just cognitively better at. When a transmission medium is likely to involve a human brain at some point in the trip, it behooves us to remember that brains are not always good at the same things computers are....
seems like overengineering.
Keep an index based on the user id with a sequence of date incidents and show the user a list of incidents with page location context.
Having the user remember a date seems more reasonable than some phrase they have to copy and paste from somewhere.
Would the user rather see this list:
Crash Incidents:
Seriously? I think the latter is a lot less scary in a lot of ways, and it contains a very specific identifier even if multiple things were happening at once. It also has built-in error correction in case the user reporting the error mis-reads one digit or something that "isn't important". And time zones in the identifier are just begging for misconfiguration problems.
Don't forget that the error phrase is not seen in a total vacuum. It is prepended with the sentence "If you contact us about this error, here is your unique error phrase", which even un-savvy users will recognise as a password (in the children's "what's the password?" sense), that they need to remember exactly and that doesn't itself directly carry information.
On the other hand, if you print out the date/time as part of the error message, the user is just going to glance at it, say, yup that's the current time, and then totally fail to record it (because there's no new information there, right?) or even worse, try to remember it and end up guessing at the time or even the date, making it almost worse than nothing.
you don't report anything to the user other than you're issue has been logged, when cust service looks up the user account they'll be able to pick out incidents themselves and verify with the user.
"Hello Bob, I see you have 4 incidents today that we've logged, are you calling about the issue with the Dashboard page?"
I agree. This weird phrase is still an exposed 'system code'. There still is no reason to expose a system code, no matter how cute.
If you've managed to log the error and displayed a payment page, you are in a good enough state to automatically send an email and/or file a ticket. You can refer to the ticket since that is the actionable object.
I'm afraid that the user, expecting something (from bad error reporting in other places) like "Resource 0x23498382 failed to close", will interpret the error message as a further malfunction.
However, it does remind me of something pgp did, where a bit string (a key hash, I think) was converted into a sequence of words pulled out of a phonetically-distinct dictionary.
They should have expanded on this: "In most other applications, a customer-facing ID is usually a long jumble of numbers and/or letters. There are lots of small, subtle drawbacks to representing a number to a human this way."
Apparently there are at least two neg voters who think that showing an error message that something is "happy" when the app crashes to John Q. User is a good idea.
Asana breaks so frequently that their users will not be particularly frightened even if they changed their error messages to dirty limericks and communist propaganda.
It's pretty good about not losing data, so the several-times-a-day crashes are more of an annoyance than anything else, and their UI is the nicest I've used, but they still need to work on being more stable than Windows 95.
I wasn't so keen on the idea until you mentioned "dirty limericks and communist propaganda". I could be mollified after a crash if I read
"This software refuses to comply with the oppression of the proletariat by the boss classes. Bug reports are bourgeois revisionism! Revolution is the only solution! There was a young fellow from Buckingham..."
