Enhancing Workflows by Web Technology - CiteSeerX

Enhancing Workflows by Web Technology Wolfgang Grgther, Wolfgang Prinz, Sabine Kolvenbach GMD - German National Research Center for Information Technology FTI’- Institute for Applied Information Technology SchloJ3Birlinghoven 53754 Sankt Augustin, Germany {sumame.givenname)@gmd.de

are located at one place today, will soon be distributed over two or more locations. To avoid communication delays between cooperating partners at different locations it is necessary to develop an adequate computer based cooperation support for ministerial processes.

ABSTRACT

This paper presents a hybrid approach for the support of workflows in a ministerial environment that integrates a Web-based interface into a groupware platform. A scenario of the application area is examined to identify the basic requirements for an adequate user support. The basic PoLffeam approach for the support of workflows by electronic circulation folders is introduced. Focal point of the paper is the design of the Web-based interface for the interaction with electronic circulation folders and its seamless integration into the groupware platform.

The developments presented in this paper are based on an evolutionary and participatory design approach. The approach is characterized by a close interaction with our user groups in a German Ministry who use the PoLlTeam system for support of their daily work. This allows us to derive the requirements for the development of PoLlTeam from the actual use of a groupware system. Our experiences indicate that this approach leads to a system that provides an adequate electronic support for cooperation processes and its integration into the groupware platform.

Keywords

workflow, electronic circulation folder, HTML, Internet, JAVA INTRODUCTION

The remaining of this paper is organized as follows. First we present an outline of the working processes that the PoUTearn system aims to ,support followed by an identification of the requirements for an adequate support of these processes. Then the basic design of electronic circulation foIder component is introduced. The main part ‘of the paper concentrates on the design of the Web-based interface for the interaction with electronic circulation folders. Furthermore the PoLIWeb gateway is presented that provides a Web-access to the shared workspace component of the PoLlTeam system.

The design of Web-based interfaces for all kinds of applications and in particular groupware applications became very popular recently [2]. We present a hybrid approach that combines the facilities of an HTML.-based user interface for the interaction in workflows with a traditional windows user interface. In most cases a Webbased user interface is developed to provide a platform independent interface to an application that is usable from any computer that has Internet or Jirtranet access. Although we also wanted to take advantage of these properties, our further motivation to utilize this interface technology~was to develop a user interface that allows browsing and interactions close to the traditional working modes on paper. This paper presents the design of a flexible workflow system for the support of administrative work that is enhanced by an interactive HTML interface. .

THE WORKING PROCESS AND ITS REQUIREMENTS

This section provides the organizational background at our application partners that led to the development of the GBE’ system. We will first present a scenario to illustrate the work setting and processes that we aim to support. This is followed by an >dentification of the requirements that have informed our design process.

Background of the presented developments is the PoLlTeam project which aims to develop electronic cooperation systems for the distributed governments located in BOM and Berlin. Government departments that

The methods that we apply to identify the requirements for an adequate user support are interviews, user-advocates, user workshops, and designer workshops. The combination allows a derivation of user requirements from the actual use

Permission to make digitnlhnrd copies of all or part of this materiel for personal or chssroom use is grnnted without fee provided that the copies we not made or distributed for profit or commercial ndwntage, the copyright notice, the title of the publication and its date nppear, nnd notice is given thnt copy&& is by permission of the ACM, Inc. To copy otherwise. to republish, to post on servers or to redistribute’to lists, requires specific permission nndlor fee. GROUP Copyri&t

97 Phoenix Arizom

t GBE: “Geschaftliche Behandlung der EmgSinge” (Approval of incoming documents).

.!I,$4

1997 ACM O-89791-897-5/97/1

1..$3.50

271

addressee or the content of the document, based on an organizational plan of responsibilities. However, the document is not forwarded immediately to the final recipient in one of the units. First, the document is passed along the hierarchy.

of the PoLfleam system by our application partners. Based on that feedback, the .POLfI’eam system is improved in evolutionary cycles. Currently the third system version is installed at the application partners sites. A detailed description of these complementary methods and our experiences with these can be foundin [9].

For that purpose, the document is included in a circulation folder that is addressed to the unit to which the final recipient belongs. The folders for all units that belong to one department are then forwarded in a larger folder to the head of the department, i.e. this manager receives a folder which contains a folder for each of the subordinated units.

The Working Process

