It was not surprising, then, that much of the discussion emphasized the differences in the two paradigms. A good deal of time was spent discussing when each technique was most useful under what circumstances.
Many HCI practitioners say that interfaces should be designed to facilitate opportunistic planning on the part of the user, since this is the natural planning model that a person uses. Others, however, claim with equal conviction that opportunistic planning is an undesirable feature of the human cognitive process, and it should be discouraged in favor of more orderly techniques.
One point that came up repeatedly in class was that the decision to use one of these techniques versus the other is really quite dependent on the problem domain. For example, several comments on earlier days had indicated the potential problems in designing and developing software opportunistically. Many people feel that software engineering is a discipline and as such should entail a certain deliberate structure. Such structure is thought to be necessary to ensure the quality of the final product.
The issue was raised that, if this is the case, why are many modern software development tools providing interfaces which encourage opportunism? Examples of this are the Microsoft Visual products, graphical debuggers, and language interpreters that allow code to be changed during execution. Some people pointed out that certain aspects of software development, such as debugging, are inherently opportunistic tasks. You can't know ahead of time the exact sequence of operations to perform during debug; it's dependent on information you collect while doing the debugging.
Dr. Hartson pointed out that different levels of the development process can benefit from different types of planning. While a more structured approach is very useful at a high level, at a lower level, it can be more beneficial to have tools which allow for more flexibility. As an example, he discussed the design paradigm used when batch processing computers were the norm. Because turn around time executing a program was so large, programmers spent a lot of time going over the tiny details of their code to make sure that everything worked exactly as it should when it finally ran. Nowadays, with high speed personal computers being so prolific, programmers no longer have to spend so much time laboriously scrutinizing this low level code. If there is a problem, the programmer can simply fix it, recompile, and rerun. This is a very opportunistic approach because the actions taken depend on the behavior of the system.
Moreover, there is a certain school in software engineering that advocates creating an initial version of a program with the full intent of throwing it away and rewriting it again. The theory is that this first draft allows the developers to explore the problem space, discover problems in the system design, and figure out how the system should be designed. In the second version, they can apply this knowledge to produce a better product. This initial process of discovery is a very opportunistic technique. Design decisions are made and changed based on the experience gained as the prototype evolves.
The point was also made that not all software projects are equal. While it is certainly not realistic to attack a large commercial product design opportunistically, smaller scale projects may fit this mold quite easily. This lead to the suggestion that perhaps successive refinement techniques are better in more complex task domains while opportunism might be better suited to simpler ones. However, Dr. Carroll indicated that one danger with this mentality is that many times projects begin small and then grow larger. Will the planner's strategy really shift with an increase in scale, or will the habits applied to the simpler problem be habitually applied to all problems?
In response to this, several people questioned the idea that opportunism will always lead to bad habits. Dr. Hartson pointed out that opportunistic planning is not unstructured and totally chaotic. Rather, it is simply built upon a less rigid structure than the strict hierarchical decomposition of successive refinement.
Similar quandaries exist in the user domain as well. If the user learns a computer system via opportunism, it is possible that he or she will fall into the habit of using inefficient techniques to perform certain tasks simply because they found that technique first and it was sufficient for their needs. A user who only needs to accomplish a few simple tasks may not care if they are using the most efficient operators to arrive at their goals. The benefit in reduced learning time tends to make up for the reduced efficiency.
During the discussion, an analogy was drawn between computer usage and learning to play a musical instrument. To be really skilled at an instrument, a musician most follow a fairly methodical learning pattern to master all its nuances. At the same time, however, this long and laborious process may be overkill for a person who is only interested in learning to play one or two songs.
Also, not all musicians go through this classical training process. Many jazz and rock musicians learn to play simply by experimenting with their instrument to find what sounds good. It's not uncommon for such musicians to be unable to read musical scores. In fact, a large part of jazz is unscored improvisation, which is again very opportunistic in nature. However, problems arise if too many musicians are all improvising at once with no underlying structure. This, combined with previous discussions about large programming projects involving many developers, seems to suggest that opportunism has problems working in large group settings.
To illustrate, consider that many people in the HCI community vehemently oppose the idea of opportunism and direct manipulation, preferring instead the straightforward decomposition of a GOMS analysis. Their arguments are similar to those outline above in opposition to opportunistic planning. However, given that GOMS provides no mechanism for system feedback, an inherent part of virtually all modern computing systems, it would seem that the applicability of this approach is severely limited. How can it possibly be applied to model all user planning activities?
Rather than trying to draw hard and fast boundaries between the two extremes, we asked the class to suggest ways in which feedback could be added to GOMS. This had been discussed in part earlier during the discussion session for the GOMS group. Both then and now, the class generally agreed that attempting to incorporate feedback into GOMS would dramatically increase the complexity of the model due to the large number of conditions that would have to be considered.
One difficulty in adding feedback to GOMS is that quite often the information which determines the users action is not known in advance, even for simple behaviors. An example might be the user moving the cursor in a text editor to the beginning of the current paragraph using the up arrow. The length of the paragraph will determine how many times the arrow must be pressed. This kind of do-until behavior is problematic in GOMS.
Perhaps we can model this type of repetition probabilistically. We could collected data on sample paragraph sizes, fit this data to a statistical distribution, and then use that distribution to determine an "average" number of times to execute the operation.
In doing this, though, we might be reducing the value of GOMS as a tool for predicting task time because of this additional approximation we are making. However, it was pointed out that GOMS is already an approximation as it stands, so perhaps an additional approximation would not be so bad. Besides, this form of modification would be moving GOMS just a bit closer to an opportunistic model, which is design to handle an unpredictable problem space.
Dr. Carroll also pointed out that not all opportunistically planned tasks are easily defined as do-until loops. One would be hard pressed to define jazz improvisation in this manner, for instance. This suggests a spectrum of tasks in an interface, some of which could be incorporated into an extended GOMS but others of which are simply impossible to define with sufficient rigor to fit them into the fundamental GOMS structure.
Still, even incorporation of a simple do-until structure into GOMS has not been attempted. It would be interesting to see if such an extended model would be applied more or less than the current GOMS model. On the one hand, it would encompass a broader range of tasks. At the same time, though, it would increase the complexity of a model which is already rather tedious. Which is the main reason that GOMS does not enjoy more wide-spread use: its complexity or its restrictiveness?
One point that was made in the direct manipulation paper (Hutchins, Holland and Norman, 1986) and that was observed during the Day 3 exercise was that it is often easier to learn by observation with these interfaces. You can actually see the actions being taken by an expert user on screen and see the results as they happen. With conversational interfaces, you often see nothing more than the expert's hands waving over the keyboard, which is very difficult to interpret.
Another attribute of a good direct manipulation interface which aids the learning process is that important information and operations are readily visible or discernible right on the screen. With conversational systems, most information is not immediately available.
Dr. Hartson observed that, based on that exercise, it was clear that other things besides directness had an important effect on the usability of an interface. A good basic design, whether "direct" or not, was more critical to creating a usable system.
Along these lines, many concepts which are considered "direct" can often be more confusing, especially to a novice user. One example that was mentioned was the "drag-n-drop" paradigm. While such interfaces do allow the user to directly manipulate an object by dragging, it's not always clear if an object can be dragged or where it can be dropped. It's also not always clear what action will be triggered by dropping. To some extent, however, these issues could be addressed by an improved design that defines and enforces conventions for drag-n-drop behavior.
He also observed that, in many cases, combinations of direct and indirect tools could be effective. The name sliders in Spotfire were a good example of this. In this instance, it would have been much easier to simply type in the desired name instead of having to fight with the awkward and overly sensitive sliders.
Another point brought up was the fact that direct manipulation does not always require impressive graphics, icons, and color displays. In emacs, for instance, there is an incremental search feature which moves you through the document as you expand your search string, showing you exactly where the match is and letting you adjust your searching as you go. This seems very direct, yet it works on simple text-based computer terminals.
One of the keys to direct manipulation, then, seems to be providing the user with all the useful information about the state of the system. In fact, the paper on display-based action (Payne, 1986) suggests that ``perhaps systems should be designed so that exploitation of the display during action is maximized, and memory load consequently reduced.''
The problem here is that the designer runs the risk of data information overload. When there is too much on screen, the user may not be able to find the particular piece of useful information they need. Somehow, a balance must be reached. Usability testing may be key here in finding the best way to display the information. Also, the work of people such as Edward Tufte (Tufte, 92) may be useful. His books show via numerous examples how information can be presented efficiently and intuitively with minimal clutter.
In the end, what was really decided was that opportunism and direct manipulation are just tools, like most other things in HCI. They are neither inherently good nor inherently bad. It is up to the designer to choose what is most appropriate for the task at hand, to combine techniques effectively, and to provide the user with the information he or she needs.