Everyone has a bias for certain technology based on his/her experience with or ownership of the product. Given that the Oregon University System (OUS) has license to the Oracle software and is using it extensively for Banner and other applications, using Oracle for the database is still the best choice we could have made. There may be other systems that use a more mainstream programming language that is more web-suited, but we've had no problems with database performance. Oracle tools and PL/SQL are very stable.

Database-based submission (exporting from a centralized pool of data): In order to develop a common searchable database to merge data from multiple campuses, ONE staff and our pilot institutions defined the standard of the file feed. It then becomes the responsibility of individual campuses to match that standard. This generally requires campus Information Technology staff to write a program to extract the data matching the ONE specifications. Once this program is operational, very little time is involved in any future data feeds. This is the most automated process of the three and should theoretically be the most trouble-free. However, we encountered difficulties because some campuses employ customized coding symbols that require stripping out to get clean data, and slight dissimilarities in data field definition caused inaccurate search results for a few campuses. Fixing these problems generally requires a one-time revision of the campus data extraction program.

Microsoft Access submissions: For campuses without a centralized database, we developed a Microsoft Access template to allow them to use a PC to get the data into a format from which they could export course data to the ONE database. Using the Microsoft Access template requires hand-entering (or cutting and pasting) data, so we expected that campuses would use it only if they had few courses to enter. However, we discovered that a few campuses with a centralized database and substantial numbers of courses used the Microsoft Access template in order to enable distance education staff rather than overworked technical staff to handle the data submission.

Course Edit Tool submissions: The Course Edit Tool was developed at campus request in Fall 2000 to enable campuses to individually correct inaccuracies in their course data without having to submit an entirely new data feed. Campuses with few courses to submit can also use the tool to submit course data into the database. Its drawback is that all data must be hand-entered. Since it is a web-based tool, however, it is easier for non-technical staff to use than the Microsoft Access template.

One issue is the technical expertise of the person(s) submitting the data. The ONE technical staff have never experienced problems when dealing directly with campus-based Information Technology personnel who understand data file protocol. Technical expertise among distance education staff, however, varies greatly among the campuses; for example, some had great difficulty using Microsoft Access and exporting files. When it is necessary for our technical staff to walk someone through the data submission process over the telephone, having personalized desktop set-ups or different versions of the Microsoft Access software complicates the process. It is much easier with the web-based Course Edit tool.

A minor difficulty is also caused when a few campuses submit their data completely in upper case (most use title and lower case). Since upper case fonts take more space, this results in course titles sometimes being truncated, which lowers readability. We recommend that campuses submit data in lower case or title case, but do not require it.

Hardware/Software. The advantage of using hardware and software that you are already maintaining for other applications is that adding one more application generally adds very little to the time or price of maintenance. Our server has sufficient capacity that a substantial increase in visitor traffic and courses in the database should not cause any problems in the future.

There are always systems administration concerns when you share server resources among multiple applications. Upgrade needs of another application may force you to go through the same data migration (with the resultant need to performance tune programs again) simply because you are sharing the same machine. We do have a development machine to test out new programs/routines, but that doesn't mean that when a program is migrated to the production server that it will be trouble-free, since it now has to operate in a different environment because of the other applications on the server.

Technical Staffing. Developing and testing the database and the Course Edit Tool, adding user statistics compilation, assisting campuses in the data submission procedure, and optimizing the database required approximately 1,200 hours of technical staff time over the two-year period. Additional programming or changes to the database will require substantial technical staff time, partly because any major changes to the database, generally requires re-beta-testing the entire site since a major change will affect many subroutines. A major change for 2001 will be the addition of key word search capability. We will also be adding a program to track user exits to be able to report ONE-generated traffic to our participating institutions. As campus program staff become more familiar with the Microsoft Access and Course Edit tools, they will require less assistance, which will lessen our technical staff responsibilities. We expect to spend approximately 350 hours of technical staff time this year to develop a key word search and an exit-tracking tool, and to provide routine technical support for ONE.

Related Staffing. ONE program staff and the ONE Steering Committee with input from Information Technology Services determined data elements, search categories, timelines, and conducted an evaluation of the prototype site. ONE program staff also developed the content of support pages and created more than 80 informational static web pages.

• We are using two servers: one for the database and one for the static web pages, so there are subroutines that we had to write to integrate the two for user results. Generating usage statistics or checking log files also requires information in the database to be merged and then presented on the other server, so we had to write routines for this.
• We asked campuses to submit their course data to us at the same time as they must submit it for their campus schedule in order to ensure that courses for upcoming term(s) would be available.
• We also made a decision to "age" course data on four dates throughout the year so that no courses older than the previous term will be actively displayed (although the data remains until supplanted so that a campus can update a course using the Course Edit tool).
• We use linkbot software monthly to search for broken links, which are then repaired or removed.
• ONE staff keep track of information that needs periodic updating (e.g., campus calendars) and ask campuses to provide this and any updates of campus or program information on the ONE website. Every six months we also examine all static pages for out-of-date information.

Our database analysts examined the database parameters and made some changes that nearly halved search time. It is good practice to have a database analyst examine the database approximately twice a year to keep it running as fast as possible (size of the data packets, how the data are growing, where you're putting the data, estimating/forecasting growth, etc.).

A planned key word search tool will offer the user the option of searching by course designator or course number, which is currently unavailable. It will also offer an alternative to the format of the five course searches ONE is now using.

Oracle databases are always active, so we must back up the information nightly in order to have an accurate record for restoration purposes. The database that OregonONE shares with many other OUS projects is backed-up from 2:00 a.m. to 4:00 a.m. six nights a week. While this happens, users trying to access the database will receive a message informing them that the server is being backed-up and when it will be online again. This only affects the dynamic database; the server with the static web pages is still accessible.

One aspect of our beta-testing of the prototype ONE site was to have faculty, staff, and students from participating campuses fill out a survey form evaluating the website for ease and effectiveness of course and program searches. We also asked for input on attractiveness, navigability, ease of use, information included, etc. We used this feedback to redesign various details in the database and website prior to and immediately after going public on March 27, 2000. Since that time, we have received numerous positive comments from users. The only negative feedback resulted from inaccurate subject searches caused by a few campuses using non-standard data field definitions.

Two improvements have been requested by campuses: a Course Edit tool (instituted December 2000), and a Key Word Search (planned for implementation in 2001).

A database is an ideal tool for generating data to support research, though you may need a program specifying which data you want and how you want it displayed. ONE is already tracking user statistics at http://OregonONE.org/stats.html. In 2001, we will add a program to track exits so that we can report ONE-generated traffic to participating institutions.

OregonONE supports searches by institution, subject area, level of study, delivery method, and term for courses and subject, institution, and degree level for degrees. To do a gap analysis of courses, you would have to choose the desired subject area (+ other delimiters if desired), and then examine the output to see which required/desired courses are unavailable. So, you can use the database for the search, but the individual must make the analysis.

The Microsoft Access template is not very user-friendly, and now that we have the Course Edit tool, we probably don't need it. However, developing procedures for data feeds (both database and Microsoft Access) benefited the development of the Course Edit tool, so it was a necessary but currently redundant step. Eventually we will probably drop the Microsoft Access template because it is complicated and support must be updated with each version of Microsoft Access.

Adding informational content about online and distance learning, distance education pedagogy, instructional design tips, articles about lessons learned, "how-to" handbooks, etc., will not affect the database at all since these are static pages. Reworking the homepage by a graphic designer, however, may be necessary.

If ONE decides to host faculty discussion forums, set up a listserv, or provide an interface to display exemplary courses for other faculty to examine, that would require necessary software, but it still would not affect the database. If ONE wanted to catalog the articles, threaded discussions, etc., and make them key word searchable, this would add a major piece to the database and would require extensive programming.

Any time you want to merge data from two or more databases, you need prior agreement on specific data standards and parameters. Unless a regional consortia decided to adopt ONE data and field standards for the database, we would have to modify our data for a feed into a regional database. It would be a major project.

We had hoped to register OregonONE as ".edu" because ONE represents the courses and programs of many colleges/universities. Since ONE does not actually issue degrees, however, we were denied the use of ".edu" and consequently chose ".org".

Once we decided on the domain name OregonONE.org, we needed to affirm that no one else was using that name and then apply to one of many domain registrars (we used Network Solutions) to register the name. Fees for registration vary depending on the registrar; Network Solutions charges $70 for every two years to keep the registration current.