Executive Summary

In this study, ethnographic participant observation was used to understand the specific interface requirements of system administrators of super-large organizations (SPORGS) for their system administration software. The goal of this paper was to provide Netscape with design suggestions for their "Suite Spot" software products in order to make the product better serve the specific needs of large organizations. The paper outlines the user interface requirements of the IS market and the organizational contexts shaping these requirements.  We define the prototypical user, the organizational context in which system administrators work in, and the user interface requirements of these individuals.  Based on this investigation, we offer design suggestions for Netscape's Suite Spot line of server products to better meet the needs of the client market.

1. Introduction

Currently, Suite Spot software is only marketed to organizations with up to 5,000 employees, and many organizations which are much smaller (some with fewer than 50 employees).  Netscape would like to widen the customer base for Suite Spot to super-large organizations (SPORGS) with over 50,000 employees as well as Internet Service Providers (ISPs).  The work environment as well as the technical server setup which shapes the daily work environment of system administrators in SPORGS differs greatly from smaller organizations.  Therefore, in-depth understanding of the challenges faced by system administrators in SPORGS is necessary in order to create a version of Suite Spot that will meet their needs.

2. Goal of study

 In order to gain this in-depth understanding of the work practices of system administrators of SPORGS, ethnographic methods of participant observation, depth interviews, and narrative analysis were used in order to find answers to the following questions posted by Netscape's Server Product Division:

3. Research Questions

 How does the organizational context of SPORGS shape system administrators'  server administration interface requirements?  What are the user interface requirements of the IS-ISP market?  What suggestions for the design of a server product can be given based on the  findings?

4. Methodology

 This study involved performing participant observation and depth interviews of system administrators of academic institutions and large companies. Our goal was to discover 1. the administrators' daily practices in managing the servers and 2. the organizational behavior of the company they worked in.  We observed what products the company currently uses, personal configurations, and most frequently performed tasks.  Typical interview questions included features system administrators disliked about their currently used product, features they specifically liked about it, features or interface types which they deemed appropriate or necessary for their daily practices, and their "ideal" server administration product. We also asked our respondents to comment in general on different interface types for server administration (Web-based, GUI in stand-alone/desktop application, command line), and to tell us about those work routines we might have missed on the specific days we visited them. Other questions included the organizational context:  Specific technical setup requirements shaped by the size of the organization, cooperation between administrators among each other, and with other departments in the company, etc.  We conducted follow-up interviews where time permitted in order to further research these topics.

5. Prototypical Users

 In the course of conducting research on the user interface requirements of the IS market and the organizational context shaping these requirements, we found that system administrators in general tended to be male, aged 22-35 and very overworked.  We found two types of prototypical users:  

The two types of users we found were system administrators at universities, non-profits and public administration, and system administrators at large sized companies.  We will examine the organizational contexts in which these two types of users work and how these contexts affect their UI needs.  

6. Research Question 1: Organizational Context

 There are many organizational, contextual factors involved in why system administrators use the server products they do.  These factors range from being in a supportive environment to the cost of the products.  The following is a discussion of these factors.

Acceptance of complexity of Interface  

A system administrator's tolerance of difficult to use server products depends on whether or not the organization promotes communication and cooperation.  In the academic environment, we found that users are more isolated, having their own offices.  System administrators here communicate with other system administrators primarily through email.  Since they rely on themselves much more, they need to be able to understand the interface of their product and therefore use products which are easier to use (i.e. GUI based).  

When a company fosters good will and cooperation with coworkers, however, people are more tolerant of complicated interfaces.  For example, one large company which we profiled uses very old and cryptic server product software. 

However, there are very few complaints with this software because when a system administrator encounters a problem with the interface, he feels very free to ask his coworkers.  Many companies we visited had open cubicles instead of closed door offices so coworkers see and speak to each other frequently.  They often speak to each other over their walls and talked on the phones constantly.  This cooperation effectively reduced the problems caused by the difficult user interface. We concluded that in an environment in which employees felt inhibited or embarrassed to ask for help, we might encounter a lower level of satisfaction with a complicated user interface.

Cost of Product  

The cost of the product may also play a role in determining the use of a server product.  In the academic environment, where monetary resources are scarce, system administrators use products which are relatively inexpensive or free. 

For large companies, however, cost is not an issue.  They have much larger amounts of money at their disposal and prefer to buy the better product, not the cheaper product. Willingness to change or upgrade  The size of the institution also determines what type of server product they use.  Universities and small companies do not spend a lot of time and money in the server products they use.  They typically run only a few servers and hence when they do change their products, they don't have to invest too much in training users or installing the product.  

Therefore, there is a tendency for younger companies and universities to be more willing to switch to new software.  Since products are being installed so frequently, it's very important for the products to be easily installable.  Large sized companies have many servers set up in complex ways to accommodate their many employees.  They have invested a lot of money in training their well educated system administrators and in buying their server software. 

Therefore, these users are less willing to change the server products they use, even if they are very complicated to use.  In addition, the complexity of the setup (worldwide server connections, many kinds of servers, highest volume, and unacceptability of the server being down for maintenance) makes the installation of a new product an extremely difficult endeavor. They are only willing to switch to a new product if it is clearly much better with large benefits.  Since these companies install software so infrequently, they do not mind if installation is complicated or lengthy.

Reliability  

Reliability is a factor in purchasing server products depending upon the organizational context of the institution.  For academia, reliability is not as important of an issue as is cost.  There is not a lot at stake in academia if one of these products should have a breakdown. In corporate environments, however, reliability and stability is extremely critical.  Data has a cost value in corporate environments, and should a server product result in a loss of this data, huge amounts of money may be lost.  If a server product does have a breakdown, the breakdown must be resolved immediately.   For a company such as this, even a breakdown which takes a day to resolve may be too long - sometimes an hour can be a big problem, e.g. for Web servers which have to be up at any time, or for mail servers.  

"The Netscape product we used crashed too often - about once a month. That, to us, is unacceptable"                                                Andris, HP

Cooperation  

Another organizational consideration when buying server products is whether or not the product supports many users working cooperatively to maintain the server.  For system administrators working in an academic environment, this support may not always be important since many of them work alone.  However, in large corporations, several system administrators maintain the same server.  Therefore, it is critical that the product be able to support this cooperation.  Security is also an issue for institutions depending upon their organizational context.  In universities, it may not be too critical if a third party gains access to one's data.  However, in the corporate environment, security is an overwhelming concern because of the intense competition.  Many system administrators we talked to stated that if a product doesn't provide excellent encryption, they would not buy it even if it worked great in every other aspect.  

7. Products currently used:

 The computer science department of a large university we spoke with mostly use Apache and Microsoft Intranet Suite for their web server because of free access to these products.  Apache has the additional benefit that since it's publicly developed, it has the latest features.  For their mail server, they used the Sun IMAP server because it provides for features of being able to retrieve data that someone has deleted.  These system administrators stated that they don't use Netscape's mail server because they mistakenly assumed that it didn't follow the IMAP protocol.  (Our respondents stated they don't use Microsoft's mail server because mail was too important to them). 

The system administrators generally mix and match products depending on the server they are administering and the particular feature they would like to use.  All the companies we spoke with mostly use in-house server products.  The main reasons for this are 1. that these applications are built to meet the very specific needs of the company, and 2.  that home grown products eliminate their dependence on outside third party technical support.  This independence is critical for these companies because the technical support they do receive is slow and doesn't provide them with source code for the company to solve problems on their own. For example, one large computer company we spoke with stated that they use a mail server product called Meeting Maker which locks up frequently for no apparent reason.  When they call Meeting Maker's technical support, the support engineers do not release error code to help the company figure out the problem themselves. 

This situation is completely avoided with in-house software.  System administrators understand the problem more quickly and have the source code to solve the problem.  However, technical support is not the only issue involved when companies create their own server software.  The software requirements of large organizations are very specific and there is no standard off-the-shelf product that could meet all of these requirements.  The only way for the company to have all the features they wish to have is by creating the product themselves or by using a server product with an API which would allow them to create their own features.  

8. Research Question 2: User Interface Requirements

 Based on our observations of the organizational context of system administrators at universities and companies, and the feedback given by these individuals, we have come up with a list of user interface requirements that server software must have to better meet the needs of the IS market.

a. "Gilbert"  

For the academic environment, it is very important for server software to be very easily installable because system administrators are installing new software so frequently.  Since installations are performed so often in universities, reducing time spent on installation makes a system administrator's job much more efficient.  One system administrator we spoke with stated that server should be installable with only a few mouse clicks. The fact that the isolated work environment seems to stimulate a playful approach to system administration may account for the great interest in downloading new, free additions to the server software, even if these added features are not necessary.  Because system administrators at academic institutions are not as well trained as their counterparts in the corporate world, it is very important to have a very intuitive graphical user interface.  The GUI should make it very easy for them to add new features and should provide a visual representation of files.

b. "Dave"  

For large corporations, the interface requirements tend to be very different.  One important user interface requirement is not only to have a graphical user interface for the server, but also to have easy access to a command line interface.

GUI and command line

As companies become larger, it can be expected that they will need to constantly add new features to their server to software to accommodate their server needs.  GUIs do not support these features as well as command line interfaces do.  A GUI will either appear too cluttered with all the features or it may take too long to access the particular feature they like through the GUI.  However, a command line interface, while not intuitive, is a quick method of accessing features in a field where speed is critical.

Visualizations and simulations

 On the other hand, GUIs are preferred to visually represent the state of companies' servers.  Companies would like to use GUIs for experimentation purposes: Many of our respondents would favor an interface that would have the ability to graphically simulate the effects of changes (based on actual data) before the system administrator actually performs the change; thus, the system administrator would like to observe how the server would run differently. 

Thus, what system administrators would favor is the software's ability to calculate the effects of proposed changes based on actual data.  For example, a GUI should be able to represent the current traffic load, the traffic load based on a simulation of a change, and the states of the server over the next half hour of both the original setting and the experimental altered setting.  This is important, since the server setup in SPORGS is so extremely complex that changes are complicated to make, and the effects are difficult to foresee. Having to change the settings back to the original, because the change was not beneficial, would mean a large amount of work in the highly complex interconnected environment.  

An example would be switching part of the traffic from a server with high traffic to another server with lower traffic. However, some side effects in the complex setup might make the change counterproductive. If the software were able to anticipate this and offer suggestions for optimal settings, this would help administrators immensely. In other words, often, system administrators feel that they can do most of the things which a GUI based program does, anyway, and thus they are more interested in features that can do things the person is not able to do by hand.  The program should run in Java, C, or C++ for high performance.

Crucial: API

 Another requirement of server software is to have a Java or C++ API for companies to build their own features.  This was considered extremely important by most of our industrial respondents. The reason for this is that the server configurations and setups have a very high level of. Many of our respondents reported being in charge of many different servers spread across different countries and interconnected in extremely complex ways. The tasks which these servers perform are highly specialized - for example, remotely monitoring high-volume printers.  

"We are managing 2000 printers around the world through 80 servers. Not even our custom in-house software is able to handle our very specific software needs; we are writing our own scripts and additions constantly. If we couldn't do that, we couldn't do our jobs."        Adam, Cisco Systems

 This means that our respondents considered it very unlikely that an off-the-shelf product could offer all of the very specialized functions they need. Thus, they feel that it would be absolutely necessary to be able to modify and add on to the software themselves.

 "I manage four different kinds of servers for IBM. My Web server alone gets a million hits per month. The setup is very complex. We do use our IBM software, but we have to write our own scripts constantly."        Dave, IBM Triangle Park  

