• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    July 2009
    M T W T F S S
    « Jun   Aug »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • Archives

Efficiency


There used to be a time when the choice of car influenced significantly the probability that the trip from A to B could be completed. Nowadays all manufacturers have implemented a common set of reliable functionalities. Any car can complete the trip. The critical issue is no longer to get from A to B but to do so in the most efficient way, maximizing output and minimizing the scarce input factors. Environmental and economical consideration make some factors more relevant than others. Driving time (miles per hour, MPH) is no longer relevant. Fuel (miles per gallon, MPG) is one of the most critical input factors today and has a significant impact on the choice of the car.

There used to be a time when the choice of computer influenced significantly the user’s ability to complete the intended task. Nowadays all boxes are the same and there are enough mature software packages that offer equivalent functionality across operating systems. Almost any system does the task. If all systems have sufficient functionality and development focuses on efficiency, what are the scarce input factors? how do we measure them? how do we weight them? which one have an impact on the choice of software?

Unlike cars there is no speed limit. Raw speed still counts and time is of essence. In recent years energy efficiency (e.g. FLOPS/Watt) has become a factor of consideration, but time still is the most relevant measurement. And in my opinion the most important. Not CPU-time, user-time.

The best software is the one that reduces human interaction time (including time waiting to interact) to the minimum.

Human interaction time can be categorized in:

  • Time to prepare the operation: the shorter the better. While for frequent users with a good memory can enter a command line with a few parameters (out of a few dozens) very quickly, an intuitive GUI shortens this time for the occasional user that would have to call the command’s man page or other help text, read it, scribble down on paper while composing his command until it can be triggered.
  • Typing on the keyboard: the smaller number of keystrokes for an input, the better.
  • Reading from the screen: the less there is to read, the better (but the relevant information must still be there).
  • Interaction with the pointer. Positioning the pointer on a target, dragging, clicking, are all operations that require dexterity and accuracy. Like typing on the keyboard, there is a trade-off between speed and accuracy; and between simplicity of the movements and speed.
  • Waiting for the computer to request additional input, but only if the interaction is supposed to be in or near real-time. Batch processing time does not count – the user can do other things while the computer processes the batch.

Good software design aims to minimize those interactions. If an operation can be completed with the nine key strokes, completing it in ten is a 10% efficiency-loss. This is what happens when renaming layers in Photoshop compared to the same operation in GIMP; or when renaming a file in  Windows Explorer compared to Nautilus. The inefficiency cost? find it out for yourself. Take the typing test and find out your accuracy and speed. Multiply your words per minute by 7 to estimate the number of such operations that you need to perform to loose one minute. Estimate it across the days, weeks, months, years you sent at your computer. Extrapolate on the millions of users of the software, and you’ll know what is the waste resulting from such a simple bad design.

Extra-bonus: how fast can you target a single random pixel in the middle of your display? And the single pixel at the corner of your display? And a single pixel on the border of your display? Now you should know why positioning the application menu on top of the display (as done on the Mac) is superior to positioning it on top of the window (as typically done on Windows or on Linux). And wich single pixel on your display is the fastest one to target? Hint: context menu.

Ah, and time is still the most relevant factor also when getting from A to B too: I’d rather read a book comfortably seated in a train, airplane, but or taxi and let somebody else do the driving. As in: program the journey and sit back, while somebody else does it for you. Batch processing, wherever possible, is my favorite type of processing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s