With the PoLflYeam circulation folders we focus on the support of workflows within a ministerial environment, in particular on the support of the managerial level. Although this is a specific application area, we will see that many of the requirements identified from that process are general and that the concepts of the developed solution are applicable for other working environments too.

This folder is received by the secretary of the department manager. The secretary pre-scans the documents and probably sorts the documents according to priorities or other preferences of the manager.

Let us now consider a working process that spans several hierarchical levels. Figure 1, illustrates the organizational structure of a ministry and the flow of process documents between and within the involved organizational units. n

@

c flP Post Oflice

The manager then works through the pile of documents. After a document is read the manager signs the document in the appropriate field of the stamp that was created by the post office. Advices for the subsequent processing of the document are provided by a set of standardized dispositions. They indicate for example that the manager wants to discuss the document before actions are taken by a unit-worker, or that the manager wants to receive a copy of an answer to an incoming request before it is returned. Many of these shorthands are standardized by appropriate symbols. In addition, the document can be annotated with further comments. All written comments on the document are made by the department manager using a pen of a certain color, i.e. the color that is assigned to the organizational role.

l d

Minister

Department

Subdepartment

If the manager decides to forward the document to another unit than the one initially selected by the post office slho simply strikes-through the number that indicates the receiving unit in the stamp and replaces it with the number of the unit that s/he prefers to process the document. When the secretary post-processes the pile of documents, rerouted documents are moved into the appropriate folder. The folders are then forwarded to the managers of the subdepartments who perform similar operations on the document.

Unit

Figure 1: Simplified organizational structure of a ministry. The ministry is organized in four hierarchical levels. The minister and state secretaries represent the’ top of the pyramid. According to differentorganizational or political functions the organization is then divided into departments that are further divided into a few subdepartments. The basis of the ministry is build by different units, which each belong to a subdepartment.

When the employees at the unit finally receive the document the different colors used by the managers for their annotations help them to identify the role of the manager whomade comments to the documents. If an incoming document requires an answer by the ministry, this is produced by the members of the unit. Before the response is sent it must be approved by the department and subdepartment managers. For that purpose the whole set of process documents including the answer and an additional cover sheet are included in a circulation folder and forwarded to the department manager. At each management level the answer is approved by a signature on the cover sheet and often annotated with comments.

Each mailing that is sent to the ministry is first received and opened by the ministries post office, unless it is a private mailing. Then the covering letter of the incoming documents is stamped. This stamp provides various fields which are filled in by subsequent receivers of -the document. Additionally the post office decides on the recipient of the documents. This decision is made due to the

272

Although derived from a very specific application domain, most of these requirements are applicable to other working environments too. Therefore we believe that the concepts presented in the following sections provide a general input for the designers of cooperation support systems.

Sometimes even the whole folder is returned to the unit for the development of an ahemative response. This process also inchtdes other organizational instances, for example a registry, but these further details are out of the scope of our considerations for the GBE system.

In the next sections we will first present the initial Pofleam solution which is based on an adaptation of the groupware platform LinkWorks and the integration of different office application. Then we describe how an HTML-based approach provides more adequate solutions for the identified requirements.

Requirements

After this brief ihustration of a working process that involves the managerial level we will now identify some basic requirements for an electronic support. A department manager receives a pile of 30-60 incoming documents three times each day which are processed within 15-20 minutes. This indicates that an electronic support must provides means for a rapid browsing through electronic documents. Although the incoming documents will be of different types, e.g. scanned letters, fax, or email, the flow of work should not be disrupted by the need to start different applications for each document type.

BASIC WORKFLOW SUPPORT IN POLITEAM

The client-sever groupware system LinkWorks [7], by Digital, has been selected as the development platform for PoUTearn. Integrated into this object-oriented platform we realized three basic components: shared workspaces [15], electronic circulation folders, and an event notification service [14] for the provision of awareness about actions in the cooperative environment.

It must be easily possible for a user to annotate documents and to give comments according to the standardized set of dispositions, using the color that corresponds to the managerial role. It is also an important prerequisite for the acceptance of an electronic solution to supply a user interface that is similar in look and feel to the traditional paper-based process. This includes an indication of the amount of incoming documents and the current progress of the individual work, e.g. the amount of documents that have already been processed.

The design of these components is guided by the approach to provide the user with a collection of complementary and integrated cooperation tools instead of predefmed cooperation mechanisms. This allows the users to select and adopt the tool that is most appropriate for the actual cooperation needs. The workflow approach chosen by PoLlTeam is similar to the ProMInanD system [6]. More sophisticated attempts such as the one described in [12] or [S] are not useful for our application area, since a more formal description of the working process would impose too many constraints on the users working style.

Most processes down the hierarchy are characterized by a fast scanning and commenting of incoming document. During that task the manager becomes aware of the process that belong to his/her department and they are enabled to provide advices for their employees. Processes that proceed the opposite way often involve political decisions. Therefore an electronic support must also integrate an solution for the authentication of signature and the reconstruction of decisions.

In the following section we describe the basic LinkWorks functionality concerning workflow processing and how this functionality was adopted and extended to realize electronic circulation folders. The section concludes with a discussion of that solution.

Looking at the process we must enable the user to re-route or return documents easily. This must be as simple as writing a new recipient on the paper document. A solution which requires the user to specify an ad-hoc workflow seems not appropriate. For the recipients of the documents it should be possible to easily grasp the comments and advices provided by the predecessors of the document.

Circulation Folders in POLlTeam

LinkWorks supports the worHow fhnctionahty by circulation slips. A user may attach a circulation slip to any LinkWorks object, e.g. documents or folders. For this purpose users make use of predefmed workflow blueprints, which can be adapted, or they define the transport route of the workflow from scratch. The transport route consists of a set of workflow activities, whereby the transport route may be sequential or parallel. LinkWorks presents the circulation slip as a graph, wherein the workflow activities are displayed by different colors. Passed workflow activities are blue, the current one is red and the activities not yet reached are black. If the user selects a workflow activity, LinkWorks shows detailed information like the receiving and leaving date.

The following lists summarizes, the requirements: fast browsing through incoming documents of different types, means for the annotation of documents and provision of standardized dispositions, provision of awareness about the progress of the working process, secure authentication of signatures and reconstruction of document history, and flexible re-routing of workflows.

To represent the ministerial workflow process PoLrTeam expands the basic LiiWorks functionality and implements three new types of folders derived from a LiiWorks

273

container class: a circulation folder for normal ministerial processes (green), a circulation folder for procedures with a high priority (yellow) and a red colored circulation folder which transports only requests of the government cabinet and takes precedence of other incoming tasks. The representation of different colors informs the user immediately about the priority of an incoming circulation folder. Furthermore the user can use the type of the circulation folder as a sorting criteria in a list of folders. Meta-information about a workflow-process is managed in PoLl’I’eamby the implementation of a special object, called cover-object. The cover-object is part of the circulation folder. It provides meta-information of the procedure such as record number, responsibility or additional comments. The PoLfleam approach is to design the circulation folder as an electronic media which is able to transport any documents, e.g. text, graphics, audio, video etc. During the workflow process the participants may add and remove documents by simple drag and drop operations between the desktop and the circulation folder. When a document is opened (double-click), the application appropriate for that document type is launched. Furthermore workflow members may modify the circulation slip if required. The type of operations allowed on the circulation folder and its contents can be controlled by appropriate access rights.

-Ix_---~-.--l.-.._.-_.___

.^_-

Figure 2: User interface of the mail inbox. LinkWorks informs a workflow member in detail about status and current location of a circulation folder. Thus a workflow member is informed about the complete history of a workflow process, but on the other hand interviews with the pilot-users indicated concerns that this information can be misused for observation and control purposes. Thus, we reduce the detailed set of information to a simple status information. When users forward the circulation folder to the following workflow participant PoLfleam leaves a shadow object in the mail outbox. By opening this special object the user is informed about the actual location of the circulation folder. Further information about specific receiving and leaving dates is hidden. This increases the acceptability of such a tool for the users.

Interactions with Circulation Folders

In LinkWorks, all incoming documents and containers are encapsulated by an envelope including information about the sender, the sending date, subject etc. When users open their mail inbox they are not able to distinguish between different mail types or to recognize the priority, since all objects are encapsulated. Therefore it is necessary to open the envelopes to determine their contents. To provide a more convenient way of interacting, POLITeam extends the functionality of the mail inbox to the effect that an incoming circulation folder is automatically unpacked. This avoids multiple operations and users are informed immediately about the type of incoming mails.

Signature List

We have illustrated in our scenario that the authentication of signatures and the reconstruction of the document history is important for the support of workflows that spnn hierarchical levels. For that purpose a cover note is attached to each workflow. Each person who approves the workflow signs with a colored pen and may additionally add further comments. During the workflow process the complete history is documented on the cover sheet.

