"Sitting Tight" at LinkedIn

In the course of some routine site browsing at LinkedIn.com yesterday, the error shown above was thrown. It's polite, aesthetically acceptable (if not pleasing) -- even hopeful, but the message implies that one should take no action. Just "sit tight." 

I struggled to think of an error condition that had visibly recovered itself in a timely way with no interaction required from me. It's possible that some exist, though none came to mind, and my skepticism was rewarded by having this screen remain static for 90 minutes. An auto-refresh might have effected a change, but starting a new session seemed like a better plan. I did reproduce the situation on the same computer with a different browser (and obviously different session), and it too remained static after encountering the error.

Self-correcting errors -- even user-advised self-correcting errors -- are not unheard of, and this may have been one of them, but any correcting that took place was not visible to this visitor.

HTML5? Great. Now What About Webserver Error Handling?

I just saw a Google / Arcade Fire video that has been widely viewed (fun stuff!), but this blog post isn't about the video. Rather I was thinking about the apparent status quo with messages and error notification in use for webservers (yes, even vaunted Apache). Sure, there's an API so web developers can intercept the message and put up something more elegant, but the default error processing approaches the unusable. Further, it's often the case that the developer has little control over the cause of such errors. All the more reason for the web server to offer up something sensible. Given the ubiquity of Wikipedia, maybe the user should be directed there, where natural language content curation is held in higher regard than in developer communities. 

Error Message Effectiveness

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.

Posted via email from knowlengr

The Challenge of "Model Level" Software Errors

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.

Posted via email from knowlengr

Error Processing Via Cartoon / Clip Art

Some might argue that if an application is going to fail, it should do so with a human touch. Perhaps, but helpfulness is to be preferred over humor. In this warning message from URL-shortener and URL-tracking utility bit.ly, the cartoon approach is given top billing.

"Forbidden!" - It's not a game, Mildred

Give Google Sites a poorly formed URL and receive this message from the webserver. Error 403 is commonplace, routine in web dev circles, but isn't so common that users recognize its cause and realize that it's essentially innocuous. The "forbidden" message has a misleading tone.

"System Unavailable" - But Not Really

This glitch (22 March 2009) with a recently updated Schwab website appeared to be caused by a difference in how workflow was conducted to authorize ACH transfers between a Schwab account and non-Schwab accounts. The CSR was able to straighten it out by changing the order in which screens were traversed. It most certainly was not because the system had become suddenly "unavailable."