Consolidate student reg capabilities

[pricem]

We've talked about this for a while but I want to get in Github, especially since I will be recommending for Joel to spend some time on this as his next medium-term project. This ticket can serve as an anchor for discussion although we may use e-mail as well.

We have 3 program modules for student registration: StudentClassRegModule, LotteryStudentRegModule, and StudentRegTwoPhase. These have been implemented at different times, and use relatively different design approaches. The latter modules use Javascript to different degrees.

I (and others) have proposed that we unify the underlying capabilities of the modules, so the best features of all three can be used across all chapters (regardless of whether they are doing a lottery, and what front-end interface they want). This may mean that there are still different program modules but, for example, you can use searching/filtering of the catalog even during first-come first-served registration. We get asked for this occasionally; for example, in Jordan's e-mail about feedback from students of MIT Splash:

One thing that was said was that the students still want more options for
catalog filtering. I think they might like filtering in the normal catalog,
outside reg, and I think they said they want to be able to only show the
categories they really care about (I thought we did implement that, but I
can't remember). I can't remember if they said anything else about this.

This may involve some of the following:

• Identifying a common set of JSON APIs that supply the needed information; implementing these APIs; modifying student reg views to use them. (Potentially we could use 3rd party libraries to improve/simplify the json_fetch framework.)
• Creating student reg views that can handle the different modes of registration we offer (lottery vs. FCFS, single vs. multiple priority classes), or at least making them require as little extra code as possible.
• Tweaking the front end to make things more usable.
• Making sure the performance and browser compatibility of these views is acceptable.

We should discuss what is the best compromise between effort and outcomes.

See also #564, #565, #65, #439, #438, and (for general ideas people have had about improving student registration):

• http://wiki.learningu.org/GSOC_Ideas#Redesign_student_registration
• http://wiki.learningu.org/Website_Design/StudentReg

[lenaqr]

Note: StudentRegTwoPhase is supposed to provide a Javascript-based filterable catalog. The problem is that the usual way to close the lottery is to disable the module, which also disables the catalog view.

[pricem]

Joel and I have started to think through this in more detail, and (in order to develop specifications for any code changes) he suggested that we come up with a coherent set of "stories" for what features should be possible from the user's perspective and why. Please add your own comments if you are interested: https://docs.google.com/a/learningu.org/document/d/11m5NMTCnwaZtPBcYy4oWsbxzQQ1iDQ_R4MAapAg1Llc/edit

[pricem]

Thanks Tej for adding the chances of enrollment into the stories. I also noticed we left out the distinction between "1-phase" and "2-phase."

Joel and I talked and we figured that it would be reasonable to start out approaching this from the viewpoint of: what functionality would have to be added to the two-phase module to make it useful for all modes of registration? Towards that end, some of the relevant code for the 2-phase module (besides the Python file itself) is in:

• Templates:
  • esp/templates/program/modules/studentregtwophase/mark_classes.html
  • esp/templates/program/modules/studentregtwophase/rank_classes.html
  • esp/templates/program/modules/studentregtwophase/view_classes.html [note that these all inherit from catalog_new.html in the same directory]
• Javascript:
  • esp/public/media/scripts/catalog-new.js (anywhere else?)

Anthony and/or Tej, feel free to mention if you have any other suggestions for where the most important code is, or how to best consolidate the student reg capabilities we have.

[lenaqr]

Also the styling, esp/public/media/default_styles/catalog-new.css.

Also, there are several tickets (that should all have the "Two Phase Lottery UI" label) reflecting some of the student feedback we got during Splash. It sounds like some students did prefer the old lottery interface, so maybe it would be valuable to support different "modes" of registration available to students at once (although I'm not sure how that would work).

[jmoldow]

I added a story for class changes.

[ghost]

Moving forward with merging the core student registration functionality, I've create a list of action items that should cover most of the work to be done(at a high level) for this portion of the project:

https://docs.google.com/spreadsheet/ccc?key=0Ak3V9kd77TjjdHhUUkhIVWVoY1ltelptTDFyeUdtY0E&usp=sharing

I will be starting with item: ""Merge template commonalities between student_schedule.html and studentregtwophase.html" and will likely create a generic template that incorporates the functionality.

[lenaqr]

Oh, another concern to be aware of with the current KnockoutJS-based 2 phase interface is that the client-side logic currently performs rather slowly with large programs on old computers. MIT ESP generally includes a link to the "classic catalog" from the JS-based catalog, for this reason. There are some hacks to make it "seem" less slow (e.g. manually adding delays so that it doesn't hang the whole browser while it's constructing the page) but it could still be improved, in terms of either actual or perceived speed.

[pricem]

Joel has started work on implementing things in the main_jlegris branch.

[benjaminjkraft]

This would be a really useful thing to have a better handle on -- what's the status on it?