Okay, you’ve done your task analysis, documented your user goals, gathered some key requirements, and maybe got a first cut of the data model. Time to start the first iteration of the UI. Step 1: Structure. What are your windows and how do they relate to each other? There’re two basic structures that result in two very different UIs, task-centered structures and object-centered structures. Each has strengths. Which is right for your application?
For example, let’s say you’re making an inventory system for the corporate paperclip warehouse. Your user is the Senior Paperclip Manager (SPM). When a department in the company needs paper clips, the department’s administrative assistant comes to him in person, and he directs the Assistant Senior Paperclip Manager (ASPM) to retrieve the requested number of paperclips. When the stock of a particular type of paperclip runs low, the SPM orders via the phone new lots from the manufacturer. These are incredibly specialized paperclips, by the way. On a given occasion, a department takes only one type of paperclip and each manufacturer ships only one type of paperclip (work with me here; I’m just trying to keep the implicit data model dead simple in this toy example).
The SPM tasks to be supported by your inventory application are as follows:
- Give out paper clips, recording the date, type, number, department, use code, authorization, and so on. Check the number of paper clips in inventory before giving them out.
- Take in a shipment of paper clips, recording the date, type, number, shipper, tracking code, and so on.
- Correct the number of paper clips in the inventory, based on monthly audits, which have been known to show that the number of paperclips in the warehouse doesn’t always equal the number supposedly in inventory, especially those fancy executive iridium alloy ones for some reason.
Task-centered
With a task-centered structure, each window represents a task, or, if the task is complex, a step in the task. The layout in the window and navigation links between windows represents the task structure –what steps follow what and how tasks can branch and loop. Microsoft calls this an “inductive interface,” and, while it is rare in general-purpose office applications such as word processors, it’s fairly common in custom database UIs. If, on learning of an additional feature or task to support, your reaction is, “we need a new window,” you’re probably making a task-centered structure. In the case of our paperclip inventory system, your prototype UI of task-oriented windows might look something like this:
In this structure, there are five windows. Using the main menu on the Home window, the user can open a Give Out or Take In dialog in which to record giving out or taking in paperclips. A third menu option opens a list of all paper clips and the number supposedly in inventory. The user can scroll through the list and pick the ones to correct, which is done in a subsequent dialog.
Object-centered
In the alternative, object-centered structure, each window represents one or more object classes, and the layout in the window and navigation links between windows represents the data model –how one class relates to another. For the most part, this is the type of structure seen in general-purpose office software, where there’s only one class represented, typically some kind of document. You see it in custom database applications, too, but is doesn’t dominate them. If your application is a collection of record lists, master-detail forms, and/or “properties” windows that the user can “drill down” through, you’re probably making an object-centered structure. For the paperclip inventory system, your prototype UI of object-centered windows might look something like this:
Okay, it’s one window in this example. The user selects a paperclip type of interest and the window populates with all information about that type, including, in a second pane or subform, a list of all transactions regarding it, whether giving out, taking in, or correcting number. A third overflow pane dynamically changes its controls to be consistent with the current type of transaction in the second pane.
Let the Best UI Structure
User Experience and Task Priorities
Comparing these two example structures we can see the advantages and disadvantages of each. Task-centered windows inherently guide the user on the task, essential self-documenting what the user needs to do to accomplish a task. At a glance of the home window of our task-centered paperclip inventory system, our user can see what tasks are supported, and, selecting a menu item, he sees what inputs are necessary to complete the task. Providing such self-documenting guidance on the task is not to be underestimated. It is not uncommon for a novice user, when faced with an object-centered structure, perhaps showing a multitude of objects and menus, to literally not know where to start. With a well-designed task-centered structure, often users need no training at all.
An object-centered structure inherently self-documents the state of the objects. They are necessarily visible there for study of their attributes and relations to each other. It’s what-you-see-is-what’s-in-that-there-database. Object-centered provides a more direct sense of connection to the data. Also, commands tend to follow a object-action syntax, unlike task-centered which more often are action-object. These things make it more suitable for an interface that emphasizes direct manipulation, granted the user doesn’t necessarily know at first what needs manipulating. At a glance of our object-centered paperclip inventory system, our user can see everything about a selected type of paperclip, including the details of the most recent transactions. Assuming some basic sorting and aggregating controls are included, the user can study the data right in the window, something an experienced user, one concerned with more than just blindly following a procedure, will appreciate. The need to analyze the data is obviously a task I left off in the spec (what’s the point in entering all those data if they aren’t used?). To adequately support analysis for the task-centered structure, you’d have to add a menu item and window for generating a report. Object-centered already supports it.
Task Structure
This relates to the second difference between task-centered and object-centered. Task-centered works great as long as the real world always matches the use case, and when the task is inherently rigid, where one step must be completed before another step can be taken (by “inherently,” I mean built into the essence of the task, not an artifact of arbitrary choices in the design of the current or planned system). Essentially task-centered asks the user multiple choice questions then tells the user what to do. That’s fine if everything goes as expected, but it falls flat if there are any deviations from the script. Object-centered tends to be more flexible and tolerent of a looser task structure. Its questions are more like fill-in-the-blank or even essay, allowing for more user initiative and creativity. For example, when the SPM sends the ASPM to fetch some paperclips of a particular kind sometimes the ASPM, who, quite irrelevantly, is the prime suspect in the Case of the Missing Iridium Paperclips, will yell back to the SPM a corrected number of remaining paperclips, and the SPM will want to correct that number in the inventory application before giving any out. With the object-centered structure, no sweat. Add a transaction to correct the number, then another transaction to give out the paperclips. There’s no need to alter the UI to fully support this deviation. For task-centered, in contrast, it’s a big PITA. For the sake of efficiency, the SPM will have already navigated to the Give-Out window while the ASPM went to get the paperclips. Now to correct the number, the SPM has to cancel back to the Home window, go to the Correct Number window and make the correction, return to the Home window and return to the Give-Out window. Most annoying. If you’re anticipating a need for flexibility in the task structure, lean towards object-centered. On the other hand, if the task is rigidly linear, then task-centered may be the way to go.
Now, if this need to simultaneously correct numbers and give out paperclips isn’t one of those little things that slips by the task analysis and usability testing, you have a chance to fix it in the task-centered structure. You can add a button to the Give-Out window that takes the user to the Correct Number window. Problem solved, but watch it now. You’re on a dangerously slippery slope, adding buttons and branches and loops to your structure. With only three or four tasks, this is not a big deal, but imagine a typical case of 10, 20, or 30 tasks, perhaps each with a chain of several windows. Start cross-connecting a whole lot of tasks, and soon your simple linear navigation structure turns into a dreadful plate of linguine. At a certain point, the key advantage of task-centered structure, that it self-documents the task structure, is destroyed, as the user can easily get lost in a maze of interconnected windows. Task-centered is good if your tasks have a simple linear structure, with few branches and loops. If not, consider object-centered.
Oh, by the way, sometimes an administrative assistant will camp out at the SPM’s counter waiting for an order of desperately needed paperclips to arrive, and will want them right now as the SPM is taking them in. Looks like your task-centered UI needs another button.
Task Performance, Abstractness, and Scope
Applications with task-centered structure tend to be “modey” UIs. They imply the user is event-driven machine. The user is apparently seen to be sitting idle, or at least not using the application, until some event sends them to it, where they carry out a complete task atomically: open window, fill fields, close window, then return to an unengaged state, perhaps indefinitely. That may describe some jobs, maybe even the SPM in our example, but watch your users and you may see that often their work is much more dynamic. A series of tasks are performed in quick succession on the same application, perhaps on the same set of objects. Users may be pursuing several tasks at once on the application or perhaps on several applications, interrupting one to take up another, then return to the first right where she or he left off. Users will prefer to leave one to three key windows of your application open throughout the day so they can easily monitor them and maybe do a quick task now and then. This sort of job environment benefits from the more modeless object-centered structure.
Task-centered encourages very concrete UIs: give out paperclips, take in paper clips, correct number. It’s a simple, direct fit to the user’s model of the task, with no brain strain trying to work at a level of abstraction the user is not used to. This also makes the task-centered a joy for novices. Object-centered structure, on the other hand, tends to push the UI to a higher level of abstraction. We don’t have give-out and take-in. We have transactions, which are subdivided as give-out, take-in, or correct number. There won’t be a Generate Report menu item. Instead the users has to understand that she or he can get the same effect by manipulating the Paperclip window’s sorting and aggregating controls. There is not an explicit menu item for each task. Instead, there tends to be general-purpose tools which the user uses in combination to complete tasks. This again makes task-centered more suitable to infrequent use and untrained users.
On the other hand, task-centered tends to have more windows, at least one for each major task, as we can see in this example, which tends to slow down experienced users. More windows means more clicks purely for navigation –more “excise” as Alan Cooper would say. Opening a window (or going to a new page) also entails a certain orientation cost, a delay in action while the user appraises this new image and recognizes its contents. More windows means more clutter with more buttons and menu options to open and close windows, and more windows on the screen as they stack up overlaying each other, all slowing the user from zeroing in on the control she or he wants to use. Having many simple windows also increases the chance that two things the user wants to compare are in separate windows, perhaps requiring “pogoing” back and forth. Not good. Object-centered structure tends to produce fewer, although larger and more complex, windows, each supporting multiple tasks. For the same content and an experienced user, a few complex windows is faster to work through than many simple windows. Compare using a wizard for a familiar task to the more direct approach, for example. In a simple case like this Paperclip application, it is no big deal, and I would expect that with proper design, you can make a task-centered structure faster for its primary tasks than object-centered even for expert users by optimizing the window layout for that task. But once you’re talking about a dozen or more tasks, all that excise and re-orientation starts becoming a sizeable proportion of the user’s work. Imagine how our task-driven structure would have to be changed it you had to start supporting electronic ordering of paperclips. You’d need menu items and windows to create and transmit orders, update and cancel orders, track orders, and generate reports on orders –perhaps all interlinked by more and more paths. The object-centered structure could probably get by with adding just one well-designed Orders window, which, although complex, is likely to be easier to handle and faster to use. Object-centered gets favored as the number of tasks to support grows.
The Winner Is…
So to summarize:
| Dimension |
Task-centered |
Object-centered |
| User Training / Frequency of Use |
Low |
High |
| Task Priorities |
Follow Task Steps |
Appraise Object States |
| Interaction style |
Dialog |
Direct Manipulation |
| Tasks Structure |
Linear, Rigid |
Complex, Flexible |
| Task Performance |
Atomic |
Dynamic |
| Task Scope |
Few Tasks |
Many Tasks |
From this, object-centered structure is probably better for most sophisticated heavy-use custom applications, which a user uses daily as a principle part of his or her job or area of expertise. This includes software for front-line workers in customer service and support, human resource management, accounting and billing, inventory control, data analysis and visualization, real-time process control, and plan development and monitoring. Task-centered is better for software for basic tasks infrequently done, maybe once a month or less –software that is not a significant part of the user’s job or life, at least in terms of percent of time or user sophistication. Public kiosks, such as ATMs and airline customer self-check-in stations should be task-centered (and typically are). Another candidate would be report generators for executives, most who, let’s face it, won’t take time for training and then most will probably only use the application a couple times, then not bother any more. Emergency procedure execution is another candidate, where users are expected to complete a strictly defined task quickly and accurately on the first live try.
Hybrid UI Structures
Can you have both in the same application? Well, sure, you can have some of your tasks supported by a set of windows with task-centered structure and some supported by a set of windows with an object-centered structure. For example, you could have a largely task-centered structure for the entire application, but include on your home menu something vague like “Manage Paperclip Inventory” or something, that opens an object-centered window for power-users to do unusual or unanticipated task deviations. Of course, this assumes there will be power-users who have gained experience with such a window for some reason. More practically, you could have a largely object-centered structure, but have pulldown menu items that launch task-centered dialog boxes or wizards for selected infrequent but important tasks. On your typical e-commerce websites, product browsing and shopping cart management typically have object-centered structures, while check-out is task-centered.
You can even have the same tasks supported by both task-centered and separate object-centered windows, but this can add complexity to your UI that can confuse the user, forcing them to decide which windows to use in a specific case when they probably won’t know the advantages and disadvantages of each. I had this experience this December when mail merging my holiday newsletter in MS Word 2002. Choosing Tools – Letters & Mailing – Mail Merge Wizard from the pulldown menu yielded a task-centered mail-merge task pane that rigidly insisted on doing things its own way, ruthlessly discarding careful preparations I had already made. What I should have done is choose View – Toolbars – Mail Merge, which provides the commands to work directly and flexibly on my document object.
So give it a try. Take your task analysis, user goals, and requirements and sketch out a task-centered structure and an object-centered structure. Consider all the dimensions covered here and analyze which structure makes for a better overall UI for your users. Choose wisely, because once you get well into iterating designs, switching is very costly.