UI Effort Analysis

Effort Analysis for User Interface changes

Summary of Pages

Legend

1. 

   #Course Multi-Grade

2. 

   Gradebook Items

3. 

   Gradebook Items Grade Single Item All Students

4. 

   Gradebook Items Grade All Items Single Student

5. 

   #Grade Report for Student

6. 

   Roster (All Grades)

7. 

   Course Grades

8. 

   #Gradebook Setup

9. 

   Course Grade Options

10. 

    Import Grades

Strategy

In summary, of the existing 9 "pages" in Gradebook, we are proposing the extensive modification of 2, the elimination of 5, and the addition of 1 to replace most of the functionality in the ones being removed. This should greatly improve the user experience of Gradebook and simplify all of the day-to-day tasks it involves.

Given how extensive our changes are, we have to make a decision as to whether it's going to be worthwhile to modify the existing JSF webapp or if we can accomplish our goals more efficiently and effectively by bringing in a new framework. We have decided to go ahead with a new UI. Currently, our best guess is that this will be implemented using the Google Web Toolkit (GWT). There is a remote possibility that we might have to step back from this and implement using JQuery to build dynamic html pages that talk to the server through AJAX over a JSON data transport layer. This is the more "home-grown" version of the same solution we'd like to put into place using GWT.

We may want to take into account the following considerations:

• How can we integrate our changes so they do not negatively impact schools that wish to continue to use the existing functionality in its current configuration?
• Also, how easily can we convince the community to merge our branch changes back into trunk?
• What is the complexity and development cost for developing in JSF versus a newer framework?
• What are the performance implications of each strategy? using GWT or JQuery.

If we decide to go ahead with a new framework, then:

• What kind of support is there within the Sakai community and the larger Open Source community for the framework we choose?
• How rapidly can we replace existing JSF functionality in this new framework without introducing new bugs?

Detail of Page Changes

Course Multi-Grade

The Course Multi-Grade page is a new interface on course grading that allows an instructor to grade an arbitrary number of items for a collection of students (either all students in a site, or some smaller section or group within that site). There is already a read-only view of this data that is currently identified as "Roster" or "All Grades" (depending on version).

It reproduces/replaces the functionality of the following pages:

• Grade Item Single Item All Students : since Multi-Grade allows an arbitrary number of assignments to be selected, selecting a single assignment produces the same exact view
• Course Grades : in addition to viewing any given assignment, multi-grade will also provide read-only and writable views of the final course grade
• Course Grade Options : included on the Multi-Grade screen is a read-only view of the course grade options, so giving this a toggle to make editable would be a logical extension
• Roster (All Grades) : since this is just a read-only view of the same data, assuming that Multi-Grade provides a clean read-only view, an export function, and a search function, roster becomes unnecessary and redundant

The following components will need to be developed:

1. #Grade entry table
2. #Grade item chooser widget
3. #Course grade entry options widget
4. #Course statistics chooser widget

Grade entry table

The minimum requirements for this data table/grid control component are as follows:

• Data provider only looks up objects for the selected column fields per row
• Data provider pages correctly with minimal hits on db and user selected page sizes
• Toggle any given column between editable and read-only
• Columns are sortable
• Full data set is searchable
• Full data set is filterable

Some additional functionality that would be nice to have:

• Interim user changes stored either directly in db or in some intermediate cache in case changes are not saved before session timeout or if the user pages forward without saving
  • This would allow the tool to notify the user if a version of the changes was not saved and prompt for correct action (as Confluence does, for example, when you leave the page without saving)
• Toggle any given column to hide or show
• Allow for updates without reloading the entire page
• Toggle any given column between editable and locked; that is, each column could have three states: editing, read-only, read-only locked

Grade item chooser widget

This widget is fairly open-ended... we don't have a good template for something like this. It's important to the use of this page as a whole that this widget is well-designed and quickly allows the instructor to choose from the full list of assignments/grade items rapidly. Most like some kind of a tree view that allows categories to be toggled open or closed would be best, maybe with checkboxes to indicate which items are currently selected for viewing.

Course grade entry options widget

This widget will basically replace the functionality of the Course Grade Options page. It should be read-only initially with an ability for the instructor to unlock and edit any individual field. Ideally these edits would cause immediate re-calculation of the final course grade displayed in the grade entry table. This whole widget should probably be hideable to give the instructor more screen real estate for the grade entry table.

Course statistics chooser widget

A fairly simple set of checkboxes should be sufficient for this. As with the widget above, this whole widget should probably be hideable to give the instructor more screen real estate for the grade entry table.

Gradebook Setup

By developing a hierarchical view of the category data that includes assignments (grade items) we give a more coherent structure to the user experience.

This will reproduce/replace the functionality of:

• Gradebook Items : adding/removing/modifying gradebook items can now be done inside this page

The following components will need to be developed:

1. #Grade release options widget
2. #Hierarchical category and grade item table

Grade release options widget

This is just a collection of checkboxes to indicate whether released Gradebook Items are displayed to students and which statistics are visible.

Hierarchical category and grade item table

The minimum requirements for this data table/grid control component are as follows:

• Hierarchical structure to depth of 2, with each top-level category row nesting a grade item table
  • Toggle open/close icon to display or hide this table for each row
• Textbox columns
• Checkbox columns
• Action button columns
• Drop-down select columns
• Clickable 'Add a Category' row in top-level table
• Clickable 'Add an Item' rows in nested tables

Some additional functionality that would be nice to have:

• Drag-n-drop movement of grade items between category rows' nested tables

Grade Report for Student

The major change intended for this page is to provide certain statistics, and charts/graphs of those statistics to the student should the instructor request it. These statistics would be selectable from the Course Multi-Grade page.

There are two chunks of work here:

1. Calculating the numbers themselves
2. Displaying the numbers in charts and graphs

We will most likely need to bring in some kind of charting library to accomplish the second objective.