THE NATIVE COMPUTER COMMUNICATIONS NETWORK (NCCN) PROJECT

Background

The Native Computer Communications Network Project had its roots in some information-gathering surveys conducted between 1984 and 1987. These included surveys done on native education and native business in Canada. The respondents stated a need for improved communication in these areas across the country. In early 1986, a questionnaire was developed by the Native Canadian Relations Centre (located in the Faculty of Environmental Studies at York University) to determine the extent to which native people used computers and computerized communications as well as their attitudes toward them. The questionnaire was sent to every band council and native organization in Canada. Though only two percent were returned (27 replies), the great majority expressed a positive interest in the idea of creating a computer-based communications network to link native communities together.

As a result of the perceived need, the management of the Native Canadian Relations Centre at York University submitted a proposal to the Canada Employment and Immigration Commission (CEIC) to test the feasibility of establishing a computer network to facilitate cross-Canada communications among aboriginal people.

Project Phases

The project was divided into two phases: the Development Phase and the Pilot Phase. In the Development Phase (December 1986 to September 1987), the conceptualization of the network was established, potential users of the network (including those to be in the Pilot Phase) contacted and consulted, appropriate hardware and software found and tested, abstracts of documentary materials created and input into a database, and information gathered on a number of conferencing topics.

In the Pilot Phase (October 1987 to November 1987), eight selected sites in Ontario were supplied with the computers and trained in network management. The automatic networking function of the distributed system was established in a progression of site additions and its performance monitored. The network was promoted across the country and the potential 'market' assessed. Manuals for operation of the system were developed and refined.

Development Phase

Conceptualization

The project began in December 1986 with a mandate to establish a centralized, "bulletin board" type of network, with the information residing at, and managed by, one particular site. It was quickly realized that a decentralized network would be much more politically acceptable to native people, who are traditionally averse to centralized authority. The decision to create a decentralized network meant that a personal computer at each participant's site would maintain the information base common to the network, with additions, in the form of files and messages, being passed along from site to site on a daily basis.

Features of the NCCN

It was decided early on in the project that the network be able to supply a number of features: computer conferencing, electronic mail and a resource database. The idea that a file transfer feature was also needed came later.

The main feature of the NCCN was computer conferencing. This is a means of structuring 'online' conversations centring on specific topics, much like the workshops and seminars held at face-to-face conferences. A significant difference is that with computers the communication is asynchronous, i.e., the users do not have to be online at the same time, they can read messages and respond at their leisure. Computer conferences, therefore, can continue for many months, or even years, given sufficient interest. The general conference topics which the network was to begin with were: System (about the network itself), Education, Economics, Social/Culture, and Social/Political. Within these categories a number of sub-categories were to be developed as the network grew.

The features of electronic mail (e-mail) and file transfer allow for private communication between users. E-mail, like the messages 'posted' to computer conferences, was stored at its original site until the middle of the night (when telephone rates and traffic are lowest) at which time it was forwarded to its destination. On the other hand, file transfer, which is often used for long text files such as reports, could take place at any time.

The database feature was originally intended to be an integral part of the network, with frequent updates being supplied online by users. After studying the software technology, however, it was decided that this was unfeasible. The database was to be managed by the Native/ Canadian Relations Centre, with updates being mailed out (either by file transfer or on floppy disks) every couple of months. It was to include short abstracts of documents (reports, articles, essays, books, and magazines) that pertain to native people. A 'scanner', which is a device that scans printed material and converts it into a computer text file, was to be purchased by the Centre and used to enable any requested documents to be sent out by file transfer.

Users contacted

Communication with native organizations was extensive, though most of it one-way, with various national and provincial groups being kept informed about the development of the project. Attempts to actively involve the organizations was not very successful. What is interesting, though, is that the need for computer communications had been realized by about three national agencies who were attempting to establish computer networks, albeit on a much more limited scale. These concurrent projects have not been successfully implemented.

