130 likes | 146 Views
UC Berkeley Gradebook Mara Hancock & Josh Holtzman ETS Learning Systems SEPP Conference 06/25/04. Agenda. Project background and motivators Process Basic design principles Demo Technology decisions. Why A Gradebook?. Motivation Spring ’03 Symposium on large enrollment courses
E N D
UC Berkeley GradebookMara Hancock & Josh HoltzmanETS Learning SystemsSEPP Conference06/25/04
Agenda • Project background and motivators • Process • Basic design principles • Demo • Technology decisions
Why A Gradebook? • Motivation • Spring ’03 Symposium on large enrollment courses • Sponsored by Division for Undergraduate Ed, eBerkeley • Goal: To explore ways to improve teaching and learning in Berkeley’s large enrollment courses • Online gradebook seen as a quick win: • Offload some of the administrative burden of managing a large number of students, sections, and GSIs • Allow instructors and GSIs to focus more on pedagogy than admin • Increase communication with students regarding performance • Ease gradebook submission to Registrar through adhering to egrades standards and Registrar integration • Support from administration • Small eBerkeley innovation grant helped seed the project • Central funds to cover lead developer
Background and Context • Berkeley LMS Roadmap • CA budget crisis • Explore open source alternatives • Ways to integrate open source tools into CourseWeb system • Review open source Learning Management Systems • Sakai • Gradebook Decisions • Existing vendor systems not long-term solution (LMS Review) • No plan to upgrade, not integrated, not enough seats • Usability a problem in WebCT GB, Blackboard not enough functionality • No open source GB that met basic requirements was easily adaptable • Integration with Sakai and SAM critical for long run, but post-pilot OK • Staffing on Gradebook: • Juggling existing CourseWeb staff (SIS & ETS) + Lead Web Developer • Roles: ETS LMS Developer, SIS integration/security/AuthN, ETS Project/product manager, ETS UI designer
Process • Requirements gathering • Surveys, 20+ interviews with UCB faculty & students • Range of disciplines and class sizes • Functional requirements/specs • Vetted with faculty group • Technical alignment w/ Sakai • Technical specs for SIS integration • UI Development • Wire frames user testing • Prototype user testing • Application development • Gradebook, LMS wrapper • Fall Pilot: 13 courses, range of sizes, disciplines, grading practices • Sakai integration testing –> MIT convergence?
Online Grade Book CourseWeb Data eGrades Roster Sections Course Info Final Grades Pilot Next Gen CourseWeb (Sakai) Future Campus Portal
Gradebook Development Goals • Launch Pilot in Fall 2004 2) Integrate into Sakai when it becomes available 3) Don’t let #2 interfere with #1
Basic Principles • Design principles • Support for simplest faculty use case • Layered complexity • A few condensed views • Limited navigation • Lots of flexibility without overwhelming users • Double edged sword • Encourage faculty to actively engage in analysis and explore grading options • Toggle from roster to graph view • Auto-calculate teasers • Section management – various views • Grader, GSI, Instructor • Integration would be a driving factor to encourage usage
Demo time! UC Berkeley Gradebook Application as of 6/25/2004
Gradebook Architecture options As of 3/2004, very little of Sakai was available… • JSR-168 Portlet (deploy in Pluto) • CHEF tool • "Streek" (homegrown EJB/XML/XSLT framework) • Pseudo-Sakai
Pseudo-Sakai Option • JSF for the views and controllers • Hibernate for data access and persistence • Spring to provide lots of goodies • Wire together EJB and Hibernate data sources • Provide hibernate optimizations • Isolate the application from its underlying technologies
Challenges(1 of 2) • Learning Hibernate, Spring, and JSF as standalone technologies • JSF 1.0 released just in time (3/2004) • Spring 1.0 released just in time (3/2004) • JSF-Spring 1.0 released just in time (5/2004) • Integrating these technologies • Spring managed hibernate transactions • JSF vs. Spring managed beans • Working around current limitations • JSF tags in the Sun RI are not feature-rich • JSF in JSP
Challenges (2 of 2) • Balancing goal of Sakai interoperability w/ on-time delivery of the pilot application • Creating a rich UI with a 1.0 display layer • Required using JSTL with JSF. Painful, avoid if possible. • Developing an LMS tool outside of an LMS • Developing a thin “LMS Wrapper” to handle authN, user and group management, etc.