An API thus makes the server software customizable and provides system administrators with more control.  Java was the preferred language for all our respondents, most of whom said that they would absolutely not buy a product that does not provide a Java API. The need for a Java API to handle the immense complexities of our respondents' daily activities was the single most important issue for all of our respondents from the corporate environment.  However, if an API can not be implemented, an alternative might be to provide excellent technical support, for which the support engineers would be extremely knowledgeable, intelligent, creative, easy to work with, and available at all times.

Collaboration

 In SPORGS, there tends to be a team of system administrators assigned to the same servers.  Therefore, it is necessary that server software for these companies allow them to all to work cooperatively and in conjunction.  Currently, system administrators have to talk to their colleagues on the phone, email, or exchange small post-it notes continuously in order to tell other persons who maintain the same server what changes were made or what problems arose. We were amazed at observing the amount of inefficient low-tech information flow in this high-tech work environment. Our respondents similarly felt that the software should show who is working on which server and what changes s/he is making.

 "We were a team of 5-6 people, all working on different aspects of the same servers. It was horrible. We had a web-based interface, and only one of us could work on a server at a time, but the interface wouldn't tell you whether or not someone else was working on it just then. Thus, you never knew. You also didn't know what changes they had made, unless you went through everything manually"       Dave, IBM Triangle Park

 An additional requirement would be to provide a tool that would monitor the server through a visual representation.  The monitoring tool could represent the server as a function of its response time and availability, for example.

 "The status of my 2,000 printers is something I don't want to see in tiny numbers on a screen. Graphs are much more efficient for me."       Adam, Cisco Systems

 Another requirement for a GUI would be the ability to provide a visualization of the server setup (e.g., through a tree diagram).  The system administrator should also be able to graphically change the server's setup.  The user should simply be able to drag and drop items pertaining to the server.

Remote access

 Because large companies have sites all over the world, it is very important that system administrators be able to maintain their servers, no matter where their location.  Therefore, server software should also provide the feature of being remotely operated; thus, a web-based interface is preferred assuming that security is excellent.

 "Web-based access is good, but if security is not excellent, I would not buy a product, regardless of how good it is otherwise"       Rob, Sun Microsystems

9. UI Recommendations

 Based on feedback from system administrators and the organizational context in which they work, we provide Netscape with suggestions for their server software.

Control of Complexity  One of the main features we recommend that Netscape provide is an API.  Because organizations need to constantly add features as they grow, it is vital that they be able to customize server products directly for their needs.  However, providing an API may prevent an organization from buying future upgrades of server software since they are constantly upgrading the original software package themselves.  To bypass this problem, instead of only concentrating on providing new features in future upgrades, we suggest that Netscape make their main focus providing a better user interface for their customers.  

This way, organizations constantly customizing Netscape's products will want to buy an upgrade for a more intuitive interface, while companies that do not customize the software will buy the upgrades for the improved interface as well as the new features.  In the case that an API can not be provided for, we alternatively suggest that Netscape constantly develop online plug-ins.  These plug-ins can be sold separately from the original server software package.  This strategy not only provides for the customization needs of organizations, but it also allows Netscape to sell more software units.

Security  

Another important feature for Netscape to consider is to provide better encryption for their server software.  Although the government has currently placed a limit on the level of encryption software may contain, Netscape should provide as much as is legal and feasible.  If improved encryption cannot be provided for, the server software should be made a desktop application, rather than a web-based application.  This solution avoids the problem of encryption altogether. However, a remote system (browser-based) was preferred by our respondents; thus, we recommend excellent encryption.

We also suggest that Netscape provide a feature that facilitates collaboration.  The user interface should provide a button, which when clicked, will display all servers, who is currently working on what  server and what changes he has or is currently making to it.  If only one person can make a particular change on a server at a time, a symbol such as a lock should appear on every other system administrator's screen regarding that server.  Providing collaboration facilitation prevents a system administrator from wasting time to call or visit his fellow system administrators for the same information.

Simulation  

