Wednesday, October 10, 2007

Out of Paper - File copying failed

Further discussing interface design, Paul Dorish writes about a different kind of tension: "the traditional process-oriented" and the "emerging improvisation-oriented" interface. What he discusses is the redesign of computational systems that react to certain unpredictable system functions. Consider, he observes, the simple process of making paper copies. We've all experienced it: several pages of the document we want to copy are placed in the feeder tray, we ask for 3 collated copies and we press start. Then in the middle of it, the copier runs out of paper or there is a paper jam. It is then our task to see how far the job was completed. How many pages of the first copy, second, third, etc do we have? Depending on the machine or settings the process could be different and we could just have one complete copy and a third (or a quarter?) of the second copy. Dorish then discusses the design of systems that respond to these types of unpredictable outcomes. He articulates a new design based of the interaction between the components of the system, the system as a whole and the functionality of it. If each component were to be separated from the copier: the tray and the feeder for example. And such component was capable of providing feedback -separate from the whole system -then then interaction and responses to the user will reflect better the process completion. The interface will move from being concerned with the overall process towards the components that make up the function. He calls for rethinking this process through the use of "accounts." Separating the process or the components that account for the functioning of the system. These accounts will not only provide for the reporting of behavoir of the function but will also control it. He elaborates on this concept by using another real life example: we are copying a file from one disk drive to another one residing on the network. The percentage done indicator displays (PDI) as the file is being copied. It reaches 40% and then it fails. The interface returns the message "drive unavailable." Dorish asks then, where did it fail? What does the 40% mean? Couldn't we take that 40% and continue copying the file instead of starting all over again. With the use of accounts this could be accomplished, reporting on every stage of the process, reporting (accounting) for each step towards the completion of the function. He is concerned he says with the "problem of connection between system components." Wouldn't that be great? Designers - programmers - thinking in these terms and create products that are easier to understand failures. We wouldn't have to count pages or copy the file from the start.

No comments: