Over the past several years, residential colleges and universities have rushed to wire their dormitories for Internet access, often with little regard for the support needs of such technology. As student computer ownership continues to grow, and student use of information technology skyrockets, institutions of higher education are on the brink of a support crises. Old fashioned "help desk" support notions must give way to more distributed, community centered models to keep up with the demand. This paper describes Stanford University's Residential Computing program, and draws comparisons with the development of a similarly successful model at Wellesley College.
Glowing computer screens would keep the consultants connected with every aspect of computing on campus. These consultants would wield an arsenal of high-tech tools, allowing them to solve any sort of desktop mishap, and to do so remotely. Applications like Farallon's Timbuktu were proved that it was possible to take control of a user's desktop from afar, and "diskless workstations" were going to make this support much easier, since locally stored software would be things of the past. The basic operating system and network drivers would be built into the hardware itself and applications and file storage space would be located on remote servers (This notion has, of course, been rekindled with today's promise of "network computers").
And how would the Command Center support model scale to meet increasing needs and growing numbers of ever more demanding users? Through expert systems of course! Every speck of consulting wisdom would be captured and stored into a semi-intelligent and growing knowledge base, and every user on the net would have a simple and intuitive client interface into this help system. All one would have to do is type a question into their diskless workstation and within seconds the correct answer or course of action would pop up on the screen. It seemed very important for this system to be designed in such a way that users wouldn't have to know, since surely they wouldn't care, exactly who was providing the support.
Well, perhaps the memory of these heady days is a little more fanciful than the reality, but the basic concept was there. Somehow we thought, and to a certain extent many still believe, that the answer to supporting our users most efficiently and effectively was to distance them as far as possible from the people who actually provide the support and to create electronic gizmos to make it all "seamless." In effect, to further remove the human interaction from the already impersonal environment of computing.
At Stanford University, the Office of Residential Education was pursuing a more human approach to technology support, one that encouraged face-to-face, peer support. We came to realize that our students didn't really want the Computing Command Center support model, and our consultants didn't appreciate working in such an environment either.
A robust student support model grew out of these early experiences with cluster management and was designed to dove-tail with the University's existing residential staff environment. Since no formal microcomputer support program then existed at the University, a joint management plan was formulated by Stanford's Computer Science department who would help with grant proposals and sponsor an introductory computing course, and the Office of Residential Education. Residential Education agreed to install and support donated lab equipment utilizing student staff, eventually titled Resident Computing Coordinators (RCCs), to support these new facilities and help other students use them.
It should be noted that this Residential Computing Coordinator program was developed at a time when funding for new and innovative projects was readily available and grant equipment and other kinds of corporate donations seemed limitless. Because of this, the staffing and support model had a great deal of time to grow and evolve without the kinds of pressures, constraints, and scrutiny imposed by today's budget realities. This is not to say that early residential technology support at Stanford was a financially fat operation. But as the program showed successes in its early years, and as demand for residential technology resources grew, "breathing room" existed to help the program keep up with demand. Unlike many such programs springing up around the nation today, the residential technology support organization of Stanford's Residential Education of the mid to late 1980s had the luxury of time to create a new support paradigm with an eye towards student service, community support, and future growth. The Office of Residential Education, a student life operation with little to no technical experience or resources to draw upon, had created a cutting edge laboratory to nurture a new of kind of technology support.
When the financial axe fell in the early 1990s, and funding for technology in residences was on the chopping block, the Residential Computing program was well established and had shown its value as an integral part of Stanford's growing desktop computer support infrastructure. The program was spared serious cutbacks by those with the foresight to see that residential technology support was integral for the future.
Prior to our first computing use and ownership survey in the winter of 1989, one of our primary assumptions was that students more often than not acquired computers during their upper-class years, and that ownership among frosh was rather slim. Investment in personal computing technology was thought to be made as students progressed through their four years and came upon a need to own one, based on choice of a major, convenience, or whatever. In the mid to late 1980s this led us, perhaps mistakenly, to concentrate our residential computer lab efforts in frosh and four class houses, and to more or less ignore upper-class and graduate student living areas. The 1989 survey surprised us by showing that computer ownership among undergraduate students actually decreased with years at college, not vice-versa.
In hindsight this makes sense. At the time, extremely steep discounts were available through campus re-sellers on many popular brands of personal computers, especially Apple products. Even now, personal computer prices are at the lowest they have ever been, but the cost of owning a computer is still prohibitively high for some of our students. Surveys continue to indicate that the majority of students who decide to purchase a computer do so before arriving on campus or shortly thereafter. We are now led to believe that for the most part, students financially able to afford a computer wish to "hit the ground running" and not hold off on that computer purchase until later in their undergraduate career. These results have led Stanford to step up efforts to provide public, residential computer labs in upper-class/graduate housing. Houses with a large number of first year students are still provided additional cluster equipment in appreciation of the fact that there are many times throughout the quarter when large numbers of frosh tend to have assignments due simultaneously.
Stanford's most recent ownership survey (winter quarter, 1996/97) shows that 80% of frosh own a computer compared to 78% for upper- class students. While these figures are close, they still indicate that each class continues to bring with them greater numbers of systems. Computer ownership is increasing and so too the support needs, especially for frosh who typically require a little more "hand- holding" as they begin to explore the University's information technology environment.
Another trend we have been able to quantify is that students typically like to study and use computers in the evening and nighttime hours and not 8:00am to 5:00pm, Monday through Friday as we might prefer. Of course, anyone even remotely familiar with the ways of students could predict this. But it is still common for faculty and staff alike to mistakenly assume that students will alter their behavior to conform to limited resources or other inflexibilities. How often we have seen data, cable TV and telephone lines strung from one side of a student's room to the other because he or she decided that the bed should be on the left and the desk should be on the right even though the telecommunications office clearly envisioned the opposite, and installed the service outlets accordingly. The same is true with time management. Our students don't necessarily wish to use academic technology resources when we might like them to, and certainly not when professional staff prefer to provide support.
These days, an interesting indicator of student study and computer use habits can easily be obtained from software usage logs, available to those running network licensing packages like KeyServer. Figure 1 shows the number of copies of Microsoft Word in use in Stanford's residential clusters per hour during a typical student work week. It's no surprise that activity appears to peak at about midnight on weekdays, with daytime peaks usually only occurring on the weekends. Almost every software use log from almost every week of the year shows this same trend (although during finals week things get a little chaotic). The hours around midnight seems to be when the majority of our students are at their most active with respect to studying. Obviously, this is also when they will be in most need of technology consulting resources.
Stanford activated its first residential network in 1988, allowing over 700 graduate students in the then new Rains Graduate Apartment complex access to in the Internet. Since then, the demand for this service has steadily grown, and in the past three or four years has simply exploded. During the 1995/96 academic year 29% of the available network jacks were in use, and in 1996/97 that figure had risen to 45%. Today there are over 9000 in-room connection hook- ups in Stanford residences, and we expect that between 55% and 60% will be in use, totaling over 5,000 active connections. A large number of these connected students will require some sort of technical assistance.
The bottom line is that demand for technology continues to grow at an intensely rapid rate and with it grow the demands on our support infrastructures. The burden is quickly becoming too great for antiquated notions like fully centralized "help desks." Many institutions are turning to distributed, live-in, support models to handle this growth.
RCCs are typically students in their junior, senior, co-terminal or graduate years. A very small percentage of sophomores are also selected to be RCCs. The prerequisites to apply for a position include completion of, or active enrollment in, Stanford's "Introduction to MicroComputer Consulting" course, or its equivalent. This two unit pass/no credit course is also sponsored by the Computer Science department and provides candidates with some basic skills to prepare them for the RCC position.
While a number of Stanford's finest Resident Computer Coordinators have hailed from liberal arts academic backgrounds (English, history, political science and geology to name a few) the vast majority come out of technical programs, most notably Electrical Engineering, Computer Science, Computer Science Engineering, and Symbolic Systems. In fact over 60% of all applicants for the 1997/98 RCC position are pursuing degree programs in these fields. This past spring over 130 students applied for 65 positions, making it the most competitive application process of all residence positions.
There is, however, a marked lack of female applicants for the RCC position. This disturbing trend has continued despite great recruiting effort. Interest has been barely creeping up over time, and there have even been unexplained setbacks from year to year. Our hope has always been that as more female RCCs are present in the dorms, and especially in houses with frosh, they will serve as role models to spur interest among new female recruits.
Stanford's Residential Computing central office is not an end-user support organization. It is a Resident Computer Coordinator support organization. All energy and resources go into assuring that the right students are selected for the jobs, that they are properly trained at the beginning of fall quarter and supported throughout the year, and that the hardware and software they manage is up-to-date and repaired or replaced in a timely manner.
This has become a year-round process: Summer is the time to plan for RCC training, and to implement upgrades to cluster equipment, one-third of which is turned over every year. RCCs arrive about two weeks before the start of fall quarter for intensiv e training in network and desktop support and to prepare their clusters for opening. For RCCs who support frosh, New Student Orientation weekend is full of activity to help first year students get to know Stanford's computing environment. The first weeks of fall see the greatest amount of activity with respect to in-room network connections, and require a heightened level of back-up for rookie RCCs getting their feet wet for the first time. Winter quarter is the time when staff evaluations, filled out by the residents, provide feedback on how well the RCCs are performing, input that is then anonymously shared with RCCs during one-on-one evaluations. The graduate RCC selection process is also carried out during the winter. The undergraduate RCC selection process occurs during spring quarter and takes a great deal of staff time to run smoothly and successfully.
Fortunately, the RCC group as a whole tends to be self-supporting. With 63 technically savvy and highly motivated individuals in the system, seldom is a question raised by one that can't be answered by others. An RCC newsgroup and mailing list allow for free-flowing sharing of information within the group.
As is typical with most such programs, Wellesley's DormNet support was envisioned and developed from within the College's Infor mation Services group, as opposed to residential life/student affairs. For many information systems professionals, especially those with "Computing Command Center" leanings (and you know who you are), the notion of empowering students to deliver network and desktop support services in an unstructured, decentralized environment can be somewhat frightening. In the fall of 1993 the College implemented a highly successful 43 student pilot roll-out of in-room network connections in six dorms and administered this pilot utilizing existing Information Systems personnel. But the experience of Wellesley IS staff during this limited experiment convinced them that a distributed student-based support model was worth a try.
Wellesley's Information Systems group faced a number of challenges during this pilot. One of these was communicating with students in the pilot, whose schedules proved to be very different from that of the professional staff. Delays in replies and seemingly endless games of phone tag meant that simple problems took days to resolve. Also staff didn't feel comfortable making house calls, and there was a great deal of concern for the liability involved with student room visits. Because Wellesley is an all women's college, and for safety and security reasons any visitor is required to have an escort while they are in the dorms. This restriction made trouble calls to the dorms just that much more time consuming and difficult to arrange. Support staff also learned that students involved with the pilot were much more willing to cooperate once they had developed a relationship with the individuals providing service.
By the fall of 1994 Wellesley's first student DormNet Consultants (DNCs) were on the job. Though the Wellesley program was developed seven years later than Stanford's, they share a number of commonalties. DNCs, like RCCs, live in the house where they provide support, or within a local geographic neighborhood of smaller houses, at an average ratio of about 1 DNC per 125 students. DNCs are trained to deal with almost any technology-related issue, although problems related to network connectivity take priority. They also manage computer clusters which are available in each dormitory. About 80 percent of Wellesley's 2,300 students own a computer, and it is estimated that about 75% of the 2,100 housed students are currently connecting to DormNet.
But Wellesley is a very different place from Stanford, and developed its program at a time when budgets in higher education nationwide were tightening. It was also necessary for the college to develop its program much more quickly, without the luxury of time that the Stanford program enjoyed. While Wellesley looked to Stanford's mature RCC program for some of the answers, alterations to the basic model were required to help it fit better into the College's residential and information technology support environment.
As a smaller college, and with the realities of limited institutional resources in the 1990's, Wellesley required that support for DNCs be provided with little additional staff. A strong support structure had already been built for students as well as faculty and staff, so the college looked for ways to maximize its existing infrastructure.
The solution lay in leveraging off of existing staff and providing hooks for that staff to keep involved with the DNCs and to stay in touch with their needs. The DNC Bulletin System was created which, like Stanford's RCC newsgroup, provided a mechanism for DNCs to communicate problems and issues and provide support for each other. The Wellesley approach ensured that IS staff throughout the organization kept abreast of the discussion on this forum, and were able to intervene when necessary to help solve lingering or difficult issues. At Stanford only the staff of Residential Computing is required to monitor the RCC newsgroups and email lists. If help from another University organization is required, that is typically mediated by ResComp staff.
Wellesley is an all-women, undergraduate, liberal arts college without any engineering degree programs. Because of this lack of technical programs, and perhaps compounded by the general difficulty recruiting women for these sorts of positions, the pool of candidates for DNCs is relatively small. Approximately 25 students typically apply for 18 positions. In addition, Wellesley's existing centralized support structure for faculty, staff and off-campus students utilizes a great deal of this available student consulting talent, and it is important for the college's information services group not to steal from one area to support another.
Fortunately, Wellesley College has discovered, with great relief, that an unexpectedly large percentage of the available candidates for DNC positions turn out to be highly qualified for the job. This is not unusual. At Stanford, the same is true even with its higher candidate yield. Out of the 120 to 130 students who apply, upwards of 90 are typically identified as exceptionally qualified individuals, far more than there are available positions.
A curious difference, though, is that Wellesley sees a higher percentage of returning DNCs than Stanford. This year fully half of Wellesley's DNCs are returning to the position. Stanford typically sees only about a 20% return rate. Obviously, a greater number of returning applicants means that fewer DNCs need to be trained from scratch for the job. It also allows the college to leverage off of a greater number of returning students to help with fall training and provide general back-up and mentoring for the rookie DNCs.
Although a centralized, Command Center-like, support model may feel comfortable to many, and has enjoyed some success in faculty and staff arenas, it has little hope of keeping up with the explosion of activity among our students. Such "monuments of the past" offer little more than delay and inconvenience for students of today's "wired" residential colleges and universities. Programs like Stanford's and Wellesley's provide flexible, responsive, and convenient support at reduced cost to the institution.
![[Comments]](/g/comments.gif){kind=small}
![[Search]](/g/search.gif){kind=small}
![[Home]](/g/home.gif){kind=small}