Initial Use of COTS Tools in the OBJS Virtual Office

Introduction
Facilities Required
Office Administrative Activities
Non-Collaborative Activities
Internal Collaborative Activities
External Collaborative Activities
Lessons Learned and Future Work

Introduction

Background

Object Services and Consulting, Inc. (OBJS) is structured as a virtual office. At present it has ten employees (eight full-time) and a less-than-full-time office manager distributed across several geographic regions of the U.S. and is executing two R&D software contracts and providing some external consulting. There is no central work location and employees report to work from their home offices.

OBJS is currently performing a DARPA contract: Scaling Object Services Architectures to the Internet. This 3-year contract is intended to develop technology to insure that Object Services Architectures (OSAs) like that of the Object Management Group (OMG) are scalable and can interoperate with Internet technologies and tools like the World Wide Web. The specific project we are pursuing under this contract, Accessing the Global Information Base, is a focused way to demonstrating composition and federation of Internet services including an open query service and annotation service. The Application Scenarios task of this project is developing descriptions of scenarios that illustrate the use of OSA Scaling techniques and our global information base technology, and tie OBJS work to DOD operational needs. These scenarios will be the basis of actual technology demonstrations.

As part of this contract, we are developing a sequence of four scenarios of increasing complexity. The first three scenarios apply basic and advanced commercial-off-the-shelf (COTS) technology, plus additional technology we are developing, to the virtual office, using our own virtual office as a usability test case. The final scenario applies this technology to a DoD target application.

This report describes Scenario #1, Initial Use of COTS Tools in the OBJS Virtual Office. The intent of this scenario is to illustrate the construction of a working Virtual Office (VO), using a combination of straightforward operational techniques, and readily available COTS personal computer and Internet hardware and software technology. The scenario is somewhat conventional, but is intended to illustrate how to support both research and development activities and office administrative functions in a VO, based on the experience we have gained in setting up and using the OBJS VO.

This report also discusses some lessons we have learned from our initial VO experience, as well as some additional technologies that we feel would be helpful in our VO environment. Subsequent scenarios will involve both more refined uses of COTS technology based on our experience, and the use of new technology we develop, in both internal and DoD-related applications.

Much of our experience both with VO technology in general, and our own VO in particular, has already been documented in reports that are part of our Internet Tools Survey, specifically:

This report distills and focuses that material, referring to those reports for further details. In addition, this report amplifies on those reports in certain areas. Additional background can be found in several other reports that are part of this survey:

as well as reports on specific technologies useful in the VO, e.g., Video Conferencing.

In addition, we have been active architects of the enterprise architecture developed by the National Industrial Information Infrastructure Consortium (NIIIP), which is focused on developing technologies that make it easier to set up and operate a virtual enterprise. See OBJS Participation in NIIIP Consortium.

Overview

Performing OBJS' research and development involves both independent and collaborative activities, such as:

reading and analyzing technical literature (online and hard copy)
writing reports/papers documenting our results
downloading, evaluating, using, and developing software
participating in various industry groups
interacting with both internal (company) and external (non-company) colleagues
performing conventional office administrative activities

The following sections describe the COTS technology used in our VO environment, and how the above activities are handled in our VO using this technology. Lessons learned based on our experience are discussed in the individual activities sections, as well as in a separate section which summarizes the lessons learned, and describes future scenarios based on this experience.

For the most part, these activities (with some variation) are typical of those that must be performed by any group involved in detailed collaborative work, technical or non-technical. Particularly in our field (computer software research and development), many of these activities would ordinarily be performed using computers and the Internet, even in a conventional office setting. Hence, many of the activities and technologies described here will be familiar to people who use computers a great deal in their work, or at home. However, in a complete VO, additional considerations often arise that require modifications to existing practices, or the development of entirely new practices. Moreover, VOs are more often talked about than actually seen in practice. As a result, we hope that the description of how these activities are actually performed, and technologies actually used, in the context of an operational VO will provide added insight into the promise of this form of organization.

Facilities Required

The Virtual Office White Paper and Electronic Support for Collaboration & Decision Making in OBJS reports describe the facilities and technologies required to set up and operate a VO. Basically, each employee must have the following facilities in their home office:

Office furniture. That is, a place to work in the home.
Telephone and answering machine. It is possible to operate using only a single phone line if the amount of on-line activity is rather low. However, in practice two lines are required, to allow concurrent use of the Internet while making/receiving ordinary voice calls.
Computer and Monitor. Our virtual office consists of PCs, Macintoshes, and Unix workstations.
Printer. It is necessary to produce hard copy documents in some circumstances. In addition, many people prefer to limit reading of on-screen material.
Modem. To support simple email and document transfer, this may be either an ISDN modem (or router) or a conventional analog modem (OBJS has employees using all these options). To support general usage of more advanced facilities (video/data conferencing or high-speed transfer of large-volume data such as images), ISDN or other forms of high-speed Internet connection will be required.
Internet service. The speed and reliability provided by the selected Internet Service Provider (ISP) is crucial in enabling a smooth flow of information between employees, even when email is the primary communication mechanism. Use of more advanced facilities such as videoconferencing will make the choice of ISP even more crucial.
Web browser. In addition to providing browsing, some Web browsers (e.g., Netscape Navigator) also provide integrated email and News software (many OBJS employees use this feature). In our VO, it must also be possible to publish Web pages (write them to a Web server). Some browsers (e.g., Netscape Navigator Gold) integrate this facility as well.
Word processing including HTML editor."Raw" HTML can be edited in any ASCII word processor. "Visual" (WYSIWYG) HTML editing can be done either using add-ons to word processors (e.g., Microsoft Word Internet Assistant) or specialized HTML editors (e.g., Netscape Navigator Gold, Adobe PageMill). Some of these WYSIWYG editors also allow "raw" HTML editing.
Newsgroup reader/writer. Internet news groups are a useful source of information on various topics, particularly technical ones.
Graphics Editor. This allows employees to create diagrams/figures that may be required in various documents.
Spreadsheet software. This supports electronic filling out of timesheets and expense reports (see below).
Presentation software. This allows employees to create or read presentation material, such as overheads used in meetings.
Electronic mail software supporting MIME attachments. MIME (Multipurpose Internet Mail Extensions) support is required to enable easy interchange of documents as email attachments. Email products also provide various facilities for organizing and searching the large volume of email messages that are typically saved in a VO. For example, both Eudora and Netscape Communicator provide email filtering capabilities that can, e.g., automatically route messages from specified sources or with specific content to designated mailboxes.
Document utility software. A variety of utilities are typically required for purposes such as viewing/printing documents in various formats (e.g., Postscript), converting between various document formats, and compressing/decompressing files transmitted on the Internet.

As noted in the Virtual Office White Paper, a key requirement is that employees be able to interoperate using the selected hardware and software. For example, it is necessary that employees be able to read each others email and documents (whether written using word processor software or in HTML), graphics, spreadsheets (timesheets and expense reports), and presentation overheads. This does not always require the universal use of common software, although in practice this can help a great deal. In OBJS, our employees use Microsoft Office (although on multiple hardware platforms) for word processing (Word), spreadsheets (Excel), and presentations (PowerPoint). However, employees use different email, news, Web, and software development tools. This illustrates the important role that standard data exchange formats (as opposed to standard tools) play in providing the required interoperability. Standard tools tend to be required when proprietary data formats must, for some reason, be used. We are making increasing use of HTML as a common document format. While representationally poorer than proprietary formats such as Word's RTF, HTML generally provides both interoperability and an adequate representation for many types of documents.

There are also additional home office facilities which, while not required in all cases, are in many cases either necessary or at least desirable. These include:

CD-ROM drive. Software and machine-readable data (e.g., archives of ACM and IEEE journals) are increasingly being distributed in CD-ROM form as, for example, individual software applications become larger. This eliminates the need for the large number of diskettes that would otherwise be required to distribute this material.
FAX/copier/scanner. In some cases, it is more convenient to FAX hard copy material than to convert it to electronic form for transmission. A scanner, together with a printer, can be used for small amounts of copying and, together with a FAXmodem and FAX software, can often substitute for a separate FAX machine.
Virus Scanner (Anti-virus software). VO requirements often dictate spending considerable time on the Internet, and accessing large amounts of electronic material from all kinds of sources. Under these circumstances, some form of virus protection is necessary in practice.
Backup facilities. VO requirements involve long periods of intensive computer usage, generating large amounts of data (e.g., documents, databases), and a great deal of dependence on both that data, and on locally-maintained software. Under these circumstances, encountering ordinary software bugs that could cause data loss is almost certain, and encountering major media failures becomes increasingly likely. Hence, like anti-virus software, this falls into the "not strictly required but almost certainly necessary" category. Backup techniques can be as simple as copying important files to floppy disks, or as complex as using specialized backup software to copy complete volumes to removable media (tape or removable cartridges) on a regular basis. Also helpful for this purpose are utilities for repairing hard disk problems and recovering lost data.
Security Software. VOs frequently require the ability to exchange confidential or proprietary information. Supporting this can involve techniques such as software for encrypting the text of messages, encryption on the wire via secure sockets, and password- or certificate-based access control for servers.

All of the above facilities are readily available from numerous commercial sources throughout the U.S. (hardware and software can in most cases be easily obtained via catalogs and the Internet).

In addition to these individual facilities, some form of shared information space (e.g., a file server or Web server) is very helpful. In OBJS, one employee maintains an internal company-wide Web server. This server supports an internal corporate Web and file space, accessible via https (Netscape's secure http mechanism), with authentication by passwords and electronic certificates. This shared internal space allows employees to share information (e.g., trip reports, current task status, interim documents) in a way that is more convenient for many purposes than simply "broadcasting" the same material to all employees in email messages. For example, it reduces the amount of email traffic (and delays in downloading large attachments), allows employees to access information only when they need it, and provides a central organization for the material. Sharing information in this way is also more secure, since movement of documents via https is encrypted. The documents in this internal space are indexed, and a search engine is available for querying the documents. Restricted access to this internal space is provided to allow our Government customers to access progress reports, and to review documents prior to wider release.

The same employee maintains a company-wide news server. Internal newsgroups provide a centralized "home" for on-going technical discussions. Internal newsgroups and company mailing lists are dual-gatewayed, so that messages sent to a gatewayed mailing list are also posted to the news server. This employee also acts as Webmaster for a public OBJS Web site hosted at a commercial ISP. This site supports public Web pages providing general Internet access to reviewed and approved OBJS documents, and general information about our company. Once reviewed and approved, documents are moved from our internal space to our public Web pages via Internet File Transfer Protocol (ftp).

Office Administrative Activities

In performing its business activities, a VO must carry out numerous conventional office administrative activities. For example, OBJS must carry out such activities in addition to its research and development activities. The various Virtual Office papers we have written describe many of these activities. The following paragraphs briefly describe how these activities are carried out, with emphasis on those that involve electronic assistance of some kind. In describing these activities, the emphasis is on the operational aspects of the VO. Our Virtual Office White Paper covers additional logistical aspects of setting up a VO, e.g. insurance, tax, and legal issues that arise in a VO operating in multiple states.

Legal and other general postings. The company is obligated to display postings informing employees of their legal rights. These are scanned and made available via our shared internal Web server, and/or mailed (electronically or in hard copy) periodically. The internal server is also used to post information about health and insurance plans, and other company wide information (e.g., policies and procedures).

Policies and Procedures. OBJS is governed by a collection of written Policies and Procedures covering Basic Office Supplies, Benefits Policy, Book and Subscription Policy, Home Office Furniture Benefit, Miscellaneous Virtual Office Policies (Drug Free Work Place, No Sexual Harassment, Equal Employment Opportunity, No Bribing), Other Direct Cost Policy, Reimbursement and Expense Statement Policy, Time-Bank Policy, Time Charging Policy, Travel Expense Policy, and Virtual Office Weekly Progress Reports. These policies are communicated to employees when they join the company via email attachment and hard copy. The policies, as well as forms for travel expenses, insurance, and hotlinks to IRS forms, FARS/DFARS regulations, and per diem rates, are also available from a company internal administration Web page. In setting up a VO, it is especially important that the Policies and Procedures prepare employees for some of the effects of the VO environment, and of company expectations in that regard. OBJS has adopted a specific Virtual Office Policy which relates the history of the OBJS Virtual Office, and describes the general implications of the VO environment on Policies and Procedures. Individual Policies and Procedures also reflect the specific requirements of a VO environment.

Progress reporting and tracking. Progress reporting and tracking is particularly important in managing VO activities, since employees are "out of sight". Progress can be reported in a number of ways. In the OBJS VO:

Employees distribute Weekly Progress Reports to the entire team. A month's worth of reporting is contained in a single document, with each week's activities being reported in a different color. Initially, these were distributed to the entire team as Microsoft Word document attachments to email messages. More recently, progress reports have been prepared as HTML documents and either attached to email messages as before, or posted to the internal Web server. Use of the Web server provides a convenient, indexed, archive of past reports, and avoids the need for each employee to separately organize this material.
Employees also report progress indirectly by posting new or revised documents (e.g., updates of their task descriptions) to the internal Web server, or by distributing email messages reporting new white papers or other progress to the team.

Generally, these electronic means of tracking performance have proven successful in supporting timely progress reporting, and allowing everyone to keep track of the progress of activities they are following, as well as to find out "what's new."

Purchasing and cost reporting. In the OBJS VO, some purchasing (e.g., relatively expensive items of hardware to be bought by the company) is handled by the office manager, with technical assistance from other employees if required. Other purchasing, e.g., office supplies and personal reference materials, is handled by the individual employees (following company Policies and Procedures). Product information is obtained via hard copy catalogs, phone inquiries, and Internet searches. Employees submit expense reports (including the costs of such purchases) via electronic mail, with hard copy followup (with receipts attached). This combination has improved the speed with which employees' expenses are reimbursed, while maintaining an adequate audit trail. Since our hardware/software environments consist of workstations or personal computers, acquiring both hardware and software by telephone orders from catalogs or via the Internet is both straightforward and fast. Employees also use corporate credit cards for company-related purchases and travel expenses, which provides one-stop billing, and eliminates waiting for reimbursements.

Timekeeping. Employees must follow normal timekeeping rules. Timesheets, in the form of Excel spreadsheets, are circulated to each employee monthly via email. Employees must keep their timesheets current on a daily basis, and must print and sign that week's timesheet at the end of each week. At the end of each month, the completed spreadsheets are emailed, and the signed hard copies are mailed, to the OBJS office manager. The electronic submission of timesheets helps support more timely processing of this data for billing purposes, and reduces the amount of overhead involved in this activity.

In both timekeeping and cost reporting, additional technology could potentially be used to eliminate hard copy altogether. For example, hard copy receipts could be scanned and submitted electronically, and some form of digital signature technology could be used for employee signatures. Mechanisms (and possibly changes in legal requirements) would be required that would allow such receipts to be considered as "original" for audit trail purposes, and would allow the digital signatures to be considered as equivalent to the original ones.

Recruiting. OBJS recruiting has been done via email and newsgroup postings, as well as by informal word-of-mouth "networking". Interviews have been conducted by a combination of ordinary face-to-face interviews, telephone interviews, and in one instance a videoconference between our Boston and Dallas locations (see below). In preparing for interviews, candidates' papers, resumes, and presentation visual aids are circulated via email attachments, if they are not already on-line. These means of recruiting have proven successful in building a high-quality company team, while reducing travel expenses. While these techniques cannot necessarily entirely replace conventional recruiting mechanisms, they are becoming increasingly-common adjuncts to those mechanisms. For example, listing open positions on corporate Web pages is now quite common, as is electronic submission of resumes. In addition, a recent New York Times newspaper article ("Don't Touch That Dial: Why Should I Hire You?", April 13, 1997) reports that use of videoconferencing for initial interviews is in increasing use in many corporations.

Office Hours. A key part of the VO policy is an understanding about office hours. In OBJS, employees are expected to be available for scheduled meetings (so far, we have only had one), and to be generally available during "working hours" (this has a somewhat elastic meaning). Employees indicate when they will be absent via email to the entire team. Employees can trade off other hours from work day to evening or weekend. Over time, availability is confirmed via weekly progress reports, contributions, and via phone or email interactions. Video conferencing would involve a more direct form of employee availability, and would also require more synchronization of availability. This can be a particular issue when employees work in multiple time zones (as in the case of OBJS).

Travel Planning. Even in a VO, some travel is still required, e.g., to meet with external colleagues or customers. A Travel Policy governs travel. Travel planning can be done either centrally, or be the responsibility of the individual employee (in either case, travel agents can be used). In OBJS, travel planning is up to individuals. Government per diem amounts for various travel cities are available on the Web, and OBJS forms for expense reporting are published on our internal Web server. Employees have used the Internet to find hotels/motels in travel cities, check airline schedules, etc., and either map software or on-line maps to determine proximity of lodgings to meeting locations. The Internet can also been used to make airline/car/lodging reservations. Access to travel information and services on the Internet is straightforward via index services such as Yahoo. Overall, the use of these electronic means to support travel planning has been successful, but does not necessarily replace more conventional approaches (e.g., the use of travel agents). Travel planning can involve arbitrary amounts of time, given the resources available on the Internet. Improved integration of map and travel service information would be very helpful, since it is often hard at present to determine the exact location of facilities (especially relative to others) for some purposes. In addition, the amount of information available on-line differs from facility to facility.

Non-Collaborative Activities

Non-collaborative activities are those parts of individuals' work which do not involve a great deal of interaction with others. These activities differ somewhat in detail from business to business, although many such activities are common to virtually all businesses. The following sections describe the major non-collaborative activities in the OBJS VO.

Accessing Information

A key part of any research activity is finding existing information that is relevant to the subject under investigation. Sources include the Web (and other Internet sources), hard-copy publications, and internally-generated information (e.g., company data files).

The Web. The range of information available on the Web is quite substantial -- news releases, white papers, reference guides, user manuals, publications, magazine articles, and, to some extent, email messages and News postings. Searching for relevant information on the Web involves the use of sites providing pre-organized collections of references, such as Yahoo, and/or sites providing search engines, such as Alta Vista. Multi-search search engines, which automatically access multiple individual search engines and merge (to some extent) the results, are also available. In OBJS, we make frequent use of these tools to find material on our research topics, as well as material relevant to other activities (e.g., travel planning, hardware/software products). We also make use of specialized search engines for research reports such as the Networked Computer Science Technical Reports Library.

Although these resources are usually straightforward to use, using them efficiently often requires some experience. For example, since sites can differ in their coverage of the Web, experience is helpful in determining which sites consistently provide useful results (opinions on which sites these are can differ from one individual to another). Determining the proper search terms (keywords) that will return the desired information is not always easy; experience is helpful in formulating queries that minimize the amount of irrelevant information returned, and maximize the chance that a relevant result will not be overlooked. Some Web search engines provide no ability to refine a search based on the results of a previous search. Alta Vista provides a facility called Live Topics that helps deal with this. In addition to returning the results of a search, Live Topics creates a structure of key words and concepts also contained in the returned Web pages. After looking the topic list over, one can narrow the search by selecting which topics to search on. However, instead of using the results of the previous search, the selected topics are added to the original query and another full search is performed. While this is somewhat inefficient, it at least helps in focusing the query based on the available information. Additional tools or Web resources that could help users with, e.g., search vocabularies and other metadata, would assist in the process of both formulating original queries, and refining the results of previous searches. Multi-search search engines sometimes make it difficult to adequately control a search. Some put a maximum on the number of results per query, and it becomes a race as to which search engines return their results first. Others allow a maximum per search engine. In both cases, the possibility of missing key results exists.

Information obtained via explicit search is pulled information. This has the disadvantage that the user must continually re-search, or re-visit relevant Web sites, in order to determine if new information has become available. It is also possible to obtain pushed information, i.e., the user indicates a desire to be notified when new information becomes available. Some specific sources maintain email lists to which people can subscribe for this purpose. Specific software products, such as Netscape's In-Box and Smart Bookmarks, also provide means of being notified when Web page content changes. Other tools, such as NewsTracker and PointCast, allow the user to personalize delivered news by selecting topics or channels. We have found these technologies to be useful in certain circumstances, although care in selecting sources for push information (and what specific information is pushed) is necessary in order to avoid being deluged with information.

News groups. Internet news groups can also be a valuable source of information in some areas. Such news groups are sometimes indexed by Web search engines, which can then be used to find relevant news postings. In other cases, specialized News readers must be used. In OBJS work, news groups such as comp.databases.object and comp.object.corba have proven to be valuable sources of information on their specific technical topics. In addition, they can be valuable in dealing with hardware or software problems (see below). Both Web resources and news groups require the user to exercise care in assessing the value of any information retrieved from these sources, since anyone can place information on the Web, or post information to news groups. Thus, a certain amount of cross-checking can sometimes be a valuable precaution. Experience is also useful in determining which posters are knowledgeable.

Internally-generated information. Organizing and searching information generated internally (together with information obtained from external sources) is an issue in any organization. For example, in OBJS we generate a large amount of email and documents, in addition to retrieving documents and other information from the Internet.

Individuals organize their own information however they please, although shared task-related information is organized according to task templates, as described in the next section on Internal Collaborative Activities. Email is typically organized in multiple files according to subject. Documents are organized into separate directories, again typically by subject. In some cases, employees have created desktop Webs of HTML documents containing links or references to other desktop documents, and documents both on our internal server and on external sites. This helps maintain meaningful relationships between documents. However, with the exception of HTML documents, these different sources of information are difficult to integrate, due to the limitations of current tools for integrating both HTML and non-HTML documents from these different sources. Improving the ability to integrate all kinds of electronic documents will be important in improving the ability for individuals to organize their information. Without such organization, it is easy to become "swamped" with the large amount of information that is available (or created) on a given subject (or related subjects). A better integration of the Web, desktop file systems, and other information sources (e.g., email) would also provide an enhanced ability to create the kind of shared information spaces that can serve as central repositories for company information and operations, both for accessing information, and for creating new information (since, in the context of the overall repository, it would be easy to establish relationships between the new and existing information). Providing this integration requires improved technology for integrating the various data types involved (e.g., HTML documents, email, etc.), as well as for integrating the various tools involved (e.g., integrated search tools that could then be applied to the various data types in the combined repository), since at the moment separate tools must often be used for each data type

Indexing our internal Web server has helped in locating documents based on their content. Separate tools can be useful for indexing email and files on individual users' hard disks. Some of these tools can also be used to index files on removable media (such as tapes or cartridges), so that information on them can be readily accessed even when they are dismounted (in other cases, separate tools must be used for this purpose). Another useful category of tools are those (e.g., FmView for PCs, CanOpener for Macintoshes) for viewing the contents of a file without having to launch the application that created it.

Hard copy materials. Conventional research (as well as other office activity) involves access to books, periodicals, and hard copy documents of various kinds. Organizing and searching such material is a typical problem in any office. OBJS employees typically use conventional techniques for organizing their hard copy material. To date, there has been no significant attempt to use PC database software to index hard copy collections. Some professional societies (e.g., IEEE, ACM) have begun to provide some of their technical literature, originally published in hard copy form, on CD-ROMs. These include the proceedings of some important conferences, and archives of past years' technical publications. Some OBJS employees have made individual use of this material. Since these CD-ROMs typically come with search software, they make the job of finding relevant articles much simpler. In some cases, the material on these CD-ROMs also includes links to external Web pages providing additional information on the subjects covered. This form of material also has a beneficial effect of reducing the amount of shelf space in the home devoted to retaining many years' worth of technical literature. In OBJS, we have investigated (but not yet implemented) creating an internal server-based archive of CD-ROMs, using CD-ROM juke box hardware. Such an archive is quite feasible with COTS technology.

The Virtual Office White Paper notes that hard copy materials are harder to share in the distributed workplace than in the central workplace. The white paper refers primarily to the cost involved in this (i.e., in having to duplicate material at multiple locations), but it is also an issue in simply obtaining timely access to the information. In a central office, it is possible to borrow publications from colleagues or central libraries (although colleagues are an important source even where a research library is available, since colleagues are more apt to have access to specialized publications that may not be of wide-enough interest for even a research library to acquire). In OBJS, we have in some cases used scanning and faxing to address this problem. In other cases, an on-line source for the same material has been found. As the white paper notes, this is becoming less of a problem over time as publications increasingly go on-line. This is especially a consideration in our particular profession (computing), since many of the journals and documents that we most rely on are moving fairly rapidly in the direction of on-line publication, and some of the most current documents we need to access are available on-line before they are available elsewhere.

Writing Documents

Another key part of any research activity is writing documents that record research results, or interim documents during the process of performing the research. In the OBJS VO, this includes writing email messages, news postings, documents, and Web pages. This often involves using a combination of tools, including email and news software, text editors and HTML editors, and graphics tools. This is because individual tools generally lack features provided by other tools, and because the tools are not completely integrated.

In OBJS, documents are generally written either as Microsoft Word documents or as HTML documents. When composing HTML documents, we generally use WYSIWYG HTML editors (e.g., Word Internet Assistant, Netscape Navigator Gold, Adobe PageMill), which allow document creation without needing to directly enter HTML tags. However, these editors do not support the full functionality of HTML (or support different advanced features), and sometimes it is necessary to edit the HTML directly, a capability not provided by all HTML editors. Also, some HTML editors do not provide spelling checkers. Hence, sometimes an ordinary text editor, or a different HTML editor, must be used. To read documents created by these editors, in some cases the editors themselves can be used; in other cases, a Web browser must be used. Some editors contain an internal browser, or provide for the launching of specified external browsers. Separate tools are also frequently necessary in order to prepare graphics (e.g., diagrams) for insertion into these documents. Email messages are sometimes written using the text editing capabilities of the mailers themselves; in other cases, they are prepared using HTML editors or text editors and either attached to or inserted into the messages.

Once documents are written, they must be made available to their intended recipients. This is done by either attaching them to or inserting them in email messages, or by publishing them as Web pages. We are increasingly publishing documents to our internal Web server, as opposed to attaching them to email messages. This creates an indexed, shared information space that is readily available to all employees. For reasons of security, we publish Web documents using Web publishing tools (generally, the Netscape Navigator Gold Editor), rather than providing incoming ftp access to the internal server. Current Web publishing tools are better adapted to the low-update environment of conventional Web site administration, where documents are only infrequently added or modified. They are somewhat cumbersome when used in an environment where there are rapid and frequent update requirements, such as in a VO shared information space. Enhancements in these tools would improve the ability to use the Web as a VO shared information space. The same tools can also be used to publish non-HTML documents (e.g., .doc files created by Microsoft Word), although the process for doing this is even more cumbersome. Incoming ftp access to our internal server would make some of these operations easier. However, this would require the use of either secure ftp or Virtual Private Network technology in order to provide the same security as we currently have using https. We have investigated these technologies to some extent, and could adopt one of them if the need became sufficiently compelling. IPsec, the emerging IETF standard for secure TCP/IP, is the ultimate solution, but it will not be usable over the open Internet until IPv6 is widely deployed, which is still in the future.

In addition to writing documents and posting them in a shared information space, there is a requirement to create linkages between related documents (both local and external), and to maintain the referential integrity of the collection of documents over time. As noted already, improving the ability to integrate and interlink all kinds of electronic documents will be necessary in order to improve our ability to organize our information, making it more usable in our research activities. We currently use tools such as HomeSite and CyberSpyder Link Test to verify links between HTML documents. Such tools would need to be extended to support linkages between arbitrary kinds of documents.

In preparing documents, as in accessing them, a better integration of the various tools (drawing tools, HTML editors, emailers, etc.) would help avoid the need to switch between tools in creating the more complex documents. The amount of integration available differs between tools, and also between platforms. Desktop integration technologies, such as OLE and JavaBeans, are beginning to address this requirement, but current applications do not always take full advantage of these technologies.

Home hardware/software infrastructure maintenance

A VO involves the need to set up and maintain each individual local office. In OBJS, for the most part, each employee has set up his/her office, computing environment, and Internet hookup in their respective homes. Employees have chosen their own platforms, with the result that our overall environment is heterogeneous, including Windows and Macintosh PCs, and Unix workstations. In addition, each machine has a different configuration (different software packages, different operating system versions and patches, different peripherals and drivers). Several employees have ISDN access, while others are obtaining this capability. This heterogeneity makes centralized support an extremely difficult proposition for a small VO such as ours. As a result, most setup and support is the individual's responsibility, though one of us acts as an expert consultant when problems arise, and others add their own expertise with specific support issues that arise (e.g., involving platforms they are familiar with).

The need for employees to maintain their own computing environments means that they must devote a certain amount of overhead time each month to keeping their environments up to date, performing backups and other maintenance, and dealing with any problems that arise. Given the level of reliability of some PC-level platforms and software (e.g., Web browsers), and the speed with which changes in this software occur, this overhead can sometimes be significant. For example, in the OBJS VO the Web browser is a critical tool, particularly for those employees who also use it to read email and news. Some employees have encountered problems with this software (they are relatively frequent on some platforms), and these can become serious productivity bottlenecks. At least one employee has encountered a major disk failure (in this case, the availability of a complete backup on removable media allowed for a complete recovery), and several employees have encountered operating system problems of varying severity (e.g., failure to boot). Additional time is sometimes also required to deal with interoperability issues that arise in a heterogeneous computing environment, even between versions of the same product running on different platforms.

In dealing with these issues, access to on-line sources of information and software is a significant asset. For example:

The distribution channel for much software delivery is the Web. As a result, useful software, once found, can often be immediately downloaded and put into use (in the case of commercial software, the purchase can often take place over the Web as well). This also enables the downloading of software upgrades, as well as (on a much more rapid basis) patches developed by vendors to correct bugs
On-line assistance with problems can be obtained via email (and phone) with vendors and other OBJS employees, and via newsgroups focused on particular software/hardware products (OBJS employees have both benefited from, and contributed solutions to, such newsgroups).

Having available a collection of utility software packages (e.g., Norton Utilities to find and repair disk problems) is also helpful in dealing with such problems.

Software delivery via the Web, or at least the notification of the availability of such software, is an excellent motivation for push technology. This would allow users to register their interest in being made aware of new releases of certain products, or of further information about those products (e.g., bugs that are reported), when it becomes available. Some vendors currently maintain mailing lists to which people can subscribe for this purpose, and the push tools mentioned above could also be used for this. However, this technology is apparently not yet in widespread use for commercial software change notification. This is illustrated by the fact that many messages posted to product-specific newsgroups ask about problems that are well-known to frequent readers of those newsgroups. Moreover, in many cases patches or upgrades to address those problems have already been made available for download at vendors' Web sites, unknown to the persons posting the messages.

Internal Collaborative Activities

Collaborative tasks include brainstorming, planning, scheduling resources and tasks, co-authoring documents, designing, testing,and debugging software in teams, delivering results to customers, and field service. OBJS has employed COTS VO technologies in several types of internal collaborative activities (collaborative activities among members of the OBJS team). Technology support can make several of these tasks easier. However, tasks are often chunks of work that take hours to weeks to accomplish. As a result, for many purposes relatively coarse-grained support is sufficient, and checkout-checkin and versioning protocols have generally proven adequate for our collaborative activities. Our paper Electronic Support for Collaboration & Decision Making in OBJS provides additional details of our experiences in using various forms of collaborative mechanisms.

Discussions and Brainstorming

Discussions and brainstorming are needed when many possibilities need to be discussed quickly. In the OBJS VO, we have had two major team-wide brainstorming sessions: one on major technical issues that the team ought to address, and one on formulating a technical work plan, with the latter one being particularly intensive.

In general, we have evolved relatively effective means of brainstorming via email and by annotating distributed documents. However, in some cases the threads of discussion got relatively long, and it became difficult to maintain context using only these mechanisms. For extended brainstorming sessions and discussions, NNTP or Web-based conferencing might provide some improvement, better supporting long, threaded messages and replies. Even in a relatively unstructured situation like brainstorming, it is often best if one participant does some initial thinking (makes a proposal or sketches the terrain), which can focus comment from others. Topics that wander too much are inefficient to discuss electronically. So far, our email discussions have not needed to be particularly confidential, which has allowed us to use ordinary Internet email. For confidential discussions, additional security technology, such as message encryption, would be required.

Small Group Technical Work

Small group technical work is generally more focused and structured than the general discussions and brainstorming described above. Small group work on the tasks in our technical work plan have been structured through the use of task templates. These templates consist of one or more Web pages describing each task. The templates have a common overall structure, and are located on our internal Web server. These templates undergo continual updating by the group responsible for the task (one lead person, generally with one to two other participants) as work on the task progresses. Together with task-oriented directory structures, these templates serve as the "anchor" for task-related information. Those working on related tasks can periodically access these pages to study the latest progress that has been made. Team members also notify each other of changes via email and Weekly Progress Reports. The templates provide the basis for organizing task-related technical information in the shared information space on our internal server. An advantage of using an internal Web structure for the task information is that the templates can provide direct HTML links to both internal and external sources of related information, allowing anyone interested to investigate the subject to an arbitrary depth. This ability to link related information has proven extremely useful in pursuing our research activities. However, as noted already, improvements in the ability to create links between arbitrary documents would be helpful in fully developing and using this shared information space.

Group members also communicate with each other via email, in some cases with attachments (e.g., figures illustrating architectural ideas) and phone calls. Advantages of email are that it supports thoughtful comment and creates a record of the communication. A current disadvantage is that email conversations on technical topics cannot be directly linked to task templates, and messages sometimes appear to carry more emotional baggage (e.g., flames) than similar comments made in person. Advantages of phone calls are immediacy, and the ability to flexibly shift the topic of conversation. Disadvantages of phone calls are the potential for less-focused conversations, and the lack of a permanent record of the discussion (unless the calls are recorded, a mechanism which we have not yet used).

Co-Authoring Shared Documents

Small groups sometimes need to co-author documents, such as task documents, periodic reports to sponsors, trip reports, and proposals. For example, several OBJS team members usually attend each meeting of the Object Management Group, attending different OMG subgroup meetings (since there are typically several meetings going on in parallel) to ensure more complete coverage. After the meeting, the attendees must combine their notes to produce a complete trip report.

So far, we have found that a conventional divide-and-conquer strategy is adequate for co-authored documents. One person acts as lead, with the others writing up their individual sections, and either sending them to the lead via email or, more recently, posting them to the internal Web server as HTML documents. The combined document is then recirculated to all authors (in some cases to the whole team) for review, and then posted on the internal Web server. When interchanging interim versions of documents, revisions are indicated either by using specialized revision or annotation facilities (e.g., in Microsoft Word), or by writing revised text in different colors. This color-coding can be done in both Microsoft Word (and most other word processing software) and in HTML documents. Color-coding activities by week has also proven effective in our Weekly Progress Reports, since it enables incremental progress to be rapidly tracked.

We have not yet been extensively involved in situations where multiple individuals have had to collaborate on a document in a tightly-coupled fashion, or where they have had to work on different closely-interlinked Web pages. This will probably become more frequent as our work progresses (collaborative software development is a special case), and as our OBJS shared information space become more populated. Supporting this will require better annotation, version control, and configuration management facilities. The Netscape Enterprise Server, which we use for our internal Web server, supports checkin/checkout and versioning of individual documents, but the capabilities are relatively limited, and we have not yet made much use of them. As it is, we have noticed that better version control, and annotation by something other than color, would have been useful in a number of situations (e.g., in merging the comments made by different people on the original draft of this document).

Remote Operation

OBJS employees, while members of a distributed virtual office, are generally connected to the Internet via local Internet Services Providers (ISPs). While traveling, some employees have laptops so they can carry their computing with them. This allows them to connect to their ISPs via modem and long distance lines to read their mail, or access the Internet or the OBJS internal web site. Some ISPs support 1-800 access, or have local access points in major U.S. cities. For traveling overseas, we have found it best to buy telephone adapters in the U.S. We have not as yet made use of radiolink access to stay continuously connected, since the cost is currently greater than the need. Laptops also allow employees to create reasonable trip and expense reports during the trip so no extra time is lost doing this back at their home offices. Software (such as Symantec's pcANYWHERE) is available for synchronizing files between laptop and home office machines on return to the home office.

Videoconferencing

Videoconferencing (VC) is an often-discussed technology for use in VOs. To date, we have not invested in videoconferencing in our individual home offices for general use, although we have installed and experimented with the technology. The results of our experiments, and an evaluation of this technology, are reported in the Video Conferencing section of our Internet Tools Survey. In addition, we continue to track this technology by attending conferences and seminars on VC technology, and by frequent review of new products. Generally, the situation is that current VC technology is not cost-effective for our purposes, improvements seem just around the corner, and we have not felt a strong need to communicate this way. However, we continue to experiment with the technology .

While we have not yet installed videoconferencing in our individual offices, we have gained some limited experience with commercial videoconferencing services. We recently completed our first recruiting interview with a remote job candidate using Kinko's commercial videoconferencing service. This involved one of our employees and the candidate in a Boston location, and four of our employees in Dallas. Overall, we felt that this use of videoconferencing was a success. Even though it was somewhat expensive ($600 for two hours during a weekday), this was far less than the corresponding air travel and hotel bills would have been. However, this did not involve the use of Internet videoconferencing technology, which has problems with unpredictable quality of service, as noted in the Internet Tools Survey section mentioned above. Our general observations were:

It is necessary to become accustomed to the delay in transmission of picture and sound. This can make it difficult for remote persons to interject comments at appropriate points. For example, speakers must sometimes make an effort to pause periodically to allow for remote comments.
The layout and lighting of the individual conferencing facilities is important. Unless care is taken, remote participants can be less distinct than at a real meeting, and, as a result, visual cues can be hard to pick up (e.g., who is talking). Ordinary office lighting may not be adequate.
The sound quality is also very important. If there is only one microphone it may be hard to hear participants who at greater distances from it (and increasing the volume may create distortion of nearer speakers). Good sound quality provides important cues that help remote meetings be more natural.
The ability to point to specific documents, and to places on those documents, is an important part of meetings and presentations. This data collaboration applies to both presentation material (overheads) and documents that may come up dynamically during the course of discussion, such as pictures, plans, business documents (invoices), etc. It is extremely helpful to be able to simply hold such documents up to a camera (or lay them on a scanner, as we did in our meeting), rather than having to send them via FAX or email, although the ability to dynamically send information via computer during meetings is also important. The whiteboarding facilities available in many videoconferencing products are a way of addressing part of this requirement.
It is extremely helpful to have separate display facilities for speakers and presentation materials, so both can be viewed at the same time (as they would be in a conventional presentation). This is especially important when a speaker attempts to point to a specific item on an overhead, or to draw something in real time.
With current videoconferencing technology, where limitations on attainable qualities of service often exist, it would be helpful to be able to dynamically trade off qualities of service. For example, it would be helpful to be able to trade color video (or even video entirely) for faster audio, at specific points in the meeting.
The need to explicitly schedule our meeting ahead of time, for a fixed time period, placed a limit on the value of this form of videoconferencing for general-purpose use. Such constraints are not a problem for some kinds of meetings, since ordinary face-to-face meetings often have these same restrictions. However, a VO also requires the ability to have ad hoc meetings, whose length cannot necessarily be easily predicted (e.g., brainstorming sessions). Moreover, the technology should have so few limitations that it eliminates any reluctance that may exist to have meetings or conferences, in order to improve productivity when collaboration on an issue is necessary.

Overall, given a little practice, and some additional facilities, videoconferencing could become a fairly natural way of conducting our meetings. However, our VO is a somewhat specialized case. Videoconferencing is already in regular use in some specialized office situations. In more general office settings, it is possible that there will have to be improvements in the quality of videoconferencing (particularly of video) to get most people to adopt it as a normal practice. TV is the natural comparison, since this is the quality of motion and sound most people are used to on electronic displays. Some LAN-based videoconferencing systems can attain this level of service, but many cannot (and the costs of attaining it can be high). Unpredictable quality of service is a serious issue for Internet-based videoconferencing.

Some industry observers feel that businesses in the next few years will focus more on data collaboration/conferencing than video conferencing. This is because data conferencing is more feasible with current technology--it takes less bandwidth, and imposes fewer demands on Internet QoS (ordinary conference calls can be used for the audio portion). Whiteboarding is an example of this. The idea is to collaborate around a common document in real time. This may be a diagram, plan, or spreadsheet in addition to a dynamically drawn whiteboard. This has been shown to improve collaboration, enabling the participants to come to closure more quickly. This is an example of the quality of service tradeoff, mentioned above, that current technology sometimes makes necessary.

Additional Comments

In our internal collaborative activities, we have not made use of conference calls, and have generally preferred email to regular phone calls for ordinary communication. Phone calls have been used primarily for specific situations where two employees needed to clarify some issue, or otherwise have a freer-flowing discussion than could readily be supported by email.

We have also not as yet used calendaring and scheduling facilities, although the subject was raised at a recent face-to-face team meeting (our first), and we have recently installed the Netscape Calendar Server (for use with Netscape Communicator) on an experimental basis. While employees generally use email to notify the whole team of scheduled activities (such as travel) in advance, there is no central source for this information. As a result, it is easy to forget, and it is cumbersome to have to search archived email messages to find such information. Products are available to support calendaring, and our central server could provide a host for this service if necessary.

External Collaborative Activities

Employees in VOs are often involved in external collaborative activities (i.e., with people working for different companies, organizations, or government agencies) as well as their internal activities. In the OBJS VO, these activities include:

participation in the DARPA community (e.g., IC&V, I*3, and Dynamic Database Panel)
participation in industry consortia and standards activities, including:

Object Management Group (OMG)
National Industrial Information Infrastructure Protocols (NIIIP) Consortium
ANSI X3H7 (Object Information Management)
World Wide Web Consortium (W3C)

professional activities, such as writing for publication, and refereeing (reviewing) papers written by others for such publications
interactions with customers

These activities have involved the following types of electronic collaborative interactions:

exchanging email and other electronic documents (e.g., drafts of papers) with other participants in the activity (in some cases, these exchanges have involved markups of draft documents using various annotation techniques)
accessing electronic documents on or posting them to servers (e.g., Web or ftp servers) maintained by the activity (e.g., OMG maintains such a server for access to its activities by both members and outside parties)
providing restricted access to our own Web server

These interactions involve the same general techniques that are used in our internal collaborative activities. However, external interaction can involve additional interoperability issues, since the tools and data formats used by external organizations sometimes differ from ours. Dealing with these issues can involve the need to use additional document creation tools (e.g., LaTeX), document viewing tools (e.g., Adobe Acrobat Reader), and to have available additional translation tools. However, the widespread use of specific document formats, e.g. HTML, Postscript, Adobe's Portable Document Format, Microsoft Word .doc and .rtf files, ASCII text, and LaTeX, is becoming quite common, and this has helped minimize the amount of difficulty we have actually encountered in practice.

For our team, the use of electronic means for external collaboration does not represent a change from the VO environment as compared to a centralized one, since much of this external activity took place electronically even when team members worked in conventional offices. In general, a large amount of external interaction within the computer research community already takes place electronically. For example, publication increasingly involves the electronic exchange of material and provision of journals on-line. During the last year, team members have submitted papers for publication, with the entire process being electronic (no paper changed hands from submission, through reviewing, to final publication). Such things are becoming increasingly commonplace, and illustrate the feasibility of the VO environment, at least for some types of work.

Lessons Learned and Future Work

Both our Virtual Office White Paper and Electronic Support for Collaboration & Decision Making in OBJS papers describe lessons we have learned in implementing and operating our VO, and ideas for "what would be better". Overall, there have been few surprises. In many ways, the virtual office is similar to a central office: the work remains essentially the same, as do administrative tasks. Some specific lessons we have learned have been noted in the previous sections. This section reviews some of those points, together with some additional ones. In addition, this section describes some of the work based on these lessons that we intend to pursue in subsequent application scenarios.

Lessons Learned

lesson #1: A functional VO, at least for carrying on some types of activities, can be implemented and operated with fairly conventional, easily-acquired personal computer and Internet technology. This is the first and overall lesson to be learned from this experiment. Whatever limitations may exist, this has proven a useful experiment in determining how much could be accomplished without some of the "sexier" VO technologies (such as videoconferencing), and has established a baseline for future work.

lesson #2: Current tools are generally quite usable for straightforward VO tasks, but would benefit greatly from better tool integration. Such integration can reduce the overhead (e.g., the need to switch between tools) in performing complex tasks, and hence improve productivity. For more complex tasks involving information organization and access, and fine-grained collaboration, improvements are required in individual tools (e.g., for Internet searching and document annotation), tool integration, and data integration. Technologies (e.g., OLE) for integrating both desktop applications and Internet applications are starting to address the tool integration problem, but much progress remains to be made. At the moment, for example, there are multiple integration technologies (helper applications, plugins, and Java) just in the context of Web browsers.

Similarly, better data integration, e.g., of the Web, desktop file systems, and other information sources such as email, would be extremely useful. Such integration, for example, the ability to create links between these different types of information, would provide an enhanced ability to create shared information spaces for use as central repositories for company information and operations, both in accessing information, and in creating new information (since, in the context of the overall repository, it would be easy to establish relationships between the new and existing information). Providing this integration requires improved technology for integrating the various data types involved (HTML documents, spreadsheets, email, etc.), developments in standard data interchange formats, and improved technology for integrating the various associated tools. These integration-related issues illustrate the general need for better componentware and scalability technology, which is the focus of our research.

lesson #3: Our early use of a simple, shared information space (an internal Web) illustrates the promise of a more thorough implementation of this facility. Our task templates have provided a common structure for task-related information. This, together with search tools, has made it easier for us to find relevant material, and has also improved internal communication. However, as noted above, improvements in individual tools, and better tool and data integration, are required to fully enable such shared information spaces.

Papers exploring collaboration technology have noted the role of a "community (or external) memory" in developing a "virtual community" (see, e.g., papers from the ACM CSCW '96 Workshop, ACM SIGGROUP Bulletin, 18(1), April 1997). An example is provided by "MUDs" (Multi-User Dungeons and Dragons, or Multi-User Domains). In contrast to conventional "chat" systems, where the participants only "talk" to each other, in MUDs the participants can also create and modify objects in their environment. These objects play the role of the MUD's community memory, and provide an important mechanism for interaction among the participants. Similarly, a number of industry commentators have observed that an immediate goal in many businesses is to build an intranet for sharing enterprise information, making the full spectrum of business information available on-line. This is, for example, driving the connection of corporate databases to corporate Webs, making all this data available for uniform access via COTS Web browsers.

The "community memory" in an organization, or a situation description in a C4I system, is essentially a distributed data structure for recording current, past, and future state. Such structures support push-pull population of the structure, search/navigation to locate information of interest, information source and other "pedigree" metadata, etc. Our shared information space is a small-scale first generation variant of this type of distributed structure. A key goal of our research is to develop technology that enhances the ability to construct such shared information spaces. A key issue in Scenario #2 will be to investigate simple, low-budget ways to do this. Since our VO has no large shared databases in the conventional sense, a special issue for us is determining how to do this using Web/desktop technology to the greatest extent possible--"the Web as a database". A further requirement, as noted above, is to better integrate desktop documents (Word files, Excel spreadsheets, etc.) with Web information.

lesson #4: In a VO environment, individuals assume responsibilities for maintenance, administration, etc. that, in a conventional office, are generally provided by other people. The overhead involved with implementing and operating the individual offices in a VO environment needs to be carefully considered, in terms of such things as overall costs, and the level of effort this will require of individuals. One area we have only begun to explore is how to reduce the support burden on VO members. This will be important in scaling the VO to a wider variety of collaborators, some of whom need computing facilities but do not have skills to maintain their own environments. Techniques that could be employed include contracting with local support facilities, and the use of telemaintenance tools for allowing remote support personnel to access local computers. Telemaintenance is currently available on mainframes and some LAN routers, and tools such as pcANYWHERE and Carbon Copy can be used to provide a limited amount of remote support for PC-level hardware and software. Technology is also becoming available for automatically keeping PC-level software up to date (e.g., the LiveUpdate feature in Norton Utilities for NT).

lesson #5 : There are many potentially-useful COTS/XOTS tools that we have either not yet made use of, or which have been used only by a few individuals. For example, we rely primarily on Email to exchange ideas, and use the phone relatively infrequently (even for regular calls, let alone conference calls). Similarly, we have not yet used virtual whiteboards, Talk/Chat facilities, or Internet phones. This may have in some cases inhibited collaboration, by raising the threshold to be overcome in having in-depth discussions. We also have tools in place that could be used more intensely. For example, we could make more use of our OBJS newsgroups. They act as persistent central placeholders for ideas exchanged and feedback comments. At the moment, everyone houses this information locally in email archives. (However, as noted already, we have increasingly been using our internal server to house all OBJS documents -- trip reports, progress reports, task status reports, proposals, minutes of attended meetings, whitepapers, ARPA reports, etc. -- making them all easily accessible and searchable).

In general, this reflects the following factors:

Different individuals adopt technology at different "speeds", and have differing amounts of interest in experimenting with new tools (particularly when those tools are immature). This is a situation that also exists in conventional office environments. However, this can be more of an issue in a VO in the case of tools that directly support improved collaboration, since everyone must the same tool (or interoperable tools of the same type) to engage in a given form of collaboration, and the opportunity for using alternative conventional means of collaboration (e.g., face-to-face meetings) is reduced compared to a conventional office. This situation is exacerbated in VOs such as ours, where individuals provide their own hardware/software support, since individuals may be unwilling to commit to the additional "overhead" that may be required to support new tools.
Different individuals have different preferred "styles" of doing their work. This has a great deal of impact on the choice of tools, when there are alternative ways to do the same thing. For example, some individuals prefer central newsgroups as a way to convey information to the entire team, since they can then access the newsgroups when they want, rather than being interrupted by email messages (i.e., newsgroups are "pull" rather than "push"). Others prefer email messages, because they can use filters to automatically deal with email on specific subjects, and can organize the received messages locally however they like. Particularly in our line of work, many individuals prefer almost all communication to be asynchronous (indirect, via email or news), while others prefer to discuss issues directly, by phone or in person.
We have generally used a "consensus" style of management in our VO. There has been a reluctance to dictate the use of specific tools, relying instead on general agreements, which nevertheless need to be "driven" in order to be made. Coming to such agreements is particularly important in the case of collaborative software, since everyone has to use it for it to be effective.
Our VO requires supporting heterogeneous platforms. Specific products are sometimes only available on certain platforms, or have different degrees of maturity on different platforms.

Generally speaking, there are a wide variety of collaboration technologies that are useful in any office, some more useful in a virtual office that make same/different time/place communication easier across a variety of modalities. Each one takes some effort to master, but once mastered, provides additional bandwidth in communication, some providing force multipliers that are "better than being there" for some purposes. Since most of the technologies are available separately, a user can choose to adopt a light-weight subset and add more as time and the community s/he is involved in matures. At the same time, the sum of collaborative technologies can require separate installation, maintenance, and mastery of each unless they come bundled in suites. Many are not yet well-integrated so there are mode changes to switch between different technologies. Standards help enormously in insuring that communications can be understood on either end of the wire. Also, there can be discontinuities between communities that have adopted different suites of communication technologies though there are always least-common-denominators that allow lower bandwidth communication with degraded quality of service. One of the first actions of a community forming for some purpose (a virtual team, virtual corporation) is to negotiate common collaboration communication technologies that the group can use to share information.

lesson #6: General use of videoconferencing is not yet a real option. This is particularly true of videoconferencing over the Internet, since the qualities of service available are generally not acceptable. On the other hand, more attention needs to be paid to data and voice collaboration as a way of improving collaboration, while addressing current Internet quality of service issues (similar observations about the relative importance of high quality voice and data services versus live video were made in some papers at the ACM CSCW '96 Workshop cited above). We will continue to monitor and experiment with these technologies.

Future Work

As noted in the Introduction, this scenario is the first of several scenarios exploring the use of OSA Scaling techniques and global information base technology. In particular, Scenario #2 will focus on using the lessons learned in this scenario in applying more advanced, but still COTS, technology. Areas of particular focus in the immediate future are as follows.

#1 Investigate additional COTS tools, together with more refined use of existing tools.

Previous sections have noted a number of additional COTS tools available for facilitating work in a VO. We intend to pursue use of such additional tools in subsequent work. We will adopt tools incrementally and opportunistically as needed, and as usable versions become available. This includes the use (or more widespread use within OBJS) of tools such as those in the following list:

conventional conference calls
voice mail
Internet-based voice conferencing
data and application sharing, collaborative browsing
file exchange facilities integrated with Web browsers (e.g., Netscape Communicator)
chat/talk rooms
whiteboards and other data conferencing facilities
Internet-based video conferencing (as noted already, we currently do not feel this technology is ready for operational use within OBJS, but we will continue to monitor and experiment with this technology)
recording audio/video and indexing these
increased use of OBJS newsgroups
shared calendars and scheduling
advanced email features

indexed searchable email
email filters based on queries and rules
escalation - programmable means to alert the recipient to important email (blinks, priority, beeps)
status - read or not by receiver, sender can ask unobtrusively
withdrawal or self-destruct - so sender can cancel email already sent if not read and so email messages not read by time limit will self-destruct
structured mailboxes

better integration of web-based information space, email, and desktop documents
advanced web search facilities
database software
tools for formulating and refining queries of remote data sources including customizable wire services and net accessible databases
digital signatures
checkin/checkout and versioning of documents, and document configuration management
discretionary access control within the shared information space
event notification including

time-based reminders (e.g., periodic reminders to backup your disk)
web page-change notification

lightweight workflow
annotations including voice annotations (as noted already, we have already made use, to a limited extent, of the annotation facilities available in Microsoft Word)
remote maintenance facilities
tools for logging activity within tasks so one can record a session and review when tasks started and stopped (useful for timesheets) but also generally needed for session management
MUDs
scaling collaborationware to

new kinds of users (e.g., to support users who are less-technically capable and require remote maintenance),
users who dynamically enter and leave the virtual team (the NIIIP has created a related scenario for companies entering and leaving Virtual Enterprises),
populating templated information spaces more quickly,
cross firewalls

Individuals in OBJS have already experimented with some of these tools. In some cases, several of these tools are bundled together in a single package. For example, Netscape Conference and Microsoft NetMeeting bundle audio conferencing, video conferencing, and shared whiteboards (data conferencing) together.

#2 Further develop our shared information space

A particular focus in the immediate future will be further developing the use of our shared information space. For example, the need for information on our experiences with various VO mechanisms (and the more advanced activities in later scenarios) suggests the need for us to be continually documenting our experiences, and feeding them, and suggestions for improvements, into a central "experience repository" as part of a shared information space contributed to, and accessible by, everyone. As noted already, a shared information space provides important support for other collaborative activities as well.

Part of this work will involve investigating straightforward techniques and existing tools to support enhancements in our ability to support a shared information space. Possible examples include:

Generally adopting HTML as the format for reports of all kinds. This is, in fact, already well underway, since our task templates are already HTML documents, and, more recently, so are our Weekly Progress Reports (WPRs). Adding the "experience" postings mentioned above, as well as additional technical reports as we write them, will simply reinforce this general trend.
Adopting common formats and headers for the various parts of "standard types" of HTML documents. For example, we could easily adopt a common vocabulary for our internal documents, and use these terms as HTML headers at a particular level; these headers would then serve as keyword tags. Our task templates already use this approach. In addition, progress reports and some trip reports already have a great deal of commonality in their formats and headings.
Making additional use of META and other tagging mechanisms for including additional descriptive information, e.g., for improving the quality of internal searches (this would in some cases require direct manipulation of HTML tags, as opposed to WYSIWYG HTML editors).

The use of standard documents with common formats constitutes a form of type information, and would provide the basis for interesting experiments in the context of our work on integrating object technology, which involves a more strict form of typing, with the semistructured information that characterizes the Web. This same approach can be extended to support common structures for collections of Web documents as well ("Web types"), e.g., requiring specific patterns of links "typed" by the types of documents they point to. These approaches would also allow the integration into our own operations of ideas developed in our Metadata task as it progresses.

At the same time, our task templates are an exercise in creating a shared data structure that we progressively complete to accomplish our "mission". In that sense, they resemble a situation description (or a plan) in C4I. Hence, pursuing this work provides the basis for both scenarios and technology that more directly relates to DoD requirements, as well as the basis for experimenting with new technology that we develop to more fully address these requirements. For example, we expect tools that we are developing to be able to assist in tasks such as creating a semiannual report from monthly reports by, for each section, doing a sectionwise concatenation of corresponding sections in each monthly report. The pre-existence of the base data for this in a semistructured form would obviously be helpful, and, in fact, the existence of at least some structure in documents is often the norm in much operational information.

As noted already, intensive operational use of a shared information space requires improved tools for creating and managing both the information, and its relationships to both internal and external information sources, e.g., tools for such functions as:

creating and editing individual documents
creating and maintaining links between documents
searching and indexing
versioning and configuration management

#3 Remote collaborative software development

Another area that will be of increasing relevance as our work progresses will be distributed, collaborative software development. An extreme example of this type of activity is illustrated by a short piece in the March 31, 1997 issue of Computerworld (p.130), which describes the development of Debian GNU/Linux, a Unix-compatible operating system. Among other things, this operating system will run an onboard hydroponics experiment on the next space shuttle. The operating system was developed by 200 volunteer programmers who collaborated over the Internet and never physically met each other. More information (and free source code) is available from http://www.debian.org.

Although software development obviously involves the use of specialized tools such as compilers and linkers, this activity can be properly viewed as a special case of the creation and maintenance of a shared information space, as described above, and requires the corresponding types of tools. For example, Lessons Learned Administering Netscape's Internet Site, by D. Mosedale, W. Foss, and R. McCool (IEEE Internet Computing, 1(2), March-April 1997, 28-35) is a recent article on Netscape's experience in administering its Web site. The paper notes that:

"In some ways, the creation of Web content resembles a mid-to-large programming environment. Our content comes from several different sources within the company, and we chose a document revision system to manage its development as multiple contributing editors added and deleted material from the content tree."

The paper describes the use of a versioning system, which was originally designed to track source changes made by groups of developers working on the same files, in managing HTML changes to their Web documents.

Collaborative software development will also ultimately (although not necessarily in the immediate future) involve licensing management and software search capabilities, both to search for available components published on the Internet for importing into our own work, and as part of our research into general componentware enabling technologies.

#4 Further scenarios

Scenarios following Scenario #2 will increasingly focus on the use of new technology we are developing, specifically:

an Information Annotation Service (IAS), which will provide highly general and flexible facilities for annotating (updating and commenting on) documents in a global information space.
a Semi-Structured Information Space Search Service (SSISSS), which will provide advanced support facilities for people wishing to search large-scale information spaces consisting of both structured (e.g., databases) and semi-structured (e.g., the Web) information.

Together with underlying infrastructure technologies (such as a Metadata Repository to provide the information required by these services), this technology will provide enhanced support for using large-scale information spaces in support of VO requirements. In addition, these scenarios will increasingly deal with explicit DoD applications (as opposed to generic VO applications) of these technologies.

Our near-term work on enhancing our internal shared information space will provide a bridge between our current work and the use of these tools. For example, SSISSS is intended to be capable of searching and extracting material from arbitrary sources in our shared space, including ordinary documents, Web pages, and email and news files.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1997 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.

This page was written by Frank Manola, with input from the entire OBJS team. Send questions and comments about it to fmanola@objs.com.

Last updated: 5/6/97 fam

Back to Internet Tool Survey -- Back to OBJS