- putting final touches on release/2.8 of WeBWorK
- integrating the new user interface created by Peter Staab into the development branch of WeBWorK
This camp and previous code camps are supported by the NSF through a national dissemination grant to the MAA. ( link to www.nsf.gov once it is back up and running again. :-) )
The first outcome of the camp is an updated release/2.8 which we plan to merge with the master branch on December 1, 2013. We combined the original release/2.8 with most of the fixes and small features which have been submitted to the develop branch over the last three months. Both release/2.8 and the develop branch have been running smoothly under moderate course loads on the MAA testcourse site and on the hosted2 site at the University of Rochester. The activity devoted to release/2.8 over the next few months will be responding to bug fix requests, minor adjustments of features and general polishing of the instructor experience. Very little has changed in the student interface and there have been very few requests for changes in this aspect of WeBWorK. While not specifically adapted to mobile devices the student view of WeBWorK works acceptably well on iPhones, iPads and Android mobile devices.
Features of release/2.8 are listed on the wiki at: http://webwork.maa.org/wiki/Release_notes_for_WeBWorK_2.8
(You can type release/ 2.8 into the search box of the wiki to find it.)
You can also view all of the work involved in creating release/2.8, step by step,
viewing the commits page on github. https://github.com/openwebwork/webwork2/pull/182/commits
The most recent commits are at the bottom.
The will be more exposition about new features in release/2.8 (and some under advertised features of release/2.7) in subsequent blog posts.
It should be noted that LibraryBrowser1, although it has not changed its name, has received substantial improvements in release/2.8 from the work of John Jones. In general it should be much faster because some of the ajax calls used in librarybrowsers2&3 have been used to speed up rendering of individual problems on a library page. When enabled, the library page also allows for the easy tagging of library problems. (see http://webwork-jj.blogspot.com/2013/07/webwork-opl-workshop-charlottesville-va.html for more details)
The second outcome of WeBWorK::Rochester::2013 is the integration of a new AJAX/javaScript
instructor interface, largely created by Peter Staab at Fitchburg State University, which has been merged into the develop branch of WeBWorK. This interface provides instructors with behavior that feels more like a "google app" instead of the form based interface that we have been used to since the mid 2000's. Peter began work on this project during WeBWorK::Rochester::2012 held a year ago June.
One of the early outcomes was "ClasslistEditor3" which has been available as an option in both release/2.7 and release/2.8. The current version includes the ClasslistManager (renamed and improved from ClasslistEditor3) and HomeworkManager which combines the duties of the Library Browsers, the HomeworkSetsEditors(1&2) and the Instructor tools page. The HomeworkManager's library browsing functions are built on the experience gained from the prototype LibraryBrowser2 and LibraryBrowser3 which were written by David Gage. All of these tools have been available for testing in their embryo form on previous releases, but they have now progressed to the point where they can usefully speed up many standard instructor tasks.
WeBWorK::Rochester::2013 allowed Peter to explain in person his work and his vision to several of the other core WeBWorK developers. (Peter has not been able to attend any of the code camps since last June.) We now have a clearer idea of what has to be done to finish the transition. We were able to make significant strides in improving reliability during the code camp itself but much more remains to be done.
The net effect of using ClasslistManager and HomeworkManager is that instructors can manipulate classlists -- add students, change passwords, or homework assignments -- create, assign, etc. immediately. The updates of these changes to the back end server are done asynchronously and are invisible to the user.
At the moment the develop branch is fairly wild. Some actions don't behave as you expect or as they should; there are many features of the older editors and browsers that have not yet been implemented in the new interface. In some cases things that work fine on small sets or classes slow down drastically when the scale is increased. We expect that it will take many months before this develop branch is ready for use on a regular basis.
On the upside -- the student interface is not affected, and so far at least there is no affect on stored data. Since the old editors are still available one can simply switch to them for features that are not yet implemented and then switch back to the new "managers" for their added convenience on tasks where they work well.
One other thing we need to watch out for. The new javaScript interface will initially be a step backward as far as localization (translation in other languages) is concerned. We will be enlisting all the help we can for the translating effort but there is a lot of new and quite different code that has to be internationalized. Similarly we are concerned about whether accessibility is helped or hurt by the switch to interactive apps. We are using standard libraries, all of which are concerned with accessibility issues, but it will take time and we look for a lot of constructive feedback to preserve the gains in accessibility that we achieved between release/2.5 and release/2.8 and insure that these gains are not lost in this next release (most likely to be called WeBWorK3 ).
For those helping with development:
- submit bug fixes and small feature tweaks to the release/2.8 branch
- submit new features to the develop branch
In all cases make sure that your are in sync with the branch you will submit to before you
send a pull request. If the commit does not merge cleanly it will be returned for more work before it is even reviewed.
-- Mike