The organizations who eventually participated in the NCCN project were contacted because of their affiliation in a micro-computer users' support group. This group consisted of representatives from eight band council offices in Southern Ontario, each of which had just recently been computerized. Three of these band council offices and the office of the group's leader volunteered to become pilot phase test sites for the NCCN.

The project team learned of two native-run businesses involving computer sales and training. One was located in Ottawa, the other in Belleville. These were contacted and agreed to participate. The sixth organization to join the NCCN was a Toronto-based native political umbrella group, whose offices were fully computerized.

Hardware acquired

The hardware used were IBM XT clones, with 2400 baud internal modems. The development system and central network 'server' was an IBM AT clone. Three computer distributing companies were approached, each one lending their equipment out for a week or so for evaluation. Technical problems occurred with equipment from two, so the third was given the contract for 4 XTs and one AT. Later, in the Pilot Phase, 3 more XTs were purchased.

Software acquired

After the initial decision to make NCCN a distributed network had been made, it was necessary to consider which software would be needed and how to obtain it. There were four kinds of software looked for: message structuring and manipulation; network transfer; user interface (menu); and database. In addition, other software was sought for general office usage, i.e., word processing, printout specification, and contact information file-keeping.

As the user costs were to be kept as low as possible, an attempt was made to either use public domain (freely distributable) software or to develop the software in-house and place it in the public domain. When these options were not available, the best priced commercial software programs were bought after careful research.

Since the concept of NCCN as a decentralized, distributed network was derived from the Usenet, it was considered a good idea to use Usenet message structuring and manipulation software. The added bonus was that it was all public domain. The drawback was that it had never been set up to run on a personal computer (PC) that used MicroSoft Disk Operating System (MS-DOS), which is what most of the native organizations had in their offices. This meant that the project programmers would have to rewrite it's many pieces: netnews, mail, and file transfer.

The programmers gained first-hand experience in the Programmer's Rule: "The first 90% of a job takes 10% of the time, while the remaining 10% takes 90% of the time". What had originally been estimated as taking only two months to complete had yet to be finished over a year later. Why this happened tells us more perhaps about estimating than about software development. The main programmer, at the outset, had little idea how to assess his time commitments to other aspects of his work. There were also many other demands on his time: training the other staff; handling equipment purchases, set-up, installation, and testing; attending team meetings; learning, writing, evaluating and testing the many kinds of software needed for the project; and, later, doing presentations and training classes for users.

The following is a quick review of some of the main software programs used:

Xenix, a version of Unix that runs on personal computers, was chosen as the operating system for the network. Xenix is multi-tasking software that allows many programs, and users, to operate at the same time. It is more expensive than MS-DOS, but much more powerful.

MicroEmacs is a full-screen text editor (ASCII format only). It is a very good public-domain program, with good documentation, online help, and an online tutorial. It requires learning about twenty different keystrokes for average text formatting. The one drawback is that it is not good for remote usage by dialup users who have only 1200 baud modems. This is because it must redraw the entire screen every time a new line is added to the body of text when editing, which could be a time-consuming process. For short messages it is fine. The NCCN provides vi (a line editor) as the default in mail, with the option of converting the entire message to the MicroEmacs editor for easier editing of the full text. Lengthy messages are best created on the user's own system then uploaded into the NCCN computer.

Notebook is a file system from the WordPerfect Library that keeps a list of contact groups and individuals as well as pertinent information about them all. It was not used very much but still is the easiest means of getting information about people. It works with MailMerge for quick and comprehensive mailouts. It also has the capability of having automatic dialout when connected to a telephone, making it easy to call many people in a short period of time. Notes can be taken and added to the database while on the phone. Like any database, the drawback is that it must reside on a single system for maintaining data integrity. It has a lot of online and documented help on how to use it, but very little on how to set it up for your own purposes.

Kermit is a public domain communications software program with an error-checking protocol. It has been 'ported' to (configured to run on) many different makes of computer. This means it has become a 'standard' and won't become obsolete. It has extensive written documentation but very little online help, making it somewhat difficult to learn to use. It doesn't have a very good user interface and is little better than addressing the modem directly. Another drawback is that both the host machine and the machine calling in must have it on their systems.

