Many of our users are probably familiar with the “unique error phrase” that shows up whenever our application crashes in some way. These have a curious form, and we wanted to share the motivation behind them.
When diagnosing problems, it’s helpful to be able to associate a specific customer incident with information in the logs. Whenever our app crashes, we generate a unique ID for the incident, which is shown to the customer so that they may include it when they write in to us about a problem. This is not a novel practice—it’s actually fairly primitive—but given an ID our staff can jump directly to more technical information on the customer’s issue, letting us classify and respond to it more quickly.
What is novel in Asana is the form these IDs take. 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, and so for the sake of curiosity—and to add a little levity to an otherwise frustrating situation—we tried something different.
Imagine representing 32 bits of information (numbers up to 4 billion) as a sentence instead of a jumble of digits. Each sentence can have the same predictable structure, and the number will be used to choose words from a dictionary to fill in that structure—like Mad Libs.
One possible sentence structure can be: count + adjective + plural noun + verb + adverb, e.g. “6 sad squid snuggle softly.” We can divide the bit-space of the number like so:
5 bits for the count (2-33, so it is always plural)
7 bits for the adjective (one of 128 possibilities)
7 bits for the plural noun (one of 128 possibilities, which we made all animals just for fun)
7 bits for the verb (one of 128 possibilities)
6 bits for the adverb (one of 64 possibilities)
Now, given a dictionary containing words categorized in this way, we can generate 4 billion unique (and sometimes very memorable) sentences. In Asana, the ID used to generate the error phrase is random, so the same sentence is unlikely to occur twice.
Since we care deeply about providing users with a stable experience, we have put major effort into a system which records problems that occur anywhere in our application, whether on our servers or in customers’ browsers. It collects a bunch of useful information about the crash (stack traces, log snippets, application state, user and session information, etc.) and automatically groups similar problems and imports them into an internal Asana task list, pictured below.
Having all of the issues in Asana allows us to see aggregate information on each problem, such as the number of occurrences and different users it has affected. From there we can tag, prioritize, and assign it so it gets fixed. This system makes Asana a very effective issue tracker for us, as each issue has lots of important metadata associated with it—including, of course, a way to find it from a unique error message reported by a user.
So, in the event you experience a crash, rest assured it’s already on the list for our team to act on. And we hope you at least get a gem as a consolation prize. 12 soft kittens cuddle warmly. Or 8 mad orcs stomp loudly. Or .. you get the idea.