Another recommendation is to provide a simulation tool to allow system administrators to see the effects of a desired change to a server, without actually executing the change.  Currently, if a system administrator wants to improve the efficiency of his servers, he must reconfigure them, and monitor the effects of the changes.  If there is no significant improvement, he must go back and restore the configuration to its original state.  A simulation tool would completely avoid this, saving the system administrator much time and effort.  With this tool, a system administrator should be able to simulate the change to the server and see the effects of it over a given amount of time.  If no significant improvements can be detected, he can experiment with other changes.  Since the changes are only simulations, and not actual changes, the system administrator never has to go back and restore the server to its original state.

Command line vs GUI

Every system administrator we talked to liked to have access to a command line interface as well as a GUI interface.  This provides them with the comfort of an intuitive application as well as all the power of a command line.  Therefore, we suggest that Netscape provide easy access to a command line within their GUI.  For example, Netscape can install a button in the GUI that would quickly and easily transport them to a command line. Ideally, this GUI should be browser-based and allow for remote access.

 We also suggest that Netscape make their interface model the server they are controlling as much as possible.  If a server has an up down switch on its control panel, there should be a graphical version of this up down switch in the interface; this graphical switch should be able to be metaphorically controlled as an actual switch.  If there is a light indicating that a server is on, there should be a corresponding graphical light in the interface.  Providing this sort of interface allows the system administrator to better visualize and therefore control the server.

Stability

 Lastly, we recommend that Netscape improve the reliability of its server products.  Since large organizations cannot afford to have a breakdown in their servers, it's imperative that their servers remain stable.  Netscape currently regards a breakdown of once a month to be stable, while one large organization we spoke with considered this rate to be unreliable.  Since large organizations place such a premium on the stability of its servers, we suggest that Netscape improve the stability of its software even more.   Contacts  Establishing contacts in the IS groups of organizations proved to be a huge problem for our group.  Out of the eighty requests for interviews our group sent out, only eight system administrators responded affirmatively, while two responded negatively. 

We attribute this lack of response to several reasons.  Because system administrators tend to be busy individuals they simply did not have the time to talk to us.  In addition, since they receive hundreds of emails a day, many of them have email agents to sort through their account and delete any irrelevant messages.  Because we tried to contact these individuals primarily through email, we suspect that many of our messages were not even read due to automatic deletion by a mail agent. 

Due to the dynamics of this process of contacting system administrators, we felt that perhaps we did not get a very representative sample population.  Another difficulty we faced was that we typically only had an hour to spend with our interviewees since they were so busy (some allowed us to come back, stay longer, or follow up though email, though).  Most of them would not allow us to observe them even after we assured them that we would not disturb them.  Therefore, we tended to allocate a certain amount of time during the interview to ask the system administrator about how they work instead of observing them work. In addition, whenever we did observe system administrators at their work, we were not able to ask questions to improve our understanding of the tasks, since they could not be disturbed in their work which required concentration.

10. Conclusions

This study helped identify the main problems users face when using off-the shelf products for highly complex tasks.  The main finding of this study was that the level of complexity faced by typical users and the need for highly specialized functions and interface additions necessitates an API or similar means of creating add-ons, plug-ins or similar program extensions. We therefore highly recommend providing a Java API.  

In addition, trust was a common thread in our interviews and observations. Since system administrators have to rely on the software to work without any problems, stability is as crucial as is excellent tech support with expert staff, since server emergencies are situations which companies of this magnitude cannot afford to have.  Since collaboration is becoming increasingly difficult with numbers of servers per company increasing and the number of system administrators in the companies we interviewed always in the 2-digit range, facilitating this collaboration in the interface seems crucial. Similarly, the speed at which system administratorsí work requires intuitive, fast interfaces.

This means that not too many steps should be required to get to different parts of the application, or different levels of detail. Similarly, a tree diagram might help, as would graphs of traffic load, problem zones, etc. It is of utmost importance to update graphs dynamically (every few minutes) to make sure the user is never presented with outdated information.  Finally, our respondents agreed that they did not want software which "thinks for them"; they view software as a tool, but want to be in control, and they want to be able to see every step of how the software solves problems, if it does so automatically (e.g., re-route traffic). Thus, expect these users to be highly skilled and allow them to use their skills whenever they feel a need to; optional command line mode is as important as are log files and the possibility to intervene on every level.  

