Archive for the ‘New Feature’ Category
A feature commonly requested by markers was the ability to annotate student submissions with LaTeX like math. This has now been implemented!
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.
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.
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.
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.
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.
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.
The following are some screenshots of the Summaries tab:
(1) sorting by final grade as in the Submissions tab
(2) sorting by the first marking criterion:
(2) sorting by the second marking criterion:
Also I am relatively new to the Ruby on Rails world, so if you have any suggestions or better solutions, please let me know 🙂