U-VIEW: Student Access to Information Using ATMs Copyright 1990 CAUSE From _CAUSE/EFFECT_ Volume 13, Number 4, Winter 1990. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its dateappear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu U-VIEW: STUDENT ACCESS TO INFORMATION USING ATMs by John J. Springfield ************************************************************************ John J. Springfield is a Technical Support Programmer in the MIS department of Boston College, with over seventeen years' experience in designing and programming business and university applications on mainframes, minis, and personal computers. He has conducted seminars on CICS, ATMs, PC spreadsheets, and programming languages, has written a nationally-distributed program running on personal computers, and was awarded the "best paper" award at the 1990 CUMREC conference. His current interests include developing intuitive ways for people to access computers. He holds a bachelor's degree in mathematics from Oakland University. ************************************************************************ ABSTRACT: U-VIEW is a system at Boston College which allows students to display and print their campus records at automated teller machines (ATMs) located throughout the university. This article describes the evolution of the system from terminals with magnetic-stripe readers to ATMs, how the current system works, human factors that affected the system's design and operation, shared responsibility for the system, campus acceptance, and future enhancements. A cost/benefit analysis is included. Two and a half years ago, Boston College embarked on a long-range project, known as "Project Glasnost," to open up the campus information systems to the entire community. Our Management Information Systems (MIS) department was challenged to find ways to expand access to the mainframe without sacrificing security standards. This is the story of our novel approach to providing students access to their records. An old idea, a new idea The idea of distributing computer access to user departments is not new. However, if we expand the term "user" to include the student (the true "end user" in an academic environment), we are challenged with a whole set of issues. How do we guarantee security? What hours should access be allowed? What kind of devices should be used? Should the devices be located in hallways, dorms, or kiosks? Should full-page printouts be available? Should the new service complement or replace existing departmental access? At Boston College we concluded that we needed a device that could read encoded ID cards, was intuitive to use, had a built-in printer, and was rugged enough to resist abuse. In short, we needed an ATM (automated teller machine) with a printer instead of a cash dispenser. But before we arrived at this conclusion, we tried using terminals with magnetic- stripe readers. False start After reading an article about a system at Indiana State University that allowed students read-access to their records,[1] in the spring of 1988 we set up terminals with attached mag-stripe readers in three high- traffic locations at Boston College: outside the registrar's office, inside the library, and next to the cashier windows. Since students already had encoded ID cards, we did not have to set up new administrative procedures. By late summer of 1988, students were using a system we called U- VIEW at these single- purpose terminals. U-VIEW was a menu-driven series of screens that allowed students to view their courses, grades, loans, accounts, financial aid, addresses, and other personal information. U- VIEW was easy to use: a student simply slid an ID card through the card reader and supplied a birth date for access. It was an instant hit with both students and administrators. There were problems with this approach, however. Specifically: * Some students inadvertently locked the keyboards by pressing cursor and other keys. A standard refrain emanating from the registrar's office was, "Hit the reset key!" Clearly, the standard keyboard was too complicated. All we needed was a simple numeric keypad and a few function keys. * It became apparent that most students wanted and needed a printout. Long lines were being created because students were copying information from the screen to paper. * Because the terminals and card readers sometimes confused students, there had to be a staff person in a nearby office to help them. It was obvious that these devices were not self-sufficient enough to be left unattended. * Terminals had to be secured at night because they were not designed to resist abuse or theft. * Although the system could detect anyone with an old or stolen ID card, we had no way to automatically retain the card. Experimenting with an ATM By the fall of 1988 it was clear that we needed a device that looked and acted like a bank ATM. However, there was one main difference. We needed an ATM with a built-in 80-column printer instead of a cash dispenser. Students were used to using bank ATMs on and off campus. If we could find an ATM with a built-in printer, we were sure we could solve our problems. But did such a device exist? After contacting NCR and Diebold, we discovered that Diebold had a model 1060 "Everywhere Teller Machine." It was exactly what we needed! It had a 20-by-40 column display screen, a numeric keypad, four function keys, and an 80-column printer. But could we communicate with it via our telecommunications software, VTAM and CICS? It supported SNA/SDLC protocol, but the vendor had not heard of anyone connecting it in the manner we proposed. After we secured a loaner ATM and manuals from Diebold, we were on our own. When we received the ATM in December of 1988, our first and biggest task was to see if we could talk to it. After some trial and error we found that we could! We described the ATM to our system as a control unit with a logically attached terminal. To CICS it was set up as a 3600 device. Within a month we had CICS talking to the ATM. After that we retrofitted our existing U-VIEW application to work on the Diebold ATM. By February 1989 we went live and became the first college in the country -- probably in the world -- to use an ATM to dispense student information. U-VIEW on the ATM The ATM is left powered up at all times except for periodic maintenance. When it is first powered up, a CICS transaction sends a series of "states" and "screens" to the ATM. These states and screens allow the ATM to have limited functions even when CICS is subsequently brought down. Without accessing CICS the ATM can handle menu navigation, timeouts, and incorrectly inserted cards. But once a student requests data, the ATM sends a message to a CICS transaction and waits for a response. Response time is fast when displaying data. Printing data takes longer because of the relatively slow printer. All access is recorded on a log file on the mainframe. The first screen appears as in Exhibit 1. [EXHIBIT 1 NOT AVAILABLE IN ASCII TEXT VERSION] The card is read by the ATM and verified as an active BC student ID card. If it has been reported stolen, it is kept by the ATM and reported to the security administrator. It is important to note that all cards are kept by the machine until the student is finished. At the end of a session, the card is partially released to allow the student to retrieve it. If the student walks away, the card is retained by the ATM in an internal box. Immediately after the card is retrieved or retained, the ATM is available to accept the next student ID card. After the card is inserted, the personal identification number (PIN) must be entered. If incorrectly entered, the student is allowed two more tries. The card is rejected after the third incorrect attempt, and the security administrator is notified. If the student continues to reinsert the card and enter an incorrect PIN, the card is retained after nine tries. Again, the security administrator is notified. Once the student is allowed entry to U-VIEW, the main-menu screen appears (see photo next page). Various sub-menus and screens showing the desired information follow the main-menu screen. All navigation is done by pressing one of four function keys. Each non-menu screen allows the student to press a function key to print the data on the built-in printer. Since the screen is only 40 characters wide, the printout usually has more detailed information than the screen. Exhibit 2 illustrates an example of a present semester course screen. Note that the last three lines of each non-menu screen have the options to print, make another selection, or quit. For security reasons student IDs or names never appear on screens and printouts. [EXHIBIT NOT AVAILABLE IN ASCII TEXT VERSION] By selecting various options at each menu, students are allowed to view, print, and request the following personal information: * Home, local, and parent addresses * Important messages * Last semester courses and grades * Present semester courses and exam schedule * Next semester courses * Advisor and registration appointment time * Student account * Financial aid * Student loans * Vehicle parking permits * Request degree audit (printed overnight) Human factors Even though jumping the technological hurdles was personally exciting, it is the human factors of the experience that have been and continue to be challenging. Students respond well to the simple keyboard and familiarity of an ATM. We tried to mimic the human/machine interaction of a bank ATM wherever possible. However, there are still some human factor problems that do not offer an easy solution. Our first problem centered around the printing of information. Should we automatically dispense each printout after each selection, or should we wait until the student ends the session? Even though it wastes paper, we found that people want a printout immediately after they press the print function key. So we form feed the paper out of the machine as soon as possible. Another consideration is the length of time that is allowed to view a screen or answer a question. If we do not allow sufficient time to read all the information (say 25 seconds), we frustrate the user. However, if a too-long response time is allowed, users may walk off without taking their cards. After the first year of use, we found we could predict the most requested selection based upon the time of year and student status. We also realized that virtually all students want a printout of the selection information. So we customized the main menu to put the most likely selection at the top of the list. Instead of going through two menus to reach the selection and then pressing the "PRINT" button, students now had only to push one button. This was not only easier for students, but it also cut down on long lines during heavy action periods. Shared administration of U-VIEW To make U-VIEW work successfully it was imperative that key departments be involved in overseeing it. We were fortunate to have most of the pieces in place before the project began. * The ID card is issued by the campus police. If a card is stolen or lost the campus police investigate and reissue cards. Cards that are retained by the ATMs are turned over to the police on a daily basis. * MIS handles the programming, the computer center manages and maintains the ATMs, and network services maintains the connections and checks daily for worn-out ribbons and lack of paper. * The security administrator monitors an online log of U-VIEW access. Students are notified if there has been suspicious use of their cards. Statistics are kept on daily and monthly usage. * The registrar and other offices suggest improvements to current features as well the need for new options. Acceptance of the ATM From the beginning the ATM was a success. Typical student comments were, "Gee, why didn't we do this years ago?" and "This sure beats standing in lines!" The registrar's and student account offices noticed a big decrease in the number of student phone calls and visits. The registrar noticed that students used U-VIEW heavily during three periods: (1) after drop/add to print updated schedules, (2) before exams to print exam schedules, and (3) at the end of the semester to print grades. Other administrators have noticed that students often bring U- VIEW printouts with them when they need to discuss an account balance, a student loan check, or address change. Table 1 shows the U-VIEW usage in 1989-90. Boston College has about 8,500 undergraduates, the primary users of U-VIEW. On slow weekdays about 100 students use the machines. Busy days will show over 900 students. [TABLE NOT AVAILABLE IN ASCII TEXT VERSION] We expect usage to increase as we add more capabilities. We are purposely keeping the functions static until we have more ATMs; we do not want to reduce lines in an office by creating lines to the ATMs! Cost/benefit analysis U-VIEW was never meant to be entirely justified by "saving costs." Rather, its purpose was to improve student life, improve student/staff communication, and to make information more accessible. However, let's assume that the 40,000 visits per year to the ATMs reduce the amount of "traffic" to administrative offices by 12,000 visits per year (not all visits to the ATM would eliminate the need to see a person). Assuming that each visit is 10 minutes, 2,000 hours per year in staff time are saved. As you can see from the figures offered in Table 2, we estimate that the ATMs paid for themselves in the first year. [TABLE NOT AVAILABLE IN ASCII TEXT VERSION] Future enhancements Currently we have restricted U-VIEW usage to students, but perhaps we could open it up to faculty, staff, and alumni. More "messaging" facilities could be added. Some functions may require new machines with alpha keyboards, more function keys, or voice and video. Here are a few ideas for future use of the ATM: * The ATM could be used like a voting machine for student elections, ensuring that students only vote once. Voter turnout would increase, and results would be known immediately after polls closed. * Students could update their own addresses by choosing from a list of dorms or neighboring streets. (A free-form address would require an alpha keypad.) * Faculty and staff could be allowed to view their address and phone, payroll deductions, and so forth. Currently, anyone having access to a CICS terminal can view his or her records, but not all staff have access to a terminal. * Alumni could view their records, request theatre or sports tickets, or request information on current donation projects. Conclusion The ATM has proven to be an effective way to distribute information to students, free administrators of tedious tasks, and generally improve the quality of life at Boston College. Its greatest strengths over standard terminals are the ability to retain cards, ease of use, resistance to abuse, extended hours, and ability to print full-page information. ======================================================================== Footnote 1 David Ridenour, "Allowing Students Read-Access to Their Own Computer Records," CAUSE/EFFECT, March 1988, pp. 12-16. ========================================================================