Regarding the broader organizational context, it has to be noted that the relationship between IS departments and other departments can be problematic, multi-faceted, and complicated. Very often, even several IS departments within one company find it hard to agree upon a protocol, format, or standard; thus, the use of standard protocols is important, as is an interface which allows for intervention at different levels of difficulty in order to accommodate the needs of various departments and user types.  Our hope is that a better understanding of these complexities will indeed lead to the development of a successful software products that will make the lives of our respondents slightly less complex.      

 Appendix

Excerpts from interviews:

Adam and Ben, print server administrators, Cisco, conducted May, 5th, 1998:

- To administer and maintain their servers, Cisco uses in-house SW called sddpd (simple distributed database) with a browser   interface and an underlying command line interface.

- SDDPD, however, is not simple and not a database.  It's a complex  directory server.  It allows to share information about printers   records and about 80 printer servers in charge of 2000 printers around the world.

- They created SDDPD because the other tools out there were not adequate,   such as NIS, DNS and LDAP.  DNS could not be used because printer   records need to be shifted around so quickly.

- System administrators prefer a command line interface because it makes   more tools available and because it's so portable.  There is no   practical way to do this with a graphical interface- it has to be simple   enough to be able to scale everything and be scriptable.

- Cisco is currently replacing it's NT print servers with Linux servers.   NT print servers break for no reason at all- that's another reason why   Cisco makes their own.

- Cisco built it's application to be able to remotely maintain their   printers around the world.

- The main thing that they want is a hardware (I guess to be able to   handle their software efficiently)  

- Cisco's print server system is designed to be self-maintaining.  When a   new printer comes up, it will attempt to see where it's at and try to   configure itself.  The process by which this works is that the printer   sends a boot p request.  They forward this request back to the server.   The server will then go back and say this is your IP address and this is   how you're configured.

- The web page is the most used feature of the printer server.

- There is a tool called PR-Admin which is an interface to SDDPD and the   web page is built on this.  PR-Admin is written in C.

- An SNMP request is sent when the printer isn't working.  SNMP is their   least favorite protocol.

- Cisco used to write their printer server tools in scripting languages   like Corn shell, but they had to add so many new features to it and   scripting languages are not very scalable.  Now they write things in C.

- System Administrator also use a monitoring tool called Application   Monitor.  These monitors are used to make sure that things are running   DNS.  The tool holds over 3000 (???) hosts to make sure applications are   responding.  The tool is good for making sure that one of your servers   isn't getting overloaded.     * the monitoring tool has a graphical representation of response time     and availability.  It's important to monitor DNS on all of them     because Cisco is expanding all over the world.

