Progress Bars but no Progress

Nicholas Negroponte points out, in his great presentation on the economics of ‘One Laptop per Child‘, that his 1985 apple 128K worked more quickly than his current laptop. Adobe’s interactive animating wall intrigues passers by but ultimately ‘doesn’t live up to it’s promise’ because it’s not responsive enough. Examples of user frustration with computers abound, in fact you no doubt have many of your own.

Scott Berkun hit the nail on the head in his article about “Why Software Sucks“:

Whenever you hear someone say “This sucks” they are doing several things simultaneously:

expressing frustration, experiencing shock, using criticism to mask feelings of helplessness in a cruel universe, and, most importantly, communicating the gap between their expectations and reality

So why does Writh’s Law seem to hold true? Why, as computers have grown faster has are experience seemed to become more sluggish?

Modern systems use multi-threading, communicate over networks and generally perform more complex thing, right? So we should cut modern applications some slack, right? Sadly no. How often have you presented a user with a new application only to have them start clicking furiously at random at it’s most sensitive time causing it to spit out random error messages and eventually crash? It feels like giving a Fabergé Egg to the local ASBO association.

But when you use software yourself you’re rarely as forgiving as you hope your own users would be. So why, as users, are we so impatient? And how can we close the gap between expectation and reality? I have what I think is a novel approach….

Reinventing the dreaded progress bar

Just seeing one can send shivers down your spine. The tragically ironic progress bar indicates the exact opposite as you sit there staring at it, making no progress what-so-ever. The progress bar engenders wide spread revulsion because it’s implementers break the golden rule:

A Progress Bar must move smoothly and steadily to completion and then vanish

I just made up that ‘golden rule’, but I’m sure you’ll agree that violating it will lead to pretty annoyed users.

However, it’s almost impossible not to break the golden rule because progress bars were invented when computers had no external inputs except the user and were typically running one application. So effectively their operation was deterministic. Since applications these days uses the network and run concurrently with their peers the basic assumptions on which the progress bar was built are now false.

What is progress anyway?

Taking a step back we need to ask ourselves what are we doing when we show ‘progress’ to a user? Well, in the case of a progress bar we are showing 2 thing. Firstly; that progress is being made and secondly; we are offering some form of visual estimate of when that work will be completed. Very Waterfall don’t you think? So why no make our progress bar more Agile?

What a user wants to see is that progress is being made, if you can predict when it will end, all the better. But be warned: get your estimate wrong, or over-pad it or change you mind half way through and you risk breaking the ‘golden rule’. So why offer any estimate of completion at all. This is a tactic used by the AJAX world and the progress free progress bar has many incarnations:

But in a rich client environment we can do better than that.

A Patterned Response

So my novel concept is these little guys: Identicons. Decorate certain bottleneck functions in your stack with an attribute. When they are entered, their name is turned into an identicon and sent up to the UI where they are shown in a fixed length block in the status bar (no more pop ups). Not only will this give progress feedback but it will give some basic insight into the inner workings of the application.

As the user (and the developer) get used to the operation of the application the patterns of Identicons will become familiar giving them a better feel for what the application is doing below the surface. When new patterns appear, or existing ones speed up or slow down the rapid pattern matching our brains are so good at will give instant clues to state of the application.

Conclusion

Will the Identicon Status Bar close the gap between expectation and reality? Certainly not completly. But it will give your users a better feeling for what an application is doing. And who knows, it might even distract them long enough for what they we’re looking for to appear.

I’ll build a sample app when the weather gets worse… 🙂