Figure 1. Workflow diagram representing the "results communications" process as drawn by computational chemists.
This material will be published in the Proceedings of the Sixth Biennial Participatory Design Conference, Nov. 28-Dec. 1, 2000, NY, NY. The proceedings are the only definitive repository of the content that has been certified and accepted after peer review. This material is copyrighted and may not be copied or reposted without explicit permission.
We are working with scientists from a diversity of domains to design and develop problem-solving environments for scientific research. This paper describes our current efforts in conducting domain analysis with different classes of scientists. We have employed a method we call participatory workflow analysis, which allows scientists to easily construct, evolve, and decompose workflow diagrams. Using this analysis approach, the scientists have been able elucidate and document their various research and problem-solving functions and processes. The motivation of this paper is to share our general experiences and findings from our application of participatory workflow analysis with scientists. We will describe the participatory workflow analysis approach, show examples from its usage, and present some of our findings from the analysis.
At Pacific Northwest National Laboratory (PNNL), a group of computer scientists have assembled to investigate and develop problem-solving environments (PSEs) for scientific research. As a Department of Energy national laboratory, PNNL possesses world-class scientists with expertise in a wide range of scientific disciplines. The goal of the PSE team is to work closely with PNNL scientists to understand their scientific problem-solving practices and needs, and to develop PSEs that support and enhance the scientists' abilities to address and solve more challenging and complex problems.
To many, the general notion of a problem-solving environment is unrestricted and all embracing. Gallopoulos, Houstic, and Rice [4] offer the following definition for a PSE.
Over the course of twelve weeks, we held a series of five analysis sessions with five different groups of scientists. During these sessions, scientists described and analyzed their research processes using an informal participatory analysis method we call participatory workflow analysis. The five groups of scientists were:
Computational Chemists - Theoretical and computational chemistry is the study of chemical phenomena through the use of mathematical models and computer calculations. Computational chemists apply high performance systems and tools to conduct molecular modeling and simulation activities.
Nuclear Magnetic Resonance Experimentalists - Researchers apply nuclear magnetic resonance (NMR) spectrometers to characterize and investigate molecular structures. NMR experimentalists place molecules within magnetic fields to identify unknown substances, characterize specific arrangements of atoms within molecules, and to study the dynamics of interactions between molecules in solution.
Automotive Design Engineers - These engineers focus on the design of automobiles and their parts. In their design work, they employ commercial modeling and simulation packages that support various manufacturing and design functions such as forming the shape of a part, welding parts and seams, and simulating crash situations.
Fluid Dynamics Application Experts - Application users and developers apply fluid dynamics models to solve problems involving aqueous solutions. These researchers maintain and apply complex fluid dynamics software that has been developed in-house.
Regional Climate Modelers - Regional climate change models are used to project future environmental and climatic conditions based on current conditions and trends. Atmospheric scientists at PNNL are developing a national modeling center for the study of regional climate change.
Today, most PSE research and development efforts are either focused on a specific domain or application [1, 7] or on the construction of general architectures for problem-solving [2, 8]. Domain-specific PSEs are developed to address the specific needs of a particular group of scientists, and are generally not motivated nor designed to extend to other domains. On the other hand, general PSE architectures are often extrapolated from existing domain-specific PSE work, and may be developed with very little interaction with potential users. Such architectures often subscribe to the least common dominator approach where they attempt to provide capabilities that are applicable across many domains. Since most scientists employ computers in their research, the least common denominator always seems to point at the computer. As such, most general PSE architectures focus on supporting computations by integrating and providing access to applications, computers, and databases.
Our view of PSEs is different. We submit that scientists may in fact exhibit similar behaviors and follow similar processes in their scientific research endeavors, and believe that a broad-based PSE may be developed to address the real scientific problem-solving functions of different classes of researchers. Rather than supporting the mechanical steps of running applications and operating computers, we wish to provide higher-level tools that allow scientists to effectively manage their research and experiments - not just their computer jobs.
Our disposition requires us to investigate PSEs from a different direction. Rather than looking outward from a specific PSE architecture to find applications and users, we want to look inwards from the different scientific domains to identify prototypical scientific problem-solving functions and needs. Our current efforts using participatory workflow analysis are aimed towards gathering scientific domain and work requirements as well as identifying strategic areas for PSE research and development.
Scientific workflow is emerging as a popular concept in the research and development of scientific problem-solving environments [13, 14]. It focuses on those processes that are conducted by scientists during the course of their normal research. In addition to process, scientific workflow is also concerned with the data that is operated upon during the process. As emphasized by Wainer et al. [14], "collecting, generating, and analyzing large amounts of heterogeneous data is the essence of such work, or at least of the components of scientific work that are more naturally the target of workflow management systems (WFMS)."
Workflow analysis is a natural domain analysis technique since its general aim is to describe the work the users conduct, and describes it in a way that makes sense to users. Its use is particular relevant to our project, given our specific interest in the development of problem-solving environments. We were already interested in studying scientific workflow from the perspective of developing workflow management systems. If we are able to develop effective workflow representations and scientists are able to construct and apply these representations in their day-to-day research, then we would expect that scientists should also be able to apply such representations in the analysis of their own practices.
In workflow analysis, we seek to capture and comprehend two kinds of processes that scientists carry out. First, we want to capture the mechanical or procedural processes and tasks that scientists conduct in their research. The procedural process is the one most often depicted in current WFMSs. This is also the process that designers typically want to automate and optimize. Second, we want to capture the cognitive processes and tasks that scientists carry out. We wish to elucidate the cognitive problem-solving process at the scientist's level of thinking.
Workflow diagrams have taken on various graphical representations including entity-relationship diagrams [3], state charts [6], and Petri net models [11]. Looking for a simple representation that scientists could easily apply, we employ a representation resembling traditional data flow diagrams (DFDs) [15]. Data flow diagrams represent a conventional structured systems analysis approach that have been applied by software developers for decades since the advent of traditional waterfall software engineering methods. The use of DFDs in domain and participatory analysis, however, has largely been untested.
Our goal in applying workflow analysis is to gain a basic understanding of the scientific research processes that different classes of scientists carry out. Given that scientists specify, execute, and generally own these processes, the use of participatory design techniques also seems appropriate for our needs. Participatory design (PD) advocates the direct participation of users in the analysis and design of systems that are to be eventually deployed in the user's work [5]. Ideally, users and developers would mutually apply analysis and design methods to create analysis and design representations.
In our study, the scientists' participation is confined to domain analysis since we are not seeking specific design solutions but rather seeking a broad view of scientific problem-solving and opportunities for PSE development. Over the past two decades, a variety of PD techniques have emerged to support participatory analysis. Some well-known participatory analysis techniques include collaborative prototyping [12], storyboard prototyping [9], and CARD (Collaborative Analysis of Requirements and Design) [10]. These methods generally allow users to elucidate the steps of their work processes, the tools and artifacts of their work, and the overall environment from which the work is performed.
To attune scientists to the construction of workflow diagrams, we provided them a simple, informal example of how a meteorologist might diagram his work in collecting and reporting weather conditions. In the example, we drew and labeled circle to represent specific activities such as "collect weather conditions," "compute statistics," and "report conditions and statistics." We connected the circles using labeled arrows that identified the logical order of activities and the kinds of information that was passed between activities. We then decomposed the "collect weather conditions" activity to unveil its underlying steps such as "operating measurement devices," "collecting results in a spreadsheet," and "disseminating the results to local weather bureaus."
The circles and arrows are basic representations of processes and flow (control and data) as found in data flow diagrams and flow charts. Although we used circles and arrows in our example, we did not impose any specific symbology or rules on the scientists' construction of workflow diagrams. In fact, the scientists used random combinations of shapes (e.g., circles, squares, ovals) in their diagrams. The purpose of the meteorology example was to illustrate the kinds of processes we were interested in capturing and studying, and to provide scientists very basic mechanisms to describe these processes.
The construction of workflow diagrams seemed natural and easy to scientists. At times, the scientists did struggle in developing some diagrams, but the labor was mostly centered on the elucidation of research processes rather than the mechanics of diagramming. Figure 1 presents a workflow diagram developed by computational chemists during an analysis session. The diagram describes what the chemists called "results communications," which is the process they carry out as they organize and analyze their experimental results in preparation to publication writing. The process consists of various steps such as conducting a literature search, gathering theoretical and experimental data, creating tables and figures, examining relevant comparisons and discrepancies in the data, validating the experimental results against theoretical findings, hypothesizing future results, and submitting to refereed publications. The diagram of Figure 1 also illustrates the evolution and refinement of experimental results throughout the "results communications" process, as accumulated experimental and theoretical data is successively distilled first into tables and figures, then into general statistics and trends, and then finally into validated estimates. In the diagram, the chemists also identified those steps that typically involved collaborative effort among computational chemists.
Figure 1. Workflow diagram representing the "results communications" process as drawn by computational chemists.
For the most part, the chemists were able to describe the "results communications" process in the context of their scientific research activities. One exception is the "create tables or structures or figures" step of Figure 1, which identifies the mechanics of the table creation activity rather than its scientific purpose. This activity may be rephrased in a scientific context as "identifying the salient, crucial portions of the theoretical and experimental data." During workflow analysis, we found that scientists would sometimes describe portions of their workflow in terms of the manual operations they perform. In such cases, we encouraged the scientists to elaborate the scientific purposes and meanings behind those operations as well.
The primary usefulness of the workflow diagrams was to provide a concrete artifact for analysis and discussion. The diagrams allowed scientists to quickly create and share representations of their work. Explicitly, the workflow diagrams described research activities and the control and data flow among these activities. Additionally, we asked scientists to identify
After an analysis session, we would sharpen and formalize the workflow diagrams that scientists had created. We introduced a standard set of symbols so that we could describe and compare the workflows of different groups. The resultant symbology and workflow representations generally conformed to the methodology of data flow diagrams (DFDs) where circles, double lines, squares, and arrows respectively represented activities, data stores, external entities, and flow [15]. We extended the DFD methodology by introducing diamonds to represent decisions points (borrowed from flowcharting techniques). Our use of arrows is also different from conventional DFDs in that they represent both control and data flow. Arrows represent the logical order of activities, but are labeled with the types of data that are passed between activities. We use arrows with dashed lines to represent pure control paths, and labeled arrows with solid lines to represent control paths that involve the passing of data. Normally, we would only identify the primary control and data paths in the workflow diagrams.
From our analysis sessions, scientists were able to describe both cognitive and procedural processes using the same workflow analysis approach. Higher-level workflow diagrams tended to focus on goals, motivations, and cognitive processes. Scientists would then successively decompose high-order tasks into their mechanical steps. Thus, lower-order workflow diagrams tended to focus more on procedural and mechanical operations. The successive elaboration of processes may be seen as a form of task decomposition.
Figure 2 presents a workflow diagram that resulted from workflow analysis with computational chemists. The diagram identifies the high-level activities that computational chemists conduct as they investigate potential research areas and formulate problems to attack.
Figure 2. Workflow diagram representing the problem identification process carried out by computational chemists.
From the diagram, computational chemists begin their investigation by reviewing existing research in their area of concentration. Information on existing research may be gathered from publications or from communications with peers. From the existing research, the chemists identify the class of problems in which they are interested and capable of pursuing. Once this class is identified, the chemists may then accumulate theoretical and experimental data that has already been discovered and is available to them. The data is collected from publications, directly from other researchers, or from database or repositories of molecular information. Based on the results of existing research, the chemists then identify the specific molecules they wish to study and the specific computational methods they wish to apply to formulate a computational chemistry problem. Once the problem is defined, the chemists partition amongst themselves parts of the problem and the actual computations to be conducted.
The workflow diagram of Figure 2 represents an informal process that is followed and managed by those specific chemists participating in our study. We expect the problem identification processes of different computational chemists as well as scientists in other domains to vary based on the science under study, the organizations for which they work, the attributes of their projects, and their personal research styles. In the case of the computational chemist, the objective of describing the problem identification workflow is not to capture and impose the procedure on other chemists or scientists, but more rather to comprehend the process in order to better support or enhance its effectiveness and usefulness with PSE technology.
The workflow diagram illustrates the chemist's general accumulation of research data in the form of literature references, research notes, and theoretical and experimental data. To a large extent, chemists currently maintain these different kinds of data in different forms in different places. Research data may reside on loose paper, in a notebook, in an electronic file, or in a database. Yet, computational chemists continually reference and evolve all this research data over the course of their experiments. The accumulation and longevity of the research data emphasizes the potential utility of integrated records management capabilities to help manage experimental data.
Another notable characteristic of the workflow diagram is the presence of a calculation table. The chemists in our study use a calculation table to manage their calculations. The calculation table specifies different combinations of molecules, computational methods, or other chemical or computational attributes. When the chemists initially formulate the problem they wish to attack, they develop a calculation table to specify the set of calculations to be conducted. If the current problem involves extending or completing research initiated by others, portions of the calculation table may initially be filled with results from previous research as gathered from publications, chemistry databases, and interactions with peers.
In addition to managing the set of calculations, the calculation table is also used to assign and manage tasks among collaborators. A particular chemist might be responsible for all calculations associated with a particular molecule, computational method, or some other attribute. In such an instance, the subset of calculations assigned to the chemist would represent a row or column in the table. Typically, the calculation table is maintained on paper and each chemist keeps and manages her own personal copy of the table. They may synchronize their copies of the calculation table at key points during the research.
The calculation table represents a unique concept and capability that may be supported by a PSE. An electronic version of the calculation table would provide a centrally managed tool that chemists may share. Through such a tool, chemists could verify the current research status of their collaborators. Furthermore, if a specific entry in the calculation table was actually linked to the actual research data and log of activity of the calculation it represents, chemists may gain immediate access to the calculation's historical record to verify the calculation's correctness or to track down anomalies or errors in its results.
In Figure 2, the workflow diagram for "problem identification" describes the authentic practice of scientists during a particular stage of their research. One aim of workflow analysis is to unveil the scientific practice and the problem-solving behind that practice. The normal work functions of scientists, however, also involve many activities that are auxiliary to their scientific research. Many functions centered on the operation of computers fall under this classification. Tasks such as creating input files, translating between data formats, and executing programs on remote machines are all specific side-effects of using the computer as a tool in scientific work.
Among most of the scientists participating in the workflow analyses, the employment of high-performance computers is critical to their research because it allows them to solve bigger and more complex problems. Nevertheless, the truth remains that the less time scientists devote to attending to the details of operating computers, the more time they will have to devote to their scientific pursuits. This view leads to yet another aim of our workflow analysis, which is to identify processes that may be optimized or automated. Conspicuous candidates for optimization are those processes that are mechanical or procedural in nature such as submitting a computer job to run on a remote machine.
The workflow diagram in Figure 3 conveys the procedural execution of a computer simulation as described by regional climate modelers. The regional climate model in the diagram simulates local effects caused by changes in the regional climate. The model is a sophisticated, resource-demanding application that is typically executed on high-performance computers. The workflow diagram identifies the main parameters fed into the model as spatial resolution, scenario, temporal range, temporal frequency, and other model parameters. The complete set of model parameters is collected in an input file. The modeler then selects a computer on which to execute the regional climate model with the created input file. The computer job is then executed on the selected computer. As the job is executing, the modeler monitors both the status of the computer job and the generation of the regional climate data set. Regional climate data sets produced from successful runs of the model are often archived for future use and analysis.
Figure 3. Workflow diagram representing the model execution process carried out by regional climate modelers.
In addition to monitoring the progress of a computer job, the ability to monitor the progress of the application or model is also important to the modeler. The regional climate modeler typically reviews the intermediate data produced by the climate model as it is executing. If discrepancies or unexpected results are found in the intermediate data, the modeler will try to trace the error back to incorrect or questionable input parameters. A useful function of PSEs would be to allow users to select specific properties or fields of the intermediate results produced by the model, and have these properties be monitored and tested against certain conditions. If the selected properties fail to meet the specified conditions, the PSE could alert the user and facilitate the modification of the input parameters and the restart of the application.
As shown in Figure 3, the modeler may iteratively modify the input parameters and rerun the regional climate model. In fact, modelers would often run their models with different input parameters to explore and experiment with the functionality and boundary conditions of the application or model. In other cases, the modeler may partition their target region into smaller areas and run multiple regional climate computations in parallel. A large number of computations may be difficult for modelers to maintain and manage. Records management capabilities would be useful in assisting the modeler keep track of his computations as well as provide a historical record of activities that may be reviewed and verified.
Different scientists have different problem-solving requirements and foci depending on their specific research functions and roles. One way to better understand a scientist's research functions in comparison to those of other domains is to examine and contrast the individual stages of their research processes.
For each domain in our study, we developed high-level workflow diagrams to describe the domain's general research process. In Figure 4, we have collapsed this collection of high-level workflow diagrams into a single generalized workflow representation. The generalized workflow consists of the following six specific stages.
The workflow diagram in Figure 4 also identifies key decision points in the problem-solving process. The first decision point occurs after the experiment is designed. If the experiment's specification is not complete at this point, the scientist must either further define the problem or abandon the problem as one that cannot be resolved given the experiment's current design. Upon conducting the experiment, a second decision point is reached. Scientists look for specific patterns, trends, and behaviors in the experimental data to verify its reasonableness. If the specific patterns do not exist, the scientist must redesign the experiment to correct any flaws in its design.
The final decision point comes after the results of the experiment have been collected and analyzed. At this point, the scientist verifies the completeness and conclusiveness of her findings. If the findings are found to be incomplete or inconclusive, the scientist may redefine the problem or redesign the experiment and conduct additional runs to validate or bolster the findings. Alternatively, the scientist may conclude that the problem is unsolvable or intractable and abandon it altogether.
Figure 4. High-level workflow diagram of the scientific research process.
Figure 4 presents an expanded view of scientific problem-solving that extends beyond the scope of most modern-day problem-solving environments. General PSE architectures focus on the "conduct experiment" stage of our scientific research model. They generally provide tools to integrate, execute, and monitor computer-based simulations and calculations in distributed computing environments. In comparison, domain-specific PSEs have greater breadth. Such PSEs may provide tools that allow scientists to build preliminary data sets, identify specific scientific properties, construct input files, execute simulations or calculations, statistically analyze data, and visualize experimental results. These are all functions of the "prepare experiment", "conduct experiment", and "collect and analyze results" stages of our scientific research model. Both general and domain-specific PSEs are typically geared to solve computational problems.
The high-level workflow diagram in Figure 4 illustrates the other problem-solving stages that are generally neglected by the PSE development community. In the three problem-solving stages supported by domain-specific PSEs, these three stages capture the mechanical process that scientist carry out as they conduct experiments. What existing PSEs fail to capture is the very process in which the mechanical process is designed. An experiment has specific scientific goals. It has constraints (e.g., time, space, money, manpower) and access to specific resources. The ability to fashion an experiment to optimally make use of resources, alleviate constraints, address goals, and identify solutions is a critical part of scientific problem-solving. We call this function of scientists', experimental design, which is encapsulated in the "design experiment" stage of our scientific research model.
Furthermore, experimental design fits within an even larger context. Scientists design experiments to investigate and validate specific hypotheses. When scientists identify problems, they also formulate the hypotheses they wish to prove. We call this more basic function of scientists, research design, which is encapsulated in the "define problem" stage of our scientific research model. The problem and the hypotheses are the drivers of the research. The high-level workflow diagram provides a context from which we can review and analyze the problem-solving characteristics of different classes of scientific problem-solvers. The research processes that scientists elaborated in their workflow analyses emphasize different stages of our high-level model. In Table 1, we examine the research activities of each class of problem-solvers with respect to the individual stages of our scientific research model.
Table 1. Research activities of different classes of scientists throughout specific stages of the scientific research process.
In the case of the automotive design engineer and the regional climate modeler, these problem-solvers do not play a significant role in defining the problem. The engineer attacks design problems that are assigned by his manager, while the modeler leaves it to the external client to specify and solve her own particular problems. As a result, engineers and modelers may require little PSE support for problem definition. In contrast, the fluid dynamics application expert works with his client to specify the problem. The client originates the problem, but the application expert helps the client elaborate the problem in the context of the application. Thus, the application expert may make use of capabilities that allow her to share and brainstorm problems and issues with clients.
For the computational chemist, NMR experimentalist, and fluid dynamics application expert, these scientists first identify the problem and then fashion a research design or strategy to reach a solution. To support the activity of research design, scientists may desire high-level capabilities to develop, manage, and track research hypotheses, and to tie these hypotheses more closely to the actual experiment.
In next stage of our scientific research model, scientists design experiments. Except for the automotive design engineer, all scientists in our study actively planned out the experimental process. In their experimental designs, the scientists identified the specific steps of their experiments and the key decision points in the process. Furthermore, the experimental design may also identify the computing and scientific resources to be applied. Typically, the experimental design is informally specified in loose notes or in the laboratory notebooks of individual scientists. Capabilities to assist scientists in identifying resources and in specifying, maintaining, and sharing the experimental design would be useful to scientists. The capability to manage and navigate the process that the experimental design represents would also be useful. These kinds of capabilities have largely been associated with WFMSs.
For the automotive design engineer, the design of their work processes is somewhat fixed. The engineer follows a particular sequence of steps (i.e., forming, welding, crash simulation) and employs specific applications and computing resources that are mandated by his organization. To support engineers, one might envision capabilities that allow managers to define and make available specific design models for engineers to follow.
For the computational chemist and the NMR experimentalist, these scientists often conduct experiments that involve completing or extending existing research work. In such cases, the scientists derive their problems and data from research that may be gathered from published work, molecular or chemistry databases, or directly from collaborating researchers. A useful capability for these scientists would be some facility to draw and accumulate theoretical and experimental data from a variety of sources.
For the fluid dynamics application experts and regional climate modelers, their models are typically executed in conjunction with other domain-specific models. For example, a hydrologist may execute a groundwater model on a data set that was originally produced by a regional climate model. Thus, the ability of scientists to incorporate new domain-specific models and advisor tools that may assist them in selecting and applying the correct set of domain-specific models would be a useful capability.
For all scientists, the negotiation and assignment of tasks were typically accomplished during this stage. Tasks scheduling and monitoring would be another useful capability for scientists - particularly if scientists were able to define and manage tasks along meaningful mechanisms such as the computational chemists' calculation table.
Except for the NMR experimentalist, all scientists in our analyses run computational models as the primary activity in their experiments. To prepare for the calculations, these scientists collect required input information to define their models. The input information represents specific scientific attributes of the model, and thus, is domain and model specific. To collect model attributes, scientists may employ general computational tools such as molecule builders, data analysis packages, and CAD/CAM systems. In other cases, more specialized, domain-specific programs may also be applied. The diversity of computational tools emphasizes the need for an integration platform where different programs may be integrated into a common environment.
For all scientists, a data management facility for storing and managing model attributes would allow scientists to reproduce, review, validate, and share model information. In addition, the regional climate modeler may have to conduct field studies to collect salient information to be fed into the regional climate model. Thus, data acquisition and management facilities for collecting and managing external data would also be useful to the climate modeler.
In some cases, the computational chemist, fluid dynamics application expert, and the regional climate modeler may need to develop custom functions to be integrated into their scientific models. The main applications that computational chemists and regional climate modelers apply are normally designed to be extensible - allowing end-users to incorporate and access their own functions from within the application. The chemists and modelers did occasionally incorporate new codes into their main applications. The fluid dynamics application experts, however, did often modify or extend the code of their main fluid dynamics application. Their main application was developed in-house - giving them the freedom to modify the actual code to solve specific problems.
To accommodate end-user development of code, another useful feature would allow the end-user to integrate and configure his own code modules, and allow them to be used with other applications and models. A more sophisticated solution would be to provide actual software development support through a programming environment.
Except in the case of the NMR experimentalist, all scientists in our analysis execute one or more computational models in their experiments. Scientists may seek a variety of capabilities to assist in executing computational models such as intelligent user interfaces, job launching, resource management, records management, data archiving, application monitoring, and interactive steering.
Furthermore, the automotive design engineer and the regional climate modeler typically work with a number of different models. In their cases, additional capabilities to manage and integrate different computational models and to provide translations between different accompanying data formats would also be valuable.
In the next stage, scientists collect and analyze results from the experiment. Unlike other kinds of scientists, the NMR experimentalist collects raw data directly from a physical device. He uses a specific hardware and software system to acquire the data and to store it on a computer. For the NMR experimentalist, data management facilities need to support the collection, management, and integration of data originating from physical devices.
During data analysis, the precise reasoning that a scientist follows is bound to vary among different domains and individual scientists. Regardless, all scientists generally evaluate their experimental results in relation to the scientific hypotheses they established during problem identification. The capability to track hypotheses and manage the research design process is relevant to this stage as scientists attempt to validate their experimental results and conclusions against the problem and hypotheses that they originally defined.
Furthermore, scientists employ a variety of tools during analysis such as visualization and statistics packages. The use of such tools again emphasizes a general need for an integration platform from which different applications may be accessed and linked.
In the final stage of our scientific research model, all scientists conclude with the writing of a publication or technical report. While commercial word processing and desktop publishing tools are in abundant supply, specific capabilities to gather and organize experimental hypotheses, models, data, and findings would be particularly useful and relevant to scientists and their writing functions. In addition, scientists may also wish to have collaborative writing and publishing tools that allow them to collaboratively develop publications and reports.
We have applied participatory workflow analysis with scientists from five different domains. The collective results of the analyses underscore the similarities and differences among the problem-solving functions and processes of different scientists and domains. These results are important and useful because they
For our next step, we are planning to work with atmospheric scientists to develop a PSE for regional climate research and applications. Working from our current domain analysis of regional climate modeling, we will conduct more detailed requirements analysis and design, using additional participatory design methods such as collaborative and storyboard prototyping.