Procomm is communications software that includes more than half a dozen different protocols, including Kermit. It is very good, with good online help and documentation. It has an excellent user interface. It is public domain shareware for testing purposes. It allows multiple dialup listings that can be called with only a few keystrokes.

Database established

The database of abstracts of all documents contained in the Native Canadian Relations Resource Centre was started by doing an inventory of the materials, after which abstracts were written on each item and entered into the database. This took quite a lot of staff time to do.

The database software was difficult to develop. Several consultants had to be hired to write the 'front end', i.e., the user interface. Eventually the database was finished and was available to be mailed via 'floppy disk' to any interested party requesting it.

Though a scanner had been obtained for evaluative purposes, it did not meet the requirements of the project. As a result, the idea to make the full documents available electronically via e-mail was scrapped.

Conference 'priming' information gathered

A researcher was hired to write brief articles on topics related to the online conference categories. This was to ensure that some useful information was periodically put into the conferences to keep participants interest high and to give them a sense that the conference was not 'dead'. Though over 80 articles were eventually written, few were used. It was thought that because many of them were derived from newsclippings, they were outdated by the time the network got established and users had been trained. It was also surmised that while the information would be interesting, it would not be conducive to interaction and merely reinforce a passive, 'read-only' expectation in the new user.

Pilot Phase

Installation of equipment

Computers were installed at the various sites during a 3 month period. Eventually there were operative machines in the following locations: York, the system programmer's home, 3 band council offices in Southern Ontario, the office of a provincial native political organization, and a native business. Two other native business offices, one in Ottawa and one in Belleville, supplied their own computers but were set up with the network software.

Though there were many technical difficulties encountered, these did not present too many long-term problems. There was one exception - it was discovered that XTs were unable to initiate dialout to other systems under the Xenix operating system. This meant that the computer at York (the AT) had to become the 'central server', calling up all the other sites and feeding them the nightly updates. Had ATs been used at all the sites, the network would have been truly decentralized.

One of the interesting features allowed by the network configuration was the capability of the York-based programmer to dial up any computer on the network, run diagnostics tests, and make 'fixes' to that site's software, all from a distance.

Promotion

Promotion was given a high priority in the project. As early as February 1987 there were visits to native organizations to inform them of the project's existence and to solicit their opinions on what they would like the network to be. It was assumed that, since the network would utilize computers and software already existing in most native offices and use ordinary phone lines, it would be very attractive to native organizations and relatively easy to have them join as full sites. It seemed reasonable at the time for the project team to think that soon the NCCN would be technically ready and they would be able to set systems up all over the country. Though this proved not to be the case, promotion still went on, especially after December 1987 when the network was judged to be fully operational from a technical point of view.

Perhaps the main impetus of trying hard to "pitch" so many potential sites was the perception that a 'critical mass' of users was needed to facilitate on-line interaction. Without a certain number (50 was often mentioned) of sites, there wouldn't be enough 'action' on the system to keep people interested.

Another reason had to do with the team's perception of the potential usefulness of the medium. It was seen as a tool for promoting grass-roots empowerment through shared information and co-operative activities. The more sites on the network, the better. The faster they came on-line, the better.

There were various kinds of promotion: formal presentations, visits to select organizations, demonstrations, press releases and media interviews, materials made available at conferences, brochures and business cards, and a mass mailing to most native organizations in Canada.

Visits to various native organizations took place in Ottawa, Vancouver and Toronto, with five or six organizations contacted in each. Political organizations seemed, for the most part, quite wary of the new technology, while those of an educational nature seemed the most enthusiastic.

In general, it was found best to have called well in advance to set up the meetings. When this was not done, it sometimes occurred that the 'right' people, i.e., the decision-makers, weren't present. Calling beforehand also gave the advantage of learning of other important contacts to make while there, thus saving time and effort.

