OLM On Rails

Goals for the summer

with 2 comments

We are already two weeks into the summer and I haven’t published the promised set of goals for the summer.  This happened partly thanks to my procrastinating, and partly because Nelle, Mike, and Severin dove into the project with such vigour that I was afraid of holding them back.

Nevertheless, we need to keep our eyes on the goals:

0. Refactor the database schema and finish the refactoring from last term

This wasn’t on my original set of goals, but was identified on day 1 by Nelle, Mike, and Severin as the first step.  We did a big refactoring last term, and not all of the dead code was removed.  We are well on the way to completing this task.

1. Deployment.

This is the most important goal of the summer.  We plan to use OLM in the classroom in September so all decisions on features this summer will be based on whether or not they can be fully completed by September.   

The two things we are doing to work on this goal are that we will be meeting with Alan in the last week of  May to figure how to get an intermediate version running on our production server.  Hopefully if we spend time on this in late May and early June, we can iron out the system administration aspects of deployment.

Also, Severin is working on a test server that we can frequently update both to run tests and to use a demo server so that we can start to try out some of the new features on other instructors and students.

2. User permissions and visibility  

The roles (student, ta, instructor) exist in the code but we aren’t doing full checks to make sure that users can see only the views they are supposed to.

3. File submission backend

It would be really nice to use a version control system to store the student file submissions.  The current plan is to build an abstraction layer for file add, delete, replace, and view.  This will allow us to build 3 versions of the backend: an in-memory store for testing, a file-based store for simplicity and completeness, and the desired SVN store.  There are a bunch of design issues here that are unresolved.

4. TA mapping

The view that allows an instructor to attach TAs to the groups that they will mark is incomplete.

5. Administrative interface

This version of OLM includes a web interface for the instructors to do all the setup for an assignment.  This includes assignment setup, group formation, rubric creation, downloading data (grades, annotations, files), and probably a few other things.  We haven’t put any thought into the UI for this yet, so that’s on the list.

6. Grader view

This view is mostly complete, but it needs to be tightened up and made prettier.  Undoubtedly, it needs more testing.

7. UI design

We’ve spent most of the effort so far (with a few exceptions) on the back end, so we have lots of work to do on the UI.  Fortunately, we will be able to work with a Season of  Usability student on this part of the project.


No list of goals would be complete without a list of the new feature that would be nice to have.  I’m not sure how many of these we will be able to get to, but I’m hoping we can get a few of them in.

  1. Logging: I’d like to be able to log all events and display them to the instructor.
  2. Metrics:  I’d like to be able to display graphs and different views of the data we collect such as mark breakdowns, histograms of marks, number and length of annotations, number of submissions per group, etc.
  3. Mark entry:  If OLM becomes really useful, it would be nice to have a view to use to enter grades from another source such as lab marks or test marks.
  4. Another marking scheme:  The rubric approach has proven to be pretty flexible, but it would be nice to have another way to specify a marking scheme.
  5. Automated testing:  This one is the highest priority long term goal.  I don’t think we will get to it this summer, but I would like to be able to allow students to submit their code, and receive immediate feedback from an automated system. 


Written by Karen Reid

May 22, 2009 at 1:13 pm

Posted in Uncategorized

2 Responses

Subscribe to comments with RSS.

  1. Paul thinks that it would be nice if students could upload a whole directory of files, but that they don’t necessarily need to be able to upload a hierarchy of directories.


    May 22, 2009 at 3:58 pm

    • Would be very useful, indeed! We might run into some problems with that, though: IMHO file uploads via HTTP only work for single files. It isn’t possible to upload a whole directory that way (I think). A common workaround for this is usually to create some kind of archive containing the files to be uploaded (bulk-upload) and have them “unpacked” server-side.

      Say, we would implement this feature and the archive format would be ‘zip’.

      What happens when it is required – or some students decide – to upload a ‘zip’ file as part of an upload? Maybe we could circumvent this problem by requiring a very particular file name (e.g. ‘multiple_file_upload_archive.zip’) for an archive which should be handled as a ‘bulk-upload’?


      May 22, 2009 at 11:15 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: