This document summarizes the University of Illinois at Urbana-Champaign's transition to requiring freshman applicants to submit a Self-Reported Academic Record (SRAR) beginning in 2012. It discusses the reasons for moving to the SRAR, including staffing issues and administrative savings. It also describes the technical aspects of creating an online SRAR form and integrating it with the university's systems. Finally, it outlines the user experience, common errors, enhancements made, advantages, disadvantages, and verification process to check SRARs against official transcripts.

1. One Year Under Our Belt:
Self-Reported Academic Record
Session A4
Gregg Perry, Thomas Skottene & Nancy Walsh
Office of Undergraduate Admissions
University of Illinois at Urbana-Champaign

2. Agenda
• Introduction
• History
• Reasons for Moving to SRAR
• Technical Aspects
• User Experience/Common Errors
• 2013 Enhancements
• Pros/Cons
• Verification Process
• Summary
• Feedback/Q & A

3. Introduction
Gregg Perry
Associate Director, Recruitment
Thomas Skottene
Associate Director, Data Services
Nancy Walsh
Senior Associate Director, Operations

4. Historical Perspectives of the SRAR

7. S RAR TM
B a c kg round
• Self-Reported Academic Record
– Used by University of California system, Georgia Tech,
Rutgers, and others
– Freshman applicants self report their academic record
– Self-reported data is used to process & review applications
– Once applicants accept their offer, final transcripts are
checked for discrepancies

8. Why S R A R ?
• Staffing issues
• Large administrative savings
– 7,000 vs. 30,000+ transcripts, automation possibilities
• Enhanced Customer Service

9. S R A R Tim e lim e
• Trial Run, 2011
– All freshman applicants with international credentials & applicants from
Glenbrook North High School
• All In, 2012
– All freshman applicants required to submit SRAR

10. Technical Perspectives of the SRAR

11. H ig h L e v e l
Te c h n i c a l
•
C o n s id e r a t io n s
Easy to use
– Our applicants
– Internal users
• Integrate with our systems
– Banner – our Student Information System (SIS)
– eAdmitTM
• Volume/Load
– Handle current and expected future volume, including peaks around deadlines
• Security Concerns
• Utilize new possibilities
– Automation
– Transparency
– Archiving

12. Eas e of Us e
• The SRARTM is a web form
– Familiar Design
• applicants are used to it
– Flexible
• able to make changes quickly
– The Regular Application Form is also a web form, though separate
– Applicants need no special system requirements
• Some schools reported very old browsers and could not submit
– Warnings
• When applicants do something unexpected such as not filling in all four years for
coursework
– Errors
• When applicants make errors such as leaving required fields blank

13. U s e r Te s t i n g R e s u l t s
• Our initial approach was too process-centric
– i.e. what Admissions needed to get our process done
• Applicants will guess and make (false) assumptions if
they are not allowed to choose exactly what they
expect/want
– Drop downs have more options now
• Even if we internally strictly don’t need it
– Places for information we don’t really need
• Applicants will find a way to give it to us anyway

14. In t e g r a t io n w it h o u r
S ys te m s
• Banner
– Illinois has used Banner as our main university wide data repository and
student information system since 2003
– Banner is a 3rd party tool made by Ellucian (Previously Sungard,
previously SCT, etc…)
– Banner is housed and controlled by Central IT
– Gives Admissions very limited power over functionality and look and feel
• eAdmitTM
– eAdmitTM - Internal application processing system
– Workflow and data repository for most internal admissions processes

15. How It Was Before
Print out
Banner
relevant materials
(our Student Paper manila folder
Information
System)
Enter decision
back when
review was done
Online Web Other paper
Application Test Scores Transcripts
forms
Form
Electronic Paper

16. How It Is Now
Import relevant data
Banner
(our Student eAdmitTM
Information System)
Push back data
Online Web Other electronic
Test Scores SRARTM
Application Form forms
Electronic