Figure 2 shows an opened mail inbox on the PoLtTeam desktop. The interface is subdivided into three parts. In the upper left part POLlTeam lists all incoming mails. The circulation folders are presented by their colored symbols and ordered according to the priority. If the user opens a circulation folder Po&fI’eam shows the documents included in the circulation folder in the upper right part of the interface. The content of the selected document is displayed in the lower part of the window. This functionality enables a user to browse quickly through the content of received circulation folders.

To support the secure authentication and signing documents POLlTeam functionality on electronic implements the signature list. To realize that, POLlTeam integrates SecuDE, the Security Development Environment [13], which supports digital signatures according the RSA technique [ll]. The user interface design of the signature list is adopted to the outlook of the cover note.

274

through a stream of documents. In this case the viewing and handhng of singIe documents is too time consuming because the user has to interact with the documents step by step. We expect that an interface design approach that is more closely related to the traditional paper-version and that allows the user to browse smoothly through the contents of the circulation folder provides a better user support than our basic support. Based on this expectation the next section describes our approach to provide an alternative HTML-based interface for the interaction with workflows as an extension to this base version. CIRCULATION FOLDERS AND HTML

The GBE system supports the approval of incoming documents. It is an extension to the initial PoLrTeam solution that meets the specific requirements of managers listed in a previous section. In this section, we describe the user interface, especially presentation, interaction, and awareness aspects. Subsequently we look closer at the system architecture, describe major design decisions, explain the component structure, and discuss our approach.

Figure 3: User-interface of the signature list. Figure 3 shows the interface of the signature list which consists of two parts. The upper part of the window lists the members who are involved in the signing process. PoLtTeam enumerates the roles and names of the persons in the hierarchical order they have to sign. After a person has supplied the signature PoLfI’eam shows the name, the date and a comment. The name is read from the user’s SmartCard which includes the Personal Security Environment, i.e. the information to create the digital signature. The lower part of the window shows the document which has to be signed. If an entry in the list of persons is selected, PorJTeam shows the version of the document which has been signed by the specified workflow member. This document version includes all modifications made by the selected person and the predecessors at the time the digital signature has been supplied.

User Interface

One disadvantage of the solution presented in the previous section is that for users at the managerial level the working process becomes unnecessarily complicated so that users cannot apply analogy from their nontechnological work [3]. Our overall aim, however, was to stick as close as possible to the look and feel of the current paper-based working process. Presentation

We defmed a special circulation folder cIass in LinkWorks; instances of it will contain all the documents which had to be looked over by the managers of the responsible department and subdepartment. If a manager opens (double-click) such a circulation folder, located on the PoLlTeam desktop, then the GBE system is started, that is a Web browser, in our case Netscape, is launched, and the startup HTML page for approval of the documents is shown.

In this section we have briefly outlined the basic functionality of the electronic circulation folder component of PoLlTeam. A more detailed description can be found in

HOI. Discussion

The circulation folder is a flexible transport medium to support workflow processes. Workflow participants are able to change easily the content or route of the circulation folder.

Figure 4 shows the user interface of GBE in a state, when the manager of the department has already made annotations to the documents. It is now the task of the manager of the subdepartment to inspect the documents. The Web browser is shown without any toolbar, the window below the menubar displays an HTML page with 3 horizontally arranged frames. The leftmost fixed-width frame contains a Java applet with check boxes, a choice menu, buttons for user actions, and au area for status information. The stamp put on the document by the post office is shown in the middle frame in HTh4L format. The rightmost frame displays a request sent to the ministry; in this case a plug-in for Word is used.

The fact that the contents of a circulation folder is separated into single documents has advantages and disadvantages depending on the users working tasks and style. For users at the unit level who need to interact with single documents of a workflow this approach is suitable. They can easily exchange the content of a circulation folder with other folders or shared workspaces by drag and drop operations. Support for a secure approval of documents, which is required for workflows that go up the hierarchy is provided by the integration of electronic signature lists. However, for incoming documents, i.e. workflows that go down the hierarchy, users at the managerial level do not interact with single objects, but they need to browse quickly

275

In contrast, the information displayed in the lower area is changed during document inspection by the managers of department and subdepartment. Dispositions and remarks made by them are highlighted in their respective color. First, lines with the standardized dispositions are shown, which are abbreviations defined in the regulations of the GGO’. Second, remarks are presented separated from the dispositions by an explanatory title. One advantage of our presentation is that documents, enclosures, dispositions, remarks and other information can be recognized at a glance. We will now present the interaction aspect of the GBE system.

-.

Figure 4: The user interface of GBE shown in Netscape.

interaction

The rightmost frame is most important for the approval ‘process and consequently occupies the largest space, see Figure 4. By default, the request is shown, but this frame is also used, when enclosures are presented. We prefer to use plug-ins whenever possible instead of helper applications to view different document formats, which provides a coherent working process.

The main task of department and subdepartment manager on the documents is to annotate a document and to assign a responsible unit for the further process; aZdefaul\ unit is entered, by the post office. This task can be accomplished using the functions offered by the Java applet presented in the leftmost frame of the user interface. Standardized dispositions can be chosen by check boxes and are attached to the document (stamp) through pushing the set-button. Remarks are attached to documents by pushing the remarks-button; a pop up dialog is shown and freetext can be entered. Pushing the secrerary-button pops up a dialog where instructions and directions can be entered. The registry-button points to corresponding documents which belong to the same process. Re-routing of documents is supported by a check menu which contains all the units of the manager’s department. The forward- and backymfbutton enables browsing through the pile of documents.

The stamp is modeled as an HTML table and consists of two areas which are vertically arranged, see Figure 5. The area at the top contains only information acquired by the post office: phone number, date, and current number of the document; the identification number of the responsible unit and the priority are shown next, the latter is highlighted in a certain color. Finally, enclosures are listed as hyperlinks including a link to the main document. At the bottom of this area remarks may be shown. All these information are static and cannot be changed. _._..-____-- ._.._--__- ---^-_--_c.j

STAMP __~_~. ..---)------ -fft

,Phone: ..--~-

T

,&it

R E A 1

Date: -.--* Number: _~

12730 ----;+ -- -..---. IAugust 13,1997-----’ -1004266 _-. r “, _ ?272,--.-.-----

,PriOrily furgent Enclosur&~ Erwelooe photo r&In documsn

‘~.

I A

-I

There are mainly three different interactions in the cooperative process possible: The attached workflow (post office 3 department secretary 3 department manager -+ secretary department -+ secretary subdepartment + .., 3 registry) can flexibly be. changed with the basic PoLITeam means.

Reh’ks. Address not readable1 Envelope was scanned. -I -.--* Dispositions:

A R E A

Only little interaction on the documents takes place directly in the stamp. This is the case, when the document comprises enclosures. Pointing on the corresponding hype&k will view the enclosure. Note that the presence of enclosures is immediately visible; access and viewing is much more simpler than by a nested folder structure.

Users can give instructions or directions to their secretary. The Java applet therefore contains the secretary-button linked to a pop up dialog for freetext.

.

Re-ordering of documents in the unit folders or reordering of unit folders in the circulation folder

3 Figure 5: User interface detail: HTMJL stamp with post office data, annotations from the managers of’ the department and subdepartment.

* Gemeinsame GeschZftsordnung der Bundesministerien; (common business regulations for the German federal ministries.)

276

subsequent working processes. On the other hand, instructions and directions to the secretaries are not persistent. They are all deleted, whenthe secretary forwards the circulation folder.

according to priority or size is possible. These manipulations are executed in the status area. A fourth type of interaction concerns forwarding of partially handIed circulation folders. This is not reahy a feature of the GBE system, only a flag has to be set by the user, but depend on the implementation of the mail inbox class of LinkWorks.

This section presented an HTML-based interface for the presentation of and interaction with electronic circulation folders. This satisfies the requirements for fast browsing, standardized dispositions, flexible re-routing, and awareness of the progress of the working process outlined previously.

Further usage convenience is achieved through enabling and disabling of buttons depending on the current working context. But one feature is missed: in paper-based work, users have immediately an idea of the amount of work, when they look at the pile of unit folders containing all the documents and enclosures. In the next subsection we will present some awareness features of the GBE system.

System Architecture

The GBE system offers functionality for a working process which was so far not supported by PoLrTearn. We decided to use techniques from the Web and Internet. The main reason for this decision was that Web browsers can display not only documents in I-ITML format, but also different text formats, graphic formats, and even audio/video documents; this can be achieved by plug-ins or helper applications. So, the GBE system can handle multimedia documents by default which is necessary in our application domain. The unification hypothesis is an other reason for our decisions, i.e. the assumption that Web browsers will serve as a uniform interface to many applications including cooperation facilities, for example, mail.

Awareness of fhe Working Process

The amount of work can be estimated by the total number of documents which is shown in the status area, for each unit folder the number of documents is also indicated. Moreover, for each unit folder colored stripes with variable width show the portion of documents with the corresponding priority, see Figure 6.

Design Decisions 2093

2721

We made an overall decision that all documents and their respective annotations should persistently be stored in LinkWorks. Not only document management is supported by LinkWorks but it provides -also functionality for cooperation. This decision together with the above commitment to Web and Internet (Java, HTML, HTTP) implies that only.presentation and interaction of documents but not their administration (storage, backup, . ..) is carried out by the GBE system. It therefore is a hybrid approach and not a pure Web approach.

2730 -I

Figure 6: Status information with unit numbers and number of documents. Another kind of individual awareness on the document processing was required: we had to model that the manager of the department, for example, ascertain a change of the unit folder immediately, during approval of documents. Therefore we introduced special IITML pages into the stream of documents. The working process starts with a page, where only the forward-button of the Java applet is enabled, the frame for the stamp is grayed out, and the frame for the document contains in large digits the number of the unit on a light green background. During approval and browsing of documents there is always a correspondence between the check boxes and the dispositions in the stamp. When a new unit folder is reached a page similar to the starting page is shown. This is also the case at the end of the working process. The user can terminate and go back to the PoLlTeam desktop.

We decided that IITML should be the basis for presentation of documents and stamps by the user interface. Java applets enhance the user interface and provide interaction functions. Other techniques would have been JavaScript or CGI-scripts. One advantage of Java applets is that according to the abstract window toolkit of Java users have the same look and feel as in their usual window system. This decision raises other questions: What should be modeled using only IITML? What is better modeled in a Java applet? A good example to discuss this problem is the HTML stamp of the GBE interface. Our first idea was to model the stamp as a Java applet. The main advantage wouId have been that the user couId directly enter annotations in the respective elements of the table. But after discussions it seemed to us better that the user operates only on the leftmost frame of the GBE interface.

At least five different persons or units are involved in the working process: post office, manager of department and subdepartment, and their secretaries. Though the working process is sequential and asynchronous, it is necessary to see what others did on the document. The annotations, dispositions and remarks, have to be obeyed in the further working process. Therefore the GBE system presents and stores all annotations given by the users which are used in

One problem remained open: user actions should have visible consequences in the HTML stamp, i.e. annotations should be directly updated. There is no simple solution to

277

vice versa. Our strategy is to demand for objects individually, i.e. requesting in LinkWorks for a document or attribute when it is needed by the user (GBE applet client); annotations are stored back to the LinkWorks object and its attributes, when the corresponding document has been fully approved. Another approach is to get the complete circulation folder only once, store it locally at the GBE server’s site and put it back, when the complete working process is finished. One disadvantage of the latter approach is that data for the whole working process has to be securely maintained by the GBE server.

this problem in the context of stateless HTML. We therefore implemented a client-server architecture, which also allows us to work around the security mechanisms of Java apple& Component Structure

The GBE system consists of three components: the GBE applet client, a small GBE server, and LinkWorks, see Figure 7. Note, that a Web browser is needed for the display of the GBE applet client.

II,

The user interface of the GBE system is implemented completely in its applet client. The GBE applet controls presentation and interaction of the user interface. Communication to GBE server and then LinkWorks is achieved by a simple protocol with keywords and their parameters, e.g. STORE-STAMP XHTML string,. Both, GBE applet client and GBE server are completely implemented in Java, the latter calls external functions of LiiWorks through an API.

, s~orageofliTML-stamps

I 1

LinkWorks

