Student 2

This Summer we are working on an updated version of the college's student advising database STEP. Project name while in development is "Student 2". The major outcomes of this update are:

Structure data like UW student data so that updates can run automatically and be scheduled nightly.
Provide reports about student activity that highlight when students need attention.
Integrate with Appreview and provide access to meaningful application material.
Restructure student groups to allow student to be part of multiple cohorts and other groups.
Provide access to test score data through Student 2. Use this better for teacher certification.
Refine Milestone system to make it configurable for more progams.
Refine Placement data to support state reporting requirements.
Decouple system from old and unsupported code frameworks.
Clean up system visually and make more mobile friendly.

Data Structure

In our existing system, STEP, we have tried to group student work over time into a single record of a program the student is in and degree being pursued. Conceptually this makes a lot of sense. However the UW student data doesn't group student work over time this way. The UW data tracks what a student's major and degree was in any given quarter.

When a student's major or degree changed we would manually update those records in STEP to keep the related quarters together. Sometimes this logic was routine other times it was unique to a student. When we update the student data each quarter, historical data is left as is and new data has to be massaged to fit the system. This takes some manual effort and prevents us from updating more frequently.

Instead of coding the years of manual massaging (we tried and realized it was a sisyphean task) we are adopting the UW student data model. We will be able to tell you the program a student is in now. If you need it, you will be able to see what a student's major and degree was quarter by quarter.

We think this will get us the answers we want in almost all cases. What is the student's current (or latest) major and degree?

But most importantly, by adopting this model we can automate the import of UW student data, update daily, and keep Student 2 fresh and accurate.

Apply

"Apply" is a new web application for the College of Education that will allow potential students to apply to our programs. The applications they submit in Apply will be visible and reviewable in Appreview.

Currently the only applications we have available in Appreview are graduate applications. Graduate applicants complete their applications through the UW Graduate School's MyGrad web application. We then import the data into our Appreview system using a web service. For graduates, the apply interface that the applicant uses is operated by the Grad School.

We would like to have all of our applications available and reviewable in on place so COE faculty and staff can interact with a single applicant review system. Our Early Childhood and Family Studies undergraduate program is the first program we are adding to the graduate focused Appreview.

So "Apply" is the applicant facing side of "Appreview", initally for ECFS applicants.

New and Improved Applicant Review!

The College's new and improved Applicant Review is now online at:

https://education.uw.edu/a/appreview/

We've worked hard to design an interface that's similar to the other College information systems and easily navigated. A couple things to note:

Historical admissions data starting with Autumn 2014 and moving forward will be accessible
You can filter down to a set of applications by year, term, program, degree, decision, and advisor similar to how you use the filters in the Courses database
Check out the "My Applicants" link: https://education.uw.edu/a/appreview/my-applications for a view of your applications

Stay tuned for up coming brief demonstrations and training videos we'll post on the Canvas Information System Training Site: https://canvas.uw.edu/courses/864904

Next up? We are working with the CoE Undergraduate team to add undergraduate program application data to the system. We're planning to have this addition in place by March!

Educ: Unified Application Infrastructure

The College of Education has somewhere between nine and a dozen (depends how you count them) distinct information system applications.

Building these applications separately had some advantages. It kept the domain logic specific, gave a clear context to design decisions, prevented cross system bugs, and let us keep iterating on and improving our framework. But it has gotten to the point where the technical debt of maintaining those multiple systems is impacting our ability to deliver new functionality.

Going forward our plan is to have a shared infrastructure that we implement new applications in and when the opportunity arises fold the existing applications into the shared framework. We are calling the new unified application infrastructure "Educ" since it will potentially house all College of Education information systems. The new Person and Budget databases are built in Educ and Appreview Plus project includes migrating SOARS to the shared framework.

Within the Educ project we create "contexts" so the single application and database under the hood can still appear as distinct systems on the surface. Switching "contexts" between Person and Budget and Appreview gives you different titles, menus, and search scopes. It looks like you are switching applications, but you are navigating between sections.

Educ uses Laravel which is a robust, popular, and high performance PHP framework. Educ has a shared person repository which allows greater consistency of data and easier sharing of information across contexts.

Appreview Plus

Our existing online applicant review system (SOARS) was built as a view on top of the live Graduate School application data. When you look at the detail page of an applicant in SOARS, a big chunk of what you see gets queried real time from MyGrad. This met the original specifications and has the nice advantage of being up-to-date and authoritative, but it has several downsides.

If Graduate Service goes down, SOARS goes down
The only applications we can have in SOARS are ones that come from the Graduate School
Once the Graduate School stops making applicant data available through the web service, it disappears completely in SOARS

To address these issues we have decided to build Appreview Plus. Appreview Plus will operate like SOARS feature for feature. But it will store application data locally and the application data will be structured for College of Education needs. For graduate applications the data will still map back to the Graduate School and get updated from their web service. But it will not be a requirement for there to be Graduate School data for our system to have data. This decoupling allows

Continue to view old application data (e.g. for current students) after MyGrad application is removed
Have local applications included side by side with MyGrad applications (e.g. existing students who change programs or continue on to additional degrees)
Able to handle applications from students that don’t apply through Graduate School (e.g. ECFS)

