Here are the beginnings of a pattern language for user interface design. These patterns drive the initial phases of design. They key off of Story, a pattern from the early development language. The patterns are:
1. User Decision
2. Task
3. Task Window
I'm indebted to the user interface pattern mailing list and to Ward Cunningham for the seeds for these patterns.
You have collected a set of Stories (early#1).
How do you organize a Story so it can be mapped into a simple and coherent user interface?
Stories give you a lot of raw material from which to mold the user interface. The problem with stories is that they are organized chronologically, while interfaces are organized spatially. We have to break the story into parts, some of which will be spatially closer than others. We need to translate the story from the time domain into the interface domain (there is some weird analogy here with FFTs).
A good user interface has a sense of plot and flow. You naturally follow some path through the parts of the interface, first using one window or kind of window more, then shifting your focus to another. Interfaces that force you to jump back and forth between different style of interaction (text editing to form fill out to tabular presentation to direct manipulation) violate this sense of easy flow.
Avoiding "interface shock" requires that we put chronologically related parts of the story close together spatially in the interface. At the same time, we should use the best possible presentation and manipulation technique for every part of the story. To start with, we need to identify the "atoms" of the interface so we can begin to find "clumps". Therefore:
Make a list of every decision the user has to make during the stories. For each decision, write down the information the user needs to make the decision wisely.
Group the decisions in Tasks (2).
You have a list of User Decisions (1).
How do you group decisions into coherent tasks?
One of the marks of a good interface is that everyone feels like they can work the way they want to, that the system does not impose any particular method of solving a problem. Indeed, it is just this feeling that is the primary goal of my whole involvement with patterns- to give users a sense of mastery of their environment (I stole this idea from Dan Ingalls' paper on the Smalltalk design principles).
This feeling of mastery is often at odds with the users' managers' need to feel in control of the users' work. I'm thinking of a room full of customer service representatives for a major bank or insurance company. The company and its customers will benefit from a certain uniformity in the approach of every user. Some companies go so far as to script every word the user speaks.
We need to design an interface that satisfies both these desires. The user must feel like the system doesn't impose on their prerogatives. Management (who likely decides whether you get paid for this work) must feel that no user can stray too far from productive paths.
Users with more autonomy will not be under the intense scrutiny described above. Even so, we owe these users a debt, a debt of structure. An interface with no structure, no point of view, gives the user no leverage. Such an interface quickly devolves into an exercise in interface design for the user, through preferences, macros, or even an embedded programming language.
Here is the dilemma in a nutshell. We must structure the interface, because without structure there is no leverage. We mustn't structure the interface, because structure takes away the user's experience of being in control of the machine instead of the other way round.
The artistic "liberating structure" debate arises once again! Short circuiting hours (days weeks months years) of debate, structure liberates, as long as it eliminates unnecessary decisions on one axis in order to open up decisions on another.
You may not be comfortable making these kinds of decisions. How can you possibly know how every user who will ever encounter the system will use it? How can you be sure that you're right, that you aren't restricting important avenues of exploration for the user?
Two answers. 1) The patterns give you a pretty decent chance of being right for most users most of the time, provided you are listening to them. 2) Of course you'll make mistakes. That's no reason not to ship the system. There will always be "power users" who will stretch whatever facilities you provide. Therefore:
Write each User Decision and its required information on an index card. Put cards with the same information touching each other. Put clumps of cards listing similar information close to each other. Each clump of cards is a task. Name it.
Support each Task (2) with a Task Window (3). Use a Wizard to overlay temporality when the spatial layout becomes confusing.
You have found a Task (2).
How much of the system do you reflect in a single window?
Interface design tends to fall into one of two camps- the "everything in one window" camp and the "everything in separate windows" camp. Neither of these extremes serve the user of current computer systems.
The "everything in separate windows" is exemplified by early design on the Macintosh. With the extreme limits it had on screen real estate, it was appropriate not to pack too much into any one window. However, it resulted in some software that was hard to use (Finder, ResEdit) because the user spends far too much time managing windows. The need for a separate "Window" pull down menu is a symptom of this problem.
"Everything in the same window" goes too far the other way. Putting all the functionality of a large system (many workstation CAD systems demonstrate this problem) into one window results in a vast sea of choices. The system isn't helping the user structure their time, isn't presenting any flow through the system.
Finding a happy medium is critical to the operation of the interface (and to the viability of the rest of these patterns). How do you tell when you have enough information in a window?
Ask the user to divide their job into identifiable tasks. Create a window for each task. Name the window after the task.
The available actions will be Visible Functions (?). Divide the window into a Few Panes (?).