Highlight Topic:
Performance

back To Overview

Leading Article

Introductory Articles

Human Performance at the Computer

If All Else Fails...

The PeP Project

References and More...

 

Performance Analogies

By Gerd Waloszek, SAP User Experience, SAP AG –November 13, 2008

This page collects "analogies" or "stories" that can be used in discussion as anecdotes or analogies for clarifying certain performance issues (or non-issues...). Some of these stories are included in articles from this highlight topic.

 

It's More than Providing the Technology...

Here, I use the analogy of a car to illustrate the interaction between technical and design-related performance aspects.

Using software without optimizing the technical performance is like having a car without wheels – it does not move at all. However, adding wheels to a car does not necessarily mean, that you'll have a smooth ride, or that you can drive as fast as technically possible. You must also be able to start the engine, get the car moving, and drive safely and comfortably.

My brother once told the story of a driver who had to transfer his colleagues and him to the airport. The driver tried hard to get the car to speed and pressed the accelerator pedal as hard as he could, but he drove in the first gear the whole time. After some time, the engine overheated, and the driver had to pull over and stop the car. Not only was it a miserable ride (too slow) but he also did not reach his goal, the airport.

In case of the driver, we do not know why he did not switch gears. Perhaps he had only driven cars with automatic transmissions. If we transfer this example to the world of software applications, we might find that the other gears were buried somewhere deeply in the menu hierarchy, had illegible or unclear labels, or weren't there at all. Interaction design, information design, and visual design are the "set of screws" for optimizing such performance aspects.

 

Perceived Performance

Here, I use the analogy of a car to illustrate perceived performance.

I would like to illustrate perceived performance with the following story: A long time ago, we took a friend of ours for a ride in our car, a Renault R4. I was driving at a speed of about 110 km/h (nearly 70 mph) – the R4 is not a fast car. Suddenly our friend cried: "Please, slow down, I am terrified by the speed!" Well, it could not be the speed that had terrified her, because she owned a Mercedes Benz and was definitely used to drive at much higher speeds. It was the noise and the vibration of the car that made her feel like she was going more than 200 km/h (120 mph).

 

Computers are Getting Faster and Faster – and Computer Magazines Have a Lot to Write About...

This story illustrates the problem of ever increasing processor speeds – and what that means for users.

Every half year, or even faster, computer companies present new, improved models, mostly featuring higher CPU clock speeds. For example, Apple once increased the processing speed of its MacBooks from 1.8 GHz to 2.2 GHz, which was an improvement of about 20%. Regrettably, such an improvement does not lead to 20% shorter working times. Typically, some other system components (for example, the bus) have been speeded up as well by the update, while others may even have become slower or less powerful for cost reasons. Thus, the new computer will show a "mixed" performance, which is usually tested as soon as possible by computer magazines using "real world" tests. That is, they run a standardized test suite of applications (standardized for one magazine only, of course) and compare the results of the new model with those of older ones or of models from the competition. The results are typically mixed: Some applications will run faster, some even slower. Let's say, the net result will amount to a speed improvement of about 10%.

Will users recognize this improvement? Of course, they will not. I bought so many computer and hardly ever realized speed improvements at the newer models. There was one notable exception, however, the G3-powered Apple Macintosh. This processor brought an enormous improvement over older models, about 50% as far as I remember, and it really showed. But, all those minor speed improvements are only good for marketing and sales – and also for feeding computer magazines with something to write about – but not for the users.

 

Attention Span of Adults – An Example

This story illustrates the fact that most adults will loose focus after about five to ten seconds.

In the list of basic time constants, originating from Robertson et al. and republished by Johnson, Cooper, and Nielsen, there is the "magic number of 10 seconds." This number has been characterized as the "human span of focused attention," meaning that adults can keep their focus of attention on something for no longer than 10 seconds. Less optimistic sources move this limit down to 3 seconds, some to only 1 or 2 seconds. Anyway, as far as my experience goes it must lie somewhere between 5 and 10 seconds. You can make a simple and easy test on your own to verify this: Just try to take a photo of a group of people and ask them to look straight into the camera and wait for the click. Then wait for 5 to 10 seconds and take the photo. You are lucky if most of the people still look into the direction of the camera and not somewhere else!

 

An Analogy – Encased in the Format of a Use Case – To Illustrate the Time Ranges

The following analogy of an old-fashioned book store serves to illustrate the different time ranges. It has been encased in the format of a use case.

You enter an old-fashioned shop with a counter and a clerk behind the counter, your dialog partner, and want to buy a book. The following "use cases" might happen:

Use Case
Variants
You (User)
The Clerk (System)
Type of Feedback
Type of Task
Outcome
1: Immediate Success     You ask for a book that you want to buy        
        The clerk lift his right hand indicating you that that he has acknowledged your order and will process it – that takes just a fraction of a second Immediate feedback Cause and effect Acknowledge-
ment
        The clerk grasps in a shelve, gets the book, and places in front of you: There it is – it took just a second Dialog style feedback = successful end of operation Simple task  
      You get the book, pay, and leave       Success
2: No Immediate Success     You ask for a book that you want to buy        
        The clerk says: "It's not in the shelve but I will look into the store room and see if there is a copy for you." Here you may want to see a "busy" indicator like a watch because you do not know how long the clark will stay in the store room    
2.1: Short Delay 1     The clerk goes to the store room, returns with a copy, and places in front of you: There it is – it took just a few minutes Delayed successful end of operation Common task  
      You get the book, pay, and leave       Success
   
2.2: Long Delay 2     The clerk returns without book and explains: "The book has been sold out. I'll have to order one for you from the wholesaler." The clerk should also tell you that it will take about a week until the book arrives -> The analog of a progress indicator Complex task  
2.2.1: Success   1   The book comes from the wholesaler by mail, and the clerk notifies you of its arrival: There it is – it took a couple of days Very much delayed successful end of operation    
      You get the book, pay, and leave       Success
     
2.2.2: Failure   2   The book does not arrive, you do not get a notice, etc. No successful end of operation -> The analog of a crashed or hanging system   Failure

Table 1: Book store analogy, encased in a use case format, for explaining the human time ranges at the computer

This analogy has been inspired by Jeff Johnson (2007), who uses real-world dialogs in order to demonstrate certain responsiveness issues. For example, he exemplifies missing feedback using the analogy of a repair shop. You might want to try that as an exercise for yourself using the use case notation.

 

Further Responsiveness Analogies

In in book, GUI Bloopers 2.0 from 2007, Jeff Johnson presents certain issues of poor responsiveness as dysfunctional person-person communication. See the book for these examples.

 

References

Jeff Johnson (2007). GUI Bloopers 2.0: Common User Interface Design Don'ts and Do's. Morgan Kaufmann Publishers (Chapter 1: First Principles; Basic Principle 8: Design for Responsiveness; Chapter 7: Responsiveness Bloopers). (Review • See book in the book list)

 

top top