Specialized methods do not always increase efficiency

The current research is a complex, 5 day, training experiment investigating several questions about the learning and use of software methods. Central issues concern the situation in which a software user knows more than one obvious method for accomplishing a task at hand. We call this situation "multiple methods". Multiple methods seem to arise most often from the creation of commands or functions specialized for a subclass of tasks. For example, in a word processing application there are often several ways to move the cursor, with arrow keys, by word, by line, by page, to end of line, to start of line, to top of document, and to bottom, to name some common methods. Designers and users typically assume that the existence and use of multiple methods in an application increases user efficiency. We tested that assumption directly. In this experiment we investigated the effects of multiple methods during learning and performance measuring task time, planning time, and error rates and types. In addition, we also investigated strategies subjects employed when choosing between their methods.In a rigorous training regime using the spreadsheet software Lotus 123, subjects learned one or two ways to move the cursor and one or two ways to sum the contents in a section of cells. During the 5 day experiment, subjects repeatedly moved the cursor to an indicated location and entered a formula summing an adjacent group of numbers. Cursor movements were of varying distances and sums involved various numbers of addends.On the first day, subjects were taught their method set which they practiced to a criterion of 24 consecutive correct repetitions. On days 2 and 3 (practice), subjects performed tasks comprised of 128 repetitions of their method set. On every task, the best method was assigned in the instructions and used by the subjects. The best method was determined by constructing theoretical keystroke models of the methods (see Olson & Nilsen, 1988) and assigning the most rapid method. During practice, the order in which the methods were used was counter-balanced.On days 4 and 5 (testing), subjects performed 338 similar tasks but selected the method themselves on every task. These 338 tasks were comprised of thirteen different cursor task distances and thirteen sizes of sums sampled thirteen times each. During both practice and testing, subjects used the key to toggle between task instructions and the spreadsheet on which the tasks were performed. During a cursor task, the target cell was not indicated until the subject removed the instruction screen stating: "move the cursor to the target cell using the X method". Similarly, during a summation task, the addends were apparent only after the instruction screen was removed. This allowed partitioning of the total task time into planning time and typing times.During both practice and testing, and on both cursor and summation tasks, subjects who knew two methods for a task made more errors on that task type (matched tasks) only. That is, knowing two sum methods increased the number of sum task errors, but did not increase the number of cursor task errors. Similarly, knowing two cursor movement methods increased the number of cursor task errors, but not summation task errors. In addition, two method subjects were no faster on matched tasks than were one method subjects, despite their specialized methods. In fact, the two method subjects had longer planning times on matched tasks than did one method subjects. Once again, these effects of knowing two methods were segregated to matched tasks.It is interesting to compare the two groups of subjects that each knew three methods as a way of controlling for effects of workload imposed purely by the number of methods known. The subjects with two cursor methods and one sum method (2-1 subjects) were compared to those with one cursor method and two sum methods (1-2 subjects). Consonant with the results above, 2-1 subjects made more cursor task errors than did the 1-2 subjects who made more sum task errors. Increases in planning time at the start of the task followed this same pattern.Although error rates were low and task time differences modest ---between 500 to 3000 msec---in a population of "real users" who know more commands and do not undergo such rigorous practice the differences are expected to be much larger. These results contradict the common assumption that specialized methods for subclasses of tasks increase a user's efficiency. In addition, these results demonstrate the costs of multiple methods even in an impoverished repertoire of only four commands.