While we are restructuring data to exist as local application records we are also restructuring to better integrate the data with other systems. This offers many potential benefits, two big ones include

Inclusion of application data in student data views (e.g. Statement of Purpose, previous degrees, contingencies visible in STEP).
Shared storage of Person records simplifies administration and reporting.

This is a big project we want to do thoughtfully over the Summer (2015). This means reviewing existing system with SME’s and thoroughly reviewing existing code and database so we protect current capabilities while implanting the new features.

Ticket First

Our initial requirement for the Business Operations database (Bizops) was to implement an electronic version of the travel form. This was a complex process that frequently required back and forth revision so it was identified by the college process improvement group as a first place to focus.

The Bizops system was built using code from the Help Desk ticket system which contained many useful entities like Tickets (a project or task) a requestor, a person responsible for completing the work, a collection of messages related to the ticket, etc.

As we talked with the fiscal team we became concerned that Bizops: Travel Form might be another disjointed collection of tasks to keep track of. If some work is listed in email, some is in one-of-three excel sheets, some is in the shared drive, some is on a post-it, and now some are in the Bizops: Travel Form, it can be messy.

“Ticket First” represents our plan to surface the Ticket concepts and user interface from the existing Help Desk code so that Bizops can be a repository for any request, any task, not just Travel Forms.

Travel Forms now become an extra artifact related to the ticket. The ticket structure provides the context for who the requester is, who the staff responsible is, and what messages went back and forth about this particular travel form.

Ultimately it will be up to the fiscal team to decide if Bizops tickets helps them track work and share information.

Business Operations Ticket System

The Business Operations Ticket system is will be available to faculty, students, and staff of the UW College of Education. If you should have access to this system contact the COE Help Desk.

Website URL: https://education.uw.edu/businessoperations/pub/

Purpose

The client interface of the College’s Business Operations Ticket system and allows faculty, students, and staff of the UW College of Education to make fiscal business operations requests (currently only travel authorization and reimbursement requests). The portal allows users to see their open and resolved tickets and add additional information.

The business office interface provide ticket administration ability including reporting. It is currently under development and is expected to be available to users starting spring 2015.

Features

Support ticket creation and tracking.

Users

All COE faculty, students, staff – best way to request travel support
COE fiscal staff for managing support, sharing information on cases

Tech Support

The Tech Support Ticket system is available to faculty, students, and staff of the UW College of Education. If you should have access to this system contact the COE Help Desk.

Website URL: https://education.uw.edu/techsupport/

Purpose

The client interface of the Tech Support Ticket system allows faculty, students, and staff of the UW College of Education to make technology support requests and equipment reservation requests. The portal allows users to see their open and resolved tickets and add additional information.

The Tech office interface provide ticket administration ability including reporting. It also features an equipment database, a reservation search & availability system and and online checklist for classroom technology review.

Features

Support ticket creation and tracking.
Equipment database and equipment reservation system.
Classroom technology checklist.

Users

All COE faculty, students, staff – best way to request help desk support
COE tech staff for managing support, sharing information on cases, managing equipment reservations

Students

The Student database (STEP) is a student advising tool available to faculty and staff in the College of Education. If you need access to this system, contact the COE Help Desk.

Website URL: https://education.uw.edu/step/

Purpose

The student database supports College of Education program operations such as advising and reporting on current (and past) students in the college. STEP is the authoritative record of student, practicum placement data (student teaching, practicum, internships), OSPI certification, and advisor relationships. STEP also keeps track of doctoral student degree milestones. We utilize authoritative data sources where possible in STEP, example student lists, student contact information, student demographics and student course registration. This data is imported from authoritative sources via import or web services.

Features

Student lists by program, cohort, advisor. Student contact information.
Access to UW student transcript data.
Record of student placements
Record of teaching certificate recommendations to OSPI and certificate numbers
Degree milestone tracking for doctoral students including committee membership
Customized report views to support college workflows

Users

Faculty use STEP in advising their students.
OSS and Academic Support Team maintain local student data through STEP web interface.
Several programs including Teacher Education Program use STEP to track placements including student teaching and internships
Institutional Research uses STEP extensively for providing specific reporting to leadership and faculty and for required reporting in program accreditation.

Recruitment

The Recruitment database is an internal tool available to faculty and staff in the College of Education who work with prospective students. If you need access to this system, contact the COE Help Desk.

Website URL: https://education.uw.edu/recruitment/

Purpose

Recruitment database is a custom built customer relationship management system for COE prospective students. It stores contact information and prospect interests. The system provides tools for automated email communication based on interests. It also allows for one off custom email. The system has one main public interface, an About Yourself “Half Sheet” (named for a half page form we used to take to events).

Features

Public form accessible from main COE website where prospective students can add their own contact information and register interests with specific programs.
Email system for communication with prospects that supports templated messages and keeps a shared log of interactions.
Ability to create automated email communication campaigns based on prospect interests.
Ability to generate reports to use prospect lists in other contexts.

Users

Prospective students – About Yourself half-sheet is a public form linked from the main college website. It is regularly utilized we get about 20 prospects self-registering per week, rate fluctuating through school year.
OSS – Office of Student Services replies to questions asked by prospective students. Marty Howell works with Development office to plan automated email communications.
OMRR – Office of Minority Recruitment and Retention uses system to track and communicate with candidates.