One of the most common tasks computer users face is repetition -- performing the same task more than once. Computers are fairly good at this. So why do people spend so much time repeating tasks by hand? Often the interfaces they use are resistant to automation, and other interfaces are obscure or unavailable.
One of the greatest time-saving inventions of all time may be simple carbon paper. Even though copies are almost never produced by actual carbon paper anymore, the underlying idea that a single action could be duplicated in some way remains an interesting one. One of the great steps forward promised by computers is the ability to perform tasks over and over without manually performing every step yourself.
For most users, this ability extends to printing multiple copies of a document, or perhaps, with training, a mail merge. Batch processing is almost always considered a "power user" feature, if it's possible at all. In general, though, many tasks are simply not subject to automation. Need to rename files? You rename them one at a time.
Users spend hours, even days, carefully repeating tasks. Open each file, then do each of three steps to it, then do exactly the same thing over and over again. New company logo? Go through each file using the logo and update it. By hand.
Macro recording provides one option for fixing this problem. In principle, macro recording ought to solve most of the problems of repetition. In practice, issues are invariably discovered. Many users are understandably reluctant to learn a full programming language, with looping constructs, so they settle for making a macro to "do everything I need to this file", then loop through files by hand. An improvement, but not a solution.
Some macro recorders have been observed to record exact key presses and mouse movements - meaning that even the slightest deviation can render them useless. Sometimes, the recorder just doesn't notice a given action. I was frustrated to no end to discover that the AppleScript script recorder could not detect or record screen resolution changes, when I wanted to make a script to change resolution before starting a game. In this case, there was no way to script the change, without third party software. Sometimes there is a way to script the action, but the macro recording software doesn't recognize it.
Macros are an excellent start to making programs usable. It is unfortunate that many sites, quite justifiably, ban them entirely for security reasons.
Ask a Unix user to explain how he can "put up with" that ancient command prompt, and chances are, he'll observe that Unix's environment is somehow conducive to productive use. The degree to which an experienced user can take advantage of this is truly stunning to a user unfamiliar with the power of the environment. Since the Unix shell is a programming language, users can easily learn to write simple programs, such as loops and iterations over sets of data. These simple programs can make all the difference in the world for long and repetitive tasks.
There is no convenient way in most GUI environments to express the idea of "do this twenty times" or "do this series of operations to each file I have selected". Unix users often do such things without a second thought.
You can have this same experience in other environments in which programming is a standard feature. Amiga users often produced small scripts; similarly, even fairly naive Macintosh users have been known to produce fairly flexible AppleScript programs.
Time and time again, we are told that a feature would be useful only to programmers. Why shouldn't users have access to this feature? Most users will, if shown how to perform simple tasks, gleefully take advantage of advanced features, as long as the introduction is not too overwhelming. Many features once described as useful only to programmers are now considered standard features of a modern operating system; consider multitasking. For many years, people insisted that multitasking was useless to normal users because most people only did one thing at once. Now that it's a standard feature on most computers, people can't imagine doing without it.
In the end, users are programmers; they are people who come up with a series of operations they wish a computer to perform and direct the computer to perform those operations. When an office's local domain expert in a given program can rattle off the instructions for a common task from memory -- without looking at the computer -- reliably enough that other people can follow them, chances are that person could easily learn to describe this same series of operations for the computer. AppleScript's pseudo-English syntax is probably intended to take advantage of this.
Many users are not aware that their computers can perform repetitive tasks automatically. While some kind of programmability is a common checklist item in software descriptions, many users are never exposed to the basic techniques of identifying a repetitive task that the computer could easily do, and then having the computer perform it.
Of course, sometimes, the tools aren't quite up to snuff. There is something exceptionally irritating about building a script to automatically perform a task that would otherwise have taken you the whole afternoon, only to discover that you should have clicked buttons on several occasions because the scripting tool can neither suppress nor respond to confirmation dialogs.
Often, the tools used for scripting are entirely separate from the tools used for normal use of a computer. This increases the learning curve for scripting substantially; one of the advantages of the Unix model is that the tools you use when scripting tasks are the same tools you would normally use when performing these tasks yourself. Familiarity, in this case, breeds ease of use.
Repetition of common tasks shows us that, while users may not program by habit, they have the concrete need for some kind of minimal programmable functionality. Many users, when exposed to such features, rapidly learn to use them, if not as well as experienced developers, certainly well enough to more than justify the time spent learning the tools.
In many cases, these tools already exist, and this is simply a question of user education. However, it is often also a question of completeness or accessibility. Tools for automating repetitive tasks should be reasonably easy to find, and should be able to control any task the software can perform.
This Week's Action Item: Do you ever repeat the same task several times on a computer? Can you make the computer do it automatically?
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at [file://localhost/home/seebs/ic/crankynew/crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.