(

document repository

There are two different configurations for the GBE system possible. In the first configuration, both components, GBE applet client’ and GBE server, can be running on one computer, i.e: the user’s PC. In the second configuration only the GBE applet client is running on the user’s PC, the component GBE server is running on a server machine, for example, the machine where the LinkWorks software is installed. This configuration distributes workload from the user’s PC to a more powerful server machine.

Figure 7: The component structure of the GBE system. Lit&Works3 serves as a repository for documents and containers (objects). In our case these objects are: the specialized circulation folder class with an attached default workflow; a specialized object-with-attributes class which models the request to the ministry including post office information and annotations made by the managers of department and subdepartment; enclosures are modeled as objects without attributes. The object model is illustrated in Figure 8.

.

Discussion

In contrast to the initial POLlTeam solution there are many advantages: only one tool, a Web browser, has to be used to accomplish the approval task; all documents are accessed in a linearized order, i.e. no nested folder structure has to be traversed; the mailing to the ministry and the stamp are presented side by side.

&JJ .,.. p....a .....y.... T-- ............ik 023 !LYP

From a software architecture point of view the main advantage of our approach is its extensibility. Currently we support only one task, the approval of documents, which is achieved by different persons in an asynchronous sequential cooperation process. Additional tasks could be supported in an additional applet client; if the LinkWorks objects contain all the information necessary for that task, then only the protocol of the GBE server has to be extended. In this way additional functionality can be integrated into the basic LiiWorks and POLITeam cooperation facilities.

A.... ............

Figure 8: The object model: nested folder strncture and documents in different formats.

Our hybrid approach offers two working styles on the same documents. Working with the GBE user interface is appropriate for the managerial levels in a ministry. On the other hand, unit-workers will use the basic POLlTeam means to accomplish their tasks on the documents.

One task of the GBE server is to temporarily read and store HTML stamps. The second task is to serve documents and attributes from LinkWorks to the GBE applet client and

To supply a further support for the interaction with circulation folders we are currently experimenting with a voice control system. We expect that the integration of such

3 LiiWorks i&elf has a client-server structure but that is not important for our discussion.

278

public access to documents cooperatrvely developea with PoLLTeam.

a tool increases the acceptability of an electronic solution for the support of managerial work.

l

The hybrid GBE system differs from other approaches which utilize the Web as a platform for the support of cooperative work. The BSCW (Basic Support for Cooperative Work) [I J or Meteor2 [SJ system for example both provide basic functionality for group cooperation and workflow management and use the Web as a communication infrastructure. In contrast to the GBE system both do not base on other professional software components.

The design of the user interface, see Figure 9, was kept as much as possible the look and feel of the original system. i.e. the gateway provides the same configurable document attributes, list structure, and icons as the original desktop interface. Additionally, it provides user specific indications of the status of shared documents. The interaction functionality covers the function of the shared workspace component of PoLLTeam: up- and download of documents, creation of new subfolders and the administration of the user group of a shared workspace.

POLlWeb The realization of an intuitive user interface was the primary design goal for the GBE system. As a complementary tool to that the PoLLWeb Gateway [4] has been developed.

PoLLWeb is realized as a set of CGI-components that access the LinkWorks server. The architecture of these components is divided into a generic and a functional layer. The generic layer contains three generic classes. Each of them has a distinct task and all together provide a basic request/response cycle. They are responsible for: .

creating and validating a connection between the groupware application and the world-wide Web,

l

for extracting data from the groupware application,

l

and for presenting the data.

The functional layer produces the HTML code for the visualization of the PoLLWeb user interface and maps the interaction protocol to the methods of the generic layer. Summary This paper presents a hybrid approach for the support of cooperative processes. It combines a standard windowsbased user interface design with an HTML-based user interface design to support the different working styles we have found at different user groups. of the POLITeam application partners. The presented workflow functionality is not yet completely installed at our application partners. However our experiences based on the practical use of PoLfl’eam combined with the feedback we received presenting the GBE solution during workshops, encourages us that the GBE extension will be accepted by our users at the managerial level. Nevertheless we cannot neglect that the individual paper-based working style is more convenient for the managerial users. But, we expect that the preference of paper documents over electronic documents will change as soon as more departments are geographically separated. The tradeoff between the additional individual or organizational efforts and the advantage of fast increased responsiveness in transportation and organizational procedures will then move toward the computer-based cooperation support.

Figure 9: The user interface provided by the PoLrWeb gateway to the a PoLflYeamdesktop. The objective of PoLLWeb was the realization of an alternative Web-based access to the POLlTeam system to provide: 0

To accelerate this transformation process we aim to design a flexible tool for the support of ministerial workflows that copies the artefacts and functionality of the non-computer supported work and provides a similar style of interaction.

means to create quick and flexible ad-hoc, task-related work groups that involve people outside the domain of installed groupware clients,

279

The design of the workflow component is guided by the idea to provide a cooperation tool that is integrated with the other components of the PoLfTeam system. Instead of being forced to use predefmed cooperation mechanisms the user is enabled ‘to select and adopt the tool that is most appropriate tool for the actual cooperation needs. Although some of the extensions, i.e. electronic signature lists, are typical for our application domain, we believe that the general concept provides valuable input for the designer of flexible workflow systems. This general approach is further elaborated by the GBE system which realizes an alternative interface to the PoLITeam workflow component that meets the specific requirements of users working at the managerial level. We have shown that the specific properties of HTML, combined with Java applets allow the development of an interface that is close to the paper-based working style. The extension of the PoLlTeam platform by two additional Web-based interfaces extends its usage range for flexible and spontaneous group support. Work tasks can be performed not only at the office but at any remote site. The group tasks do not come to a standstill just because a group member is away. Members can perform their group tasks via remote Web browser access. Ad-hoc and task-force related teams can easily and quickly be built. Acknowledgements

We want to thank the anonymous reviewers for their valuable comments on an earlier version of this paper. PoLlTeam is a project of the POLIKOM programme funded by the German Federal Ministry of Education, Science, Research and Technology. REFERENCES

1.

Bentley, R., W. Appelt, U. Busbach, E. ,Himichs, D. Kerr, K. Sikkel, J. Trevor, and G. Woetzel, “Basic Support for Cooperative Work ‘on the World Wide Web,” International Journal of Human-Computer Studies: Special Issue on Znnovative Applications of the World Wide Web, 1997.

2.

Bentley, R., U. Busbach, D. Kerr and K. Sikkel, “Special issue on CSCW and the World Wide Web,”

Carroll, J.M. and J.C. Thomas, ‘“Metaphor and the Cognitive Representation of Comptuing Systems,” IEEE Transactions on Systems, Man, and Cybernetics, 1992, Vol. SMC-12, No. 2, pp. 107-l 16.

4.

Conference on Computer Supported Cboperative Work (CSCW’P6),Boston, MA, ACM Press, 1996, pp,

1

180-189.

Karbe, B., N. Ramsperger and ‘P. Weiss, “Support for Cooperative Work by Electronic Circulation Folders”,

6.

in Proc. of Conference on OfJice Information System,

Cambridge, MA, ACM Press, 1990, pp. 109-117, 7.

LinkWorks, LinkWorks User Manual, Digital, URL:http://www.digital.com/info/linkworks, 1995.

8.

Miller, J.A., D. Palaniswami, A.P. Sheth, K.J. Kochut and H. Singh, WebWork: Meteor2’s Web-based WorkfIow Management System, int. Report: The University of Georgia, Athens, UGA-CS-TR-97-002, 1997.

9.

Pankoke-Babatz, U., G. Mark and K. Klockner, “Design in the PoliTeam Project: Evaluating User Needs through Real Work Practice”, in Proc. of Design

of

Interactive

Systems

Conference,

Amsterdam, 1997. 10. Prinz, W. and S. Kolvenbach, “Support for Ministerial Workflows”, in Proc. of Conference on Computer Supported Cooperative Work (CSCW’P6), Boston, MA., ACM, 1996, pp. 199-208. 11. Rivest, R., A. Shamir and A.’Adleman, ‘A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,” Communications of the ACM, 1978, Vol. 21, No. 2, pp. 120-126. 12. Schael, T. and B. Zeller, “Workflow Management Systems for Financial Services”, in Proc. of Conference

on Organizational Computing Systems,

Milpitas, California, ACM Press, 1993, pp. 142-153. 13. Schneider, W., SeCuDE. - Overview, Arbeitspapiere 775, Bonn, GMD, 1993.

GMD-

Sohlenkamp, M., L. Fuchs and A. Genau, “Awareness and Cooperative Work: The POLITeam Approach”, in Proc. of HZCCS’97, Maui, Hawaii, IEEE Computer Society Press, 1997, pp. 549-558.

15. Wi A., “Tailoring Cooperation Support through Mediators”, in Proc. of ECSCW’97~ Fijh European Conference on Computer Supported Cooperative Work, Lancaster, UK, Kluwer, 1997, pp. 157-173.

Freund, R., A Model to Access Groupware Systems via the World-Wide Web, Master Thesis, University of

280

URLt 1996.

Glance, N.S., D.S. Pagini and R. Pareschi, “Generalized Process Structure Grammars (GPSG) for Flexible Representations of Work”, in Proc. of

5.

i4.

Computer-Supported Cooperative Work: The Journal of Collaborative Computing, 1997, Vol. 6, No. 2-3. 3.

Computer Bonn, Science, http://member.aol.com/gardezl/yfre7.htm,

'