Archive for the ‘User Interface’ Category

After several weeks, the first prototype of the tagging feature has been implemented. While the views for this feature are not final, this gives an idea of what the final product may look like. In the next few weeks, Nathan and I will be hooking the tagging views into the controller and model.

Feedback on the new views is very much encouraged! This is still a work in progress. Without further ado, here are some screenshots of the views.

The Tag View:

As shown in the previous blog post, this is the Tag view. This view is used for creating and managing specific tags for an assignment. The user is able to add, edit or delete tags and see the tag usage across assignments.

The Submissions View:

From here, we now have our Submissions view. Notice the new column in the submissions table for tags. This will hold all tags assigned to that submission.

In the submissions table, when the user puts their mouse over the Tags column, a dropdown appears featuring a search bar to filter by tags and a list of tags that they can filter by. To make the dropdown concise, only the five most used tags will be featured in the list. Others can be accessed by searching for them.

Individual Submission View:

In the individual submissions (Review) view, a new tag tab has been added to the right sidebar of the screen. In it, TAs will be able to add and remove tags from a current assignment and also see most used tags. Admins will have the additional ability to add or remove tags as they see fit.

There you have it. As always, feel free to check out the tagging branch of the MarkUs repo and again, feel free to suggest any improvements that you have on the feature.

React is a JavaScript library for building user interfaces. It’s used heavily in production in both Facebook and Instagram (Facebook created React), and in my opinion is an awesome tool for building front-end interfaces.

The work I’m currently doing on MarkUs involves re-implementing, using React, the sortable, searchable, and filterable tables used for listing users and managing groups, graders, and submissions. This is a prime target because 1) the previous tables used a library that depended on Prototype, which we are trying to move away from, 2) these tables can be really slow, since the html for each row is rendered in the backend individually, and 3) the previous tables became messy enough (_boot.js.erb files and construct_xxx_table_row methods) to warrant a rewrite. Also because 4) React is awesome. So let’s go into how React works.

React, at its core, is a library for creating components: functional, reusable, and composable web views. It also manages to let you do this in an extremely simple fashion.

Each component has two objects: this.props and this.state. Props are generally for holding immutable data, while state holds mutable data. In a sortable table, for example, the titles of the columns would go into props and the currently sorted column and sort direction would go into the state. A component then defines a render method that is functionally pure; that is, given the same props and state, the output will always be the same. The render method also cannot cause any side effects.

Now, when React detects a state change of any kind, it’ll quickly re-render diffs for the new DOM based on the render method. Managing state suddenly got a lot easier.

Here’s an example from MarkUs: StudentsTable, which is the React component that defines the listing of students in the Users view. StudentsTable has two pieces of state: students, which is the array of student data that will be used to fill the table, and selected_students, which is an array of student ids that represent the selected students (duh) for doing actions on.

The render method then defines some column and filter objects (based on an ad hoc protocol; column objects have boolean attributes such as sortable and searchable while filter objects define a test for each object). Then it returns a div (really a React DOM object: React uses a virtual DOM) containing two other components: an ActionBox and a Table.

Here’s some demo code for StudentsTable:

