Extending cut-and-paste: meshing operation structure with perceived task-structure

People's use of cut and paste operations is driven by the moment-to-moment way they are perceiving and thinking about tasks they are trying to perform.

I'll try and explain what I mean by talking about the last two examples I've given.

In the second example, the person wanted to copy a bibliographical entry, containing both the entry's text and, from within that, the URL of a link (to an online copy of the paper).

In the way they're looking the task, they conceptualise the paper as a single thing that they want to note down information about. And thus it's desirable to be able to perform a copy operation on the text, immediately followed by a copy operation on the URL.

Then they've got the information they want about the paper, and can now switch to their notes file and paste it.

Having to copy the text, switch to the notes file, paste it, switch back to the bibliography, copy the URL, switch to the notes file and then paste that is a distraction that doesn't mesh so well with how the person is perceiving the task.

In the first example's scenario, there's really two ways that the person could be perceiving and thinking about their task as they go about it. In the way I presented it, the person wants to grab a bunch of server names from a diagnostics report, then open an email and paste them into it. That is, they're thinking of it as a batch-copying operation like with the bibliographical entries.

Alternatively, they may approach the task in a more serial fashion, scanning through the diagnostics report, finding a particular server that they want to investigate, thinking a bit about the problem, copying that one across to the email and adding a short write up for it there, and then going back to the report and repeating the process to find the next server of interest.

Whether the person undertakes the task in a 'batch' or 'serial' fashion may depend on factors like the size of the report (how many servers, how many statistics about each of them), the nature of the problems with the servers, whether they basically already knew which servers were problematic before looking at the report, etc - and also on the person's habits and nature.

The general point I'm trying to make is that cut and paste it not just about "moving information around". It's about supporting the ways the user wants to move the information around, in the context of how they perceive and think about the task.

When someone is performing a task, they've got some notion of their goal in mind (though it might be very vague). The information in front of them, and how they perceive and think about it, will shape how they will want to proceed.

Within this context, they decide on the sorts of operations they'd like to perform. While they are performing them, they need to be able to keep in mind (though it doesn't have to be fully consciously) what their broader goals are, what tasks they want to do next (we often have in mind the next few things to do), and often something of the state of things before performing the operation.

In their minds they break down the task in a certain way, and the operations provided by the software should try and mesh with this breakdown. That is, offer ways to perform each of those tasks in a convenient fashion.

It's easy to look at operations -- like cut and paste operations -- in the abstract, and think, well if I can already achieve the same effect one way, why do I need another way of doing it? The answer to that is that the other way may better mesh with the way you are perceiving and breaking up the task.