Figure 1. Intranet Front Page
Rod Byrnes, Southern Cross University, Lismore, NSW 2480, Australia. Phone +61 (0)419 292 590 rbyrnes@dromedarius.com.au Home Page [HREF 1]
World Wide Web, Intranet, Internet Service Provider, System Administration
"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean--neither more nor less."
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master--that's all." [HREF 2]
The above quote may sound cute and light-hearted, and it is, but it illustrates a very important point: an Intranet can mean many things to many people. Is an Intranet an information system, or a network with information systems on it? The most common interpretation today seems to be the latter, but there is a good case to be argued that both are valid definitions of an Intranet.
In this paper I will describe an Intranet, based on the former interpretation, that I developed for a commercial Internet Service Provider with a customer base numbered in the thousands. It performs system administration tasks, provides customer support functions, manages financial information and generates reports for management. Issues that I will cover are user interface design and user acceptance of the Intranet, technical details, security considerations, and an evaluation of the experiences and knowledge gained during development.
What does the word "Intranet" mean to you? If you think like many people I have met, it will mean, in theory, something similar to "an internal information distribution system, using Web technology, which allows an organisation to access specific information designed just like an Internet home page." [HREF 3], but perhaps phrased in less formal terminology. Although this is a good general definition (with the exception of the fact that it emphasises access and not participation), in practice peoples' understanding of Intranets is usually far narrower, being based on the specific articles and papers they have read, and their own thinking about Intranets and how an Intranet would operate in their own peculiar corporate or academic environment.
I too have developed my own idea of what an Intranet can be, and it is the fulfilment of this idea that I will describe in this paper. To begin with, though, here is some background information about my Intranet project...
It was a dark, drizzly Thursday morning in August 1995. The day was not going well. The espresso machine was broken and we were forced to drink instant coffee; my in-tray had just fallen over and taken out half the wall as it went down; and 54 urgent requests for new Internet access accounts had just come in that had to be set up now. There were four staff members in the office but only one (myself) with the skills necessary to create new user accounts on our Unix system. The rest of the staff spent most of their time playing around on the web and being generally unproductive.
In an instant coffee induced stupor I looked around at my technically incompetent colleagues, intellectual ZX81s, and was surprised to see the ease with which they were pointing and clicking and navigating their way around the web. My brain ticked over slowly, grasping, trying to work out the significance of this and why it seemed so strangely important to me. Then, in a moment of clarity, I "suddenly realised what it was that had been going wrong all this time ... This time it was right, it would work, and no one would have to get nailed to anything." (Adams, 1984). And so our Intranet was born.
On that cold August morning 20 months ago I had not heard of Intranets. In the 20 months since then our Intranet has undergone continual development, but most of that development has been initiated by staff requirements rather than general developments in the field of computing. The result is an Intranet that is quite different from other present day offerings, yet is one that to many Internet users will seem oddly familiar.
These days there is a lot of information available to help people decide on the product that they should use to develop a system. When I decided that a system of some sort had to be built to help solve our problems, there were fewer good choices. I could have chosen a different environment, but to be honest, I didn't research it very thoroughly at the time. This was partly to do with the fact that implementation time was extremely limited, but also that the Intranet felt right. Papers such as Austin's "Managing Login Account Creation With the World Wide Web" (Austin, 1995) described very early Intranets of this type that also increased my interest in further investigating this medium.
It is important to carefully consider the advantages and disadvantages of using an Intranet approach before deciding whether or not to begin implementing one. Some of these advantages and disadvantages will be discussed in this paper.
When designing our Intranet, I had several important considerations in mind. Specifically, the Intranet had to be easy and convenient to use, and contain sufficient functionality to perform most if not all of the everyday tasks necessary to run the company. These goals were based completely on selfish motives - I knew that if I could make the complex system administration tasks I was performing so simple that anyone with mouse proficiency could perform them, it would free me up to work on more interesting projects.
I chose a simplistic yet functional design approach. Every function appears on one page (in fact on one screen), so the operators don't have to click more than once to access any particular function. Similar functions are grouped to reduce the complexity of such a screen design to manageable levels (Comber, 1995). The result is an Intranet that people use. It didn't take long for the office staff to get used to loading one page and performing many of their day-to-day tasks from it. A side effect was that new functions that were added to the Intranet were quickly picked up without resistance because they were added to the same page that the staff were already familiar with.
Figure 1 shows the main Intranet page. Note the cramped and austere appearance that results from the large number of functions on the page and a minimalist approach to the use of graphics. Although this isn't the most attractive web page ever designed, the staff members who use this page appreciate this design philosophy as it is quick to load and navigate - it facilitates them in their job rather than hindering them. This may partly account for why our Intranet is so successful.
The Intranet Journal [HREF 4] specifies that an Intranet promotes organisational well-being "by identifying and communicating missions, goals, processes, relationships, interactions, infrastructure, projects, schedules, budgets and culture on-line, in a single interface everyone uses and can add value back to." This is a fairly one sided definition as it concentrates predominantly on the human resource aspects of the organisation. We found that in a small company of under 10 people working in a close environment, this functionality was completely unnecessary as the communication that this type of Intranet was intended to foster was already present.
The Intranet that we built grew gradually, function-by-function. Its growth was driven directly by user requirements and demands. The functions that the resulting Intranet provides fall roughly into four broad categories:
To give you a taste of the Intranet and its operation I will now illustrate two of the user account administration functions.
This is the page that staff members use to add users to the system. Most of the technical details such as allocating unique user IDs and determining the user's home directory are taken care of automatically. The fields are self explanatory, and a number of them have default values that don't often have to be changed. This results in a form that is easy to learn and easy to use. Compared with ordinary Unix adduser routines, this form is also far less frightening to the casual computer user, which helps drastically increase its overall acceptance. Note that the form also collects financial information that helps significantly automate the generation of end of month accounting reports.
This function demonstrates the integration of the Intranet with a standard Unix system function. A common occurrence in the ISP business is the client who receives an email with an attachment too large to fit within their disk quota. Ordinarily, only the Unix system administrator can modify disk quotas. This function provides enhanced security features so that other staff members can change the disk quotas of client accounts (and only client accounts) to values within reasonable limits. This removes the burden of disk quota modification completely from the system administrator.
These are the only functions I will describe here. They should give you an idea of what our Intranet looks like and how it differs from other Intranet implementations (see, for example, Netscape's Virtual Intranet Project [HREF 5] - you will need Netscape 3 to use it though!). I have provided a working model of our Intranet [HREF 6] if you would like to investigate it further.
Our Internet Service Provider operated on a predominately Unix base running Solaris 2.4. Our web server was NCSA's server, but I didn't trust such an important task to unencrypted transfers so we purchased Netscape's Commerce server and a secure encryption key. This provided one level of security.
A second level of security was standard WWW password protection, admittedly quite an important aspect of the overall security strategy. Finally, the web server was configured to only accept connections from specific hosts.
Each function supported by the Intranet had an associated CGI program. These programs were written in a mixture of C and Perl. For those functions that required root access (such as the modify quota function) a separate module was called from the CGI program to perform the actual root functions. These additional functions were very carefully written with security precautions in mind and stored in a directory that had its web access disabled. In general, the CGI programs were written in C, and the modules that were called by these C programs to perform system operations were written in Perl. Following is pseudocode for the modify disk quota function of the Intranet.
Get the key/value pairs from the web server Display the page header If no action has been specified Display the initial form Otherwise Check that the username being modified belongs to a valid client If it doesn't Display the initial form again Otherwise If the action was to lookup the client's quota details Get disk quotas from quota file Display disk quotas in an HTML form Otherwise if the action was to modify the client's quota Check that the new quotas are within valid limits Change the client's quotas appropriately Display a message indicating success or failure Otherwise Display an error message Display the page footer
The above module follows the same basic structure as all the other modules that make up the Intranet. It is a simple and consistent design that makes it relatively easy to maintain the existing Intranet as well as add on other functions when necessary.
I chose Interbase 4 [HREF 7] for our database engine. The database was linked with the CGI programs using the Interbase shared libraries and embedding SQL commands directly into the CGI programs. There are numerous ways of linking CGI with an SQL engine. For more information, have a look at the paper "A WWW Gateway for Interactive Relational Database Management" (Bjorn, M. & Hotaka, R., 1995).
The database was an extremely important aspect of the overall Intranet implementation. It drastically shortened development time, improved reliability, and simplified maintenance of the Intranet. The choice of Interbase over some of the less expensive databases available proved worthwhile, especially its support for multiple transactions, stored procedures, generators, and triggers.
There is not much to report regarding the user interface. Standard HTML is used. Any browser will work with the Intranet provided that it support forms and tables. Java applets, Javascript, frames and other recent enhancements were purposely avoided. With correct usage they could have made certain parts of the Intranet easier to use, but I decided against this for two reasons. Firstly, I wanted the Intranet to be as usable as possible, and this meant it would have to run on as many browsers as possible. Secondly, and equally significantly, a more complex user interface would have resulted in a longer development time. As with many projects, the time just wasn't available.
Looking back on the development of our Intranet, it is easy to see some things that work extremely well, and other things that perhaps could have been done differently. The largest problem has been development time - even with the generous use of library routines that provide interfaces to the web server and the database as well as consistent design methodology, development time was still too great for some tasks. Although writing CGI programs in languages such as C or Perl give great flexibility, I am sure that by now there would be better ways of performing some of the functions. That said, development time was still trivial when compared with developing a system of equivalent functionality in either a terminal emulation environment or writing specific client-side applications.
I consider the use of a professional quality database to be an essential part of the Intranet. Interbase is a professional quality, value for money database. Other databases such as Sybase or Oracle would perform equally well if not better, though they are more expensive. Netscape's Commerce server also performed exceptionally well. I didn't notice any bugs, and it comes with a very easy to use web based administration tool (almost an Intranet of its own!). A later Netscape server, the Enterprise server, appears to have some bugs, and, to my way of thinking, the administration tools are not as nice to use.
Probably the hugely successful uptake of this Intranet can be attributed to the following factors:
After reading this paper, you may be thinking that Intranets are the solution to all the world's problems. In my experience, this is definitely not the case, and I think some of the other issues involved in Intranet applications should now be discussed.
Is an HTML GUI a replacement for other GUIs, such as MS Access or Powerbuilder or a number of other products that can accomplish similar things. The answer is definitely NO. In comparison to these products, HTML is awkward and sluggish. It is not suitable for complex or high volume data entry tasks. HTML applications require extensive use of the mouse, and in situations where large amounts of data are being entered, the continual movement between mouse and keyboard would significantly reduce productivity. Other products can be customised better to this type of task.
The user interface components provided by HTML are inferior to those provided by other applications. HTML is capable of handling simple user interface requirements such as those described in this paper, but only just. Its simplicity is like a two sided coin. Easy development is traded off against the richness of the interface. A benefit of this is, of course, that it should be relatively simple to evaluate at the outset of a project whether an HTML solution will be adequate or not. (See the paper Exploiting the Full Web User Interface Spectrum [HREF 9] for more information on Web user interface components).
This Intranet has been in operation since late 1995. During that time it has proved to be an invaluable resource, both in allowing general staff members to directly perform integral functions of their jobs, as well as freeing IT staff to work on tasks that draw more on their experiences and abilities.
The creation of an interface (WWW) that is flexible, easy to program and easy to use has been a great invention. The potential of this medium is huge, and has only been minutely explored by this project. There is now just one question that remains. I think I will let Alice ask it.
"Would you tell me, please, which way I ought to walk from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where--" said Alice.
"Then it doesn't matter which way you walk," said the Cat.
"--so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough." [HREF 8]
Adams, D. (1984) "The Hitch-Hikers Guide to the Galaxy", Pan Books, p. 6.
Austin, P. (1995) "Managing Login Account Creation with the World Wide Web", in proceedings of Ausweb 95, p. 211.
Bjorn, M. and Hotaka, R. (1995) "A WWW Gateway for Interactive Relational Database Management", in proceedings of Ausweb 95, p. 419.
Comber, T. (1995) "Building Usable Web Pages: An HCI Perspective", in proceedings of Ausweb 95, p. 120.
Rod Byrnes © 1997. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.
[Interactive Presentation] [All Papers and Posters]