- They also monitor SNMP to make sure they can get information.  (This   doesn't make sense to me either.)

- Daemons handle service requests for the particular server they're   running on.  For example, a web daemon handles HTTPd service requests.  

- One thing that Cisco is interested in is why the printer loses print   jobs.

- They don't like a mail server called Meeting Maker because it locks up   for no reason.  When they call technical support to find out why there   is a problem, they won't release error code to help them figure out the   problem.  This makes them more dependent on other companies.  That's   another reason why they developed their own printer service tools.   They're not dependent on anyone.  However, whenever there is a problem,   that means that they HAVE to figure out the solution because there is no   one else they can go to.

 "Our servers have to be up all the time; they can never be down. If my server is down at four in the morning and I have to wait on the phone for an hour to reach tech support, that is not acceptable."

- The print servers at Cisco must be remotely maintainable, scalable and   fault tolerant (if they lose power to the building, the printer server   should still be able to work).

- Cisco's print servers are very feature packed.  They put features in   depending on how important they are and if the system administrator who   wants the feature can code it herself.

- Cisco wants to merge it's printer server to have one global strategy.   * There are two feuding families within Cisco: the IS Department and     the Engineering department.  The Engineering group wants a newer     version of lpr ng, but the system administrator group currently has no     time to implement it.  I think that they said that the Engineering     group used NT servers, but not sure.

- A web based interface is used for some tasks.

- Dynamic, constantly updated visualizations of the status of the printers (statistics, traffic) are provided on another monitor and are frequently utilized by the system administrators.

Typically, the system administrator gets a printer problem report by email, then looks up the source of the problem using another computer and monitor via the web-based interface of the Cisco system administration software, but then fixes the problem usually using the command line based interface that is on the machine which is also used for email. In between, the monitor displaying the visualizations is frequently consulted. In addition, the telephone is used to check back whether the problem has been fixed.                

Henry, Manager of Distributed Systems at a large private university

Henry:  at a university there is a very different culture.  We will help anybody.

What kind of server products do you use?

 An NT and Unix Workstation.  We use an IMAP Server for our mail.  IMAP is a protocol for mail.  POP gives features for putting things in the home directory.  I like IMAP because it  gives more functionality where you can put things in a folder.   You can arrange things.

Do you use Netscape's mail server?  No, because it doesn't follow the IMAP protocol.

What other server products do use?

 Apache, Somba, I don't really buy packaged stuff.  Sun gives me a lot of stuff for free, because we have a licensing agreement with them. We basically use a hodge podge of products for the different servers we maintain.

Is that all the server products you use?

 I don't like Microsoft's products because they're third rate software and they have a predatory nature.  We don't use Microsoft's mail server because mail is too important to us.  I like Sun's IMAP server because you can get things in ASCII spool mode, and in a lot of instances you can get data back, even after deleting it.

Rob, Sun Microsystems, Menlo Park.

  Servers managed: Home direct, print server, application servers, backup server, Web servers. The servers are accessible to the staff of this Sun plant (several thousand people), except for the web server, which is accessible to the world.

  A staff of 14 manages these servers; Solaris is used for print and file servers. Command line is used, but the backup server has a GUI for administration.

  GUIs are *not* preferred or trusted for maintaining these large servers, since the system administrators want to know exactly what the application is doing at any given time.

  Software by Lexmark is used for remote operation - an important issue. If the server is used to manage devices, such as printers, it is extremely helpful when a GUI actually shows a visualization of the front panel with all the switches, so that if a switch setting on a printer is wrong, it can be changed in exactly the same way the physical object would be manipulated.

  Since a GUI is perceived to take away control from the user, a GUI would have to be extremely flexible and customizable - preferably through a Java API.

  For tasks such as adding new users, which is currently done using command line, it would be extremely helpful if the application were compatible with NTFS.

  Tasks such as monitoring printers or other servers should be automated, including visualizations. A GUI would be preferred if the System administrator would not have to compromise in anything else, thus, he/she should be able to run their own scripts, if necessary. A GUI is not helpful just for the sake of having it or looking nicer. What counts is the end result: How efficient and customizable, and fast is it? How transparent are the underlying processes? Speed is a very important issue; another important factor is the ability to manage the server from remote locations; security has to be excellent.

  In general, you don't want software to think for you; you have to know what is going on at every step; simulations of effects of intended actions before you actually do them (e.g., effects on traffic) would be very helpful.

  Routine tasks such as printing, backups, adding new users should be fast and easier. Better control on logins and IDs should be given; the GUI should be designed to help detect login and ID/password errors. An all-in-one interface would be nice, which allows the system administrator to access database information on how to administer the server .

  Trust is a big problem when buying a product from a third party; Sun would currently not consider doing it, because of trust issues. Tech support would have to be excellent. These people would have to be extremely knowledgeable, intelligent, creative, analytical, and easy to work with, as well as available at all times.

  An ideal interface for server administration software would allow you to graphically change the server setup in the GUI (e.g., move one part of the files from one sub-part of the server to another just by dragging and dropping). You should see a visualization of the current setup and should be able to just drag and drop - ideally, you would see a simulation of effects before you decide to actually make this change. Again, a Java API would be important.

  A log of activities would also be important. A Web-based interface would be good if security is good. Visualizations would not have to be too advanced. Security should be good enough to also detect and identify bugs and potential problems.        

Dave, IBM Triangle Park (NC) systems administrator:    

Servers run: Web, FTP, BBS in a team of 20 system administrators for IBM.   Software used: OS/2 Server software "Internet Connection". NCSA htpd running on AIX used to run external Web server. Very large Web site.

  The OS/2 software had web-based interface to manage permissions, authentication, operating system environment.

  Problems: Only one admin. at a time could use the software. Html/CGI was slow, cumbersome, limited, not immediate. Wait time was a big problem in browser-based interface.

  Things liked the most: Accessible from anywhere in the world, let them reboot the server from anywhere (but security must be given), ease of use.

  Interface preferences: The Web interface was preferred for tasks that required to try things out, experiment, make lots of small changes. The text-based interface was preferred for quick routing tasks. GUI was overall preferred, but Java would be preferred, because it runs client-side, thus would provide more immediacy. However, java is slower than C, so for super high-performance, C might be better. Effects of changes should be displayed on the *same screen* that the changes were made on, so that it would be easy to change it back.

  Features wished for: A visualization of the server setup would be helpful (e.g. tree diagram).

  Ideal Interface: Should have GUI for configuration, but should allow to play around with alternative settings without actually doing them (thus, it should be able to simulate the effect of a change based on the actual current traffic - changes in dynamic load, etc). It should be browser-based and have real-time visualizations of:

  - current traffic load, and show changes over the last 30 minutes, and should be able to simulate the next half hour.   -which parts of site are accessed the most   - ranking of current http refer addresses.

  *Most* desired feature: An *API* in Java (or C++) to add on your own features (e.g. pager or voice support).  It should be possible to work with text directly (command line) if so desired. Should provide a configuration mode, and a monitoring mode. Comments: Setup time is not an important issue; it's ok if it takes a day.                                                  

William, Multimedia Programmer, Computer Forum; CSD Webmaster

1. What server products do you use?

 Sun Ultra Sparc II  Apache  Microsoft

2. What do you like about this product?

    Apache:         1) free       2) configuration done in one simple text file       3) not big       4) very fast       5) publicly developed, so it changes all the time.  But it's not          hard to keep up with all the changes

    Microsoft Intranet Suite:         1) easy to set up and integrate       2) very inflexible

    Mac HTTP or WebStar- GUI for administering.  He likes this one a lot because it's very easy to go from a GUI to a textbased interface.

