You gotta love John Dvorak, even if you hate him sometimes. I’ve been catching his stuff for years, first in Byte, then PC Mag, and now PC Mag online. Sometimes I agree with him, often I don’t. But in his rant in yesterday’s column I think he got it pretty much right. Photo editing software, of which category Adobe’s Photoshop is the reigning monarch, is a good example of the difficulty inherent in simplifying complex tasks. Some amount of complexity is irreducible, but if you have used image or video editing tools, software development environments, word processors (who hasn’t?), etc., then you know how frustrating it can be to attempt some task you know you have completed successfully in the past, only to find that you can’t remember the navigation path to get to the goal.
I have long felt that the concept of layers is important, and might lead us to a general paradigm of mastering complex interfaces. This is where a good understanding of what an abstraction is comes in handy. Think of all the complexity of any given subject at it’s lowest level of detail: all the individual parts in a car by name, for example. This is equivalent to the thousands of individual commands in a complex software application. There is too much detail to remember, so we classify things and group them into named abstractions like “drive train,” and “cooling system,” and “editing functions.” When we confront such complexity the creation of appropriate abstractions is almost second nature: it’s hardwired into our heads. But deciding how to organize those abstractions in terms of how they relate to one and other is more difficult, and not everyone is good at it, or has enough time to think about it when designing an application. The simplest place to go, since we have been doing it for so long, is to hierarchy. And for many simple applications hierarchical orderings of interface elements work fine. We don’t have any problem finding “Edit->Search->Find and Replace” in a text editor.
But when you look at complex applications that require batches of multiple commands to achieve an effect, such as “Put a reflective glass pane in the empty frame in this picture,” the hierarchical approach breaks down. This is because achieving the goal requires more than a simple drill-down through the layers to an end-point command, and then a click. To achieve this goal requires picking effects and commands from various points in the hierarchy and stringing them together. In essence this is another layer of relationships between functions, orthogonal to the tree structure of the command interface. It’s a layer in which relationships are goal-based rather than class-based.
Wizards were one early attempt to provide an alternative navigation path through a featureset, but wizards are not flexible enough: the goals are not mutable. There have been many different attempts to address this issue, from allowing the user to create custom wizards to using “sideband” interfaces that collect groups of commands together under meaningful names.
There is probably no more challenging or critical area of focus in the world of software development. We have made tremendous strides in terms of how we specify, engineer, test, and deploy software, but we have come almost no distance at all in the interface. Complexity has overwhelmed utility in many application domains, and the fact that we have been hearing this same complaint for twenty years says a lot about the situation. A new interface paradigm is required, but in my opinion there is nothing on the horizon that promises to be revolutionary.