Both the presentations and orientations were enhanced by using a set of large laminated placards as a visual aid. These cards had the main concepts of the NCCN written on them as well as pictorial representations of both the network linkages and the structure of the conferences.

For large audiences, the best way to present the NCCN was to use the portable Compaq AT, which emulated a full site, in conjunction with a technical attachment that allowed for overhead projection of the computer screen onto a large wall screen. In this way, a live demonstration of the network's capabilities could be given to twenty of more people at the same time.

Conferences were of benefit in disseminating information. Written materials explaining NCCN were inserted in each information package given to the 150 attendees at the All-Ontario Chiefs meeting in July 1987. An NCCN table was set up at the March 1988 Urban Native Conference which allowed for some valuable interpersonal contacts to be made.

The brochure also proved to be a useful way to convey information about the NCCN. It was an attractive and handy reference for those not present at the site orientations. Designed to be part of a mass mailing to over 3,000 native organizations in Canada, it had a section that could be detached and mailed back to the project team to indicate an interest in joining the network. Over seventy replies were received in this manner soon after the project ended in March 1988.

Although much preparation was put into the formal presentation of the NCCN to the public and the media on March 22, 1988, it did not elicit the turnout expected. A press release was drafted and sent out along with an invitation to dozens of native and non-native journalists representing television, radio, and newspapers. In addition, over 700 personal invitations were mailed to native or native-affiliated organizations, and faculty, staff and students of York University. Aside from the project team, there were only about twenty-five people who attended the event, of whom two were journalists. The presentation was quite well-received, however, despite the low turnout. Though an article on the NCCN appeared in both the York University student newspaper and the faculty newsletter, there was no other media coverage. As the CBC radio reporter put it, "Potential isn't news. I'll wait until it's actually being used for something."

Manual

Manuals are very important for successful implementation of innovative technology. As a highly sophisticated technical system, the NCCN had to have an exceptionally good manual to meet the demands of a relatively technically unsophisticated client population. The manual that was created succeeded in conveying the complexities of network concepts and usage in a simple and informative manner. This was probably a result of the time and effort that went into it.

Work on the manual began in July 1987. It was written primarily by the project co-ordinator, a non-technical person, with assistance on technical passages from one of the programmers. This was to ensure that the language used would be as free from technical jargon as possible. Examples were generally given with each explanation. An effort was made to make these examples relevant to the clients' culture and situation. A glossary of jargon terms was also provided for quick reference.

Because of the differing information needs of the various types of users (regular users, system administrators, system propagators, and system developers), there were actually many manuals. One was a very short quick-reference guide for the occasional user who just wants to do a few basic things. Another was the more complete Network User's Guide with directions for using all the features of the NCCN. It was written with the assumption that the user would be a complete novice to computers (it even begins with instructions on how to turn on the machines). Besides a chapter on guidelines for interaction ('netiquette'), there was also a chapter on system maintenance for the system administrators. The Network Utilities Reference provided technical reference material for the file transfer and text editing utilities. The last manual was the highly technical Network NetNews Reference that contained the documentation on the NCCN conferencing software.

There was a 'Help' option in almost every menu section available to the on-line user. While the main menu's 'help' provided short explanations on a number of topics, the other 'help' options were merely on-line versions of the relevant chapters of the printed manual. Because the messages were lengthy and it was often tedious to read the entire section when looking for a specific answer, this aspect could have been simplified. It was mainly done this way to meet the needs of first-time users who did not have a printed manual.

One of the drawbacks to writing manuals for a network development project is that the changing requirements of the system mean constant changes to the manual. This is what occurred with the NCCN. The fact that the network operated on both Xenix and MS-DOS meant that there was enough difference to warrant separate manuals. Every time there was a slight change to the user-interface (menus), the manual had to be updated. This became very expensive, considering the printing and distribution costs as well as the person-hours spent on it.

Training of users

Training actually began at the initial site visit. Orientation sessions were scheduled for as many potential users at that site as possible. At these sessions, a live demonstration of the systems was given, if possible, or at least the concepts described to the audience.

