A poor underlying model is often revealed through casually thrown (or thrown off) error messages. One post hoc way to address this deficiency -- though it may not improve the model's weaknesses -- is to request feedback from message recipients. Microsoft Office users are sometimes requested to indicate whether a particular message is effective, as shown in this screenshot. Not all messages offer this feature; it would be interesting to know how Microsoft determines which messages deserve this treatment, and what internal workflow accompanies the feedback.
Saturday, March 13, 2010
Most of the screenshots collected in errorprocessing.com involve obvious errors. Messages that are painfully obvious are thrown onto the screen, or traceback messages of use only to developers replace "normal" screens. There are other sorts of errors. Some errors are more abstract, or, stated in MVC / DSL language, occur at a higher level in the software model. In this case, a screenshot may not reveal the error. A recent example occurred when activating a replacement phone with Sprint. The Sprint web content that solicited the phone identification strings directed users to phone-specific instructions on programming the phone to reflect the new phone activation steps. I clicked into the phone-specific page, but instead of the new phone's instructions, the web content showed the old phone instructions. After 15 minutes of browsing the Sprint site failed to find FAQs for the new phone, I resorted to Google, which returned the specific URL needed: http://support.sprint.com/support/device/HTC/HTC_Touch_PRO-PPC6850SP. Result? No screenshot, but an error nonetheless. Considering how software test applications must be developed to detect failures of this sort, it is perhaps clearer why knowledge engineering is an integral part of developing model semantics as an integral part of software engineering.