1 / 53

Re-Inventing the Wheel: Building a Web-based Course Approval System

Re-Inventing the Wheel: Building a Web-based Course Approval System. University of California, Davis Keitha Hunter, Assistant Registrar kehunter@ucdavis.edu Christopher Blaise Redder, Information Architect cbredder@ucdavis.edu.

lexiss
Download Presentation

Re-Inventing the Wheel: Building a Web-based Course Approval System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Re-Inventing the Wheel:Building a Web-based Course Approval System University of California, Davis Keitha Hunter, Assistant Registrar kehunter@ucdavis.edu Christopher Blaise Redder, Information Architect cbredder@ucdavis.edu

  2. Located in Davis, California (pop. 55,000), about 15 miles from the state capitol, Sacramento, and about 70 miles from San Francisco Established in 1908 as the University Farm for students from UC Berkeley Current enrollment of approximately 26,000 students; 30,000+ by 2010 Operates on the quarter system UC Davis is . . .

  3. 3 Undergraduate Colleges 2 Undergraduate Divisions Graduate Studies 4 Professional Schools School of Medicine School of Law School of Veterinary Medicine Graduate School of Management UC Davis is . . .

  4. Courses • About 8000 active courses in the student information system • Courses approved and enacted year-round • Turnover averages around 10% per academic year (range=7-25%) • The approval process is based on a paper form and a series of review committees, which is different for each college, division, graduate program and professional school

  5. Existing Course Approval System • 30-year-old paper-based form and process • 5-part NCR form purchased in packets of 10 • Typewriters and white-out • Insufficient room on form to record course info • Insufficient information collection • Sole official copy travels by interdepartmental mail • Reviewers travel to a main office to review forms • Only one reviewer at a time can read the document

  6. 5 Copies: • Registrar’s (official record) • Academic Senate • Dean’s Office • Department (2)

  7. Room for Improvement • NCR cannot be recycled or erased/corrected • Departments must purchase NCR forms and supply photocopies of all documents for the college committees • Reviewers must hike across campus • Documents get lost, misplaced, worn out • Changes noted on one copy may not be transmitted to others

  8. Idea for Change • Use existing technology to build a Web-based Course Approval system • Computers—not typewriters • Cut-and-paste—not white-out • Electrons—little or no paper (save trees!) • E-mail—not memos and campus mail • Formalize process; no memos; synchronous records • Single, permanent, accessible archive

  9. How Did We Get into This Business? • A “logical” choice: Registrar’s Office is the office of record for courses • Publishes General Catalog, Class Schedule • Maintains Student Information System • Enthused professor in School of Veterinary Medicine pilots an approval system for their courses; urges Registrar to participate in/undertake the project • (Answer: no) • Interim Registrar pressured by Academic Senate and upper-level management • (Answer: yes)

  10. Volunteers Please Step Forward… • Catalog Editor • 7+ years in role; 8 catalogs produced already • Guest of Academic Senate Committee on Courses • Strong working relationships with those affected • Keeps paper records; maintains SIS • Programmer/Analyst • 5 years previous database design experience • 3 years in role; Web site manager • Web applications development experience

  11. Support ? — What’s That ?! • Two staff members “volunteered” • No other resources were allocated • No committees were formed • “Endorsed” by upper-level management • Inherited by current Registrars

  12. In the Beginning… • Catalog Editor’s charge: • “You know what I want; just go do it.” • No, I did not consult the end users • No, I did not consult management on design or requirements • Yes, I knew what I wanted to accomplish • Yes, I knew what the Academic Senate wanted

  13. Goals of Senate Courses Committee • Remote access • Eliminate travel around campus; no time restrictions for viewing; more than one member can view forms at any time; less paper and photocopying; screen projection in future • Better data: complete information on forms • Streamline review of Division of Biological Sciences • Guarantee of receiving mandatory Expanded Course Description (ECD) • Easier to edit • Public access to the approved courses

  14. Approach (Analysis) • All analysis and design is done by the Editor and the Programmer • Editor researches habits and procedures of departments and courses committees • Programmer designs freely, following Editor’s storyboard of form and routing designs • Duo collaborates frequently and informally on an as-needed basis

  15. Approach (Technological) • Develop in MS Access; deliver using Allaire’s Cold Fusion/NetObjects Fusion • These resources are available • Existing office Web site is NetObjects based • Programmer has high skill level in both • Database can be converted to Oracle later • Deliver through existing office Web server

  16. Functionalities • Platform independent • Users access on Mac or PC with Internet Explorer or Netscape from on or off campus • Field-based data collection in form • Validation tables used whenever possible • Automatic e-mail notifications of routing actions (receipt, rejection, approval) • Online status check • Archived courses database

  17. Features • Automatic “Save” and a “Saved” status to allow for work interruptions, etc. • Date stamps • Users can have multiple accounts, each at different levels • Printable course “form” (course summary) • Sortable lists of in-progress courses • Cut-and-paste capabilities • Viewing controls for committee meetings

  18. How Does It Work? • Routing is the key • Automates the approval process • Generates the e-mail • Routing is determined by • User information (level, department, and college) • The routing path for each college/school • The course level (whether undergraduate, 0-199; graduate, 200-399; or professional, 400-499) • User level controls access privileges

  19. User Levels • At the Department • Users • Chairs • At the Dean’s Office • College/Dean and a POC (point of contact) • At the Graduate and Academic Senate Cmte • College and a POC • At the Registrar’s Office • Editor • Administrator

  20. Basic Routing Pathways Each arrow is a “Submit” Department At the end of each arrow is an e-mail User Chair All Law and Professional Medicine Courses All Undergraduate Courses Editor (Registrar’s Office) College/School Point of Contact Graduate Group Courses Departmental Graduate Courses Archive Graduate Council Academic Senate COCI All Graduate Courses To dreams shared secretary

  21. Monday, 5/14/0110:15am, Track 5

  22. Monday, 5/14/0110:15am, Track 5

  23. Monday, 5/14/0110:15am, Track 5

  24. Monday, 5/14/0110:15am, Track 5

  25. Monday, 5/14/0110:15am, Track 5

  26. Monday, 5/14/0110:15am, Track 5

  27. Monday, 5/14/0110:15am, Track 5

  28. Monday, 5/14/0110:15am, Track 5

  29. Monday, 5/14/0110:15am, Track 5

  30. Monday, 5/14/0110:15am, Track 5

  31. Monday, 5/14/0110:15am, Track 5

  32. Monday, 5/14/0110:15am, Track 5

  33. Monday, 5/14/0110:15am, Track 5

  34. Monday, 5/14/0110:15am, Track 5

  35. Monday, 5/14/0110:15am, Track 5

  36. Decisions and Challenges • Serve broad community • System must accommodate everyone, but must not interfere with their internal processes • Security • Moderate log-in security to access system (content is not confidential) • Access within system is complex; control privileges for viewing, editing, deleting, routing, etc. • Distributed user management • Departments and colleges control their own users

  37. Development Timeline 1996 Paper-based system VetMed system in development Secretary in Engineering develops “soft” form (MS Word-based) 1997 VetMed professor demos pilot to Registrar, Editor Registrar departs; Interim Registrar Nov 1998 Editor specs form; prelim routing scheme First and only project planning meeting Routing system design begins Prog. 1st form draft Apr Jun Aug Oct

  38. Timeline 1999 400+ users signed on by end of Dec bugs, bugs, bugs… 200 users signed on by end of June Pilot roll-out; train POCs; send e-mail Mar July 2000 Create extract for pubs Senate complaints; chair turn-over, etc. Prioritize and select upgrades Release ver. 2.0 Aug Oct 2001 Open “Edit” to depts for forms at college; Continue VetMed accomodations Fix annotations; build admin privileges; improve “publications” extract, ETC. CUMREC Feb May

  39. Oops... • Started with too few pathways • Didn’t use program to separate courses going to Graduate vs. Academic Senate committees • Didn’t anticipate the problems of volume for POCs and their committees • queuing, sorting, date stamp, controlling meetings • Didn’t anticipate such immediate acceptance; couldn’t meet development demands • Controlling changes in users is complicated

  40. Measures of Success • 200 users on system within 3 months • 400 users on system within 8 months • No training offered or needed • One training session for POCs + 2 Senate members • One training session for Veterinary Medicine • Training session for School of Medicine • Unofficially adopted by Academic Senate Courses Committee in winter 2000 • Officially adopted by Academic Senate Courses Committee in February 2001

  41. Measures of Success • Paper forms disallowed in 2001 • Many kudos from users, especially after version “2.0” in October 2000 • No one wants to return to the paper system • As of May 2001 • 563 users with 630 accounts • 813 courses in the archive • 675 courses in the system currently • Almost no browser or server problems to date

  42. Some Things Never Change • Overall time frame for a course to reach full approval is minimally altered… • Routing and notification and corrections are easier, faster—BUT, • Approval itself depends on when the succession of committees actually meet, which is a moderate schedule that seldom includes the summer months

  43. What’s Still to Come • Develop a separate “Signatory” function • Improve the Course Summary printing (pdf ?) • Better navigation through pages in course lists • Restore privacy to annotations • Administrative reports and values access • Change to conform with campus log-on goals • Restore User Addition feature • Improve course “extract” for publications

  44. Status • A work in progress… • But still a fully adopted campus system • Phase 2 • Or… “If only I could get some money…” • Benefits for Registrar’s Office • Benefits for campus

  45. Goal One Central, Permanent, Accessible COURSE ARCHIVE

  46. Dreams • The course archive will feed: • Student Information System (Banner) • Degree Navigator (degree audit system) • General Catalog (hardcopy publication) • Web Catalog (Web-delivered catalog) • my.ucdavis.edu (campus Web portal) • why.ucdavis.edu (campus personalized recruitment site for enrolling students) • Web registration system and Class Schedule publication

  47. Archive • One place to enter, updated and store data • Stop re-keying course information 6 and 7 times • Use technology to “export” data to other locations • Real-time information available

  48. Recommendations • Allocate appropriate resources! • Funds, staff, time, tools, commitment, etc. • Create project team with members that know: • Technical development and delivery • Nature of the curriculum development process • SIS structure, functionality and maintenance • Diplomacy and the institutional culture

More Related