question

"Considerably more detail on the card" is a good start. I have special utility code at the topmost level for trapping exceptions and converting them into a "gracefully degraded" response. I don't read the stack trace, but I do dump it to the card. Overall, you have to remember this is a consumer device running in people's home. Not only that, it is a conversational device. The more it behaves like a conversational partner, the more people will engage with it. Again, I have utility code that creates a data structure for the response which is populated as the business logic progresses. (That's from a chapter in my book.) One of the functions to add to the response lets you specify not just one, but an array of strings. It will randomly select among them which is added. (The string supports a syntax that lets you also add to the card from within the same string.) I use this so that I can vary the response. I noted while reviewing skills that hearing the same vocal prompt over, and over, and over again got really tedious. My general rule of thumb is to have at least three different versions of reach response I make to the user. For very frequent messages (e.g. "you've just moved" in Starlanes) I have 12-15! For something like an error message, it depends. If it's a "something went wrong" technical error, then I actually want specific text that I can search for in the code. If it's a "you've done something wrong" warning, I am more likely to put in variance, depending on the frequency I see the user hearing it. Fortunately, such messages are just output, and not tied to the interaction model. If you instrument your code such that you log all errors, you can track over time the frequency of the errors, and add alternatives for those that are more frequent. [While waiting with my laptop in the doctor's office yesterday I was busy adding variant responses to Starlanes!] If Amazon ever get around to supporting multiple languages... it's going to be a *censored* to localize...