Lync - wait 15 minutes - Error handling, UX and automatic software updates: a bad example

-

Not all issues are bugs, and not all issues take a long time to fix. Consider this example from Microsoft Lync (the posh Skype):

Be right back...

Unlike many other application boo-boos exemplified in this series, this one is a bit hard to explain. The message does admit there is a problem, and this is a modal dialog (absorbing all user input and so blocking any other part of the application from processing any new user actions). So, on the face of it, this appears an example of catastrophic failure. However, reading further through the message, we see that the user has a rather specific task to perform: restart and leave it running for 15 minutes.

Restart does seem a little unfortunate and casual: we don't quite know what the problem is, but in fact we DO know the software is, like your aunt Wilma's old car, a bit unreliable, and just needs a bit of a kick and another try every now and then.

Admitting to unreliability is unfortunate, yet the honesty is to be commended - hopefully such open communication around problems will lead to improvements and solutions. The true mystery, however, is the measure of time: the exact specification of exactly 15 minutes to wait, so we can fix it. Images of little elves poring through the system spring to mind: flipping binary switches and applying code and assembly patches. A kind of ingenious SWAT team with a short window of time in which to get in, spot the evil bug-doers, and relieve them of their ill-spent lives with extreme prejudice.

For the long-suffering user, this seems an unfortunate situation indeed: having to manually restart software, so that it can simply update itself - something that surely could be automated. Allowing for this sorry state of affairs, one must admire the kind of imagination and committee-collaboration required to produce such an unusually intricate and curious error message. 

Were all software errors so intriguing, perhaps customers the world over would be that little more forgiving when the occasional bug arises. Complex software the world over keeps things ticking over, yet there is always the odd icy patch on the information super-highway...

Comments

Post a Comment

Popular posts from this blog

null++ and its alternatives - NULL as an anti-pattern and some alternatives - stateless functional code

-
Image
  Notepad++ is a great and free text editor with many practical features, such as line-sorting, multi-file and directory find-and-replace, and excellent encoding support. However, programming is hard, and even the noble Notepad++ has been caught off guard in the war on bugs:  To NULL or not to NULL... A display full of NULLs is not that desirable, but on the other hand is better than random, uninitialized data, or worse, reading beyond assigned buffers into memory regions containing data this user is not supposed to see.  The history of NULL is a controversial one: it was, somewhat like JavaScript, cheap to implement at the time and seemed a good idea. However, notoriously, even the inventor of NULL considers the invention to be a mistake . At first glance, and when used in a very limited scope, NULL seems a sensible construct: a global kind of default 'this is not set' value, that is reliably detectable, as opposed to some random memory garbage. Issues arise when the NULL val
Read more

whoa! Chrome crash! - UX challenge of presenting a catastrophic failure

-
Image
A kind of California style, cool and casual way to tell the user that something truly bad has happened to the Google Chrome browser.   why ask? Although this is a "mere browser" and not the OS (there is still a difference, right?) - this does not seem so much different or better than Microsoft's prompting the user when the dotnet platform exhausts memory . Such an error seems unrecoverable - like a catastrophic failure, there is no choice to be made - so why ask? The user really does not have much choice - so why prompt? and why should the user need to decide what to do with your bug?
Read more

Windows Vista - reproducing 56.81 Shakespeares... - Operating Systems are complex and will always have bugs

-
Image
Windows has been around for quite a bit, and been thru several revisions. The Vista edition, like the Concord, looked impressive, but at times had difficulty flying. Here Vista is trying to show some volume controls (with a pretty basic hardware setup), and running into some difficulties: What causes this bug - who knows, and I suppose, who cares. Some kind of erroneous while condition, which can cause any imperative program to enter an inefficient, repetitive  state. Given the complexity of a piece of software such as Windows Vista (50 million lines of source code!). To put this in perspective, and at risk of comparing the art of C++ programming to that of 16th century literature (though at least in terms of age and fragility, there may be parallels), the entire works of the Great Bard (he of Hamlet) number 0.88 million lines. So we may reason that Windows Vista could have been composed by 56.81 Shakespeares.
Read more