People use tools for the task that they look like they ought to do. Or, more succinctly: The affordances of a tool determine its use . Or, to quote Gibson, “the street finds its own uses for things.”
One of the challenges of a software or system designer, then, is to make sure a tool communicates its intended purpose. Another challenge, however, is to build tools durably enough that they can be put to new purposes.
A brief example
Bob, a plumber, needs to enlarge a hole in drywall. He has on his belt a measuring tape, a level, a plumb bob, a big pipe wrench, a small wrench, and a few screwdrivers. What does he use to enlarge the hole?
One common solution is to use the big wrench to hammer on the end of the small wrench (or on a screwdriver). This surely isn’t what wrenches were built to do–but to the plumber, it feels like they ought to be able to do it, and that’s enough. As a result, plumbers learn how to hammer with wrenches such that they don’t break — hammering on the very solid main handle, instead of the fragile jaws.
Could the plumber carry around a hammer just for this purpose? Sure. But it’s an extra tool, for an unusual case. And wrenches look a lot like hammers, to both the eye and to the hand. They afford hammering, as well as wrenching.
So, big, heavy plumber’s wrenches are built to withstand a little judicious hammering, if that’s what’s needed. And decent screwdrivers will also stand up to hammering, despite what your shop teacher might have told you.
Make it easy to do the right thing
As designers, it is our job to make sure that one of a few things are true:
1. The tool looks like it ought to do what it is supposed to do.
1b. The tool looks like it won’t to do what you don’t want people to do with it.
2. The tool will withstand being put to an alternate purpose, if that’s what the user wants.
1. it looked like browsers ought to be able to display active, within-page content
3. the result was incredibly useful
Engineers built a solution. First, individually, as a series of hacks. Then these were eventually gathered up and dubbed “Ajax”, and became a standard way of doing things. Finally, the technology evolved into a set of libraries (jQuery, NodeJS, etc.), to ease the burden of development. They built a new tool, or framework, within the constraints of the old — a new wrench that would withstand the hammering. And after a number of years, things were codified into a real hammer, HTML5, which integrates more fluent mechanisms for dynamic updating.
But none of this would have happened if the web browsers had fallen over dead when trying to display active content. The largely durable and flexible design of the browsers allowed innovation.
And that’s part of our job–to make things durable enough to allow a little exploration.
 See, e.g., The Psychology of Everyday Things, Don Norman (1988) for a full discussion of the important of affordances.
 From “Burning Chrome”, William Gibson (1982).