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:

Section: Dashboard, Date: 08-20-2011 5:30amPST, Count: 2

Section: Report Page 1, Date: 08-22-2011 9:30amPST, Count: 1

or Crash Incidents:

12 old crickets buzz happily

9 young monkeys smoke slowly

Asana makes weird decisions sometimes.

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?"

Hmm, I hope none of your users ever have login issues.

thanks!

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 like the idea, but I would expect to see a lot of very confused users when that error message is displayed.

Any feedback on that from your users?

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."

Love it. Someone please write a Node.js library for generating these.

Here you go - I called it Greg, after mr Slovacek.

https://github.com/linus/greg

  npm install greg

Disclaimer: I wrote this in a fit of insomnia, so it's probably buggy and there are too few words. Pull requests are welcome!

Excellent! Thanks.

"12 old crickets buzz happily"

Are they happy because they made the program crash?

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..."

I'd be waiting for a "10 green bottles hanging wall" error.