The Reed Graphical Interface Project |-------------------------------------| | Paper presented at CAUSE92 | | December 1-4, 1992, Dallas, Texas | |-------------------------------------| THE REED GRAPHICAL INTERFACE PROJECT Martin Ringle, Director, Computing & Information Systems Heidi Schmedding, Project Specialist, Administrative Computing Reed College Portland, OR 97202 ABSTRACT During the past year, Reed College has begun development of a graphical user interface for its administrative computing system, using off-the- shelf software. Screens have been developed for use by vice-presidents, deans, department heads, and other staff members in a variety of offices, including admissions, students services, housing, registrar, business office, and campus events. This paper describes the Reed graphical interface environment and the ways in which it makes the administrative system more versatile, accessible, and cost-effective. The software technology used in the project is relatively inexpensive and portable, can run on both Macintosh and MS-DOS platforms, and is suitable for small colleges as well as large universities. ---------------------------------------------------------------------- Interfaces and Functionality When evaluating an administrative computing system it is often tempting to draw a sharp distinction between functionality and the end-user interface. In fact, however, the interface itself may be a key determinant of functionality. For example, if complex data can be retrieved and displayed easily then a system could be used during telephone conversations by personnel in admissions, student services, development, and so on. If such retrieval and display procedures are difficult to learn, cumbersome to make, or excessively time-consuming to complete, then the system would be inappropriate for this type of application, regardless of its other functional strengths. In essence, the interface either enables or constrains certain functional aspects of the system. In the case of an executive information system, the user interface plays a critical role. Unless an administrative system interface is easy to learn and easy to use, most decision-makers in higher education 行 from managers to presidents 行 will simply avoid using it. It is far easier to obtain information indirectly, from an administrative assistant or other staff member, than it is to wrestle with a complicated query language. The lack of an adequate interface is one of the key reasons that so many college officers prefer to obtain information "the old fashioned way," by relying on staff members, rather than going directly to the database. Taking note of this fact, many administrative software vendors have entertained the notion of adding graphical interfaces to their products but so far none has delivered such a package 行 at least not of the power or usability of the ordinary Macintosh or the Microsoft Windows interfaces. On the other hand, a number of third party software vendors have produced tools that make it extremely easy for colleges and universities to design, develop, and customize their own graphical interfaces with which to access commercial administrative systems. Establishing a GUI Development Environment As a small liberal arts college, Reed faces many challenges when it comes to providing the best possible administrative computing environment despite severe budgetary and staffing constraints. Daily decision support, as well as long-range planning, require that we make better use of our data-processing resources. In the past, decision- making at most levels has sometimes been hampered by our inability to provide precise, timely information directly to key administrators. Traditionally, requests for information from senior officers have been directed to administrative staff members who then search the database or generate reports; in many instances, those individuals are forced to call upon computing staff members to modify or prepare new routines to accommodate specific data retrieval requirements. With more and more emphasis being placed on staff size and staff efficiency, it makes little sense to preserve the traditional style of handling data requests when we have the technical capability of providing information directly to decision-makers. In searching for a commercial design tool for constructing an administrative computing graphical interface, Reed identified seven key requirements: --compatibility with a mainstream commercial package --compatibility with different desktop platforms, including Macintosh and MS-DOS pcs --compatibility with a range of database servers such as DEC, IBM, HP, SUN... --compatibility with a client/server environment --easy of use, minimal technical expertise requirement --rapid prototyping capability --low-cost The tool we acquired to meet these requirements was Oracle Card from Oracle, Inc. As a graphical interface development tool, Oracle Card is compatible with the Banner administrative computing package from the SCT Corporation. It runs equally well on Macintoshes and MS-DOS platforms and screens developed on one platform can be moved to the other in a matter of minutes. No software modification is necessary, except for screen re-sizing if monitor sizes are substantially different. It supports a wide variety of operating systems and hardware platforms, including those listed above, and functions well in a client/server environment. Most importantly, we have found that Oracle Card can be used with relatively little training. Once the development process has been mastered, new screens can be prototyped in a matter of days or even hours. The license cost is low enough to fit comfortably into a small college computing budget such as Reed's. The Reed GUI Project Reed is a private liberal arts college of 1,300 students, located in Portland, Oregon. It has approximately 140 faculty members and 240 staff members. Roughly half of the staff members require access to the administrative computing system to support their daily activities. Reed began development of the graphical interface by inviting senior administrators and administrative department heads to describe the types of information they use 行 or would like to be able to use 行 on a regular basis. After establishing some general guidelines for menu bar organization, the use of colors, etc., we began development of the twelve prototype screens listed in Table 1. Screen Name Office Users Admission Executive Query Form Admission Dean of Admission, Assoc. Dean Applicant Information Form Admission Dean of Admission, Assoc. Dean Applicant Status Report Admission Dean of Admission, Assoc. Dean Prospect Information Form Admission Dean of Admission, Assoc. Dean Campus Visit Form Admission Dean of Admission, Assoc. Dean Budget Information Report Business Controller, Vice Presidents, All Department Heads Financial Manager Report Business Controller, Assistant Controller Faculty Schedule Form Provost Provost, Associate Provost Room Scheduling Form Registrar Registrar, Campus Events Manager Student Transcript Form Registrar Registrar, Associate Registrar General Person Form Student Dean of Students, Assoc. Dean Services Student Schedule Form Student Dean of Students, Assoc. Dean Services Table 1 - Initial GUI Screen Development [MISSING FROM TEXT FILE] Screen Customization Our first goal was to use the graphical interface as a means of tailoring the retrieval and display capabilities of the system to the needs of specific users. Users often require information drawn from many different areas of the database. In a traditional administrative system, retrieving this information generally requires navigation through a hierarchical menu system in order to access a number of different inquiry screens. By selecting just the pieces of information required for a specific task, we can create a customized screen that is accessible by a single mouse-click from a pull-down menu. Figure 1 illustrates one of the eight ordinary Banner screens that would be used by an admissions officer to find out information about an applicant. To access these screens the staff member could either navigate through a series of 20 menu selections or move directly from one screen to another by entering seven-character identification codes such as SAAADMS, SPRIDEN or SRBRECR. Figure 1 - Standard Banner Admission Application Form [MISSING FROM TEXT FILE] Using the Reed graphical interface, a user could obtain all of the relevant information on an applicant by clicking on a pull-down menu, entering a name, and clicking on the FIND menu option. The graphical screen that would appear is illustrated in Figure 2. The ability to pull diverse pieces of information together into a composite screen and to access that screen quickly and easily means that admissions staff members 行 from counselors to the dean 行 can use the database themselves, rather than having to rely on data specialists for information retrieval. Direct access to information of this sort 行 especially during telephone conversations 行 improves the capacity of admissions officers to deal with applicants or prospective students on a more personal basis. Being able to navigate from one screen to another simply by clicking on named menu items not only increases the speed of access but it eliminates the need to memorize complex screen identification codes. Figure 2 - Reed GUI Applicant Information Screen [MISSING FROM TEXT FILE] Pop-Up Windows One of the more cumbersome features of current administrative systems is the number of steps required to obtain the list of codes or values that must be entered in order to execute a search. In cases where a user doesn't know the exact spelling of a name, the correct abbreviation for a country, the current number of a course, etc., he or she may be forced to leave the inquiry screen, search through a list of possible values on a second screen, re-enter the inquiry screen, and insert the relevant name or code. Although data specialists usually know many codes and abbreviations by heart, senior administrators or department heads, do not. Casual users such as these are unlikely to bother with a system that requires them to do a great deal of memorization or to undertake a complicated process for scanning lists and retrieving field value information. The Reed graphical interface eliminates both of these problems by allowing the user to click on any field and immediately see a pop-up window that contains a list of all the values that can be entered into that field. Clicking on a value will automatically transfer it to the inquiry screen and close the pop-up window. For example, Figure 3 illustrates a graphical room scheduling screen that can be used both for classes and extra-curricular events. In Figure 3, the user has clicked on the field marked "Bldg" to see a list of buildings that can be used as values for the location search parameter. In response to the click, a scrolling pop-up window has appeared, showing a list of every building on campus. Clicking on an item, such as the Asian Studies House, will cause it to be entered into the "Bldg" field of the inquiry screen. When all the search parameters have been entered, the user can select the "Find" option under the Queries pull- down menu and a list of possible locations will appear on the screen. Figure 3 - Room Scheduling with Pop-Up Windows [MISSING FROM TEXT FILE] Notice also a second pop-up window in Figure 3 at the right side of the screen. This is a standard pop-up "help" window that explains the different fields and terms on the query screen. For new staff members or staff members who are unfamiliar with a particular screen, pop-up windows help to clarify the function and use of a screen without leaving the screen to consult on-line documentation or a printed manual. Transferring Data to Desk-Top Utilities One of the more tedious tasks of working in a networked environment is transferring information from the mainframe database to a utility program, such as spreadsheet, running on a desktop microcomputer. Though the concept of downloading is easy for users to grasp, the sequence of steps required to perform this operation is often confusing and may require assistance by computer center personnel. In the Reed GUI environment, data that are retrieved from the server and displayed in one window can be moved to a utility in another window by simply selecting a transfer option from a pull-down menu. For example, suppose that the Dean wishes to examine faculty assignments and course load distribution using a spreadsheet. The graphical screen illustrated in Figure 4a displays the current course load for any faculty member, group of faculty, or an entire department. Once the Dean has selected the individual(s) or department(s) he or she wishes to review, a scrolling pop-up window displays the course assignment(s). Figure 4a illustrates the use of the screen to examine course assignments for members of the Biology department and Figure 4b shows the pull-down menu selection for transferring the data to the Excel spreadsheet. With only one click of the mouse, the data is automatically transferred to the spreadsheet where it can be printed, encapsulated in an electronic mail message, or used on-line for modelling or planning purposes. Any type of information that can be retrieved from the database, such as addresses, text, lists, etc., can similarly be transferred to utilities such as word processors or other packages. Figure 4a - Faculty Course Load [MISSING FROM TEXT FILE] Figure 4b - Data Transfer to a Spreadsheet [MISSING FROM TEXT FILE] Creating the template in a desktop utility to serve as the destination for a data transfer can be done by the user. Setting up a menu selection for the data transfer requires programmer intervention, but the amount of time is minimal, less than an hour on average. In some cases, transferring data to a spreadsheet is unnecessary. Oracle Card can perform several basic mathematical operations that can be used to generate statistical information such as list counts, percentages, and so forth. Some of the applicant screens that have been developed for the Admissions Office take advantage of these features to provide running tabs on the applicant pool during recruitment activities. Ad Hoc Inquiry and Reporting Perhaps the most important benefit of the graphical interface is that it allows senior administrators and other end-users to perform ad hoc queries themselves and to generate their own reports, without computer staff assistance. Although many administrative operations are repeated on a daily basis, a great number of queries and reports depend on novel circumstances that require ad hoc solutions. In traditional environments, ad hoc requests account for a significant amount of programmer activity. Enabling staff members 行 especially senior administrators 行 to perform their own ad hoc searches not only frees up programmer time, it serves to empower users and gives them greater control over their information-based decision-making. Having direct and convenient access to the database means that senior administrators can entertain different planning strategies, understand the details of problematic situations, and make more informed decisions than they would otherwise be able to do. With Oracle Card, we can provide administrators with the ability to select any combination of items from the database by means of pull-down menus. Selected items appear as fields on a blank "palette" screen where they may be ordered, sorted, and used as search parameters. For example, suppose that the Dean of Students is asked to arrange a Parent's Day panel discussion on undergraduate research projects related to the biomedical sciences. In order to select the panelists, the Dean may want a list of students majoring in biology, who are juniors or above, and who have grade point averages above 3.5. Selecting items such as first name, last name, major, class standing, and grade point average can be done by pulling down field menus, and clicking on the appropriate field. Figure 5 shows an ad hoc query screen of this sort being built. Once the screen has been built, search parameters may be entered using standard comparator symbols (e.g., >= for "greater than or equals"), wild cards, and so forth. For example, to designate a search parameter to identify students who are biology majors, the user would enter "= 'BIOL'" in the "Majr Code" field. As with all Reed GUI screens, user's can obtain a pop-up window with an explanation of a field or a list of possible field values by clicking in the appropriate place. Figure 5 - Building an Ad Hoc Query Screen [MISSING FROM TEXT FILE] Conclusion Computer professionals and end-users who are familiar with the graphical interface provided by the Macintosh or MS-Windows tend to find the features of the Reed administrative GUI environment anything but exciting. Being able to navigate with pull-down menus, obtaining help from pop-up windows, and so on, are facets of computing that they have come to take for granted. Indeed, the project is not revolutionary but rather evolutionary. It merely brings to the administrative computing environment the convenience and ease that users have already enjoyed for many years in the academic computing environment. Perhaps the only surprising aspect of this effort is that administrative software vendors have taken so long to recognize the benefits that a graphical front-end can provide for their clients. Among the most obvious benefits are these: --A vastly reduced learning curve for new staff members --Empowerment of end-users to control their own data needs --Direct access to database information by a new class of users --More efficient use of administrative computing staff time Despite the speed at which the Reed GUI Project is progressing, we are still in the early stages of exploring the full capacity of a graphical environment for administrative applications. Eventually, we expect to to use this technology to build Campus Wide Information Systems that can provide convenient access to a broad range of information sources for the entire college community. Given the cost-effectiveness, portability, and simplicity of current graphical interface tools, their use in administrative computing environments should become increasingly commonplace during the next few years. Appendix: The Reed Administrative Computing Environment The Reed administrative computing environment consists of a DECSystem 5500 database server running ULTRIX, the DEC implementation of the UNIX operating system. All administrative staff and officers of the College are provided with Apple Macintosh microcomputers. A client-server architecture is supported by a 10BaseT network that links the Macintoshes to the DECSystem. The TCP/IP protocol is used for network communication. Figure 6 illustrates the basic network design. Figure 6 - Reed's Administrative Computing Network [MISSING FROM TEXT FILE] Each Macintosh uses Versaterm for terminal emulation to access the standard Banner interface and Oracle Card for the graphical interface. Oracle's SQL*Net is used for TCP/IP communication between Oracle Card and the Oracle database on the server. The server runs the Banner Student, Finance, and Alumni/Development modules over the Oracle database engine. A migration of the database server to DEC's Alpha/OSF- 1 platform is scheduled for mid-1993. Acknowledgements, Shareware, and Further Information Reed College gratefully acknowledges the support of the Digital Equipment Corporation (DEC), the Systems and Computing Technology Corporation (SCT), and the Oracle Corporation for their support of the Reed Graphical Interface Project[1]. Reed College will provide its graphical interface screens to all SCT clients or prospective clients for free. For information, please contact Martin Ringle at: Reed College, 3203 SE Woodstock, Portland, OR, 97202-8199; Tel. 503-777-7254; Fax 503-777-7778; Internet E-mail: ringle@reed.edu. NOTE [1] The following terms used in this paper are registered trademarks: DECsystem 5500, Alpha, ULTRIX (DEC), Macintosh (Apple), Windows, Excel (Microsoft), Oracle, Oracle Card, SQL*Net (Oracle), Banner (SCT), Versaterm (Synergy Software).