17. S R A R TM
B a n n e r ( S IS )
•
In t e g r a t io n
Pulling Data
– Identity
• Login & PIN
• Pre-logged-in credentials
– Previous Schools information from application
• Push Data
– Academic calculations such as GPA
– Language Other Than English (LOTE)
– Pattern

18. S c re e ns hot of
B a nne r S ta tus P a g e
– With open SRAR link
Message box telling
applicants items are missing.
Link directly to SRAR form.
Pre-logged in.
No need for username or PIN
Self-Reported Academic
Record

19. Tw o S e r v e r s
Passes the Applicant’s
Identify Securely

20. V o l u m e /L o a d
• A very large portion of applicants procrastinate
and submit very, very close to the deadlines
• 10,000 applications in one week prior to November 1
• We received no complaints of slow or non-
responsive SRARTMs during the peak times

21. U n in t e n d e d
C ons e que nc e s
• The Urbana admissions office releases the decisions
twice a year
– Mid-December
– Mid February
• In the last two years the Central IT’s Status Page
crashed during the December decision release
• Admissions Status page stayed up
– creating an alternative way for users to see their decision

22. Tw o In t e r f a c e s

23. S e c u r it y C o n c e r n s
• Concerns
– Physical damage
• Fire
• Tornadoes
– Electronic break-in attempts
• None have been successful
• Solutions
– Data is backed up daily and in different locations
• Not possible or practical with paper
– Data is stored in a server room with heightened security procedures
• Our paper files were not as safe as we would have liked

24. A u t o m a t io n
• Identify matched based on application ID
– We now know which “John Smith” logged in
• Data as data and not text!
– Academic calculations
– Pattern analysis
• Aggregate information
– Number of As, Bs, Cs, etc.
• Sorting
– Subject
– Chronological
– By grades, requested

25. Tr a n s p a r e n c y
• Stored in database – not paper
• Audit points
– Who did what when?
• Users
• Tasks
• Date stamps
• Reporting
– Data as data
• Avg amount of As

26. Functional Perspectives of the SRAR

27. U s e r E x p e r ie n c e
• User-friendly form; dropdown menus
• Very important that applicants read ALL the
instructions
• Must have transcript with them when
completing
• More work, 60-90 minutes
• Can log back in to review submitted SRAR

28. C ommon Us e r
E rrors
• Ignoring directions
• Not entering senior year courses
• ‘Creating’ their own grades by averaging semesters
• Did not convert number grades to letters
• Entering all grades available (quarter, semester, year)
• Not entering grades at all when present on transcript
• Incomplete SRARs

29. 2 0 13 E n h a n c e m e n t s
• Tweaking directions
• Designated area for senior year courses
• Edit option in extreme situations
• Academic credentials site
• Internal view improvements

30. A d va nta g e s
• Easier application process for applicants &
counselors
• Applications complete much sooner
• Solved some staffing issues
• Automation of data

31. D is a d v a n t a g e s
• Need to get the word out better; received too
many high transcripts
• Applicants not following SRAR directions;
manual follow-up needed
• Some technical issues on applicants’ end
• Verification/rescind process?

32. Ve r if ic a t io n P r o c e s s
• Official final transcripts needed by July 10th deadline.
• If final not available by deadline, 9-11 transcript is required.
• Staff will verify transcripts against SRAR.
• Suspected embellishment will be reported to review chair. Poor senior
year performance will also be reported.
• Chair will review information & determine if offer should be
rescinded. Student will be notified if offer is rescinded.
• If no documentation is received by deadline, admission offers will be
rescinded. Students will be notified by end of July.

33. S umma ry
• History – why we moved to SRAR
• Technical – how was it created?
• Functional – how did it work from user &
Admissions perspective?
• Pros/Cons
• Verification Process

35. Feedback/Questions & Answers
Gregg Perry
gperry@illinois.edu
Thomas Skottene
tskotten@illinois.edu
Nancy Walsh
njwalsh@illinois.edu