A new Gradebook?
Some interest has been expressed from various institutions (UC Davis, Indiana, and Georgia Tech, among others) in taking another look at the Gradebook in order to reevaluate some of the assumptions that went into building the current user interface and services.
Requirements that have been brought up include the following:
- To redesign around user goals
- For teachers, to give them more intuitive ways to add data and calculate from it, but also to annotate in more freeform ways for their own purposes. Current pain points include:
- Complexity of setting up a new grade book, and
- Complexity of assigning evaluations for multiple students at once
- For learners, to get clearer and better information about their performance
- For teachers, to give them more intuitive ways to add data and calculate from it, but also to annotate in more freeform ways for their own purposes. Current pain points include:
- To reduce American-centric assumptions (which tend to be rigorously numerical, and involve large classes with only the simplest assessment workflows)
- To make it easier to handle large numbers of markable/gradeable items
- To make it easier to handle large numbers of students
- To make it possible to grade or 'mark' any Sakai entity without duplicating the score data
- That is, to make the Gradebook an appealing repository for mark/grade/score/evaluation data inside Sakai
- To build in an audit trail that other services/tools can take advantage of
- To expand what it means to grade or score something in Sakai
- To make the structure of markable entities more rigorously hierarchical
- To allow more flexible roll-up rule sets to work on those hierarchies
- To make it possible for institutions or even faculty to easily plug in alternative methods of score calculation or define custom rubrics
- To allow for arbitrary forms of feedback to also be stored as evaluation data (e.g. Post 'Em use cases)
- These might include comments or non-numeric/non-letter grade marks
- To allow for ranked or multiple graders on a single entity
- That is, so two or more instructors' evaluations could be averaged or summed (or using some other formula) to arrive at a final score, or
- So an 'instructor' mark could override a 'teaching assistant' mark, for example.
- To provide histograms or other reporting for both teachers and learners
This is based on a view of the current gradebook structure as a tree with the gradebook itself as the root, with 'final course grade' branches for each student. These branches then have sub-branches for each weighted category, and the leaves are the assignment grades themselves. Making this relationship explicit would eliminate the need for a 'Category' object.
Proposed Road Map (as of May 29, 2008)
Milestone 1 (M1) - Gradebook API Changes
There are a number of new feature enhancements we will need to make to the current Gradebook APIs before we will be able to deliver the new user interface.
for more details see Gradebook API Changes
Milestone 2 (M2) - New User Interface for Existing API
As part of this effort UC Davis has proposed to implement a new user interface that will run against the existing Gradebook API. The current thinking is that this work with be done using the Google Web Toolkit.
TODO: explain choice of GWT, alternatives, including RESTful JQuery/AJAX/JSON option
Milestone 3 (M3) - Strawman Interfaces for the new API
TODO: explain this
