MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for the ‘New Feature’ Category

Integrating MathJax

without comments

A feature commonly requested by markers was the ability to annotate student submissions with LaTeX like math. This has now been implemented!

 

Screen Shot 2015-04-10 at 11.38.45 AM

Anywhere annotations exist markers can enter LaTeX like math thanks to MathJax. When creating an annotation the marker just needs to surround the math in a pair of dollar-sign symbols. The entire annotation shown in the image above is:

should actually be $$\lt \frac 1 2$$

As would be expected, students also see LaTeX like math when viewing an annotation with math in it. This math rendering system expands (and reinforces) the utility of Markus for theory-based courses such as calculus, discrete math or linear algebra.

In addition to the MathJax integration, markers can now preview their annotation prior to submitting it.

Screen Shot 2015-04-10 at 11.51.07 AM

The preview functionality will help speedup the marking process for users unfamiliar with MathJax syntax. Instead of submitting an annotation, hovering over it and then editing it, markers can now preview exactly how their annotation will look once submitted. This also allows markers to preview rich HTML annotations with bolded and italicized text.

Written by Paymahn Moghadasian

April 10th, 2015 at 12:54 pm

Posted in New Feature

Creating A New Tagging Feature for MarkUs

without comments

Since the UCOSP code sprint that occurred several weeks ago at Mozilla, our development group for this semester has been assigned projects to work on. Nathan and I have been tasked to create a new tagging feature for MarkUs. This post has been written to serve as a Q&A for this new feature and to provide an early look into what this feature may look like from a user perspective.

Tagging Feature? What’s that?

Glad you asked! Essentially, this feature will allow TAs and administrators to tag student submissions based on certain criteria. This criteria could be things such as incomplete assignments, assignments that appear to be really well done, etcetera. The purpose of these tags will allow people marking assignments to then filter the submissions based on certain tags. For instance, say a TA only wants to mark assignments that have a certain tag. To do this, the TA can simply filter assignments by that tag and then only mark those assignments. Voila! It’s that easy!

Another use for this feature could be for TAs that want to notify a course administrator about a certain issue in an assignment. The TA can simply tag the assignment as needing further attention from an administrator. Administrators can then log in to MarkUs and filter the submissions to see if any have this tag.

What has been done so far?

Now onto the technical stuff! Currently, the models and controllers for the tagging system are being created by Nathan (which will not be covered in detail in this post) and I’m working on the views for this feature.

Probably the most important view would be the “Tag Creation View”. Here, administrators are able to create, monitor, edit and delete tags. The motive behind this is that administrators can create “pre-defined” tags for the assignment before marking has commenced. As of now, this view has been created but is not connected to the tag controller.

The new "Tag Creation" view for the tagging feature. Note the React table and sidebar upload and download buttons. Currently, the tag data being displayed in the table is just dummy data that is hard-coded into the view. Don't worry! This will change soon! MarkUs Tagging Feature - Tag Creation View

The new “Tag Creation” view for the tagging feature. Note the React table and sidebar upload and download buttons. Currently, the tag data being displayed in the table is just dummy data that is hard-coded into the view. Don’t worry! This will change soon!

Essentially, the tag creation view was designed to be as consistent with the MarkUs interface as possible. Basically, other views were looked at and used as a reference to create the view. Additionally, the code for the React tables in the student and submissions views were referenced to ensure similar structure. This makes the code more readable and easier to alter and upgrade in the future.

As you can see in the pictures below, the upload and download dialog boxes are also standardized.

MarkUs Tagging Feature - Upload

The “Download Tags” dialog. Note that the tag file can be downloaded as CSV or YML.

MarkUs Tagging Feature - Upload

The “Upload CSV” dialog. This dialog is very similar to other MarkUs dialogs.

What can I expect in the future?

This is where things get exciting (relatively speaking anyway). Probably the biggest goal is to actually get the views working and to be able to pull Tag data from the ActiveRecord. This will get a working prototype that Nathan and I can begin to refine.