StudentsTable = React.createClass({

getInitialState: function() {

// Sets this.state.students to

// what the backend returns

jQuery.ajax({

method: 'GET',

url: ...

dataType: ...

success: ...

});

},

render: function() {
// this stuff could and maybe should actually be moved to props

Now, StudentsTable will pass down selected_students to ActionBox, which will receive it as props. This may be a little confusing since selected_students was in state originally, but it doesn’t matter. ActionBox doesn’t know, and ActionBox doesn’t care. Its render function should account for both state and props, and in fact it helps to think of selected_students as immutable, since what ActionBox really needs to be worrying about are things like the dropdowns and the grace credits input and managing that stuff.

We can see that the data flow is kept one-way: StudentsTable, as the parent of the ActionBox, doesn’t know about the state of the ActionBox, nor does it care. If you really needed to know something, like when StudentsTable should request new data, you can create a hook by passing down the refresh method as a prop and have ActionBox call it whenever it needs to. But in general, it’s best to keep upward data flow as minimal as possible.

The base Table is its own component with its own subcomponents like TableFilter, TableSearch, and TableHeader which may or may not have their own subcomponents. But these parts all work in the same way; they’re just smaller parts. This way, React makes reasoning about a specific level in the view hierarchy a lot simpler since everything is compartmentalized and data flows only one way. Consider implementing the same thing in jQuery or Prototype: it would probably require a crazy amount of reasoning about state (of which the size is huge — blame combinatorial explosion) and DOM manipulation.

In conclusion: React is dope. Its power comes from its means of combination and abstraction (sup Sussman). Check it out here.

The developers of MarkUs use GitHub’s issue tracking system to handle all the bugs floating around our application. It is a very useful system for maintaining current and old bugs, requests for new features and represents the overall state and goals of MarkUs.

Unfortunately, our users do not have the chance to see this unless they try hunting it down themselves. I’m currently working on a feature to point our users to our bug tracker, providing them with easy access to the ability to view and report bugs at their convenience. Here is some sample UI that I’m brainstorming. I’ve come up with some rough drafts of UI that I will most likely use.

The Header

I’d like to add an icon that is placed in the header, providing users with access to it no matter which page they are viewing.

The Popup

Once the icon is clicked, a modal dialog will open, disabling the rest of the webpage. The user will see the following options.

View current issues will point to the bug tracker. Reporting a new issue will point them to a blank issue form and requesting a new feature/enhancement will point to the same form but with the RFE label set already. All of these links will open new tabs and redirect to our tracker accordingly.

Drawbacks

In order to file issues, you will need to have a GitHub account. Users might not be bothered to sign up (or even sign in), making this feature practically useless to them. Unfortunately, there is not much we can do with our given resources. Forcing them to use our tracker will help keep things centralized and in one place, rather than setting up some kind of form that sends out emails to mailing lists with the given bugs. Fortunately, the links redirect to logging in or creating a new account and then redirect back once done. If the user is willing to follow through, the login process is just a small, extra step and places the user back on track.

Another issue is the potential increase in duplicate bugs. Some people do not have time to read through our current issues and may just jump straight to reporting one. This is not too disruptive but adds to a teadious process for developers now having to close duplicate issues. I am hoping that the “View current issues” link will nudge users in that direction first but that will not always happen.

Finally, some issues are not in the application but in the way it was setup. These need to be directed to the course admin rather than to us. However, this is not always obvious so adding this feature might also cause an overflow of unnecessary bugs. This can be avoided by only displaying the links in the dialog when the user is an admin. When a grader or student is logged in, perhaps a simple message telling them to contact their course administrator/instructor might suffice.

This is what I have come up with but I am open to suggestions, please nitpick, modify and comment away!

Here is the UI for Role Switching that I developed. I made the design to be similar to that of the login screen though there were some changes. The changes I made was just so that the UI for role switching is not confused for that of logging in.

The option to switch roles added for admins to the top right of the screen

The UI for role switching added to the right of the screen

The view of the UI in the browser

The screen displayed after the admin with first name “admin” switches role to student c5anthei

Error Messages:

The error messages are a mirror of the ones for login

Error message displayed when user name and password fields are blank

The password field was blank

The user name was invalid

Input about the quality of the work and some error cases that I might not have considered will be appreciated.

I am currently working on ways to display the mark summary during remarking and after remarks have been completed.

This is what the instructor view currently looks like:

And this is what the student view looks like:

I am having trouble deciding on my own how the summaries should be laid out. In my opinion, the current views seem a bit cluttered and messy, but I haven’t come up with good ways to show this information. The highlighting of the old mark when remarking also seems a bit awkward to me. I am wondering if anyone out there has any suggestions that would make this look better? 🙂

Some ideas I had:

– Separate Remark Summary tab? We wanted to be able to compare old vs new marks on the same page though..

– Collapsable information for old marks? Old mark info would show only if user clicks on or hovers over a button.

MarkUs 0.9.3 fixes a nasty little bug that prevents students from viewing their test results. If your students have been complaining that they can’t see their test output, well, this is the release for you.

Or, if you’re running 0.9.2 and want to patch up – download the patch here (you’ll want to apply sequentially). It’s short, sweet, and shouldn’t require any special configuration. All wins.

Misa and I have been thinking about ways to implement the remark request feature. These are a few screenshots of our initial design.

When a student wants to request a remark, he/she will first click on Request a Remark at the bottom of the source code. This will create a new tab ‘Remark’ on the right side where the student can make their case about a remark. Students can save, submit, or delete the request. Once a request has been submitted, it cannot be modified unless a student deletes and makes a new request. Instructor instructions (specified when they create an assignment) will also appear in this tab.

When a student submits a request, their assignment gets a new marking state ‘remark’ with a new icon in the instructor/TA view. Then the instructor/TA can start modifying the students grade.

This view was trickier to design because we want graders to be able to see the student’s justifications, their old marks, as well as new marks. For now, we have decided to keep the two tabbed sections and have old marks are highlighted in yellow while allowing the grader to click and assign new marks. (We still have to work out a way for instructors that use manual rubrics). The grader also has space to make his/her comments.

After the instructor completes and releases the student’s mark, the mark breakdown and summary for both the instructor and the student will show the changes that have been made.

Well, this is basically how the remark interface will work. I think there can be improvements, especially on the grader view, but we haven’t been able to think of an elegant way to show all the information at once. If anyone has any ideas or suggestions they’d like to add, please comment!

Hora and I have been experimenting with a number of possible options for graphing data in MarkUs. We have narrowed down our options to two javascript frameworks and are going to use this blog post to solicit input from the Markus community.

Highcharts

Highcharts is a commercial javascript graphing library. However, they have released their software under a creative commons license for use in non-commercial projects. Additionally, lazy_high_charts is a rails plugin which allows for simple integration of highcharts into rails projects.

Samples

Pros

Thanks to lazy high charts, most of the programming can be done in the controller. This leads to cleaner code.

Graphs are very attractive, animations are professional.

Dynamically hide single items in a chart. Example, don’t show one of the TAs.

Lots of options for creating charts

Great documentation

Cons

Built on JQuery. Markus uses Prototype which can have conflicts with JQuery. In the few tests we’ve done several javascript errors were reported.

As a commercial product, we are unsure about the future possibilities for use. Licenses can change.

Bluff

Bluff is a JavaScript port of the Gruff graphing library for Ruby. It is pure javascript and has no conflicting dependencies.

Samples

Pros

Small javascript files, with no dependence on JQuery.

Easy to generate graphs quickly.

MIT License, so no conflicts with Markus.

Simple, attractive graphs.

Cons

Code must be written in Javascript. This means that most of the work will be done in the view, which creates ugly code. If we choose this path, a set of ruby helper methods (or a rubygem) could be created to clean up the code.

More simplistic than Highcharts.

API exists, but doesn’t provide a lot of examples.

Conclusions

Both graphing methods work well. Highcharts produces a cleaner code base but has some implementation issues and is (sort of) proprietary. Bluff is completely open source but will involve embedding javascript into views (or partials). If anyone has opinions either way please sound off in the comments.

We met up with Karen last week to discuss what she had in mind, and iron out some issues such as where what goes and how. We want the students to be able to request for re-marking but not make it too easy to request. We also want them to be able to edit their request until their assignment is actually in the re-marking stage by the prof/TA. We want profs to be able to comment on the re-mark request, as well as save original marks.

Our next steps over the course of the term are:

1) Figure out what is and isn’t possible to do GUI/feature-wise (i.e. familiarize ourselves with the existing framework and GUI)