FIGURE 7.2 Interrelation of

and Materials

Material Design Tool Design

Work Environment

FIGURE 7.2 Interrelation of tools and materials.

SOLUTION

We model an application system from the user’s view in the core as a meaningful collection of materials and tools suitable to complete different tasks at a single workplace.¹For this purpose, we first define the current tasks to be supported by the future system and the task that will be handled in the same conventional way once the system is in place. The tasks to be supported define the work con-texts in which users handle tools to manipulate materials.

Our application system should allow for completion of the tasks on hand so that it reflects the way these tasks were handled before the system was in place. This similar-ity is initially reflected in the application-oriented core of the materials. This means that the important materials in the application domain form the platform from which we start modeling the software materials. We always think of materials as objects in the computer, which have to be manipulated as before.

In this connection, we use tools that show us the relevant aspects of the materials manipulated and offer us the required work options. A tool should be handy so that we feel comfortable using it to manipulate materials. After all, we want to concentrate on the material rather than on the tool. The tool lets us access and interact with a mate-rial, but then remains in the background.

Tools are normally designed for recurring tasks; they are well-suited to complete the tasks at hand. Software tools are not images of real-world tools. They represent domain principles and recurring actions necessary for the completion of tasks. In this respect, they support work forms appropriate for specific materials and support possible interactions in software. Tools may be thought of as the means to support recurring activities, which may differ depending on the material and the situation.

EXAMPLE

Let’s return to our EMS example. We have seen that the device manager has used until now a few simple, general-purpose tools, such as a pen, ruler, and eraser. But she has worked on a variety of materials: the room plan, device identification cards, and employee information. It seems sensible to start our design from these work objects and tools familiar in the application domain. The work materials look like good candidates for elements of our usage model for the application. At the same time, it is obvious that we cannot transfer the available tools such as a pen or ruler into one-to-one software elements. Nevertheless, the overall idea looks promising. We want to design an appli-cation where the device manager can work with appropriate tools on room plans, device identification cards, and so on. Even the basic interactions seem to be appro-priate for our usage model: a tool should support the purchasing of devices; when an employee moves to another workplace there should be a tool to modify the room plan;

and so on.

BACKGROUND

Objects (in the sense of things) are used in daily work to complete tasks. At our work-place we arrange these objects so that they are available, depending on the work situa-tion. We normally have no problem classifying most of these objects as either a tool or

1. Chapter 10 will take a closer look at distributed and cooperative work situations.

Similarity of materials

Tools

The EMS example

a material. Depending on the work context, we select appropriate tools suitable to han-dle materials so that we eventually obtain the desired work result.

The conceptual pattern interrelation of tools and materials helps us to take these work contexts as our platform for the software design. The corresponding components of an application system should be understood as tools and materials and designed accordingly. In this attempt, we cannot simply transfer existing tangible tools and materials to software. In fact, this is not even desirable. Tools and materials should be designed to fit the potential of application software, where we have to observe several side conditions.

An analysis of the application domain results in a domain model. This model rep-resents the relevant work objects and their usage forms or interactions. These interac-tions result from the way the objects are altered and probed when completing the relevant set of tasks. This defines the domain core of the materials, because we assume that the important tasks will be maintained beyond the introduction of our application system.

There is an important difference to note when mapping work objects from the real world onto the domain model: when actively completing their tasks, users have to use software tools to be able to manipulate materials. Users cannot simply grasp software materials in their hands. This means that we have to design a tool suitable for each case. In your software system, a material is always the object that is manipulated by a tool (or an automaton) within a work situation.

A tool can be understood by looking at the ways it is used to manipulate materials.

Tools present materials fitting for the work situation, offering users the desired func-tion. A tool represents recurring manipulations of materials. The quality of the work depends largely on how well the tools are suited to produce the results. In turn, the tool quality depends on properties like easy handling, efficiency, and consistency.

This means that tools and materials are closely related, so we always need to deal with them together. The same applies to the software design of tools and materials. A tool can be conceived only by its use to manipulate materials. A material is what we can do by the use of tools.

We can thus exclude the possibility of directly transferring existing objects to software components. For this reason, we have to look at the concepts behind the materials existing in the application domain, and the activities to complete the set of tasks. They represent the work relationships that we can use as guidelines in the design of tools and materials for an application system.

We further assume that a material can be probed and manipulated in different contexts, thus taking on different states. This corresponds to a normal work situation.

Depending on the tasks at hand, users are interested only in specific properties or spe-cific states of a material. This means that a material is normally manipulated by the use of different tools, and that we handle a material in different ways, depending on different states. For example, once a user has purchased a device, it should not be pur-chased again. On the other hand, a device should be planned, if it is to be positioned on a room plan.

A tool is not suitable for only one specific function. It is generic in that it can be used for different tasks and purposes, that is, it has more than one function. Only a few tools are designed for a special use and a single material. Matured tools can be used to manipulate different materials in a similar way.

From analysis to

RATIONALE

The concepts behind tools and materials are closely related to each other. We always have to look at them in combination. We have to define a coherent set of tools and materials to support the user in an optimal way in his or her daily tasks.

WHATNEXT

The patterns for material design and for tool design take a look at each of the concepts introduced here in more detail.

7. 4 T H E M AT E R I A L D E S I G N P AT T E R N

INTENT

Materials are both objects and outcomes of work activities. They form the domain basis for the application system. Therefore, we take a closer look at how to choose and design material.

PROBLEM

We have to bridge the gap between the work objects of the application world and the conceptual material units for the application system. Therefore, we have to solve the following design problem:

We want to identify the main material concepts of the application domain that are relevant to the daily tasks of the users. As materials should be conceptual units, we have to choose and design them well regarding the system under construction.

Materials are probed, manipulated, and embedded in other materials. They can take different work states; when working with them, users concentrate on manipulat-ing them.

We have said that we use design metaphors to analyze the materials relevant in the application world. We have also used them to model appropriate usage models. We