3. Are these products GUI based or text based?

    GUI based.

4. Do you prefer GUI based or text based interface?       GUI, because he likes to be able to see the files.  If you have to go through second editing it isn't easily done.

5.  What do you dislike about these products?

    In general, the languages these products use are unnecessarily  complex.   6.  What would be your ideal server product?      1.  One that's easy to install with a couple of mouse clicks.      2.  One that's easy to administer with a central grouping of  files.      3.  Has the ability to add new features.      4.  Something that's hot swappable- administrator module that   could be anywhere.

7.  What is a typical day for you like?

     Two hours of answering email in the morning and later, going  around and trying to find answers to questions that people sent  him.  Large amount of work is spent reformatting other people's web pages.  The worst product that has come out is Office 98 because it allows people to save a word file as an HTML file.  People think that they are creating technically correct HTML, but they're not.  So, a lot of his time is spent  reformatting other people's web pages.

8.  What do you like best about your job?     It's very pioneering

9.  What do you like least about your job?     It's very boring and tedious.

Observations:

Bill has four computers in his office, one that's used as an intranet server, two web Macintosh development servers and another UltraSparc webserver.  His office is very messy with papers and files everywhere, but he knows exactly where everything is supposed to go.  He doesn't receive phone calls very often, sometimes, he can go for three days without receiving a phone call.  He keeps his back to the phone while he works.  He gets about four hundred email messages a day, but he has an email agent that sorts through his email and deletes about 80% of the emails that don't have certain keywords.