The project trainer set up a series of site visits and concentrated mainly on training the person responsible for administering the system there, though others were welcome to be trained too. The initial visit was for assessing skills and experience, and giving an overview of the online environment.

Training sessions were about 2 hours each and conducted four or five times over a 2-3 month period. Lessons progressed from the simpler aspects to the more complex, e.g., reading mail to posting items in conferences. A relationship of camaraderie was built up between the trainer and the trainees, with extensive support being given via e-mail and telephone. Users were also encouraged to make extensive use of the manual and give feedback for its refinement.

Online Interaction

Most of the interaction that took place online was in electronic mail between members of the project team. Hundreds of messages were exchanged as a means of keeping informed about the rapid developments of the project. Trouble-shooting and 'bug fixes' required a lot of testing and feedback at different locations and at all hours of the day and night.

The new users at the various sites, with minor exceptions, used e-mail to correspond with the network trainer only. They did not have much interaction with people at the other sites because they did not know very many of them. Those few who did know each other used the telephone to communicate.

There were two conferencing areas, one consisting of five conferences relating to native issues, the other made up of over 75 USENET conferences. There was very little interaction in the former, with the project team members posting almost all the articles, and none at all in the latter since, to avoid offending USENET site administrators with novice errors, they were made read-only conferences.

Very little use was made of the file transfer feature of the NCCN by the users who weren't part of the project team.

Skills transfer

About halfway through the first phase of the project, it had become apparent that the success of the network would depend on locating and training those organizations who would be willing and able to offer technical support to maintain the hardware and software as well as provide training to system administrators. Such support was seen as being necessary to for the continued propagation of the network. The project team was able to provide this service only for the limited time that project funds were available.

The project team located three such organizations. All three had extensive experience with native computer users, selling and maintaining computer equipment and/or training people to use computers.

These businesses became full sites on the NCCN during the Pilot Phase and each made a person available to act as a system administrator. Though all pilot sites were invited to send a representative to York for a special two-day training session on network usage, maintenance and propagation, only one of the three managed to do so.

At the end of the project in March 1988, none of the three organizations were either willing or able to 'take over' the role of the project team in further propagation or support. There are a number of reasons why this proved to be the case.

All three were relatively new and expanding enterprises. This meant that their staff were very busy in activities that had immediate benefits (profits). Expanding NCCN might have been too risky to devote their resources to over the short term.

Their area of expertise lay in systems that used MS-DOS. The Xenix operating system is quite complex and difficult to learn. It seems reasonable to assume they were reticent to spend time learning a system that few of their clients use, especially without some guarantee that large numbers of their clients would switch to this system. The MS-DOS version of NCCN software installed at one had not been rigorously tested prior to its installation, nor was there time to finish it. As a result, that site received a $500 phone bill for the last month they were on the network. They decided the software was not suitable and ceased participating in the network.

Two of the businesses were already involved in their own computer communications projects. One was selling software and training to clients affiliated with the National Aboriginal Communications Association (whom project staff tried unsuccessfully to meet with on a number of occasions) to enable them to use a commercial electronic mail and database access service called iNet 2000. Another had been operating an electronic bulletin board for exchanging messages with their clientele, and later began a database service.

Lessons Learned From The NCCN

After going through the trials and errors of the NCCN Project, learning while doing, the following are some of the main recommendations to be made for those who may be attempting to set up similar distributed networks in the future.

Technical Development

The first thing to remember is that a software development project always takes more than twice as long as you think it will, so allow ample time for programming and testing.

'Technical interlock' was an important factor. When creating an interdependent, complex technological system using a variety of hardware and software, there is an interactive progression of key elements, all of which must progress 'in synch' or risk delaying the whole.

Establish A 'Critical Mass'

Computer networks are still networks of *people*, first and foremost. This perhaps was forgotten in the rush to set up and test the technology at the various sites. Sites were equated with users, with an implicit assumption that the establishment of a network machine would almost automatically produce dozens of users at that site in a very short period of time. This didn't happen.

