This is an important interaction idiom. It's probably the most widespread and important idiom in paper bureaucracies. Its application makes the entire difference between great service and bureaucratic hell. And it's the first thing that programmers eliminate when they automate paper processes.

The key difference between a suspended operation and an incomplete operation is that a suspended operation is '''persistent'''. It doesn't go away or disappear just because you turn your attention elsewhere. It doesn't go away even when you dismiss it, it just sits there waiting patiently for you to resume it.

So in the example of a web form that you submit incorrectly or incompletely, where the result is a shorter form with just the missing fields to refill, then this is an ''incomplete'' operation. If the web form were a suspended operation, it would be possible to save it either as a bookmark or a file and resume it later. So we see that incomplete operations are inferior substitutes to suspended operations, though they are vastly superior alternatives to unsuccessful operations.

The same is true of GUIs which provide modal dialogs and wizards that can't be saved and dismissed. They're not suspendable operations.

The Smalltalk package mechanism provides suspended installation of components. If a package can't fulfill its dependencies, its installation will be pending the installation of these other packages. In contrast, dpkg provides only unsuccessful installation; not even incomplete. Unix shells provide limited suspending of jobs. In contrast, taskbar applets provide only the ability to kill jobs.

In order to make an operation suspendable, it's necessary to reify its entire state. And to make it arbitrarily suspendable, then it can't hold any locks. The latter is preferable since then you don't need to develop an artificial state model of the operation.

CategoryInteractionDesign