Sometimes you'll hear people say, "I'm no good with tools." Don't believe them. Watch: they use tools to cook and eat their meals, clean their teeth, unlock the door to their house, and so forth, all with unremarkable virtuosity. Tools are more than just hammers and screwdrivers and saws. Rather, tools surround us in our everyday lives, and we have evolved to be very good at using them.

Well-designed tools can be a joy to use. When the act of using a tool breaks down, however, it can give us insight into what makes tools usable in the first place:

"My dad once owned a pair of pliers that always gave me a problem when I used them. Every time I tried to grip something to tighten it up, they clamped down on my fingers. I eventually learned to watch my fingers when I used them, but I still remember the pinch marks they left."

"[In putting together a bookcase] there was so many different types of screws and bolts of different sizes (some were metric and others were American sizes), that you had to have five different wrenches and screwdrivers to get the job done."

"My toaster oven has a couple of design flaws, one related to how you clean it. If food falls down below the hot coils, it tends to catch on fire easily; therefore you have to clean it frequently. The problem is that the bottom of the toaster needs to be removed to do this, and your average college student is going to put this off because he doesn't have a screwdriver sitting next to the toaster to remind him before he runs off to class after breakfast."

Tools work best when they are designed for the physical and capabilities of their user (they are most commonly held in the hand), when they are well-suited to the task that they are applied to (tools mediate interaction with other objects), and when they are ready at hand in a well-organized work environment. More basically, good tools help people reach their goals, by making incremental changes directly on visible objects. In their application, tools often act as amplifiers of some ability, but tools can also help people constrain objects (e.g. with clamps), gain information about objects (e.g. using a magnifying glass), or mark objects according to need (e.g., using a carpenter's or seamstress's pencil).

Some of what we know about the use of tools can help us build more effective software (or hardware) systems. Tangible user interfaces and handheld devices offer the most direct possibilities for mimicking tools in the real world. For example, the I/O brush, produced in Hiroshi Ishii's lab, takes the form of a large artist's paintbrush. A tiny camera embedded in the tip of the brush can pick up color and texture from any surface that the brush is touched to. Using the brush, the artist can transfer information from the physical environment onto an interactive canvas, painting in a natural way.

Graphical user interfaces based on tool metaphors take a less literal approach. The best-known work along these lines is the idea of "local tools," developed by Ben Bederson and colleagues as part of the KidPad project. Local tools are an alternative to the modal behavior of tool palettes. In a drawing application, users can pick up a pen or an eraser, use it, and drop it in a convenient place for later use. More than one copy of a tool can exist at the same time, supporting collaboration. Children as young as four can use local tools to draw pictures. Work in my own group has pushed this idea further, to explore the range of physical metaphors for software interaction, again in a drawing environment. For example, a ruler in our HabilisDraw system can act as a straightedge for freehand drawing and can also be used, when picked up, to push drawn objects into alignment at arbitrary angles. Other physical analogs, aside from pens and rulers, include pushpins to constrain movement, compasses, inkwells, and magnifying lenses.

An important question is how the benefits of tool-based interaction for drawing might transfer to tasks with a less obvious physical interpretation. This requires a bit of thought, but some abstract properties of tools can provide guidance. For example, most tools in the real world must come in contact with an object to have an effect on it. This means that the effect of a tool is generally localized. To see how this notion of "effect locality" might improve a software interface, consider a Find and Replace dialog in a word processor. Suppose I want to change every occurrence of "image" to "icon" in a document. A global replacement may give unexpected changes, such as "iconery" from "imagery" (or the less likely "pilgricon" from "pilgrimage".) If I add spaces before and after "image" to fix this, then I will miss forms that include punctuation, such as "image,". The safest route is to walk through all the matches and decide whether to change each one, in context. This has its own difficulties, however, with each successive match appearing at an unpredictable place on the screen and sometimes even with the dialog box moving to avoid obscuring matched strings.

An improved Find and Replace dialog might exploit effect locality by gathering all matches to a string in the same place, and letting the user refine the search criteria, directly apply the replace option to specific matches, or de-select some matches and then perform the replacement to the remainder automatically. This is just a brief example given to suggest further possibilities; who wouldn't like software to work as easily and transparently as a hammer or saw?