TCBWorks: A First Generation Web-Groupware System Alan R. Dennis Dept. of Management, University of Georgia, Athens GA 30602
[email protected]
Sridar K. Pootheri Dept. of Mathematics University of Georgia, Athens GA 30602
[email protected]
Abstract In this paper, we describe the development of a first generation web-groupware system called TCBWorks (http://tcbworks.mgmt.uga.edu:8080) that enables anyone with a web browser to use groupware. We discuss the overall design strategy, the browser and server environment, and the technical implementation and programming. More than 200 organizations around the world are using the software, either on our server or theirs. We discuss our experiences in using the software and lessons learned.
1. Introduction Over the past two years, the World Wide Web has enjoyed explosive growth and has become a major force in network computing. We believe the web (both on the Internet and on internal corporate intranets based on Internet protocols) will become the preferred development environment for future network applications, more so than Windows, Macintosh or UNIX. Likewise, the web browser will become the standard client for many client-server applications. Today, the web is primarily one directional -- a way to publish documents, advertising information, catalogues, and so on. The future of the web will be different. We see the web as a highly interactive communication super highway -- a natural groupware highway, where individuals can work together to generate ideas, discuss problems, and make decisions whether they are in the same room, or halfway around the world [4, 5, 8]. In this paper, we describe the development of a first generation web-based groupware system called TCBWorks that enables anyone with a web browser to use groupware [10]. We expect that by the turn of the century, most organizations will have a host of web servers with groupware systems like this to support their many project teams and work groups. Groupware will be
Vijaya Natarajan Dept. of Computer Science University of Georgia, Athens GA 30602
[email protected]
another "standard" office system, much like word processing, spreadsheets and e-mail that will simply be taken for granted. We provide some background on groupware and then discuss our system and its design considerations, and the lessons learned.
2. Groupware Groupware is a term that is commonly used, but lacks a commonly accepted definition. In general, groupware is a set of hardware and software designed to help groups work together [see 7]. Vendors, consultants, users, and university researchers all have used the term groupware to refer to many different types of software, each of which supports very different types of group work. Our software has its roots in one sub-area within the overall umbrella of groupware: Group Support Systems or GSS [6]. In this paper, we use the more generic term groupware rather GSS, but our focus remains on this form of groupware whose primary goal is to improve decision making. This includes some applications of workgroup software such as Lotus Notes designed to provide information databases, electronic meeting systems designed to support same-time same-place meetings, and group support systems designed to support groups working together at different places and times. It excludes transaction processing workflow applications. In general, this form of groupware provides two key functions to groups [7]. First, it enables group members to generate, read, and organize information in a structured manner. A weak form of this is the usenet newsgroups. They are very good at enabling many people to generate information, but they are seriously lacking in the ability to organize it. Groupware enables groups to edit, move, delete, and structure information so that it is presented in a hierarchy or map that is easy to analyze and can evolve as new information is added. The second key function is the ability for group members to vote. Most groupware systems enable users to
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
vote by ranking or rating alternatives. Some support multicriteria decision making, so that a set of alternatives can be evaluated by all members on a series of criteria (e.g., rating cars on gas mileage, trunk space, etc.). The members' ratings or votes are then combined and presented to the group as a whole for further discussion. Many companies now use this form of groupware in special purpose meeting rooms, as well as using it to enable groups to "meet" from different geographic locations. This form of groupware has also been the subject of much university research [3, 6, 7]. While it can improve the quality of group decisions, its primary benefit is time savings: research with more than 40,000 participants suggests that groupware can reduce the time needed to make decisions by 50-90% [7]. One key problem with many of these groupware systems is that they are primarily designed to work on a LAN or proprietary WAN. Using them to support distributed meetings over long distances requires special hardware and software and can be quite expensive. They do not have the same low cost, technical simplicity and “reach” of Internet-based tools.
3. Developing TCBWorks In this section, we discuss the general concept and specific details of the technical architecture of TCBWorks. TCBWorks can be accessed using a web browser at tcbworks.mgmt.uga.edu:8080. TCBWorks takes its name from the initials of the Terrry College of Business at The University of Georgia.
3.1 Design Strategy Although we know a fair amount about groupware, it still is not a mature technology. The web on the other hand, is about as mature as a two-year old -- able to do some things well but just learning others, and changing directions every ten minutes. We decided the best strategy was to begin with a general design, but to be flexible and let the design evolve as we discovered what could and could not be done using the web as a development environment -- and as we discovered how people used the software. Most current groupware tools take either a datacentered or process-centered view in their design. Lotus Notes, for example, is data-centered; it provides an excellent repository for storing data in a highly structured database format. There are many different types of data that can be defined and many ways to view them. However, Notes is extremely limited in the types of group processes it supports; it is difficult to analyze, prioritize, and vote on the information without writing special-
purpose external procedures. Other groupware tools such as GroupSystems or VisionQuest are process-centered. They provide any different tools to support different group processes, such as idea generation, information organizing, and voting. However, integrating data among different processes can be difficult because each process is supported by a separate tool that treats its data separately from the data in other tools (e.g., one tool for generating ideas, another for voting). This approach has two major drawbacks. First, data often must be moved from one tool to another (and some tools cannot even exchange data directly). Second, to accomplish most tasks, the user must master a set of tools each with different interfaces. We took an object-oriented view to the design of our system. The system was designed as a set of objects, each with a common set of data and processes. All data is available to all processes, eliminating the need to move them among separate tools. Most processes share some common objects (e.g., add, delete) meaning that separate processes share the same program code and interface. The system is also flexible, but restrictive, as defined by Silver [9]. It is flexible in that there are a wide range of functions that participants can use in a variety of ways. It is restrictive in that one person, the leader or organizer of a project, defines what participants can and cannot do. No function is available unless the organizer makes it available. Restrictiveness provides a more powerful intervention so that groups are more likely to use the system as intended. Used properly, it promotes the use of more effective techniques and prevents less effective ones, fosters learning, promotes consistency, and provides coordination [9]. However, it can also constrain creativity and exploration, limit the applicability of a system, promote user dissatisfaction, and be seen as manipulative, resulting in non-use of the system [9].
3.2 Overall Design The principal organizing object in the TCBWorks is the project. A project contains all the data and processes needed to perform most group tasks. Projects are organized in a hierarchy, so that projects can contain subprojects, sub-sub-projects, and so on. All projects can be added, deleted, modified, and moved, etc. Each project in turn contains a set of topics. Topics contain many of the same properties as projects. They are also organized in a hierarchy (with a series of topics, sub-topics, sub-sub- topics, etc. within each project) and can be added, deleted, modified, and moved, etc. Topics in turn contain comments (short paragraphs of text) that can be added, deleted, and modified. Comments can also contain HTML tags, enabling
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
participants to specify formatting (e.g., bold, italics, bullet lists), as well as taking advantage of all the other benefits of the web. It becomes simple to imbed a graphic in a comment (provided, of course, you know the HTML syntax and the web address of the graphic). It is also simple to put a link to other web documents as part of a comment. Comments can be anonymous or identified by the name of the contributor, depending on the leader’s choice. Each topic can be rated (i.e., voted on) using a set of criteria defined by the organizer. There are a maximum of ten criteria, each with separate user-defined ranges (i.e., minimum and maximum values). Each participant can enter a rating for each topic for each criterion and the system provides the mean value of the group’s ratings. The topics can then be viewed in order based on their mean rating across all criteria, on the mean rating for any one criteria, or their original order. We believed that to be flexible yet restrictive, there had to be several different categories of users, each with different access rights. There are four categories of users: • An Administrator can perform any function, including creating and deleting users. • An Organizer can create new projects and perform any function on the projects he or she creates, including granting access to other users, deleting the project, moving it, etc.
• A Participant can only access those projects to which they have been granted access by an organizer, and perform those functions permitted by the organizer. • An Observer has read-only access to the projects specified by an organizer
3.3 Interface Design When the user first connects to the web server, it presents a login screen that requests the user to enter a user name and password. Once a user has successfully logged on, the user is presented with the Project Screen (see Figure 1). This screen displays the list all projects to which the user has access. The action buttons displayed on the left of the screen change depending upon the type of user. Figure 1 shows the project screen as seen by the system administrator, showing all possible buttons. A project organizer would have all of the buttons except the Controls button, which is used to control access to the database (e.g., create new users). A participant has no ability to create or change a project, so a participant’s project screen would only have the Open and View buttons (as well as help, refresh, and exit). An observer’s project screen would have just the View button (as well as help, refresh, and exit).
Figure 1: Project Screen
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
Once a project has been selected, the user clicks the Open button, and the Topic Screen is displayed (see Figure 2). This screen displays all the topics that exist for the project and enables the user to discuss topics and add new ones. Once again, the buttons that are displayed depend upon the type of user and the rights granted by the project organizer. System administrator(s), the project organizer, and any user to whom the organizer has granted organizer rights can perform any function. Participants will only have those buttons the organizer has selected. The buttons available to participants can be changed at any point by the organizer. For example, the organizer may begin a session by permitting participants to add new topics but not vote. Once the list of topics has been developed, the organizer may remove the add button and turn on the vote button. Figure 2 shows the organizer view of the topics with all buttons. The Topic Screen enables users to perform two major functions (aside from adding, changing and deleting topics): discussing the topics, and voting. The first function, discussion is done via the discussion screen (see Figure 3). This screen displays all the comments entered under a topic, and provides an input box for participants to enter their comments. There are typically many
comments from different participants under the same topic. Comments are normally displayed in the order in which they are entered, but participants also have the option to insert comments after a specific comment, simply by changing the number in the comment number box (see Figure 3). The organizer can specify whether participants can Insert, Delete or Replace comments, as well as specifying whether comments will be anonymous or identified by the name of the contributor. The second major function is voting (see Figure 4). The organizer first defines the criteria that will be used (a maximum of ten criteria ca be defined; the default is one) and the scale that will be used for each criterion (any integer range; the default is 1-10). Once these have been defined, participants can enter their votes on each of the topics in the boxes provided. Votes can be easily changed at any time and participants can move back and forth between the screen in which they enter their votes and the screen that displays the average of all participants’ votes (presuming that the organizer grants them access to the screen). The results can be sorted to display in ascending or descending order by the average across all criteria, or any one criterion.
Figure 2: Topic Screen
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
Figure 3: Comment Discussion Screen
Figure 4: Voting Screen
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
3.4 Browser Environment One major design decision was the development environment: what web browser should we to support? One option was to develop the system to run on any web browser; that is, to develop the system for the lowest common denominator. The other options were to develop our own web client, or to develop for one of the specialized browsers such as Netscape or Hot Java. We chose the lowest common denominator strategy, because we wanted the system to be useable by the most users. Most of the development proceeded using the lowest common denominator strategy. However, midway through the development, it became evident that there were significant differences in execution among even the small number of most commonly used browsers. For example, virtually all browsers return information from forms in the order in which the fields are defined on the form. However, the browser used by CompuServe returned them in reverse order. We noticed similar inconsistencies in the way items were returned from a selection list in other browsers. This, coupled with the fact that the voting module could benefit from the use of the table feature in Netscape, made us change strategy. We chose to develop the system to run on Netscape 1.1 browsers, even though this would limit the potential users. As discussed later, we are continuing this strategy by developing for Javaenabled browsers.
3.5 Server Environment The next decision was the server environment. Our Windows NT server was out of service for several months, so we were unable to use it. The other options were Apple or Linux (UNIX for Intel-based computers. We choose Linux because we believed that it could provide faster throughput under heavy load than our Apple server. There are also many tools available for UNIX that can also be used in Linux, and Linux and UNIX are widely used. After testing several web server packages, we chose NCSA's httpd web server. The next problem was to find a good text-oriented database, since much of our data was text. We chose MiniSQL, a lightweight database offering a basic subset of SQL features that is at least as fast as, if not faster than, Oracle and Ingress. It includes the database engine, a terminal "monitor" program, a database administration program, a schema viewer, and a C language API. MiniSQL was developed at Bond University in Australia and has been adopted by several major Internet service providers and software vendors. Although MiniSQL has a Perl interface, we decided to
use C. Perl is an interpreted language and thus C is considerably faster and provides a greater range of capabilities. We found also found C superior to C++ because C gave faster, smaller executables.
3.6 Technical Design Our system uses a series of 28 C programs (about 25,000 lines of code) to generate the HTML forms that are used to capture the user's commands and present information in response. The user enters information via their web browser and clicks on a button, sending the form the web server. The server calls the appropriate C program based on the information on the form and passes the form information to it via the CGI interface. The program processes the form information and interacts with the MiniSQL database via SQL statements to retrieve information from or update the database. The program generates an HTML form and sends it to the web server which sends it to the browser for display. The web server doesn't remember the previous states that it took to reach any given screen. Each transaction is a separate request. The user can get into any screen (by using the “back” key) and exit at any state. Therefore, the HTML form that is returned with each request must contain sufficient information to tell the system all choices made by the user in the previous screen, in addition to the current request. For example, to add a new topic, the HTML form must also contain information on the current project, because the system has no other way of knowing in which project the user is working. This information is passed along from program to form and form to program as a hidden value. Thus each form contains the information needed to process the current request, and also the system's memory of who the user is and how the user has reached the current screen . Figure 5 shows the HTML form generated by the system to produce the project screen (this is from our public database called guest). This form specifies the title, the background GIF, the type of form, and the command buttons (e.g., Open, View, Add), and the list of projects from which the user can choose (e.g. holding a meeting, strategic planning). The database id, userid, and user type are hidden so they are not displayed (see lines 8-10), but are present so they can be returned back to the program to identify which user and project are linked to the request. The decision to use an object-oriented design approach meant that many of the software modules could be reused. For example, the code to add, delete, modify, and move topics is virtually identical to the code for projects. Once the program modules for the projects were complete, it was simple to reuse most of it for the topics.
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
Debugging in such an environment can be difficult. Our programs produce HTML documents which are displayed by web browsers. Any serious error in a program will result in a badly formed HTML document that cannot be read by the browser. Small mistakes are likely to result in partially formed HTML forms that cause the browser to display an Error 500. One cannot use regular C debugging tools to locate the mistakes in these programs since the inputs come from an HTML form from the web server, not the normal input process.
4. Discussion The first version of TCBWorks (version 1.0) was released October 10, 1995. The second version (1.1) was released April 1, 1996. At present, more than 200 organizations are using TCBWorks, with at least one installation on every continent except Antarctica. The largest concentration of organizations is headquartered in North America, followed by Australia, Europe, and Asia, respectively.
TCB Works - Projects for Folder: Guest Database
| Actions | Projects for Folder: Guest Database |
|---|
| Holding a meeting Classroom Use Holding a meeting Renouvellement des machines Présidentielle USA 1996 Meeting Agenda .....Agenda Item 1 .....Agenda Item 2 Strategic Planning Teams: Does Groupware Help? Collaboration on the Web |
Figure 5: HTML Form for the Project Screen
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
4.1 TCBWorks Compared to Other Systems When we began developing TCBWorks, there were virtually no other web groupware systems available. Today there are more than 75, with new ones being added every week. David Woolley’s web page on web conferencing [11] is the most comprehensive list of systems that is continuously updated. Collaborative Strategies [2] and Groupware Central [3] are also good sources of information. Since new systems are being added and existing systems are being updated very rapidly, any direct comparison of TCBWorks to specific systems would become quickly outdated. In general, as we write this in the fall of 1996, most other web groupware systems could be classified as web conferencing systems. These differ significantly from the GSS type of groupware of TCBWorks in three major ways. First, web conferencing systems typically organize each comment as a separate entity within the overall structure of the discussion. Each comment has a title and lists the author’s name; anonymity is rare. Each comment that replies to another comment is usually presented as visually underneath and indented from the original comment. This approach tends to emphasize the uniqueness and focus of each separate comment, rather than the structure of the overall discussion; structure follows the comments, rather than comments following the structure. Discussions with many replies often present a visually complicated display with many indented comments. In contrast, with TCBWorks, comments are subordinate to the overall structure. The structure changes only when the organizer or participants explicitly choose to modify it. All comments about the same topic in the structure flow together, with related comments flowing like paragraphs in a paper. Comments can be anonymous if the organizer so chooses. The disadvantage of this approach is that individual comments can get buried within the structure and are not highlighted as well as with the conferencing approach. A second major difference is the ability to organize comments and selectively enable or restrict participants’ ability to perform different functions. Few web conferencing system enable users to combine, move, edit, or delete comments and topics. The few systems that do, usually restrict these to the system administrator and provide little capability to selectively share these capabilities. This again fits the intent of the two types of systems. Web conferencing systems are often intended to share information to be read once, much like e-mail, where as GSS-like systems such as TCBWorks are designed to enable groups to build and edit pools of
information and knowledge. Finally, TCBWorks enables users to vote and make decisions. Most web conferencing systems do not, simply because this is not their intended application.
4.2 Experiences with TCBWorks There are many ways of examining the ways in which TCBWorks is being used. One is to consider distance and time. TCBWorks was designed to be used by people working in different places and times across the Internet. Many organizations are using it for exactly that. However, more than half the organizations are using it in intranets -- local area and wide area networks that are closed to external users. These intranets use the same network standards as the Internet (e.g., TCP/IP), but are designed primarily for private use. The most common use is to support different time and place discussions within a campus or corporate office park. However, TCBWorks has also been used to support same time and place meetings in decision room settings and those where some participants are at remote locations. Another way to examine its use is to look at the nature of the groups and tasks. One classification is a loosely connected electronic community of users that share the same interests and many of the same goals. An example here is Electronic Technology Group of the African Studies Association, a group of information technology researchers with interests in Africa. The goal of the group is to share information about research resources on Africa between universities in the United States and Africa (Kenya, South Africa, Zambia, and Uganda). Similarly, a variety of student groups at the University of Georgia and elsewhere are using the software within their campus (i.e., an intranet) to discuss issues of interest to the students. Job-hunting, and course evaluations are typical applications. The key benefit here -- and in the African example above -- is the ability to hold formal and informal discussions and to share information and opinions among a groups of individuals with common interests in a more structured form than a newsgroup, listserv, or mailing list would provide. Task forces and project teams are examples of more tightly connected groups. The Modeling and Simulation community has a variety of Standards Groups, each of which must work together to design, propose, and formally approve sets of standards. Members of these groups are drawn from organizations all over the world and must represent the interests of their members in developing the standards. Members hold regular face-toface meetings, but use TCBWorks to plan meeting agendas, and discuss issues outside of meetings to reduce the time spent in meetings.
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
The key contributions for these distributed project teams are the ability to extend focused discussions beyond the face-to-face meetings. The discussion agendas are clearly defined by the project leaders who shape and guide the discussions to reach the project objectives. Objectives and timetables are clearly defined and work assigned to various members. Face-to-face meetings (and telephone calls) are used to coordinate work and clarify issues requiring “richer” discussions than is possible using the electronic media. Five organizations have installed TCBWorks in special purpose decision rooms, either instead of or in addition to more powerful groupware systems designed specifically to support face-to-face meetings (e.g., GroupSystems, VisionQuest). The rationale is that TCBWorks provides a simpler user interface, enables a common tool to be used in the meeting room and on the desktop, more easily enables remote group members to participate, and costs less. Creative Loafing, an Atlantabased “alternative” newspaper with circulation of 180,000 uses TCBWorks in their decision room. The primary uses of the system are strategic and operational planning, and employee feedback. In the next few months, the system will be opened to enable access from their four satellite offices outside of Atlanta, so that managers at these locations can participate in planning meetings over the web combined with simultaneous conference calls. Another application area that is somewhat surprising to the us is the use of TCBWorks in education. Several dozen installations are using it to support distance education across the Internet, or class discussions in decision rooms or outside of regular class time.
4.3 Lessons Learned We have learned a host of lessons from developing and using TCBWorks, both technical and user-based. The first major technical lesson we learned was that it is possible to develop a major application system using the web. The use of a web browser such as Netscape as the client environment offers distinct advantages and disadvantages over traditional system development. First, because the web browser provides many built-in functions, development proceeds much faster than it would in a traditional environment. Traditionally, 6080% of any system is the user interface. With web-based development, much of the interface is automatically provided by the browser; you only need to specify what functions to use. It is very much like building with children's blocks or objects. Interface coding is reduced to about 40% of the application, saving a significant amount of programming time. The disadvantage is that
one is limited to the capabilities of the browser. A second technical lesson was security. Security concerns were expressed by a significant percentage of our users. If security is important, a secure web server that encrypts packets can be used. Most servers also can restrict access to only certain Internet addresses (e.g., within one company or set of companies). The problem occurs if users regularly use CompuServe or other commercial access provider, because one must grant access to all users of those services -- not a very satisfactory solution. Our system has a moderate level of security beyond that of the web server itself. Every time a user logs in with a correct userid and password, the user is assigned a randomly generated authentication code that is valid until the user logs out or after 12 hours has elapsed, whichever comes first. This code is used as the user’s access into the database. Without this code, no access is granted. It also prevents someone from placing a bookmark in the middle of the system to bypass the login process, or “stealing” a packet and using its information to gain access. You can still bookmark a screen or steal a packet, but the authentication code granting access will be useless after logout or at most 12 hours. A final technical issue was the importance of testing the system on many computers and browsers. Netscape, for example, produces slightly different displays for the same HTML form when running on a UNIX machine, a Macintosh, or in Windows. The type of display (14-inch versus 17-inch) can also make enormous differences in the readability of graphics, particularly background graphics. Many users with low resolution monitors complained that they could not read the text on the screen because of the background gifs we used in the first version of the software. After several trials, we found some simple background gif files that add color but do not detract from use. We also learned several important lessons about user expectations. Learning about the software, and making an informed decision about its fit with a specific organization’s needs is simplified by using the web. Since it is web-based, anyone with a web browser can experiment with it. About 20 organizations have established databases on our server at Georgia as a trial period before deciding to install it on their own servers. Second, most users have been quite enthusiastic about the software. It is a novel web application and also provides clear value to their work groups and project teams. However, some users have been less than enthusiastic. Rather than viewing the system as a web application, they see it as a regular desktop application and hold it to the same standards. They expect to use all the standard interface concepts such as double-clicking to open topics, dragging-and-dropping to move, and using
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
pull-down menus with multiple windows. These simple operations are beyond the capabilities of systems built with today’s web browses. Until the next generation of browsers with Java become more common, we will not be able to satisfy users with these needs. A third issue deals with response time. In general, every request issued by the user results in a request sent to the web server. Response times vary depending upon network traffic. Most intranet users have reported response times of 1-2 seconds, or less. Response time across the Internet varies tremendously. While some North American and Asian users have reported response times that are also 1-2 seconds (even Japanese users accessing our U.S. server), most response times are considerably longer. Even only moderately longer response times (3-4 seconds) can prove extremely frustrating, because they occur after every command. Several users have discontinued use of the software because the response times proved too frustrating. Java also offers opportunities to overcome this problem to some extent. Java is multi-threaded, which means it is possible to separate transactions from the network. For example, when a new item is added, or an existing one deleted or changed, Java can display the results on the client immediately, and then start a new thread which operates in the background to send the update to the server. The user need not wait until the transaction is complete before continuing. Obviously, an action which requires the server to provide information will still introduce delay, but the decoupling of input from its processing will help immensely.
6. References
5. Conclusion
[7] Nunamaker, Jr., J.F., Dennis, A.R., Valacich, J.S., Vogel, D.R., and George, J.F., “Electronic Meeting Systems to Support Group Work,” Communications of the ACM, 34 (7), 1991, 40-61.
We believe that we are at the edge of a revolution in system development. We expect that within two years, most companies will realize that the web is not only a means of electronic publishing, but can be a full-scale development environment. Rather than developing systems for Windows, UNIX, or Macintosh, companies will develop systems for the web. Even systems that are designed solely for internal use (and do not access the Internet) will use web browsers as the client. Of course, the web will need to mature, and there will still be the need for traditional applications, but more and more applications that require networking will use the web, rather than proprietary operating systems and networks. Those who get to the web first, learn its intricacies, and push its limits will have a distinct competitive advantage.
[1] Baecker, R.M. (ed.) Groupware and ComputerSupported Cooperative Work, Morgan Kaufman, San Mateo, CA 1993. [2] Collaborative Strategies, Clearinghouse for Information on Collaboration Technologies, Tools and Methods, http://www.collaborate.com, 1996. [3] Dennis, A.R. (ed). Groupware Central, http://www.cba.uga.edu/groupware/groupware.html, 1996 [4] Dennis, A.R., Quek F. and Pootheri, S.K. "Using the Internet to Implement Support for Distributed Decision Making," in P.Humphreys, L. Bannon, A. McCosh, P. Migliarese, and J. Pomeroi (eds.), Implementing Systems for Supporting Management Decisions: Concepts, Methods, and Experiences, Chapman & Hall, London, 1996 139-159. [5] Fellers, J.W., Clifton, A. and Handley, H., “Using the Internet to Provide Support for Distributed Interactions,” Proceedings of the Twenty-Eighth Annual Hawaii International Conference on System Sciences, 1995, 5260. [6] Jessup, L.M. and Valacich, J.S. (eds.) Group Support Systems: New Perspectives, Macmillan Publishing Company, New York, 1993.
[8] Quek, F. and Tarr, I. “An Example of the Use of the WWW as a tool and environment for Research Collaboration,” IFIP Working Group 8.4 Conference Proceedings, April, Arizona, 1996. [9] Silver, M.S. “Decision Support Systems: Directed and Non-Directed Change,” Information Systems Research, 1:1, 1990, 47-70. [10] TCBWorks, http://tcbworks.mgmt.uga.edu:8080. [11] Woolley, D.R. Conferencing on the Web, http://freenet.msp.mn.us/people/drwool/webconf.html, 1996
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
