KnowlEngr - Better Than 1,000 Pictures

Thursday, May 5, 2011

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

Wednesday, March 2, 2011

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. 

Sunday, March 14, 2010

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