Something that I am beginning to work on now is incorporating the tagging feature into the submissions view. In this, the React table containing all the submissions will have a new column named “Tags”. This will keep track of what tags are assigned to assignments and will allow administrators and TAs to filter assignments by tags. Additionally, in the grading view, there will be a new pane above the rubric panel that will allow markers to add and see current tags.

Currently, Nathan is working on the database side of this project. He is working on creating a proper model and controller for this feature. In the next few weeks, we will begin the process of integrating this model and controller with the view.

Where can I see updates for this feature?

This code is currently being held in the official MarkUs GitHub repository under the “tagging” branch. You can access this code here.

Written by Bryan Muscedere

October 14th, 2014 at 11:18 am

Posted in New Feature

Tagged with , ,

New feature: Summaries tab

without comments

I have been tasked to implement this new “Summaries” tab which is under “Assignments” and on the same level as “Groups”, “Submissions”, etc. It has a similar basic layout as the “Submissions” tab which is a table with functionalities such as filtering, pagination and sorting by columns. Each row in this table corresponds to a group; the columns are Repository, Commit date, Marking state, Grace credit used, Final grace, and grades for each marking criterion of the group. It serves as a detailed mark breakdown for each assignment.

While implementing it, I following the same logic for the “Submissions” tab for populating data, handling pagination and sorting. For the most part it works fine. However, I did come across two major roadblocks:

1. This is more of a difference to consider than a problem. Since I am displaying marks for each marking criterion, the number of columns is different across different assignments and it might change when the assignment rubric is changed. Therefore I need to dynamically display the criteria according to which assignment we are viewing. For the “Submissions” tab, since it only displays information that is common to every assignment, the number of columns won’t change.

2. Since now I have new columns, I need to implement new “compare” functions for them for the “sorting by column” to work. The way sorting and paginating works in the “Submissions” is as follows: The “compare” function for each column is coded in a constant hash in the Submission controller; when a pagination/sorting event occurs, the hash, along with other paratmeters, is passed to the handle_pagination_event helper function which handles sorting, and then pagination. The problem is I can’t store all the “compare” functions for the criteria in the same static fashion since the marking rubric may change and the corresponding compare functions required also change. In addition, since data in the criterion columns are of the same type (“mark”) and the implementation of the compare function should be identical except there is a unique mark id for each column.

 

The way I implemented it is that, hopefully following the “DIY” principle of Ruby on Rails, I created a single new compare function for comparing marks for a certain marking criterion. Instead of having two parameters (the two objects being compared), I have a third paramter, mark id,  for the compare function to get the desired mark. Then the two marks are extracted and compared according to the established logic. The whold picture is, the view generates table columns dynamically according to the rubric of the current assignment; when a “sort by criterion” event occurs, the corresponding mark id is passed along with other parameters and the hash which contains the new 3-parameter comapre function to the pagination helper function; the helper function executes the compare function to sort the data by this particular marking criterion.

 

While exploring other possible solutions, I have noticed that there are sortable table in Markus that are handled in a totally different way, namely the “FilterTable” javascript class. After reading the git wiki page of FilterTable, I found out that when the FilterTable object is created, the columns should be specified. Therefore it cannot handle situations where name and number of columns are changed dynamically. Moreover, it doesn’t seem to have pagination feature (it’s just a long table). I am by no means a javascript expert, so please correct me I am wrong.

 

The following are some screenshots of the Summaries tab:

(1) sorting by final grade as in the Submissions tab

Screenshot_sort_by_final_grade

 

(2) sorting by the first marking criterion:

Screenshot_sort_by_criterion1

 

(2) sorting by the second marking criterion:

Screenshot_sort_by_criterion2

 

Also I am relatively new to the Ruby on Rails world, so if you have any suggestions or better solutions, please let me know 🙂

 

 

Xiang Yu

 

Written by Xiang Yu

November 3rd, 2013 at 3:35 pm