Rule #1 in the computer network creator's handbook: GET A 'CRITICAL MASS' OF PEOPLE ONLINE AS SOON AS POSSIBLE.

The actual number of users to constitute a 'critical mass' depends on several factors. The first is the attractiveness of the network to each person on it. The more attractive the network, the more likely the user will use it, and the more likely the users will encourage their colleagues to use it.

Things that make a computer network attractive to a user include:

1. Low cost - especially true for organizations and individuals with small budgets

2. Having previous experience with computers - knowing how to type and word-process, and having a basic knowledge of the operating system and the concepts of computer networking

3. Simple instructions - a good basic manual for beginners and a 'user-friendly' interface

4. Right people online - knowing that there are people online that the user wants to communicate with

5. Right information online - knowing that there is information being put online that the user is interested in

6. Quick and easy technical support - having a real person to call on for help with hardware and software problems as well as confusions in accessing and using the system

7. Time saving - seeing that it doesn't take too much time out of one's day and that it actually saves time for many things

8. Proven applications - knowing how the network can do a lot of things you are doing now, only better, faster, and cheaper.

Other factors include: average time available the user has to spend on the system to learn how to use it; average need or willingness to send mail, transfer files, or contribute to the conferences.

Dialup Access

Bringing users online "as quickly as possible" means applying the resources toward the most efficient technology. This implies setting up a single centralized machine to be the host to enough users to ensure enjoyable and fruitful interaction. Many more users can be brought online via dialup access than by setting up a multitude of single site machines. Dialup equipment and software are easier to support technically and are also less expensive to initiate and maintain. Ease of use is a factor here, too. Public domain communications software, such as ProComm and Kermit, is very easy to learn.

A major disadvantage to dialup is that each user must have their own computer or access to someone else's. The cost of the telephone connection to the central network server is cumulatively more expensive with many users from a single remote region calling in individually than it would be if there was a local site near them to call with no long distance charges. This, however, implies that enough remote users live in this region to justify the costs of maintaining a network site there.

Another consideration is the Canadian public data transmission network called Datapac. It is a value-added common carrier that is more usage-sensitive than distance-sensitive in its charges. This means that people pay for the time they spend online and the amount of data that is transferred more than for the distance covered by the connection. It is generally cheaper for all but the users closest to the network server to use this service over direct telephone dialup. The Datapac lines used are much 'cleaner' too (less 'noise' from electrical interference). Those users who live in most Canadian cities can access Datapac from their local telephone dialling area. Rural users, however, must call in long distance to the nearest city served by Datapac and pay for that connection on top of the Datapac charges.

Network Development Strategy

Perhaps a better way to develop a network of this nature (where there are multiple sites that share a common information base and updating procedure) is to go through a series of stages.

Stage 1

Set up a single machine to be used as the test site. Have a second machine set up beside it in the office to test the inter-system communication software and modems. Get the hardware, software, and manual developed and tested until the system can support new users.

Stage 2

Promote the network. Seek out individuals and groups with the potential to be keen networkers. Evaluate half a dozen groups for their capability to be pilot participants. Try to get groups that will each bring about 20 or more new users online quickly. Only work with groups in or near the city where the network server resides. Establish close working relationships with key individual members of the pilot groups, using a 'buddy' system and frequent usergroup meetings.

Stage 3

Assist the groups in getting online by telling them where they can purchase the necessary hardware and software and showing them how to install and use it. Provide them with plenty of manuals. Try to build up their ability to propagate the network on their own. Develop applications in cooperation with the users. Work on helping them to find ways to get funds for further applications and related projects.

Stage 4

When one of the groups feels it is has the resources, set it up as a full site by showing them how to install and maintain the system. Begin to promote dialup access to groups that are recommended by the users presently on the net. In particular, assist the new site to establish a base of its own dialup users. Continue doing this until all groups have their own site machines.

Stage 5

Provide training and assistance for those established sites who wish to propagate the network outside the city. Train the trainers. Continue doing research on applications.

Return to home page